terjeio
commented
2 days ago First press of hardware START button on GRBL often ignored by IoSender.
Is the signal even reaching the sender? Legacy Grbl and older grblHAL versions did not send the status if the hardware button was not pressed when a real-time request was prepared by the controller. A workaround for this is to press the button long enough for it to be reported.
Also, there is an interlock mechanism in ioSender that suppresses the first cycle start keypress, this is to block accidental motion that was reported by a user (or users). It may be this that is interfering as well, and it is tricky to solve in a safe way. I do not remember the exacrt reason now, but part of it could be due to many not wiring hardware buttons resulting in the S (and H) state beeing always reported.
returning from this state require to push Pause than Stop button.
Hmm, I guess harware cycle start should be should be ignored during an alarm?
IoSender 2.0.45.P12 and all 2.0.45 ; 1.1ha.20201101 ; [OPT:VPR+,15,128]
First press of hardware START button on GRBL often ignored by IoSender. It's normally decoding button pressed, light-up red "S" on DRO, but doing nothing. Usually second press of the same button starting current G-code streaming. This condition often usually registered after opening program and setting working Zero or probbibg to set TLO offset. Console output for 2 consecutive button press:
It's also incorrect state indication if START button pressed during GRPL Alarm state - IoSender indicating Alarm, but after presing START button, GRBL returning alarm
error:9 - G-code lock: G-code commands are locked out during alarm or jog state.but IoSender blocking CircleStart and FeedHold, enabling Pause button and still indicating red Alarm machine state sign. returning from this state require to push Pause than Stop button.