UC100 and G2 ramp down interpretation

[MileHiDude]

Hello
New to the forum.

I’m having a serious issue with a ramp down move.
I’m using Mach4 with Windows 10 (64 bit) and the UC100 motion controller.
All my posts have been done in Mach3 with CAMBAM whereby I’ve enjoyed
excellent success in the past.
However, I have lately run into a situation where my router has suddenly plunged
10-15mm when it came to a G2 ramp down move utilizing the additional Z move
on the same line.
Now Mach4’s simulator (as well as 3rd party simulators) have all run this simple
pocket cutout perfectly. And if I remove the ramp down move (the G2 line with
additional-Z), the MOP runs flawlessly.
And perhaps the problem isn’t even associated with the G2!
Still, it seems evident as though the UC100 is the “problem child” here as the MOP without the
ramp down and the simulators’ effortless handling of the code with the ramp down
so indicate.
Clearly, I still wish to employ ramp down moves as part of a MOP, so I’d love to
get past this ‘snafu’.

The suspect line(s) of code:
....
G1 F735.0 X42.5 Z-0.28
G1 X47.5
G1 F300.0 Y202.0
G1 735.0 X51.5
G2 X52.0 Y201.5 I0.0 J-0.5 (Where things got ugly)
G1 Y193.5

Your help will be deeply appreciated.
Walt

[cncdrive]

It is Mach4 who calculates the motion path and the trajectories.
What the UC100 sees is only time frames with frequencies. It does not even have an idea if it is a G1, G2 or G3 movement in Mach4.
Maybe it is a bug in Mach4's plugin interface if the UC100 makes it wrong while the simulator makes it right.
So, I don't think it is a UC100 related problem, but please post your g-code file, possibly cut out just a short part of it with which you can reproduce this issue and we will then check it out to see what happens on the plugin and UC100 side.

[cncdrive]

Another thing you could do is please also test a different Mach4 version to see if the problem is still there or not.

[MileHiDude]

Thanks. I appreciate your input.
I understand your thought process regarding the run disparity between the Mach4 (and other) simulator(s) and the actual run of the program; I get it. It isn’t the motion controller’s responsibility to interpret. Yet, that is where the evidence seemed to point.
Now, I have heard of line voltage spikes rendering some “interesting” issues at the controller; though I personally deem that highly unlikely; (unit is well protected from EMI as well).
As to posting my G-code file, I’m afraid that it has been accidentally overwritten and since I now have completely disassembled my control box to do some long awaited improvements, I’m in no position to regenerate the code and subsequently check it for the same error.
Additionally, the new box will incorporate a ESS in combination with a PMDX-126 board, so the UC100 will go back in its box for future projects. Being that as it may, if (as you suggest) there is indeed a Mach4 glitch that is still outstanding, then we should all be made aware of it.

In all honesty, the speed at which that 3kw spindle plunged and “ate” through waste board AND my precious 3/4” plate aluminum table was scary. I’ll have to fire up the TIG and see if I can fill that ugly 10mm deep scar.
I absolutely hate it when I can’t figure out what went wrong.
But then, I’m sure I’m not alone in that feeling.
Presently, I’m about 3 weeks from firing up the new control box and controller.
I still would be interested in knowing if anyone else has encountered a similar crash whereby the Z-axis plunged 10-15mm beyond what even the deepest Z coordinate listed in the MOP G-code.
Thanks
Walt

[cncdrive]

I have not heard anything like that so far, but I do not know how many Mach4 users are out there who using our motion controllers.
Nowadays most users using the UCCNC and also many users using Mach3. I think there are probably only a minor number of Mach4 users here.
I think you could find more input on the Mach3support forum, you might find users with the same issue there.