The process you describe is a kind of checkpointing for hardware. Unless it’s a loss of communication between CM and the GRBL controller,if something goes wrong, the part will probably be damaged.
It’s probably possible to display the current gcode line, so if the communication stops you know where you are in the file. It may be possible to restart from this line assuming there is no dependency, skipping the portion that is already done.
More often than not (thus far) when something goes wrong it is one of the following: loss of connection between the pc and the nomad (thus the part is fine) or occasionally a stalled bit ( the part may or may not be fine). I have been lucky and the part was not damaged in all but 1 case. I have been able to recover but had to start the run from the start. So a more robust connection between pc and the nomad would be welcome ( thus solving this issue by eliminating the root cause). When it is a stalled bit ( typically in aluminum and when making a hole) i would really like the ability to recover without having to start over. It seems like there is a > 0% chance of every run failing for some reason and the longer the run the higher the chance of an issue. a waypoint feature would make the odds of completing a long run considerably higher.
Mark, something you may want to consider is putting some cutting fluid on the material when you’re trying to “drill” like that, and also slowing your plunge-rate to prevent overloading the bit. If you’re experiencing this as specific drilling operations as opposed to on the lead-in plunges, then you may want to run the drilling separately to allow you to keep lead-in plunges at a reasonable speed while slowing the drilling plunges down.
When you say the bit stalls, does the spindle stall out (the whole thing stops) or does the spindle keep spinning but the bit itself is not turning?
I have been using cutting fluid. The binding is of the entire spindle. typically when the bit reaches the far side of the part and breaks through. I am not so much drilling as machining a large round opening (5/8ths inch ) in a thick block of aluminum. Plunge is slow and step is small. As the bit breaks through the far side, something grabs and it stalls. Thus, at ~90% or more of the way done, the spindle has stopped but the nomad has moved on for the few seconds before I can pause the code. I can typically finish with the part intact once I clean out what ever snagged the bit. Unfortunately, I have to restart from the beginning.
some examples of the sort of work where this happens is over in the gallery.
I’m still hoping for some way to address bit fouling during a run.
Just posted a new beta. We added support for the Shapeoko, that should begin shipping tomorrow, and added a “Rapid Positioning” mode in jogging to get you to the corners of the table quickly.
Let me know what you think. I’d love to get this moved over to “released” and no longer beta.
-Rob
Wonderful! I will try it out too, although i just started a 6h job with the old version about 10 minutes before your post 
Oh well, there is always another carving!
I installed the new version and it doesn’t work. When I open the application a windows window opens and says that carbide motion doesn’t work anymore. I installed it in different ways and changed the compatibility settings but nothing worked …
What kind of PC and OS are running?
-Rob
My OS is Windows 8.1 64 Bit and I tested it on various PC’s but one is the Asus UX32LN. It has a i7 and 8GB ram.
My fault- a new version is posted now.
-Rob
Thank you! Now it works.
Thanks for the update. Let me know if anything comes up.
-Rob
so far so good. love the quick positioning.
Glad you like it. I think we’ll be adding drop down menus to pick additional features to reference like the dowel pin holes, flip jig (when it ships).
-Rob
I just d/l’d and installed the Carbide 2 Beta on my ThinkPad X61T running Windows Vista — the type looks ghastly.
Intel something or other graphics, 32-bit colour 1024 x 768.
I had a similar problem when I installed Carbide Motion on an older Dell Laptop. Rob advised that Carbide uses OpenGL and I found that Dells video card didn’t have an update for its video driver that old. I re-installed Carbide Motion on a newer computer and everything worked and looked the way it should. Give it a try on a newer computer and see how it works.
Why does this need OpenGL? It’s flat graphics and type.
The new computer angle is a bit of a sore point at the moment, due to Asus’s pathetic quality control and stupidly small and fiddly and confusable connectors and people doing instructions as videos.
The Qt framework that we depend on uses OpenGL heavily. They have an optional rendering system for Windows that I’ll be looking into but most of the OpenGL issues went away on their last update to Qt so we put that on hold.
Fair enough.
Some further observations:
- when it can’t connect, it says it can’t connect to a Nomad — update for the Shapeko 3?
- first time I tried to zero I wound up w/ -0.00 for X, 0,00 for Y and -0.02 for Z — despite pressing the relevant zero buttons repeatedly. Other times it was -0.00, 0,00 and -0.00 — while you’re looking at that, could you change the hyphen to a true minus symbol?
- is there a manual? I found this page: http://carbide3d.com/carbide-motion/ (which btw needs to be up-dated to mention that it’ll work w/ an SO3). I did find a couple of .pdfs on your site (one mentioned L for the log window and M for the MDI window)
- I brought up the latter, typed $$ and hit Send, but didn’t get settings (this was was the Carbide Motion Control Software beta and the Carbide Motion all-in-one board I just got w/ my SO3) — I was able to update $100 and $101 to 40 to get my machine moving properly for 1/8 microstepping though (once I also did this for $102 for the Z-axis)
Nifty and nice looking program — I just wish one didn’t have to toggle though so many windows — have you considered just having an array of tabs / buttons across the top of the window to switch between modes?
It would also be nice to have the option of either a progress meter, or a display of the toolpath and the machine’s progress along those.
Thanks!