Servo error input and Alarm?

[phil-barrett]

I get the question about supporting servo error output about once a week now. Generally the answer is to use door or estop inputs for that. But it seems like grblHAL should be able to distinguish a servo error from other errors. If for no other reason but to be able to say "Servo Error". The Door signal is generally available but the semantics of Door Alarm are not correct for Servo Error (GCode execution resume when de-asserted).

I do not have any experience with servos but I believe that Servo Alarm semantics should be fairly close to EStop - the machine is failing to correctly execute the GCode instructions so the job should end.

Anyway, I would like to see a Servo Error alarm code added along with the ability to see it in senders.

As to input pins, I could see using the Door input or unused limit switch inputs or even a dedicated input pin.

[terjeio]

I have alreay added motor_fault and motor_warning to the control signals bitfield as these can be used for Trinamic drivers too:

grblHAL/grbl/system.h

Lines 133 to 151 in 9cfceba

	typedef union {
	uint16_t value;
	uint16_t mask;
	struct {
	uint16_t reset :1,
	feed_hold :1,
	cycle_start :1,
	safety_door_ajar :1,
	block_delete :1,
	stop_disable :1, // M1
	e_stop :1,
	probe_disconnected :1,
	motor_fault :1,
	motor_warning :1,
	unassigned :4,
	probe_triggered :1, // used for probe protection
	deasserted :1; // this flag is set if signals are deasserted. Note: do NOT pass on to Grbl control_interrupt_handler if set.
	};
	} control_signals_t;

IMO motor_fault should be used for servos.

There is no handling of these signals in the core yet, motor_fault should obviously result in a corresponding alarm but IMO not one that blocks communication like hard and soft limits or estop. It should prevent further G-code execution though, I think error 9 - G-code lock can be used for that. Actions should be taken when this alarm is raised? Retract, stop spindle and coolant? Nothing? Configurable?

motor_warning can be added to the Pn element in the realtime report (a W?) with no further action taken by the core.

If information is available from the drivers this could be output as messages, either from a plugin or the driver. Trinamic drivers can be queried for fault reason: overtemp shutdown, motor coils shorted or open etc.

Pin assignment and handling has to be done in the core, is run time routing for some pins desirable and should be looked into? Routing by binding function pointer(s) to some pins?

[phil-barrett]

So you are thinking of something fairly close to safety_door_ajar? But without the resume execution semantics?

[terjeio]

So you are thinking of something fairly close to safety_door_ajar?

I have not thought this through at all, it would be nice if some of those wanting this feature would chime in with ideas. And even better if someone working with pro controllers could explain how those handle motor faults.

Some random thoughts related to this:

Doing a retract on a motor fault may not be possible if the Z motor fails, and with one input only it is not possible to find out which?
Trinamic drivers can be queried via UART or SPI interface about what is wrong.
Some or all servos has a ModBus (or other) interface that can be queried?
Fatal errors where the motor cannot be run anymore vs. lost position?
Wire-or'ing fault signal from several motors is possible? (Requires open drain or open collector outputs).
Spindle and or coolants should be stopped on a fault?

[phil-barrett]

From what I understand , the primary error output is lost position so treating it similar to an EStop is reasonable.

There are a lot of different ways servos work but most of the complexity is around where the "loop" is centered. I don't think grblHAL should be involved in the servo control loop, at least in the short term. Perhaps focus initially on something like Clearpath hybrid servos that control the loop and have an output that indicate position errors.

[terjeio]

Ok, I have now added fuctionality similar to EStop to the core so somebody can check to see if this is a reasonable approach. For now available in the test branch, driver support has to be added for it to work.

I have only done some basic testing by swapping signals.e_stop with signals.driver_fault in systemGetState() in the MSP432 driver.

[phil-barrett]

Sounds good. Thanks.

[epineh]

Hi, I'm one of the guilty ones asking for a servo fault. As Phil mentioned if a servo drive does actually fault then it usually means something catastrophic has happened, a cutter has crashed into a clamp, a mechanical binding/crash, or you are tinkering late on a Tuesday night and run gcode without a spindle running to test something and forget to set the Z height to clear the table and it plummets into the bed. That last one may seem oddly specific but lets just say the sound of a large cutter scraping along a machine table then snapping isn't very calming.

