You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are developing a machine that can cut and mark textile.
In our configuration, we are using M7/M9 to command a relay thanks to the 'coolant' output. This allows us to direct the spindle signal to the primary or secondary tool, and thus change tool easily from the g-code.
Problem
Unfortunately we noticed that when a door sensor or our emergency button was triggered, GRBL would reset the 'coolant' state. In our case, it means that we revert to the default tool. So if we trigger a door signal mid-shape, we then resume with the wrong tool.
What we tried
In protocol.c, We commented the de-energizing of the coolant when going into sleep state (line 622). So now the coolant isn't reset when triggering a door, however, when sending the resume signal it resets a second time apparently.
What we need
We couldn't find a way to prevent this behaviour, could someone help us find a solution please.
We would like the coolant state to be unaltered by door/alarm/hold or any such signal, considering it only select the tool, it can't activate it.
Thank you in advance for your help.
The text was updated successfully, but these errors were encountered:
Hello,
Context
We are developing a machine that can cut and mark textile.
In our configuration, we are using M7/M9 to command a relay thanks to the 'coolant' output. This allows us to direct the spindle signal to the primary or secondary tool, and thus change tool easily from the g-code.
Problem
Unfortunately we noticed that when a door sensor or our emergency button was triggered, GRBL would reset the 'coolant' state. In our case, it means that we revert to the default tool. So if we trigger a door signal mid-shape, we then resume with the wrong tool.
What we tried
In protocol.c, We commented the de-energizing of the coolant when going into sleep state (line 622). So now the coolant isn't reset when triggering a door, however, when sending the resume signal it resets a second time apparently.
What we need
We couldn't find a way to prevent this behaviour, could someone help us find a solution please.
We would like the coolant state to be unaltered by door/alarm/hold or any such signal, considering it only select the tool, it can't activate it.
Thank you in advance for your help.
The text was updated successfully, but these errors were encountered: