Restart program from any point of the Gcode line

[shad]

Hello Balazs!
My customers report that there is still a problem. The issue very stable.
UCCNC version 1.2044, UC400ETH controller.
I am attaching cutting program and link on the video. https://www.dropbox.com/s/kbn5kgpvycio3 ... c.mp4?dl=0

test uc2.rar

This is the program file

(604 Bytes) Downloaded 834 times

[cncdrive]

Hi Andrew,

What is not exactly clear to me is how the code execution is going, because you have your own screenset, so I'm not sure how you executing the g-code file.
Are you executing with single line or you executing with the normal Cycle start and then removing the THC on signal?
Can you please explain this to me a bit to let me understand how you doing it...

[shad]

Operator open cutting program and click on the START button - code start. On the M3 controller make IHS, arc transfer, pierce and then send to the UCCNC THC ON signal. machine start profiling on the XY plane.
On the arc lost issue controller turn off cutter, send to the UCCNC arc lost signal. Then plugin store current positionб line number and turn off THCON signal (UC.Callbutton(537)). XY motion stopped with deceleration.
Then operator start cut recovery procedure. The procedure make (simplified version) :

Code: Select all

 
UC.Callbutton(130); //stop program
UC.Setfield(true, (double)line_number, 866); //set line
UC.Validatefield(true, 866);
UC.Callbutton(169); //set next line
UC.Wait(100);
UC.Codesync("M205"); //turn on thc
UC.Codesync("M3"); //turn on spindle
UC.RemoveRunfromhere();
UC.Callbutton(128); //start button


Controller make IHS, arc transfer, pierce and then send to the UCCNC THC ON signal. machine start profiling on the XY plane.
This is the sequence of actions.

[shad]

I am forgot - after

Code: Select all

UC.Callbutton(130); //stop program

plugin initiated G0 move to the arc lost position, then plugin set arc lost code line.

[cncdrive]

Hi Guys,

I think I figured out what the problem is.
You might remember a previous issue corrected earlier that when the g-code execution was stopped with a cycle stop and the motion stopped at the very end of an arc then the next Cycle start made a full circle, because programmatically that ment a full circle when the stop point was on the end of the arc, so the software made a full circle. This issue was corrected, we added a protection that when the motion ends at the very end of an arc then the API increments the g-code line pointer ID with one, so the pointer points on the next g-code row, so the next cycle start did not cause a full circle.

I think the same issue is happening on your video, the difference is that it is in regards the torch on signal loss when the motion stops when the arc gone and then the software moves the torch back to the stop point and I think the problem happens when the arc gone when on the very end of the arc. This is the same situation as the previously corrected issue, but happens from a different cause and I think we did not add a protection against this.
We will investigate this further and if this is the cause of the problem then we will implement the same protection...

[cncdrive]

Hi Andrew,

We further investigate this issue and we think that the problem is probably not what I thought about yesterday evening.
We think that the issue is how you handing the arc lost recovery.
I think that what you do is you read the arclost position in the wrong timing, I mean you probably read the arclost position too early, before the motion actually stops,
so what arclost position you get is incorrect, too early, because ofcourse what you can read on the PC side is not the very realtime position of the actual coordinate,
but a few milliseconds earlier data, because the controller sending the data to the PC but the same time there is still motion.

So, the question is when you reading out the coordinates and the line ID in the lost arc situation?
I think you reading these out too early, because the motion controller moved back to arcloss point.
You should read these out in the stationary motion stopped state, in other words when the arc went off and the motion stopped.

I also see that your recovery function moves the position, why is that? Based on what do you adjust the position? I mean when your recovery windows shows up and the user OKs your window then I can see a movement on your video. So the question is why is this movement and what coordinates do you move, where do you get this position date?
The issue seems to be that you adjusting the position to the end of the arc and the line ID is set to the arc which end you standing at, so when you cycle start then it means a full circle.

[cncdrive]

Hi Andrew,

We again further investigated the reported issue and it is now sure that the issue is not what I thought, because the protection is already there in the code for the scenario which I've mentioned, so when the machine moves back to the exact endpoint of an arc then there is the protection, that the next line ID will be given back by the API in the stationary stage.
So, the issue has to be in the sequence of recovery in your plugin, probably you reading out the arc stop position and line ID too early, before the machine moved back to the arc lost position and actually stopped.

[shad]

Hello Balazs!
Thank you for fast support.
I need to explain how cut recovery works.
If controller during cutting lost arcok signal from cutter he immediately send message to the plugin and plugin store current XY position BUT NOT inform UCCNC about this - motion on the XY plane not stopped. In same time controller start ArcLost timer (500 msec). We need to delay ArcLost issue for prevent errors on the end of cut, because almost at the end of each cut, the cutter turns off in consequence of arc lost.
When ArcLost timer elapsed controller send message to the plugin and THCOFF signal issue - UCCNC stop motion with deceleration.
So we have exact XY position on the trajectory and can return on this position for restart - you see on the video - torch return on the previous arc, where arclost issue.

Please take into account that we STOP program and return on the position using G0 command. Then START program. We set correct position and correct line number. Just need to start from this position.
I am very sure that this a standard situation for UCCNC.

[cncdrive]

Hi Andrew,

OK, I understand now how it works and the problem is that you sending the machine to the end of the arc and setting the line pointer to that arc which was already fully executed,
so when you then cycle start on that g-code line, the arc will mean a full circle, because an arc is defined as:

- Start point: The point the machine is standing at
- End point: The point programmed in the arc g-code line
- The Center programmed as an inceement to the Start point

So, the problem is that where the machine is at when Cycle started is on the end of the arc or over the end of the arc and the endpoint is the endpoint programmed and the direction is set by the G2 or G3, so where the machine is standing is already at the end of the arc, so executing the same arc g-code line again will mean a full circle for the software.

I think the only easy solution to resolve this issue is to handle the arc lost differently, with detecting the arc loss and then tell the UCCNC immediately that the arc was lost and so it will deccelerate and stop the motion.
Wait until the motion is stopped and so the UCCNC moved back to the arclost position, because that function is built in, so if the THC is enabled then the UCCNC moves back to the arc lost position point and gives back the proper line ID also. Also there is the builtin protection, that if that point is the very end of the arc then the software will give back the next line ID, so the next line or arc will be executed on Cycle start and the "full arc" issue will not happen.

Or you can make your own calculation and protection in your plugin, if you want to do this differently and want to add your own protection routine against this "full circle" issue, but that is harded to do in my opinion, because then you will have to check which line the motion was stopped at with getting the line ID, and get the endpoint coordinates out of that g-code line and if the arc lost point is closer to one step to the end of the arc then increment the line ID with one, because then you are already at that point, on the end of the arc then executing that line will cause a full arc execution.
However this algorithm will not work properly on full circles, because then the situation can be the same when you are on the starting point of the arc and when you are at the endpoint of the arc, because for a full circle the start and endpoints are the same, so the algorithm will be unable to decide if the circle was already cut out or not. So, there will be a limitation with this algorithm, that full circles can't be programmed, I mean the recovery could not work for 100% goodness with this algorithm, only with using the built in stop and moveback algorithm of the UCCNC.

[shad]

Balazs, please explain how the built in stop and moveback algorithm of the UCCNC working. There are any difference between my arc lost recovery algorithm in similar situation (on the end of the arc)?
After moveback program stopped or paused?