Random stops

[ger21]

Running the 1.2037 Test version. UC300 ETH
Yesterday was the first time I actually controlled a stepper with UCCNC, and was also the first time I've noticed this.
Occasionally, within a few seconds of starting the g-code, UCCNC stops, and rewinds the file, with no error messages.
It acts exactly like a stop, and rewind. The spindle turns off, and the g-code is rewound back to the beginning.

It seems to happen most often the first time I run a program, but not always. And once it happens, it doesn't appear to happen again until I load another program.

But it's very random, and with seemingly no errors, probably almost impossible to track down?

Just wondering if anyone else has seen this?

[A_Camera]

I have been using this version since it has been officially released and not seen this issue. I hope it is just your system or the fact that you are using a test release.

[cncdrive]

Could you please post a g-code file with which this sure happened at least once?
I will try to reproduce the issue then.

[ger21]

It's happened with every g-code I've tried, including the SimpleSpiral.tap. When it happened, it seemed to stop at the end of the first or second move, maybe? It always stopped within a few seconds of starting. I never saw it stop when it was running longer.

If nobody else has reported this, don't worry about it right now.

I don't have time now, but I'll try to do some more testing later in the week and see if I can find anything else.

[ger21]

OK, I've managed to duplicate this, and have found a way to repeat it.
I had the g-code loaded, and had changed the velocity of the one motor I have connected.
When I went back to run the code, it happened.
I ran the g-code a few times, and then went in to change the spindle on delay, and it happened again.
At that point it dawned on me that changing the settings was causing it.
I went back and changed the delay a few times, and saw it happen some more.
So, I grabbed my camera, and it happened twice, on the first try.
It seems to run 2-5 lines of code, then return to the place it started, stopping, and rewinding the g-code.
Although the second time in the video it runs a few lines longer.

http://www.thecncwoodworker.com/downloads/uccnc/bug.mp4

After it stops, it'll run fine, until I change a setting again.

[mphel]

Just for info, I can reproduce this by simply hitting "save Settings" once a file is loaded regardless of whether any settings were actually changed.

[cncdrive]

Gerry, thank you for the video.
I've tried to replicate this, but it seems I can't. Will try on my other PCs also soon.
Meanwhile can you please check if you can also reproduce this in demo mode?

And I think I will send you an .exe soon which creates a log file which will let me see a few things about what is exactly happening.

[ger21]

Yes, I can get it to do it in demo mode, but only on the laptop that I've been testing with. I couldn't duplicate it on my main PC at my desk.

One thing I noticed. In Demo mode, it runs much slower, and I noticed that it's jumping to the last line of code, which is why the spindle is stopping, and it's rewinding.

[ger21]

And an unrelated question. In Demo mode, when I save settings, it resets my velocity as if the kernel frequency was ±25Khz. With a steps/unit of 6400, it changes my velocity to 222.###
You also can't change the kernel frequency in Demo mode.
Not sure why this is, but if you make any changes while in demo mode, it can mess up some of your settings. There should be no restrictions like this while in demo mode.

[cncdrive]

Gerry, I've uploaded a text .exe here: http://www.cncdrive.com/UCCNC/UCCNC.exe

Just replace the original UCCNC.exe file in your folder. Do not rename this file, the filename must be UCCNC.exe when you running it.
And this will only work with UCCNC version 1.2037.

What the test file do is it creates a log.txt file in the UCCNC directory and the file is recreated every time you run the software.
What is written into the log file now is when the Cycle is started with the Cycle start and then all the movement IDs are written into the file.
The content is flushed and the file is closed only when you close the software.

So, what I would like to ask you is to please run the software and reproduce the issue and when it was reproduced, when it rewinded the g-code file and stopped then close the UCCNC software and upload the log.txt file to let me see it's content.
Based on what will be in that file I can decide if the issue is in the UCCNC or in the API part and then we can go on with the debugging from there.