-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Warn if pending jog will (implicitly) re-enable spindle / laser #63
Comments
Are you saying you want to poll the controller to see if the spindle/laser is active before a command of any kind is issued? Or are you saying that you want to analyze the gcode and check if there is a rapid move coming up before an M5 is issued? |
Shortly before writing up this issue I was at my CNC machine and I had turned turned the spindle on (M3 S10000). While the spindle was running, I executed a Machine Home. The spindle powered down. Curious at this point I then did a jog to a "safe" location. The spindle spun back up as it moved to that position. Seemed a smidge dangerous so I'm thinking a simple check is needed prior to a framing operation, jog / work home that warns you if the machine is not in M5 and S > {weak laser} value. I've got x, y, z, speed, power, state, and mode all defined as individual variables today. This would be a good time to consolidate them into a dict and pass them along to the view models that need them (tab and sidebar). A couple nights ago I put in the hooks for catching the current state of the spindle mode / power level by integrating $G into the plugin connection logic. With bgs keeping track of them from that point forward (it continuously monitors the outbound buffer) the plugin always knows what their values are.
|
It is possible to have M3 active with S > 0 prior to executing something such as a machine home or jog. The behavior is inconsistent between them which can lead to the spindle / laser powering back on.
For example:
Insert a warning / confirmation request at the beginning of step 4 if M3 /M4 are active and S>{weak laser value}.
The current values ($G results),as well as mode, state, x, y, z should be placed in a shared dict and the existing individual variables removed.
The text was updated successfully, but these errors were encountered: