Better disconnect handling

Right now the only option on disconnect is re-connect, then initialize. The initialize procedure is not perfectly reproducible, so you can easily end up with your zero moving a small but noticeable amount.

CM should determine if a program was running at the time of the disconnect, and then be a bit smarter about initialization.

Disconnect -

On connection - Was CM running a program?

Y - Ask the user, was this an emergency stop or an unexpected disconnect?

E-Stop - re-initialize.

unexpected - Accept current position as accurate.

1 Like

I think one thing that might make this difficult is that the machine doesn’t know where the spindle is when you turn it on.

It’s like a person waking up in a dark room. They have to shuffle around slowly to find the walls before they can figure out a fixed location. From that point on, they need to count what steps they take to determine their position relative to that fixed location.

I guess CM could assume the spindle is where it last instructed it to go and then tell the machine it’s at that position. But if CM had sent the machine an instruction to move just as it disconnected, it wouldn’t know if the machine actually got to the target location or not, or if it stopped somewhere in between.

1 Like

I am assuming that the ‘unexpected disconnect’ is not a power reset on the shapeoko, so you can just query GRBL where the position is using ‘?’.

If CM detects that GRBL has reset, then a homing sequence is probably a good idea.

I’ve only had two or three disconnections.

Each time I’ve had to power-cycle the Shapeoko to get CM to connect again. My experience is not great here so perhaps there are occasions where that is a power cycle is not required.

Yeah,

The re-homing is really irritating, it seems to happen after a STOP on a toolpath, for example, when you want to change the feed speed in CAM and not wait 30 mins for the current toolpath to finish, pause then stop seems to trigger a re-home.

I now only run toolpaths that leave the zero probing material in place as losing zero due to USB disconnect or wanting to stop and tweak a toolpath happen too frequently to ignore.

I understand from the software side of things that you don’t know the state after a disconnect but it would be nice to

  • Try to read current position from the machine, perhaps run homing as a validate and throw a warning if it is out by more than 0.5mm or so?
  • Not force a re-zero after a soft stop on a toolpath

I think the fundamental issue is the controller board’s notion of the spindle’s position is only reliable if no motion has occurred that it hasn’t initiated.

So these sorts of strategies only work if there is a USB disconnection that doesn’t require the controller board to be reset, and where there was a disconnection and the spindle stopped moving at the explicit request of the controller board and hasn’t moved since.

Do such disconnections occur?

No…

2 Likes

Hmm,

I’ve had quite a few where unplugging and re-inserting the USB connector to the laptop re-connected to the Carbide controller without power cycling the machine. I guess that’s more a comment on the USB port on this old macbook than the controller…

4 Likes

I have not tried that.
When or if I have another disconnect, I will give that a shot, Thanks.

1 Like

You still have to tell Carbide Create to initialize but it’s better than a full power cycle.

Sorry about my brief reply earlier…got distracted.
I believe that the Carbide3D boards are designed such that the controller is automatically reset on establishing a connection (most arduino-based designs are). If I’m correct about the board design (been a while since I poked around on one), the any disconnect/reconnect would aslo involve a grbl reset.

1 Like

Aha, now that would both be logical and explain why CC has to start with an “initialize machine” to kick off.