Motor power up state

[jkuusama]

How would I set the controller power up state to be motors disabled? Use case: My pick and place machine has sturdy motors for movement (and once I have software for the grblHAL board I'm working with, even stronger). But the rotation motor is small to keep the head light and the machine fast. The TMC5160 drivers don't remember set driver currents, and the default is 500mA. The tiny rotation motor current is less than 100mA. So, the system comes up with 5x maximum current for the motor.

Q1: Is this worry unnecessary? Parameter $680 description is "Delay from stepper enable to first step output." This kind of hints, that steppers might power up not enabled (power off) and turn on only at first move. Is this so?

If yes, thank you for confirming! If not:

Q2: is there a way to configure the web builder to solve the problem?

Q3: If there is no straight forward way, I can try to set up the compilation environment and chance the default currents. Where are those defined?

[jkuusama]

Q3 answer is config.h.

[terjeio]

Q1 - depends on $1 (if 255 steppers are always on) and $37 which overrides $1 to keep only specific axes enabled. Some may want only Z to be always enabled if gravity pulls the spindle down when disabled.

Q2 - no. Default is to disable steppers when idle.

The tricky bit is what happens during startup, initially the GPIO pins are typically high Z inputs so a pullup (or pulldown) resistor is required to set power on state for the driver. During startup stepper enable pins are configured as outputs and then the behaviour is undefined for most MCUs. Some (all? - I have not checked) allows setting the output level prior to changing pins to output, E.g. the STM32F4xx driver sets the pin state signal high before configuring it as an output ensuring that it does not produce an undesired level change on the output. Other grblHAL drivers may not behave in the same way. The startup sequence is basically this:

1. MCU pins high-Z, pin level is determined by any pullup or pulldown on the pin.
2. the grblHAL driver sets up basic I/O and inits most of the plugins.
3. the grblHAL core reads settings from NVS storage (Flash or EEPROM)
4. the grblHAL driver sets up GPIO pins - this is where the enable pins are initialized.
5. the grblHAL core completes t6he configuration itself including setting the initial stepper enabled state.

Step 4. is where code may have to be changed to set the initial driver state according to the configuration.

[whmountains]

I happen to have a logic analyzer and a grblHAL board on my desk so I decided to test it.

First with non-inverted enable ($4=0, enable=HIGH, disable=LOW). The pin floats while the chip is in reset, but I don't see any deliberate enabling of the stepper driver.

And now with inverted enable ($4=7, enable=LOW, disable=HIGH). It looks to me like the pin is first initialized to a low state, and then set to the disabled state later in the startup process. Or maybe the rp2040 silicone defaults to pulling it low, until software sets it otherwise? That goes beyond my knowledge. The time spent at LOW after reset is about 80ms.

It doesn't look like grblHAL is actively trying to boot up with drivers enabled, unless you have $1=255 of course. I have a feeling this behavior might be board and driver dependent. A pull-up/pull-down resistor would suppress the floating behavior for example.

There is one more case I just thought of. Reading between the lines of your question, it sounds like you are using a Trinamic driver that grblHAL configures at runtime. That's cool, I have a driver that's capable of it but I never dared to try. Anyway, if you are using one a driver with I2C then it looks like the enable and disable is handled over I2C rather than a pin. (Example from RP2040, other drivers should be similar.) If that were the case then there's nothing to worry about regarding pin initialization. The driver won't be enabled until it has been configured.

[jkuusama]

sounds like you are using a Trinamic driver that grblHAL configures at runtime.

Correct.

there's nothing to worry about regarding pin initialization. The driver won't be enabled until it has been configured.

My worry is that the software configures the drivers correctly, and enables(?) them with default current values, killing the small motor. Caleb Whiting ***@***.***> kirjoitti 15.7.2025 kello 20.37:  I happen to have a logic analyzer and a grblHAL board on my desk so I decided to test it. First with non-inverted enable ($4=0, enable=HIGH, disable=LOW). The pin floats while the chip is in reset, but I don't see any deliberate enabling of the stepper driver. image.png (view on web)<https://github.com/user-attachments/assets/ac0ca7da-fb3f-430a-b044-f85364f99580> And now with inverted enable ($4=7, enable=LOW, disable=HIGH). It looks to me like the pin is first initialized to a low state, and then set to the disabled state later in the startup process. Or maybe the rp2040 silicone defaults to pulling it low, until software sets it otherwise? That goes beyond my knowledge. The time spent at LOW after reset is about 80ms. image.png (view on web)<https://github.com/user-attachments/assets/6925e174-24be-42b3-ae8c-02c9ea426fe6> It doesn't look like grblHAL is actively trying to boot up with drivers enabled, unless you have $1=255 of course. I have a feeling this behavior might be board and driver dependent. A pull-up/pull-down resistor would suppress the floating behavior for example. There is one more case I just thought of. Reading between the lines of your question, it sounds like you are using a Trinamic driver that grblHAL configures at runtime. That's cool, I have a driver that's capable of it but I never dared to try. Anyway, if you are using one a driver with I2C then it looks like the enable and disable is handled over I2C rather than a pin. (Example<https://github.com/grblHAL/RP2040/blob/master/driver.c#L690> from RP2040, other drivers should be similar.) If that were the case then there's nothing to worry about regarding pin initialization. The driver won't be enabled until it has been configured. — Reply to this email directly, view it on GitHub<#776 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABDYRZUZG4SDW6ILHAIPNY33IU34JAVCNFSM6AAAAACBSORHDKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNZWG42TONY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[whmountains]

Based on my testing I don't believe grblHAL enables steppers at startup unless $1=255. Otherwise I'd have seen something on the logic analyzer.

[whmountains]

Also, what do you mean by "configured"? Wouldn't the current limit be part of the configuration or am I missing something?

[jkuusama]

I have spent a few days adapting my software to grblHAL and I find that my worry is unfounded. Although https://github.com/grblHAL/Plugins_motor claims that "Stepper current is not permanently stored", I think it means only the M906 command. When I set current using $140, $141, ... commands, they are stored. Doing setup this way, the power up state doesn't really matter, at least for this reason. Once I get the machine really up and running, I'll add the result here. (The application needs to keep the motors on after standstill for several minutes, so the setting would actually be $1=255.)

[terjeio]

M906 is for changing stepper currents temporarily, $-settings are always stored.

[jkuusama]

Thank you for your great support! You might want to edit the note on the page. ;-)