Open comps opened 1 year ago
Either or both modulated by the expected motion system load (ie. acceleration being more demanding than constant rapid movement).
Acceleration/cruising mode transitions can be detected by hooking into hal.stepper.pulse_start
, but I am not so sure it is wise to change the current in the middle of motion, it might cause unacceptable jitter/stalling. A second MCU for controlling the Trinamic drivers might be a way to avoid this. grblHAL has an I2C interface for that, current implmentation is for a MSP430.
A core event for motion mode changes can be added with a negligible/low performance hit since these are relatively infrequent. Jogging can be detected by hooking into the grbl.on_state_change
event, motion mode changes possibly as well (but perhaps not 100% accurately) by getting the current mode on transitions to Cycle state.
M-code configurable current / SG thresholds
Marlin style M-codes are available for that. You may also bypass M-code parsing by calling the Trinamic driver interface directly, this since injecting M-code commands is only possible when the controller is in Idle state.
Natively supported would mean you'll have to write a plugin to accomplish this.
It would be great if we could utilize Trinamic's feature set for some safety, namely:
G0
or jogging should require much less than steel milling).(Just some ideas.)
Exceeding these thresholds (triggering StallGuard) would result in an E-stop (or something equivalent, doing
M5
, disabling theEN
motor driver pins, etc.).This is something I'm considering doing on a standalone Arduino (probably with a potentiometer for the current / SG setting), but it would be better to have it natively supported as it could integrate with motion planning more closely.
The use case is mainly for teaching CNC programming to students / novices and minimizing the damage caused by them. :)
Thanks!