forum.cncdrive.com

Hello Balazs!
My customers report about problem.
We have Cut Recovery procedure to restart cutting from plasma arc lost position. The problem issue any time when we try to restart on the arcs.
After then plasma arc lost issue, plugin store current torch XY position and turn off ArcOn emulate signal. UCCNC stop motion.
Operator start Cut Recovery procedure.
Plugin execute:
- G0XlostYlost - torch return to the arc lost position;
- Then

Code: Select all

UC.Setfield(true, (double)line_number, 866);//set arc lost line number
UC.Validatefield(true, 866);
UC.Callbutton(169);//call button RunFromHere
UC.Wait(100);
UC.Codesync("M205");//turn on THC
UC.Codesync("M3");
UC.RemoveRunfromhere();//prevent open runfromhere window to allow start from any poins of the code line (not from frame start coordinates)
UC.Callbutton(128); //call button START


- After then UCCNC received ArcOn signal torch start to move on the XY plane;
- Torch makes movement on the full circle with radius equal arc radius and then continue to correct move on the trajectory.

This issue only if we try to restart from arc and not always. But this is very painful.
I am attaching picture for better understanding. And send to your email program - this issue was on the 111 code line.
Thank you!

Hi Andrew,

One thing is not clear to me is where do you get the line_number parameter.
I think it may be possible that that parameter is not correct and then the software has to create a full circle to reach that endpoint from current point with an arc, but this is ofcourse just an idea yet.

It would be also very useful if you could make a short video to let me see more clearly how it exactly happens.
And if you could send me your plugin and profile file too so I could reproduce the same as you will do on the video.

Plugin store number of the code line and XY positions on the plasma arc lost event.

Code: Select all

ArcLostPosX = UC.GetXpos();
ArcLostPosY = UC.GetYpos();
ArcLostCodeLine = Convert.ToInt32(UC.Getfield(true, 866));

I will send plugin, profile file and screen on the email.
Thank you!

Hi Andrew,

I've made some debugging and I see what the problem is, but do not know yet how to resolve it.
Let me explain:
The issue happens when the motion stops exactly on the endpoint of the arc, but it do not yet start the next line or arc, so the current line number is still that arc.
Arcs are defined with the endpoint and the center point and the current point.
So, when the motion stops on the exact endpoint of the arc and the current line is still the same arc then when you Cycle start again then the same arc is put in the motion buffer for execution,
and in this case this same arc becomes a full circle, because the startpoint is the same as the endpoint. So the software will make a full circle.

I don't know yet how to resolve this logic problem, because gcode-wise it is the proper operation if a full circle is made, but for toolpath-wise this is not correct.
So, I have to figure out how to resolve and distinguish when it has to make a full circle and when not ... for first thinking it does not sounds easily resolvable ... still thinking...

And I think this is the exactly same issue what Derek earlier reported to us and which we could not reproduce at that time, had less luck with the debugging that time.

Hello Balazs!
You right, my user notice that it happens on the end of arc. They said that arc lost position was on the middle of the arc, but motion was stopped later and around arc end points.
Torch returned to the middle of the arc after cut recovery procedure and then make full circle - please notice that restart was not on the end of arc.
I am try to make any debug too and report to you.

I am assumed that stop exactly on the end of the arc endpoint is unlikely event. It is possible, but not very often.
I am now make simulation of the plasma arc lost close to the arc endpoint and purposely in the cut recovery procedure change captured plasma arc lost line number. For example it was 18 line, I am change to 17 and start.
Torch make full circle and continue to move on the correct trajectory.
What I think, may be there are any problem in the RunFromHere future on the arcs?
I am very sure that captured line number on plasma arc lost event is correct, but may be something happens in the RunFromHere when we start not from start point of the frame?
Look short video - please notice on the video line number was purposely set to (Captured line number - 1):
Arc lost on the end of arc https://www.dropbox.com/s/9jr2ahl36bdmjpu/Problem.wmv?dl=0
Arc lost on the start of the arc https://www.dropbox.com/s/5trk1onfitpn9o3/Problem1.wmv?dl=0
Also I am try to restart very close to the arc endpoint and it's work fine (without change captured line number).

Hi Andrew,

It is not very unlikely event that the motion stops on the exact endpoint of an arc.
By exact endpoint I mean within +-one step on the cut plane (XY in your case) which is the last possible step on the arc.
It is not an unlikely thing, because if there is a sharp connection to the end of the arc which causes an exact stop, e.g. stop at angle is 89° and the connect angle is square 90° then it is easy to stop at the endpoint of the arc.

I've cut some parts of your g-code to test with and I can easily reproduce the issue intentionally with stopping the movement with the Cycle stop button before the end of the cycle with about the decceleration distance.
If there is a sharp edge movement in the g-code after the arc then I can easily stop the movement at the exact end of the arc from around 8 times out of 10 when the next cycle start causes a full circle.
Which is as I said before is OK gcode-wise, because the axis is standing at the very end of the arc, so executing the same arc command again is a full circle, but this is not the correct operation for the toolpath.
The situation is similar in an arc lost event.

I've also managed to figure out a solution for the issue, it is to make the software to check the following:

- If the object on which the motion was stopped is an arc AND
- If the stop point is within +-1 steps (which means it is the last step on this arc) to the endpoint of the arc THEN
Make the software to inrease the movement ID with +1, so the stopped line number will be the next line after the arc.

This will resolve the issue, because then when you next time cycle start that will be the next arc, but we will need a few days to add this code, it has to be added to the API level which is what my collegue will make.

Thank you Balazs!
We will wait. If you will need to make any debug, inform me.

Hi Andrew,

We've fixed this issue in version 1.2040 : viewtopic.php?f=2&t=240&p=4434#p4434
Please test it.

Hello Balazs!
Great! I will test it and inform you about results!!