Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trinamic: StallGuard based crash safety #12

Open
comps opened this issue Aug 16, 2023 · 1 comment
Open

trinamic: StallGuard based crash safety #12

comps opened this issue Aug 16, 2023 · 1 comment

Comments

@comps
Copy link

comps commented Aug 16, 2023

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!

@terjeio
Copy link
Contributor

terjeio commented Aug 16, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants