BitRunner and losing connection

CNC Machines Shapeoko
1

Question about the BitRunner when Carbide Motion loses connection for any reason, should it tell the BitRunner to cut power to the router?

2

If you get a disconnect the router will continue to run. If you pause then stop the router will shut down. The BitRunner gets gcodes signals. If you lose communication there will be no gcode sent to the bitrunner so it will not shutdown.

1 Like
3

I’m not sure that is quite the way it works. I think its the Carbide Motion Board which receives the gcode which in turn sends a control signal to the BitRunner. The logic on the Carbide board knows it has lost connection because it stops receiving gcode so it ought to be able to send a signal to the BitRunner to cut the power to the router.

4

When I get home tonight I will verify operation. I am in Nacgodoches Tx picking up some supplies.

5

I know it doesn’t, I’m just supposing that it could/ should cut the power.

6

When I got home I cut a project out. The job finished. I started the job over and after the router turned on and headed over to cut and starting cutting I pulled the usb cable out from my computer. The router stayed on and just stopped where it was, running.

I know when you hit pause during a job the router lifts and then shuts off with the BitRuner. If you then hit stop the router returns to the rear with the router still off.

Before BitRunner if you hit pause and then stop the router kept running until you manually shut it off.

7

The BitRunner works off the “PWM” signal that is generated by the Shapeoko’s controller board when it receives an “M3” command (spindle start). The controller runs a vanilla version of GRBL software, and as far as I know GRBL’s internal logic is to just listen for incoming commands, and react to them, in a loop. When a CM disconnect happens, I think GRBL does not know, from its standpoint there are just no commands coming in, and it can be a normal situation (well in practice the controllers tend to poll GRBL continuously for current status, but GRBL can’t assume that they will).
It would be a good idea to shutdown PWM (and therefore the router when using a BitRunner) when USB communication arise, but this would have to be managed in GRBL code, and I’m afraid it could tricky for GRBL to find a robust (and non-Shapeoko-specific) way to detect loss of communication with the host.

Maybe @chamnit can chime in and correct me, I confess to not having search the GRBL repo for questions around how GRBL handles USB comm issues.

2 Likes
8

Hi Julien,
Thanks for your input here, I was hoping you’d but in!
So what you are saying is there is no other logic control on the Carbide board other than the GRBL code running/ processing. So it does not know what state its in as in connected or not or whether it has switched on the router or not. It just polls for GRBL code to process and nothing else?

The reason I asked this was because this happened to me while I was cutting MDF (before my CM board flaked out different story) and the cutter stopped moving whilst cutting a slot. I did not realise for maybe a minute or so until the sound difference registered I then hit the emergency stop. It was concerning because of the obvious risk of fire. Other than vigilance is there any other way to mitigate this risk? I love the BitRunner by the way.
Thanks
Mark

2 Likes
9

My uneducated thoughts would be some basic logic running on the board as in 4 states 1. Idle 2. processing code 3. Paused and 4. timed out as in a disconnect.

2 Likes
10

I found this gcode M85: Set inactivity shut down timer
Edit: I just checked the Shapeoko gcode wiki and M85 is not listed as supported. But in the same wiki under GRBL code not supported M85 is not listed so does GRBL support M85 but Carbide Motion does not?? or do I just not get it.

2 Likes
11

Yes

Yes. GRBL manages various machines states: Idle, Run, Hold, Jog, Alarm, Door, Check, Home, Sleep. But (again, to the best of my knowledge) it cannot assume that the host computer will continuously send data, not in Idle (because it’s a normal state that the host would do nothing), and not in Run mode because arbitrarily long pauses are allowed, so GRBL cannot just consider that an absence of commands from the host is a problem.

I’m afraid not, not without modifying GRBL.

