You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great if we could utilize Trinamic's feature set for some safety, namely:
Different motor currents for different modes (G0 or jogging should require much less than steel milling).
StallGuard thresholds associated with those modes / current settings.
Either or both modulated by the expected motion system load (ie. acceleration being more demanding than constant rapid movement).
M-code configurable current / SG thresholds, so that wood-cutting jobs can run much closer to stalling (causing no damage on crash), while steel-cutting ones can ask for higher values.
(Just some ideas.)
Exceeding these thresholds (triggering StallGuard) would result in an E-stop (or something equivalent, doing M5, disabling the EN 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!
The text was updated successfully, but these errors were encountered:
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!
The text was updated successfully, but these errors were encountered: