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.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.