-
Linux support won’t come now. We’re making lots of changes to the program and we’re not in a position to support another platform. Once it stabilizes, we might offer an unsupported Linux build. No promises but that’s what we’re thinking right now.
-
When the estop is hit, all chips in the device are held in reset and the drivers are disabled. Future versions might have a different behavior but in the current hardware, there’s no chip to respond when the estop is activated.
-
Carbide Motion does need better error recovery and this is a prime example. We’ll keep working on it.
-
The program zero is held in the PC so you could rerun a job in the morning but once the code begins running, it’s split between the PC and the embedded system so we don’t have any way to resume if the code is flushed from the Nomad. We’re committed to GRBL for motion control and this is a fundamental GRBL behavior so it’s not something we’d be able to change.
-
CM2 speeds up the pre-milling routine but it’s based on the principle of “Measure twice, cut once”. Any time the user may have caused the machine to lose position, it will rehome. We will probably add a “Don’t rehome” checkbox at some point for advanced users.
*We had an Apple employee give us some sleep mode guidance so we’ll be looking at that soon.
Thanks for the feedback. Don’t take my “It’s not going to happen” replies as a lack of interest, just an explanation of how it got to where it is. In some cases, it’ll take hardware changes to to modify the machine behavior.
-Rob