Closed gitxmax closed 3 years ago
you might need to invert the estop and door input pins in grbl settings (or have jumpers to gnd on the actual pins)
[edit] maybe the default for those two settings should be inverted. so many people hit this issue.
Looking at the code, the defaults for door switch and limit switches check are disabled, why would this cause the issue then?
estop?
On Sat, Nov 21, 2020 at 12:22 PM gitxmax notifications@github.com wrote:
Looking at the code, the defaults for door switch and limit switches check are disabled, why would this cause the issue then?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/terjeio/grblHAL/issues/120#issuecomment-731631750, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6NUTX2HFSW7Z4URVIU22LSRAOQTANCNFSM4T57MSTA .
Don't see any settings for the estop in STM32F103 driver, either to enable or disable. According to Gcode Sender docs, Error 18 is "Reset asserted", but I have no clue, what it means..
It is a Grbl Setting. If you you are using ioSender it's 14 in the Settings: Grbl tab. Or you can do $14=64 via a terminal app.
GRBL configuration is locked, it says Read and write enabled only when connected and idle .. I tried $14=64 via terminal, no joy
From a terminal window what does ?
respond with? If there is a R
in the Pn:
part the the reset pin is asserted. Try $14=1 to invert it. grblHAL is different from grbl in several ways, one is that default switch configuration is for normally closed (NC) switches instead of normally open (NO). Another is that if the reset or estop input is asserted it will refuse to unlock for safety reasons.
To complicate this a bit the iMXRT1060 has the estop input enabled "out-of-the-box" instead of reset - the two have nearly identical behaviour, estop beeing a little less agressive in clearing data than reset.
$14=1 did the trick Grbl settings are missing $14 field, for some reason
Grbl settings are missing $14 field, for some reason
You mean LaserGrbl does not recognize $14? This is due to grblHAL having many more settings available than grbl have, some brand new, some moved from compile time configurations.
In the next build I am making it easier for sender developes wanting to support grblHAL by providing details about settings (and other code sets) via $-commands. If used by a sender new settings will be instantly visible/available.
it seems to recognize, as it fixed the alarm. But when I pull all the grbl settings, $14 line is not there.
But when I pull all the grbl settings, $14 line is not there.
It shows up when I list the settings with the $$ command from a terminal such PuTTY. I does not for you?
GrblHAL 1.1f ['$' or '$HELP' for help]
$0=10.0
$1=25
$2=0
$3=0
$4=0
$5=0
$6=0
$10=511
$11=0.010
$12=0.002
$13=0
$14=0
$15=0
$16=0
...
One short addition: I tried $RST=*
to reset the settings, but that did not change anything (other than going to ALARM
because of the no longer inverted EStop control pin which I did for testing)
Hello, For my laser engraver, was previously running 6-axis-usbcnc and decided to try the GrblHal Compiled with Stm32CubeIde. The only 2 setting I have changed, is disabling USB_SERIAL_CDC, (as I'm not using the built-in usb port) and changing COMPATIBILITY_LEVEL to 10. hex file flashed with St-Link V2
When I try to connect to LaserGrbl, it connects with Status "Alarm" Resetting the board and doing unlock, returns "Error:18" message Applying "$RST=*" makes no difference