It could do that, with the caveat mentioned above that it is not easy to know whether the host not communicating/sending commands is abnormal or not. The easiest would be a timeout indeed, but whether this timeout could be set to a relevant value is another question (if the longest valid period with no commands from the host was set to, say, 30 seconds, G-code delays would be limited to 30 seconds (not a big deal), but 30 second could be too long in your “router is rubbing in MDF” scenario.

This seems to be a specific G-code implemented in 3D printer (e.g. Marlin firmware, a remote sibling of GRBL), to shutdown the printer after a job.

The current version of GRBL does not implement it:

List of Supported G-Codes in Grbl v1.1:
  - Non-Modal Commands: G4, G10L2, G10L20, G28, G30, G28.1, G30.1, G53, G92, G92.1
  - Motion Modes: G0, G1, G2, G3, G38.2, G38.3, G38.4, G38.5, G80
  - Feed Rate Modes: G93, G94
  - Unit Modes: G20, G21
  - Distance Modes: G90, G91
  - Arc IJK Distance Modes: G91.1
  - Plane Select Modes: G17, G18, G19
  - Tool Length Offset Modes: G43.1, G49
  - Cutter Compensation Modes: G40
  - Coordinate System Modes: G54, G55, G56, G57, G58, G59
  - Control Modes: G61
  - Program Flow: M0, M1, M2, M30*
  - Coolant Control: M7*, M8, M9
  - Spindle Control: M3, M4, M5
  - Valid Non-Command Words: F, I, J, K, L, N, P, R, S, T, X, Y, Z

Maybe it could be added in the GRBL code, then you would have to either set it to a value large enough that the nominal job can finish (which would make it useless from a protection standpoint, in long jobs), or set it to a small value and keep inserting it every N lines in the G-code file to restart the timer continously. And then you would have to be really cautious about all the false positive detections of inactivity, or people would get mad that they job got interrupted mid-run for no good reason.

So I guess the bottomline is

  • to try and eradicate USB disconnects instead. There are a number of things that can be done to minimize the occurrence, but I am quite aware that in some setups, for a variety of reasons it is difficult to reach the “no disconnect, ever” state.
  • keep an ear (if not eye) on the cut (which in my book is best practice anyway). A machine that is not moving/not cutting anymore while the router is still on is easy to recognize by ear.

All that said, I like your idea of some kind of self-detection of disconnects inside GRBL so that it goes to a failsafe state. Hopefully GRBL’s developer (@chamnit) will see this message and share his insights on the matter, which ought to be much better than mine.

3 Likes
12

Hi Julien,
Thanks for that in depth analysis. So relying on GRBL as a failsafe is not really practical. In that case some sort of “Keep alive” on the USB/ Serial circuit separate to GRBL, but as we have established there is no other logic on the CM board. This is an important safety issue but I must admit as a programmer its sucking me in.

13

You could still have GRBL in the loop (I have yet to hear about a GRBL reliability issue), but the question would be how to send it the information that the USB comms went down. If you felt adventurous, and knew your way around the MacOS/Windows USB stack, a possibility could be to have the G-code sender monitor the USB status, detect a loss of comms, and in that case activate a local relay/switch that would trigger the “feedhold” input on the Shapeoko controller: GRBL would detect the feedhold signal activation, and would execute the “safe retract & stop spindle” routine. Interesting week-end hack, but not a practical solution for “regular” users.

2 Likes
14

Now that is intriguing

15

Apologies for sending you down that rabbit hole, in case you want to know more about the (physical) feedhold input, we discussed that in this thread:

16

Vigilance and a dedicated host. No surfing!

3 Likes
17

There is a ‘SLEEP’ state in the Grbl-Mega version that addresses USB disconnects. Grbl will expect a communication from the host within a fixed time, reset by the last comm. This is often handled by the host by sending ‘?’ status report queries. If Grbl does not receive a communication in time, it’ll automatically go to sleep, by shutting down the spindle/coolant and parking the machine. See config.h comment below on how it works.

It didn’t install this on the standard 328 build, because it wouldn’t fit with certain features enabled.

//Enables and configures Grbl’s sleep mode feature. If the spindle or coolant are powered and Grbl
// is not actively moving or receiving any commands, a sleep timer will start. If any data or commands
// are received, the sleep timer will reset and restart until the above condition are not satisfied.
// If the sleep timer elaspes, Grbl will immediately execute the sleep mode by shutting down the spindle
// and coolant and entering a safe sleep state. If parking is enabled, Grbl will park the machine as
// well. While in sleep mode, only a hard/soft reset will exit it and the job will be unrecoverable.
// NOTE: Sleep mode is a safety feature, primarily to address communication disconnect problems. To
// keep Grbl from sleeping, employ a stream of ‘?’ status report commands as a connection “heartbeat”.
// #define SLEEP_ENABLE // Default disabled. Uncomment to enable.
#define SLEEP_DURATION 5.0 // Float (0.25 - 61.0) seconds before sleep mode is executed.

8 Likes
18

Ha, I knew you would come and provide a killer answer, thank you.

By any chance, would these happen to be features that are not critical on a Shapeoko, so that one may consider forcing that in ?

3 Likes
19

That’s pretty cool


1 Like
20

So that’s hopeful then