Closed Tahutipai closed 5 years ago
It's a safety issue. How can you be sure the machine's location if you just connected?
Good question, safety first. In this specific case, because the machine is programatically controlled. Homing is the first task performed, and hard limit switches are in place.
I believe I am coming close to a solution: it appears pyserial
may be toggling the DTR line, which arduino's take as a reset. So this would explain why a MCU reset is caused just by opening a serial connection....
https://github.com/gnea/grbl/issues/160 https://github.com/pyserial/pyserial/issues/124
Yes its normal. In the config.h there is a command to issue a safety lock on startup which you can disable if you don't want it to operate that way.
`// If homing is enabled, homing init lock sets Grbl into an alarm state upon power up. This forces // the user to perform the homing cycle (or override the locks) before doing anything else. This is // mainly a safety feature to remind the user to home, since position is unknown to Grbl.
However Industrial machines start up in some sort of safety lock out, it deliberate as you don't want a machine thrashing about and the spindle starting without any warning on startup. You are correct that arduino's are reset when serial communication is connected this is a method used by the micro to establish and synchronise a serial connection. Both are good, in my book i think its better to learn how to machine properly.
Thankyou. I do indeed wish the safety lock out (alarm) to occur after a power cycle, but I do not wish the alarm to occur when simply making a serial connection. (serial connections will be pragmatically controlled)
In my specific circumstances, this is for an experimental (non-cnc) manufacturing machine, with no spindle or similar dangerous parts, that GRBL happens to be otherwise perfect for controlling.
Solution for future readers: 1) Realising that all arduino's, by default, reset simply by opening a serial connection. (nothing to do with GRBL, but as GRBL has "rebooted", this means the alarm will be on. 2) This behaviour can, in theory, be turned off in your OS. 3) I was unable to find success with the above on my Linux box, so I went with the hardware solution of just placing a 10uF capacitor between Reset and GND.
This worked a charm, and now homing is still required after a power cycle, but not after just establishing a serial connection.
For anyone interested in following this further, here is a link to a hack that might work
It involves recompiling the cdc_adm
driver.
I connect a hc-06 bluetooth Modul to the rx/tx Pins of the Arduino , Corse i had Problems with usb cable with more than 3 m. No reset at reconnect !
hc-06 has no reset pin. so it's usually not possible to reset the device. check google for reset mods with hc-06 or hc-05 moduls.
That's a good tip. Though, I suspect @matze-mm posted that info as a solution rather than a problem.
It is beneficial, in some setup's, to have (effectively) alarm-on-power-cycle
but not alarm-on-serial-connect
Yes , this Should be a tip, Sometimes there is a Problem to connect an Running arduino to your pc‘s usb . Especialy when you run with different powersources. Arduino Crashs and/or make an reset. With Bluetooth you dont have this Problem. You have only to connect at usb-cable to Programm. The Boud-Rate of 115000 is no Problem. I run my diy Cnc Router with grbl and on my mac Runs grblgru to send the gcode . Sorry , Hope you unterstand my Bad englisch
Matze What bad English.
I was reading back through an old issue post yesterday where the same issue was mentioned with regards to using grbl panel. I didn't even realise my machine had the issue. On grbl panel it manifests itself as not showing the digital readout XYZ work coordinates on connection to some grbl controllers. I was subconsciously pressing reset on the panel to refresh the screen before homing the machine. My machine is using a home built grbl control board/pcb, its connection to the PC is via a USB to RS232 and RS232 to TTL conversion, it looks like my setup is missing a few handshakes.
The advice for the issue to one user was to increase the connection delay in/for grbl panel
@matze-mm Matze,
Your English is very clear, can understand you perfectly. What is your native tongue? Hebrew perhaps? It is very difficult communicating in a forign language - especially one that has a totally different alphabet, and writes in a different direction too, like English for example.
For sure your skills in English are much better than mine in any other language.
Thankyou for sharing your good tip with the community!
Better than mine also and i'm English (not British)
Just to be clear. The Arduino boot loader automatically forces a reset of the controller upon a serial connection. This is not something controlled by Grbl. When a reset occurs, all memory is wiped and Grbl has to start in an alarm state, as it no longer knows where it is. I believe you can get around this issue by flashing Grbl without a boot loader and/or using a separate USB serial connection directly connected to the RX/TX pins. You can also disable Grbl’s auto-alarm in config.h, if you find it annoying, but this is strongly not recommended, as this can lead to more issues at the worst possible times.
Thanks. In hindsight, the easiest solution was just to put a 10uF capacitor between Reset and GND.
Pros: Took just 20 seconds to install, no soldering (just screws in), is an easy reversible modification.(can just remove it).
This removes the undesired ardiuno reset-upon-serial-connect
behaviour, while still retaining the desired alarm-after-power-cycle
functionality.
Cons: Need a 10uF capicator on hand.
I'm getting the same error 9, when trying to establish a connection with the cnc via raspi terminal my error:
sudo chmod +777 /dev/ttyUSB0 # 2. allow access to printer USB permissions, add user to dialout or tty is better
stty 115200 -F /dev/ttyUSB0 -echo -onlcr # 3. set serial port baud rate, might be 250000 for you
cat -v < /dev/ttyUSB0 # 4. get printer output
After passing in the commands I get back a message confirming that a connection has been made:
Grbl 1.1e ['$' for help]
[MSG:'$H'|'$X' to unlock]
I open a new terminal and use the second terminal to echo g code to the first which then should move the machine to where i want it
echo "G28" >> /dev/ttyUSB0
Once I pass the above command in the second terminal I get the following response in the first
error:9
I have tried echoing $X
& $H
"to unlock" i get a response back saying ok
then I try echo the homing command and get the same error showing up: error 9
Im not currently using linux, but are you sure each echo doesnt open the port again irrespective of the intended append >>
you could try tee -a /dev/ttyUSB0 or try bash | tee /dev/.. which will forward the result of each subsequent echo
or put 2 lines in a file and cat file > /dev/tty as a test dont know if you need dos line endings though
How does the OpenBuilds CONTROL GUI not have this issue? There is no alarm when reconnecting:
Here's a log of connect-unlock-disconnect-connect sequence:
[19:55:26] [ connect ] PORT INFO: Port is now open: COM5 - Attempting to detect Firmware
[19:55:26] [ connect ] Checking for firmware on COM5
[19:55:26] [ connect ] Detecting Firmware: Method 1 (Autoreset)
[19:55:26] [ connect ] Detecting Firmware: Method 2 (Ctrl+X)
[19:55:27] [ connect ] Detecting Firmware: Method 3 (others that are not supported)
[19:55:27] [ ] Grbl 1.1g ['$' for help]
[19:55:27] [ ] [MSG:'$H'|'$X' to unlock]
[19:55:28] [ $$ ] $0=10 ;Step pulse time, microseconds
[19:55:28] [ $$ ] $1=255 ;Step idle delay, milliseconds
[19:55:28] [ $$ ] $2=0 ;Step pulse invert, mask
[19:55:28] [ $$ ] $3=3 ;Step direction invert, mask
[19:55:28] [ $$ ] $4=1 ;Invert step enable pin, boolean
[19:55:28] [ $$ ] $5=0 ;Invert limit pins, boolean/mask
[19:55:28] [ $$ ] $6=0 ;Invert probe pin, boolean
[19:55:28] [ $$ ] $10=1 ;Status report options, mask
[19:55:28] [ $$ ] $11=0.010 ;Junction deviation, millimeters
[19:55:28] [ $$ ] $12=0.002 ;Arc tolerance, millimeters
[19:55:28] [ $$ ] $13=0 ;Report in inches, boolean
[19:55:28] [ $$ ] $20=0 ;Soft limits enable, boolean
[19:55:28] [ $$ ] $21=1 ;Hard limits enable, boolean
[19:55:28] [ $$ ] $22=1 ;Homing cycle enable, boolean (Grbl) / mask (GrblHAL)
[19:55:28] [ $$ ] $23=0 ;Homing direction invert, mask
[19:55:28] [ $$ ] $24=25.000 ;Homing locate feed rate, mm/min
[19:55:28] [ $$ ] $25=500.000 ;Homing search seek rate, mm/min
[19:55:28] [ $$ ] $26=250 ;Homing switch debounce delay, milliseconds
[19:55:28] [ $$ ] $27=1.000 ;Homing switch pull-off distance, millimeters
[19:55:28] [ $$ ] $30=1000 ;Maximum spindle speed, RPM
[19:55:28] [ $$ ] $31=0 ;Minimum spindle speed, RPM
[19:55:28] [ $$ ] $32=0 ;Laser-mode enable, boolean
[19:55:28] [ $$ ] $100=252.000 ;X-axis steps per millimeter
[19:55:28] [ $$ ] $101=252.000 ;Y-axis steps per millimeter
[19:55:28] [ $$ ] $102=504.000 ;Z-axis steps per millimeter
[19:55:28] [ $$ ] $110=500.000 ;X-axis maximum rate, mm/min
[19:55:28] [ $$ ] $111=500.000 ;Y-axis maximum rate, mm/min
[19:55:28] [ $$ ] $112=500.000 ;Z-axis maximum rate, mm/min
[19:55:28] [ $$ ] $120=10.000 ;X-axis acceleration, mm/sec^2
[19:55:28] [ $$ ] $121=10.000 ;Y-axis acceleration, mm/sec^2
[19:55:28] [ $$ ] $122=10.000 ;Z-axis acceleration, mm/sec^2
[19:55:28] [ $$ ] $130=190.000 ;X-axis maximum travel, millimeters
[19:55:28] [ $$ ] $131=200.000 ;Y-axis maximum travel, millimeters
[19:55:28] [ $$ ] $132=100.000 ;Z-axis maximum travel, millimeters
[19:55:28] [ $$ ] ok
[19:55:29] [ $I ] [VER:1.1g.20181112:]
[19:55:29] [ $I ] [OPT:V,15,128]
[19:55:29] [ $I ] ok
[19:55:29] [ $G ] [GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
[19:55:29] [ $G ] ok
[19:55:30] [ connect ] Firmware Detected: grbl version 1.1g on COM5
[19:55:30] [ ] Grbl 1.1g ['$' for help]
[19:55:30] [ ] [MSG:'$H'|'$X' to unlock]
[19:55:30] [ ] [MSG:Caution: Unlocked]
[19:55:31] [ ] ok
[19:55:34] [ disconnect ] PORT INFO: Port closed
[19:55:36] [ connect ] PORT INFO: Port is now open: COM5 - Attempting to detect Firmware
[19:55:36] [ connect ] Checking for firmware on COM5
[19:55:36] [ connect ] Detecting Firmware: Method 1 (Autoreset)
[19:55:36] [ ] ok
[19:55:37] [ connect ] Detecting Firmware: Method 2 (Ctrl+X)
[19:55:37] [ ] Grbl 1.1g ['$' for help]
[19:55:39] [ $$ ] $0=10 ;Step pulse time, microseconds
[19:55:39] [ $$ ] $1=255 ;Step idle delay, milliseconds
[19:55:39] [ $$ ] $2=0 ;Step pulse invert, mask
[19:55:39] [ $$ ] $3=3 ;Step direction invert, mask
[19:55:39] [ $$ ] $4=1 ;Invert step enable pin, boolean
[19:55:39] [ $$ ] $5=0 ;Invert limit pins, boolean/mask
[19:55:39] [ $$ ] $6=0 ;Invert probe pin, boolean
[19:55:39] [ $$ ] $10=1 ;Status report options, mask
[19:55:39] [ $$ ] $11=0.010 ;Junction deviation, millimeters
[19:55:39] [ $$ ] $12=0.002 ;Arc tolerance, millimeters
[19:55:39] [ $$ ] $13=0 ;Report in inches, boolean
[19:55:39] [ $$ ] $20=0 ;Soft limits enable, boolean
[19:55:39] [ $$ ] $21=1 ;Hard limits enable, boolean
[19:55:39] [ $$ ] $22=1 ;Homing cycle enable, boolean (Grbl) / mask (GrblHAL)
[19:55:39] [ $$ ] $23=0 ;Homing direction invert, mask
[19:55:39] [ $$ ] $24=25.000 ;Homing locate feed rate, mm/min
[19:55:39] [ $$ ] $25=500.000 ;Homing search seek rate, mm/min
[19:55:39] [ $$ ] $26=250 ;Homing switch debounce delay, milliseconds
[19:55:39] [ $$ ] $27=1.000 ;Homing switch pull-off distance, millimeters
[19:55:39] [ $$ ] $30=1000 ;Maximum spindle speed, RPM
[19:55:39] [ $$ ] $31=0 ;Minimum spindle speed, RPM
[19:55:39] [ $$ ] $32=0 ;Laser-mode enable, boolean
[19:55:39] [ $$ ] $100=252.000 ;X-axis steps per millimeter
[19:55:39] [ $$ ] $101=252.000 ;Y-axis steps per millimeter
[19:55:39] [ $$ ] $102=504.000 ;Z-axis steps per millimeter
[19:55:39] [ $$ ] $110=500.000 ;X-axis maximum rate, mm/min
[19:55:39] [ $$ ] $111=500.000 ;Y-axis maximum rate, mm/min
[19:55:39] [ $$ ] $112=500.000 ;Z-axis maximum rate, mm/min
[19:55:39] [ $$ ] $120=10.000 ;X-axis acceleration, mm/sec^2
[19:55:39] [ $$ ] $121=10.000 ;Y-axis acceleration, mm/sec^2
[19:55:39] [ $$ ] $122=10.000 ;Z-axis acceleration, mm/sec^2
[19:55:39] [ $$ ] $130=190.000 ;X-axis maximum travel, millimeters
[19:55:39] [ $$ ] $131=200.000 ;Y-axis maximum travel, millimeters
[19:55:39] [ $$ ] $132=100.000 ;Z-axis maximum travel, millimeters
[19:55:39] [ $$ ] ok
[19:55:39] [ $I ] [VER:1.1g.20181112:]
[19:55:39] [ $I ] [OPT:V,15,128]
[19:55:39] [ $I ] ok
[19:55:39] [ $G ] [GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
[19:55:39] [ $G ] ok
[19:55:40] [ connect ] Firmware Detected: grbl version 1.1g on COM5
[19:56:13] [ ? ] <Idle|MPos:0.000,0.000,0.000|FS:0,0|Ov:100,100,100>
I am trying to programmatically small batches of gcode commands, via grbl's
stream.py
.The problem I have is: every time I open a new serial connection, "Alarm Mode" is on - the device requires either rehoming, or a "$X", every single time I just open a serial connection to the device. (e.g
screen /dev/ttyUSB0 11520
)I have tried adding "$X" as the first command in my list of gcodes to send, in the hope that it would turn off the alarm when connecting, but this doesn't seem to work.
How can I simply stream a list of gcode's to the device, if homing is enabled? Homing every single time is not a workable solution.