Closing the loop on stepper motors.

[Squeack]

Moved from terjeio/grblHAL#356

Stepper motor control is open-loop and cheap. Servos are closed-loop and expensive. I am planning on partly closing the loop on my stepper driven system by feeding the step and directions outputs from the GrblHAL controller (Teensy based breakout board) to both the stepper drivers and to a separate position tracker based on a Raspberry Pi Pico. The three movement leadscrews will be linked via timing belts to 200PPR rotary encoders which will feed back to the Pico. After allowing a ratio for micro-stepping the Pico will then raise an error if the driver instructions and position feedback do not match within a given tolerance.
This has to be communicated to the GrblHAL controller somehow. What would be best? Triggering the door open switch? Does GrblHAL react to the limit switch inputs for the A or B axis even if compiled to handle only three axes?

Terjeio replied in old discussion forum:
Suggestion to use motor fault pin in newer versions. A & B limit switch pins do not respond for 3 axis mills, but can be repurposed.

[Squeack]

Motor fault does not seem to be fully supported across all platforms yet. Within the Teensy driver there is an '#if MOTOR_FAULT_ENABLE #define MOTOR_FAULT_PIN n' within GRBLHAL2000_map.h, but MOTOR_FAULT_ENABLE does not appear in any other place, so is never defined.

Following the trail for the safety door activation:
grbl/config.h may define ENABLE_SAFETY_DOOR_INPUT_PIN, although it is commented out by default.
If that is defined, then grbl/driver_opts.h defines SAFETY_DOOR_ENABLE as 1, otherwise as 0.
If SAFETY_DOOR_ENABLE is defined as non-zero then [boardname]_map.h defines SAFETY_DOOR_PIN as the pin number.

Along the same lines:
grbl/config.h should allow defining ENABLE_MOTOR_FAULT_INPUT_PIN.
grbl/driver_opts.h should set MOTOR_FAULT_ENABLE to 1 or 0 accordingly.
If MOTOR_FAULT_ENABLE is non-zero then [boardname]_map.h should define MOTOR_FAULT_PIN.

Within the iMXRT1062 (Teensy) driver, driver.c has multiple functions which make use of SAFETY_DOOR_PIN, but nothing that makes use of MOTOR_FAULT_PIN. grbl/state_machine.c has a STATE_SAFETY_DOOR, but no STATE_MOTOR_FAULT or similar. grbl/system.c uses the safety door status or signal in the control_interrupt_handler(), disable_lock() and go_home(), but only uses signals.motor_fault in control_interrupt_handler() and go_home(), but not disable_lock().

Since STATE_SAFETY_DOOR is likely to be a temporary state that can be resumed from, but STATE_MOTOR_FAULT is likely to be terminal, they probably need to be handled differently, but the core support for motor faults does not seem to be complete yet.

Is this an active area of development?

[terjeio]

Motor fault does not seem to be fully supported across all platforms yet. Within the Teensy driver there is an '#if MOTOR_FAULT_ENABLE #define MOTOR_FAULT_PIN n' within GRBLHAL2000_map.h, but MOTOR_FAULT_ENABLE does not appear in any other place, so is never defined.

Correct, it has to be added to the input definitions array as a minimum.

grbl/config.h may define ENABLE_SAFETY_DOOR_INPUT_PIN, although it is commented out by default.

I have kept this for backward compatibility - I want to rename, or perhaps remove it, it as pin definitions do not belong in the core. Signal handling functionality does,

Along the same lines:
grbl/config.h should allow defining ENABLE_MOTOR_FAULT_INPUT_PIN.
grbl/driver_opts.h should set MOTOR_FAULT_ENABLE to 1 or 0 accordingly.
If MOTOR_FAULT_ENABLE is non-zero then [boardname]_map.h should define MOTOR_FAULT_PIN

No, see above. It should be enough to define the pin in the map file. Or perhaps also by adding a plugin that claims an aux input.

... but the core support for motor faults does not seem to be complete yet.

Again correct, currently the signal resets the controller so it is pretty harsh. It can surely be improved upon.

Is this an active area of development?

Not really, but can be made active again if a reasonable functionality can be agreed upon.

This discussion could be what is needed to get it completed?

[andrewmarles]

The motor fault signal does require an additional (ideally interrupt capable) input pin on the MCU, and those are always in very short supply. Of course now that I say that I realize that adding a polling check to the (core) motor fault signal in stepper.c would actually be pretty effective. At least on platforms like STM32 it would be helpful to poll it since it is pretty easy to fill up all of your interrupt pins on that chip.

To me it seemed that the action taken in the event of motor fault was appropriate (effectively e-stop) since by definition position has been lost if the motor faults and homing is required. It is useful to the user to have the motor fault code appear rather than e-stop so that it is immediately obvious why the system has halted, so it would be good for us to start exposing this signal in more of the drivers. I guess if @Squeack with your implementation, if you are able to somehow correlate received step pulses with the encoder position you might be able to keep track of position in the event of following error and use the motor fault to signal the core to pause rather than halt so that the motor could catch up?

[Squeack]

Just a quick additional thought: The above simplification of the FEATURE_PIN usage might not work with the current code header inclusion order. If the core is built without a link to the hardware layer then FEATURE_PIN would not have been defined yet. Various #includes might need rearranging.

[terjeio]

This can be simplifed to just define SAFETY_DOOR_PIN within [boardname]_map.h or leave it undefined and drop ENABLE_SAFETY_DOOR_INPUT_PIN entirely.

I guess I'll drop ENABLE_SAFETY_DOOR_INPUT_PIN from the core and move it as an option to my_machine.h. For that I have to leave safety signal handling always compiled in in the core, that may require some thought.

This leaves the end of the movement in the wrong place, or gets multi-axis movements out of sync. I need to put a 'scope on the step and direction pins to see if the fault lies in the driver or controller, but getting inside the controller box while it is in an operatable state will require some rearrangement. Any suggestions to possible causes or fixes would be welcome.

Disable stepper disable when idle helps? Set $1 to 255, or $37 to a mask for the motors you want to keep enabled.

Just a quick additional thought: The above simplification of the FEATURE_PIN usage might not work with the current code header inclusion order. If the core is built without a link to the hardware layer then FEATURE_PIN would not have been defined yet. Various #includes might need rearranging.

The core does not know anything about the #define symbols created at the driver level - and should not. The driver advertises capabilities to the core via the HAL structure, either by setting optional function pointers or by setting capability flags. There are files in the core that may suggest otherwise but these are only referenced by driver or plugin code - added to the core for convenience.

[Squeack]

My comment about having to change the #includes was because grbl/config.h current may define ENABLE_SAFETY_DOOR_INPUT_PIN, and has optional code based on that define. If the three SAFETY_DOOR defines are condensed into one, which is at driver level, then how does the optional code in the core get enabled or disabled? Capability flags (which I had not dug deep enough into the code to know about) look like a good possibility. It is run-time rather than compile-time, which might have made a difference on the tightly constrained original GRBL running on a ATmega, but is likely to be acceptable on a more capable platform.

[Squeack]

Thanks for the suggestion of setting $1 to 255. It worked.

[terjeio]

FYI #define ENABLE_SAFETY_DOOR_INPUT_PIN has now been removed from the core.