Motor enable and Disable pin does not change state

[muhammadelmogy]

I have some issues with the driver enable signal, currently I have the Blackpill used to test some functionalities but I am planning on implementing a controller with the bare STM32F411 IC

When I jog the motor, the stp and dir signals are just ok (tested fine) but the Motor enable signal does not change the state at all! I got stepper driver enable signals inverted

When I change it to non inverted signal, the signal on the enable pin goes high but also the state does not change at all after that!

Also when I use $slp command does not work and give me error 3! (I want to test the effect on enable signal)

mlabs_controller_map.zip

[terjeio]

Motor enable signal does not change the state at all!

This could be due to you having duplicated the common stepper enable signal for motor 3 and 4? The config in _blackpillmap.h, that also has a shared enable, works as it should.

Also when I use $slp command does not work and give me error 3!

Did you enable sleep mode? $62=1

[muhammadelmogy]

This could be due to you having duplicated the common stepper enable signal for motor 3 and 4? The config in _blackpillmap.h, that also has a shared enable, works as it should.

Unfortunately this did not help! as for the sleep mode it was not enabled and after set to 1 the $SLP command is now accepted by the controller but it does not behave as intended!! What I am expecting from $slp to immediately stop motors by by disabling the drivers through the enable pin

Side note, what is the difference between setting sleep mode from setting by using $62=1 and #define SLEEP_ENABLE in config.h? Also what would happen if I enable SLEEP_ENABLE in config.h without setting SLEEP_DURATION?

[terjeio]

Unfortunately this did not help!

Now I have checked with your map file - and it works for me. Do you have a wiring/routing error? Or a bad MCU? Or an earlier and buggy version of grblHAL?

What I am expecting from $slp to immediately stop motors by by disabling the drivers through the enable pin

This is not how it is implemented. Sleep mode is only entered if in idle or alarm state on a $slp command.

Side note, what is the difference between setting sleep mode from setting by using $62=1 and #define SLEEP_ENABLE in config.h?

#define SLEEP_ENABLE is no longer in config.h, it has been replaced with #define DEFAULT_SLEEP_ENABLE, this to make it clearer which #defines are defaults for settings and which are not.

Also what would happen if I enable SLEEP_ENABLE in config.h without setting SLEEP_DURATION?

The machine should enter sleep mode immediately if conditions are met.

[muhammadelmogy]

I have made update to the code with the latest update and I am still having the same issue! I also changed the associated pin with enable to another pin and still have the same issue, I am not sure what do you mean by bad CPU?

My last machine used Grbl Mega 5X code base and I was using bCNC, when I start bCNC and make a connection with the controller(Arduino Mega in our case), it would energize the motors and enable the drivers but when I send $slp(after making reset and unlock) it would immediately disable the drivers.

Does Grblhal suppose to do the same behavior described with GRBL Mega 5x ? Because if it won't do that what would exactly $slp do to the machine?

You said here

This is not how it is implemented. Sleep mode is only entered if in idle or alarm state on a $slp command.

But when I send $slp in idle, the motor enable signal does not change!

[terjeio]

I have made update to the code with the latest update and I am still having the same issue!

Are you sure you have compiled with your map file? Check with the $i and/or $pins command. E.g. $i should show your board name in the [BOARD:<name>] element.

[muhammadelmogy]

This what I get When I send $i

$i [VER:1.1f.20230302:] [OPT:VNHSL2,35,1024,3,0] [AXS:3:XYZ] [NEWOPT:ENUMS,RT+,HOME,TC,SED] [FIRMWARE:grblHAL] [NVS STORAGE:*EEPROM] [DRIVER:STM32F411] [DRIVER VERSION:230227] [BOARD:Mlabs Controller] [AUX IO:2,2,0,0]

Here the whole project Mlabs-Controller.zip

I am not really sure If I made the update right or not because the project has submodules and I never really did any work before with submodules so what I did after is fetch latest updates from github and run git submodule update --init --remote I got it from here https://stackoverflow.com/a/19621245/309057

