Unpredictable Machine Abort - Power Route XL - RESOLVED

[paulk]

I have been running my Power Route XL for about a month but the machine is experiencing a common fault with starting jobs.  When machine will start the move usually from a high Z position and then bind.  However, I've checked for mechanical binding and can not find any.  I've ran several jobs without issues so I don't believe this is a mechanical cause.  I've tested this for several hours using the same job.  Sometimes she runs and sometimes she errors out (see image).  I've tried swapping the motor drives (Z axis with A axis because I'm not using that axis), ensured the DIP switches are set the same without any change in behavior.  The machine jogs perfectly on all axis on the entire working area.  At one point tonight, the machine went negative Z before I could stop it and ran about 3 mm into the AL table (not fun). 

The controller reports an error: Alarm: 162 - Undefined [G3 X300.........] 

It always seems to be the G3 command when the fault occurs. 

I have since resolved my issue and wanted to document it for others here.  The root cause is over-driving the motors.  I'm using the OpenBuilds software and not UGS as a personal preference which defaults these settings to the following values:

1.  X-Axis Maximum Rate, mm/min (Default = 9000)

2.  Y-Axis Maximum Rate, mm/min (Default = 9000)

3.  Z-Axis Maximum Rate, mm/min (Default = 9000)

Instead of the 9000, I set all axis to 4000 for the maximum rate.  4000 was chosen as an arbitrary value which still needs optimization.

I also changed the default acceleration for X,Y and Z axis from 400 mm/sec2 to 300 mm/sec2.  The malfunction was only resolved after I changed the maximum rate so the acceleration probably had little affect.  I believe the motor drive was giving the steppers too many pulses believing the stepper could handle that pulse count, thereby stalling out the stepper.  It is possible that this not the root cause of the issue, but my machine runs as expected without errors.

[bLouChip]

I'm not finding any grbl alarm list/tables that go that high (162) in value. Alarm 1 - 9, and error 1 - 38 is all that I find.  domoticx.com/cnc-machine-grbl-error-list/

I'm wondering if the 162 ref is a line number in the gcode file ?

G3 is an arc move btw. MRgrbl, assuming that is what runs the controller of the Power Route, can be finicky about arc moves, I've gotten error:33 many times when SheetCAM generated the toolpath. Recently I traced it back to a SC post processor that was using 2 decimal accuracy on mm units and the rounding was apparently not passing the valid arc target test in MRgrbl.  The fix was to change the post processor to generate 3 decimal mm accuracy, which should be the norm anyway.

If you are using UGS, it has a Check action/button, which will put grbl into its "Check mode", which will have grbl interpret the gcode statements and check for errors, without driving any motion in the CNC machine. If your  gcode sender does not have a Check action/button, then you can put grbl into Check mode with $C command and send the gcode file to effect the same thing.  Read about it here: github.com/gnea/grbl/wiki/Grbl-v1.1-Commands#c---check-gcode-mode

This at least will verify you have valid gcode that you are about move the machine with. It doesn't mean it won't crash the machine though when it does drive real motion. You should run with $20=1, Soft limits enabled.

If it happens again, capture a screen shot of the console messages and post here.

Good luck,

Lou

Oops,  I had my reply started since this morning and just got back to it, I didn't see your update that you seemed to have solved the problem.  Good news.  Well done.

[paulk]

Thank you for the thorough analysis. I'm don't know why the movement rate would manifest in showing a G code error. However, after slowing down the motors the error has not occurred. Since the system is open loop, the motors loosing steps should be transparent to the motor drive. I have since then increased the motor speed to 5K mm/min for the maximum rate and will test the upper limit in the future.