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?
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.
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.
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.
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.
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ā¦
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.