My background is with Linuxcnc and I hope to use GRBL hal to replace Linuxcnc in my current router and the next one I'm building. I also plan to retrofit a 2.5 Ton CNC milling machine that is sitting in my shed.

The servo fault is generally a product of the drive concerned, a simple output of some kind, Linuxcnc can handle as many servo fault inputs as you see fit, I had tied all three to a single input to save pins. Most hobby/semi industrial servo drives are still step/dir driven, and act in the same way as steppers as far as the controller is concerned, except of course they give a following error if they can't maintain commanded position.

Servo faults can be tied to an estop in wiring and I am happy to do so for my setup, the only issue is that what happens, or at least should happen is when a servo fault is detected, power is removed to basically everything, the spindle drive, all axis drives, toolchanger, anything that can cause injury to personnel and or machinery, while the estop should have the same effect, if there is a servo fault and its tied to the estop it will look the same as an estop condition as the servo drives have lost power and wont indicate a problem. If there was a servo fault persistent on the controller at least whoever is figuring out what happened has a place to start looking...been there more times than I would like to remember. A fault input per axis is nice but that will start using up precious IO, besides you could just latch a single axis fault with relays if your machine is large enough to make it worth it.

Closed servo loop to the controller is another beast entirely, I wouldn't suggest getting too worried about that side of things, step/dir drives have been around forever and will continue for a long time yet.

Sorry if this was a little long winded, happy to be of more assistance if I can, you guys are doing a great job and I hope to get some nice machinery up and running this year using grblHAL.

Cheers.

Russell.

[phil-barrett]

That is exactly the kind of input we need! Thank you! Scraping followed by snapping - brings back early memories of CNC to me.

[terjeio]

Does any step/dir controlled servos provide diagnostic output other than asserting a fault pin? E.g. via a serial interface? ModBus protocol?

Trinamic drivers can be queried via SPI or UART for the fault reason. My plan is to output a message when a fault is triggered for these so that the user can know what went wrong. If possible this would be handy for servos too?

The latest core version (in the test branch) has support for motor fault and motor warning signals. Motor fault asserted fault will trigger alarm 17 and block gcode returning error 9 and homing returning error 51 while asserted. Motor warning asserted will only add a W to the Pn: element in the real-time report. Additional messages for both signals can be issued by the driver.

[epineh]

Yes several drives will report back certain parameters whilst running, commanded position, following error, enable status, max error exceeded and so on, mostly serial. Personally I have been trying to get a Dspic based drive up and running today, blew one sense resistor up and couldn't get the second version to achieve decent comms and tuning while up and running, I may be getting too old for this shhhh...stuff! I think its an issue with the programming side, DsPic30f series are notorious for being difficult to program, and Microchip seem to like discarding programmer support and not supplying suitable replacements. At least my latest escapades seem to confirm this.

You don't plan to turn your talents to coding a really cool CNC servo drive by any chance ??

[karoria]

I also need input from drive fault. As you mentioned EStop is a workaround and I am doing same right now for my cnc mill. I want to add that drive fault can also be clubbed with hard limit input, say C axis. This way the machine stops indicating alarm and you can see the alarm on your stepper/servo drive.

[phil-barrett]

I thought about suggesting using a Limit input but does it have homing implications?

[karoria]

I have not tried yet. Will probably try in my next machine. I think you can define homing axis separately irrespective to total axis. So, you can have a four axis machine XYZA having only 3 axis homing (XYZ) as per my knowledge. Experts please correct me if I am wrong.

[terjeio]

grblHAL can be configured to home axes not set up to home with limit switches by moving them to the desired position before homing. This is enabled by setting a bit in the $22-setting.

[karoria]

I am talking about #define HOMING_CYCLE_0 and #define HOMING_CYCLE_1 in config.h in pure grbl. Not sure how it works in grblHAL.

[terjeio]

Same as grbl, however grblHAL has $-settings for these (and many more) to simplify configuration. You no longer need to recompile for trivial changes.