search

Spark-Concepts / xPro-V5

xPro-V5 CNC Motion Control System Documentation and User Information
42 stars 20 forks source link

Stepper enable pin or other way to control a Z axis stepper motor brake #171

Open matthewfallshaw opened 2 years ago

matthewfallshaw commented 2 years ago

TL;DR:

How to energise/disable a stepper motor brake when the Z axis stepper is powered / enabled, and de-energise/enable the brake when the stepper is unpowered / disabled?

Background:

As is probably the case with many others, my spindle is heavy enough that when the Z axis stepper loses power ('cos, for example, I smashed the E-stop button in a state of level 1 terror) my Z axis starts plummeting downwards (initiating level 2 terror, as the still rapidly spinning tool plunges towards my workpiece). Preferring less terror in my life, I'd love to replace my Z axis stepper with a braked stepper motor (something like this), and the most sensible way (I think) to control the stepper motor brake would seem to be from a relay connected to the enable pin of the stepper driver (so that if the stepper is enabled and presumed to be offering holding torque to prevent the axis from moving, then the brake should disengage, and if the stepper driver is disabled, then the brake should engage).

My question(s):

Can anyone help me find the Z axis stepper enable pin on the Xpro V5 board, so that I can use it to drive a relay? (And is that a dumb idea for some reason I didn't think of?) Alternatively, can anyone offer a better way of knowing whether the Z axis stepper is enabled? … or a better way of otherwise reducing the level 2 terror in my life?

Spark-Concepts commented 2 years ago

By default the hard wired stepper enable signals (active low) are set to always to remain enabled (check jumper labeled 1 in the last image below - this jumper should be set to "e-stop disabled" regardless of NO or NC estop switch configuration). Stepper drivers are enabled when this signal is pulled low AND the ESP32 module separately sends the enable command via SPI

Then the ESP32 SPI stepper enable behavior is determined by the stepper idle time delay setting:

all you'll need to do to keep all axes always enabled: verify $Stepper/IdleTime=255

Run $S to check/verify $Stepper/IdleTime setting...

Every time your steppers complete a motion and come to a stop, Grbl will delay disabling the steppers by the value of $Stepper/IdleTime (Step idle delay, milliseconds) OR, you can always keep your axes enabled (powered so as to hold position) by setting this value to the maximum 255 milliseconds. Again, just to repeat, you can keep all axes always enabled by setting $Stepper/IdleTime=255

There are effectively two enable methods actively employed on the xProV5 - the hardware enable signal on the Trinamic steppers and serially controlled enable -the ESP32 controls the Stepper enable along with micro-step and other configuration settings via the SPI serial bus:

Basic control interface schematic for the xPro (ESP32 controller to the Trinamic Stepper motor driver IC's).
image image note: Stepper EN Jumper = E-stop Bypass Jumper

matthewfallshaw commented 2 years ago

Open questions:

  1. Is there a way I can read a logic level from the xPro board to notice that the stepper motors have been $SLP'd?
  2. Alternatively, is there some way I can trigger an event somewhere else when the xPro receives a particular GCODE command (like when the xPro receives$SLP, HTTP GET a specified URL)? (And a different action when the xPro is reset?)

I have now learned a lot more, and I am very grateful for the detail and the rapid response (thank you!)… and I'm still struggling to work out how to achieve my goal.

There are four situations in which the Z axis needs to be prevented from moving:

  1. [SOLVED] When the whole system is powered down (either just powered down, or after interrupting power with an E-stop on the power supply); [if the brake is powered from anything downstream of the power supply then it'll engage when power is lost]
  2. [UGLY SOLVED] When I break the E-stop/Door SIG-GND connection with xPro jumper set to "E-Stop Enabled" (only NC firmware scenario considered, because I am not brave (is that the right word? 🧐) enough to rely on an E-Stop that will fail silently if a single connection fails); [I don't know how to detect that this occurred from the xPro, but I could use a double channel E-stop button and run the brake power through it]
  3. [UGLY SOLVEDNOT SOLVED] When I break the E-stop/Door SIG-GND connection with xPro jumper set to "E-Stop Disabled" (only NC firmware considered, as above); [either rely on the motor remaining powered and holding in position, or wire E-Stop as above — I'm a little terrified of this scenario because, when I first set up my xPro I set it up this way, and at that time hitting the E-Stop caused the xPro to finish the current GCODE instruction, then stop… which is very not what I want an E-Stop button to do!! Playing with this yesterday (using OpenBuilds Control instead of CNCjs, in case that's relevant) it seemed like this now nearly achieved the obviously desired outcome of immediately stopping all axes and powering down the spindle… but I'm still feeling nervous. UPDATE: In this scenario the xPro doesn't immediately stop, it aborts the current move, raises the Z axis, then stops the spindle. If I wire the brake to immediately engage when the E-stop button is pressed, then the brake will fight the Z-axis being raised… and hopefully that won't break anything but erghh?!]
  4. [NOT SOLVED] When I $SLP the xPro. [After staring at your schematic for some time I don't see how to logically detect this, so my best idea is something super ugly like trying to sense current in the motor wires]

Is there some way (that I've failed to work out from your schematic) that I can read a logic level somewhere to notice that the xPro has been $SLP'd? Is there some way I can have the xPro run an extra script to enable the brake every time it's $SLP'd? (And a different one to disable it every time the xPro resets?) Any other ideas?

If no one has a better idea, perhaps my best bet is the somewhat elaborate plan:

  1. Build an ESPHome device acting as an HTTP endpoint controlled relay for the brake;
  2. Use a GCODE sender (like OpenBuilds Control) in which I can implement a macro (in OB Control that'd be a Javascript macro) that will tell my ESPHome device to engage the brake, then send $SLP to the xPro… and try to never send a bare $SLP;
  3. … and keep thinking about how I'm going to make sure the ESPHome device disengages the brake whenever the xPro is reset (like have the GCODE sender notice resets? — no good ideas here yet).
  4. UPDATE: … and wire my E-stop to kill the power supply instead of relying on the xPro jumper set to "E-Stop Disabled". … so, really, that's only half of a plan.

(Again, thank you for all of the detail in your last reply.)

matthewfallshaw commented 2 years ago

@Spark-Concepts ? Any further help to offer? (If no further advice, then thank you again for the detail above, and feel free to close this ticket (or I will in a few days).)

Spark-Concepts commented 2 years ago

Matthew, to be clear there is NO discrete "brake" signal to the stepper motors...

A PWM signal from the xPro's microcontroller commands the TMC5160 driver chips which each drive two H bridge's that control the stepper motors two coils... which in-turn cause the stepper to HOLD (brake) or MOVE (forward or reverse)... by moving the jumper to "e-stop disabled" you are relying on software to stop motion. I would recommend 1 of 2 solutions:

  1. Wire an e-stop button or switch in-line to the outlets powering both the 24V Power Supply and VFD: image image

and/or

  1. Add an anti-backlash nut to your Z axis to prevent it from dropping. (How to Choose an Anti-Backlash Lead Screw Nut)