I could use some help on how to make proper update in the future!

[terjeio]

[BOARD:Mlabs Controller]

Then compilation is ok (I assume the $pins command shows [PIN:PB2,Steppers enable] - please check) . When I jog or stream gcode PB2 changes state as it should. Tested with adding your map file to my master version. I have also tested ok with inverted enable signal. So what can be wrong on your side?

I am not sure what do you mean by bad CPU?

This is one option, the pin is damaged on the prosessor.

I could use some help on how to make proper update in the future!

Info can be found in the core Wiki.

Here is the binary I tested with:

GRBL Driver STM32F401.zip

Note that I changed PWM output to PB9 to get it to compile. Is this working for you?

[muhammadelmogy]

This is from $pins

$pins
[PIN:PA14,Reset]
[PIN:PA8,Feed hold]
[PIN:PB15,Cycle start]
[PIN:PA15,Probe]
[PIN:PB7,X limit min]
[PIN:PB6,Y limit min]
[PIN:PB4,Y limit min 2]
[PIN:PB5,Z limit min]
[PIN:PC14,Aux input 0,P0]
[PIN:PC13,Aux input 1,P1]
[PIN:PA0,X step]
[PIN:PA2,Y step]
[PIN:PA4,Z step]
[PIN:PA6,Y2 step]
[PIN:PA1,X dir]
[PIN:PA3,Y dir]
[PIN:PA5,Z dir]
[PIN:PA7,Y2 dir]
[PIN:PB2,Steppers enable]
[PIN:PB2,Y enable]
[PIN:PB12,Spindle on]
[PIN:PB14,Spindle direction]
[PIN:PC15,Flood]
[PIN:PB13,Aux out 0,P0]
[PIN:PB14,Aux out 1,P1]
[PIN:PB8,SCK]
[PIN:PB9,SDA]
[PIN:PB10,Spindle PWM]

It seems the attached bin file is for f401 not f411! Can you double check the binary file and uploaded for F411 if possible? Thanks

[muhammadelmogy]

BTW I have tested the code on other board (stm32f411) and I am having the same behavior for $slp!

[terjeio]

It seems the attached bin file is for f401 not f411!

It is for the F411 - ignore the name.

BTW I have tested the code on other board (stm32f411) and I am having the same behavior for $slp!

How can you check the behaviour when the enable pin is not working?

[muhammadelmogy]

I did mention in the first post that it does not change state not it is not working

When I change it to non inverted signal, the signal on the enable pin goes high but also the state does not change at all after that!

Let me describe what I am facing again in more details because may be I could not do that since I was so focus on my own way of understanding the $slp function When I connect the USB cable to the board the enable pin goes high if the Inverts the stepper driver enable signals is not selected and if I select Inverts the stepper driver enable signals the pin state change to low.

When I am not selecting Steppers deenergize the enable goes high when making jogging or when moving with gcode and then goes low as soon as the command finish and when I select Steppers deenergize the enable signal is always high

In all the previous cases the $slp does not has effect on the enable pin but when I am not selecting Steppers deenergize and set step idle delay to 255 and send $slp and after that make a reset only in this case the enable pin change state and goes low which in return disable the drivers .

When I was using Grbl Mega 5X as soon as I send $slp in Idle the drivers would be disabled but when I send $slp in Idle nothing happens unless I send reset!(in the last mentioned case)

I hope it is now clear what I am facing here.

[muhammadelmogy]

By the way I tested the bin file and it is still the same issue!

[terjeio]

I hope it is now clear what I am facing here.

This helps - my initial understanding was that the stepper enable signal was not working at all and that you could not use the $slp command to stop motors moving.

When rewriting the main state machine some years ago I did not implement sleep mode correctly, this should now be corrected in the latest commit. Please report back if still not working, and sorry for the misunderstanding.

[muhammadelmogy]

Fix Confirmed! Thanks for your efforts