Possible feedhold bug

[Derek]

Had a problem on my router. I'm running V1.2029. Pressed feedhold, checked something in the part, pressed feedhold again and the cutter plowed into the work. The best I can determine is I paused in the middle of a G2 or G3 and when it resumed it had lost it's way. I ran the same code a few times without the hold and it worked fine. I didn't see this listed in any of the change logs. I use feedhold a lot on multiple machines and have never experienced anything like this before.

Derek

[cncdrive]

Hi Derek,

That is strange, because we have never had a problem with the feedhold, I mean I don't remember a single problem report with that function in the full lifetime of the UCCNC.
The feedhold is handled by the API, the software side (the g-code interpreter/executer) does not know anything about the feedhold, I mean it does not do any events,
and it does not flush and refill the buffer on feedhold, there is basicly no events attached, what happens is simply the API stops the motion with decceleration and does not execute more motion until the feedhold is released, then the API just continues to execute the already filled motions in the buffer.
So if there is any problem with the feedhold that must be a problem in the API or in the firmware or in both, but again, we did not receive any problem reports about the feedhold so far.

If you could reproduce this issue then please send me the code involved and some instructions about how to reproduce it.

[Derek]

I think it would be hard to reproduce by pushing the feedhold button since it would have to be at the exactly the right time and with possibly the exact same amount of time in feedhold. As you said, I've never ever had a feed hold issue either so it really caught us by surprise. Nothing like seeing a custom made 10" tool holder with a 3/8" ball mill plow into your work.

I'll see if I can recreate it but i wouldn't hold your breath.

[Derek]

Couldn't get it to repeat. Here is the offending piece of code. Keep in mind the code runs fine during normal operation.

Code: Select all

N3344 G01 X8.4687 Y4.1271
N3345 G02 X8.1687 Y4.1550 I0.5333 J7.3609
N3346 G02 X5.6802 Y5.2806 I0.5788 J4.5932
N3347 G02 X5.6249 Y5.3639 I0.2169 J0.2038
N3348 G03 X5.3353 Y5.6353 I-0.5582 J-0.3053
N3349 G02 X5.2785 Y5.6806 I0.1251 J0.2156
N3350 G02 X4.2052 Y9.6806 I3.4665 J3.0741

We did a feed hold on or near N3347 and judging by the damage to the piece it was probably line N3348 or N3349 that did the damage.

Here is a shot of where it happened. the vertical bondo area that looks like a 3/8" slot is where the bit went. If you look closely you can see where the grey area stops and the bondo cleanly joins. I believe this is where it happened. Cut direction was clockwise so the cutter was approaching from the right of the picture.

[cncdrive]

OK, thank you for the code.
And which controller are you using?

[Derek]

UC-100

[cncdrive]

OK, thanks, one more quick question: The issue happens immediately after you releasing the feedhold?

[Derek]

I would say yes. It happened very quickly and I wasn't expecting it so I wasn't paying too close attention. The machine sat in feedhold for probably 45 seconds or so.

[cncdrive]

OK, thanks Derek. I described the issue to my collegue who is responsible for the API development and he will debug this soon and I'll update you with info asap.

[Derek]

Hi Balazs
Happened again. Same scenario. This time it was clear of the work so I let it run. It basically started doing a large arc. I had to stop it before it hit a clamp. Still version V1.2029. I suppose I should upgrade:)

Derek