After playing a bit with CarbideMotion, here are some fixes and enhancements ideas. I used v2 (edit: I mistyped v6 initially but corrected to v2 later) Beta on Mac OS 10.10.2. None of the issues is dramatic.
First big big ask: Native Linux support for CarbideMotion pleaaaaase Somebody proposed a CLI - if the GUI is difficult to port, a CLI would be way good enough!
secondary ask: installation procedure for CM under Wine. It is a workaround but it would still kind of do the trick for now.
When the emergency stop button is pressed, the machine will not react (of course) but CM will not report the condition. Not sure it can but it would be nice if it did.
When connecting the USB port after starting CarbideMotion, CM fails to discover the Nomad and says “GRBL Error: Cannot open port for Nomad”. Workaround: restart CarbideMotion.
Would be nice to be able to power down the system (Nomad and computer) for the night and resume where it left off in the morning.
The procedure before milling is long and slow and possibly has redundancies
Set zero in manually (multiple steps)
Click Begin Project
insert tool request (uh ?)
actually starts milling
There are two homing and length checks. After step 3, if the stock thickness is know, the Nomad should have enough to find the zero by itself (bottom left of the plate, height = stock thickness) or accept a numeric zero (by giving it coordinates from (bottom, left, top of plate). Of course we can keep the manual zeroing for special cases but it could be automated or made shorter by sparing the first homing and length check (imho).
When Mac suspends while CM operates the Nomad, spindle keeps spinning but the head and table won’t budge (quite normal but maybe the spindle should stop). When Mac resumes, CarbideMotion’s UI is responsive but will not resume Nomad operations.
I’m in agreement that the procedure needs work with the repeated tool-length checks & homing, especially when the machine isn’t properly compensating for tool-length after all that… I had a program that I had run through, and then I changed the tool to one with a longer shank, and even after a tool-length check it didn’t compensate the program for the new tool, so it gouged into the foam during the traverse toward the start-point, so I stopped it before it could continue digging.
One thing I wanted to make sure you were aware of is that you can’t power down the machine because the motors are steppers, so it’s open-loop control to begin with, and when powered off they don’t have any brakes or anything to hold them in place. If you power the Nomad off, it won’t have a clue about where it is in space, and it would have to re-home before doing anything else anyway.
To be able to resume a job from a power-down would require it outputting/storing the line of the program it was on somewhere, then homing the machine for a safe shut-off, and then picking up from there on resume… and it would be wise to have it ask you if you’ve changed the tool or messed with anything, as ANY change to the setup would invalidate your ability to resume the job.
Yes, I do realize the problem with simply powering off the motors (or the application). I envisioned it exactly the way you described (storing, homing, sleeping then wake up, calibrating, homing, restoring - I can live with the assumption tools have not been changed etc.).
The idea occurred to me when the laptop suspended on its own, which I agree is not a use case we can decently cover (similar to brutally switching off the motors). I blended the genesis of the idea (observation) with the conclusion.
When the laptop suspended, I was actually tinkering with the idea of stopping the job altogether or maybe pausing the machine for the night as I did not like the idea of letting it run for 10 hours unattended. Laptop suspend decided for me
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.
Thanks Rob! after almost 20 years in support and software/hardware development; I understand that not everything we dream of is possible
I will definitely keep posting.
I am not 100% clear what CM does. I initially thought it was “only” (bear with me, I can sense complexity - I am trying to summarize) controlling GRBL over USB-Serial living on the Nomad controller (sending it GRBL $ commands mostly to zero the CNC and then streaming GCODE).
Can I use something else than CarbideMotion to drive the Nomad ? I can use MeshCam on my Mac but I would like to free it while milling and move the Nomad next to my Linux in my basement so anything else will do.
I am totally new (3 days old) to this world and I do not dare experimenting too much (I read about that Nomad that slashed into its tool length measurement).
I’m echoing his question, since there are a bunch of GRBL streaming things out there—even java based and web-based GUIs. If the Nomad is taking standard GRBL input, then hypothetically we could run it from a number of different tools, some of which may already support the GRBL functionality we’re looking for while you guys get it into Carbide Motion.
I really like the simplicity and straightforward interface of Carbide Motion, but until it handles G28, G53, and Ramp-in/Ramp-out moves that use G17, G18, G19, I’d be willing to put up with something else that’ll successfully pass these details in to the GRBL controller.
You can use something like Universal GCode Sender to communicate with GRBL.
That said, CM is rewriting all of the gcode on the way down to the machine to make sure that the UI has full knowledge of the state of the machine and to manage M6 tool changes, which GRBL and Universal GCode Sender cannot handle. CM is really what makes the Nomad work like a “real” machine.
CM is the core of the machine so we’ll keep working on it and making it better.
I will try too but won’t be able to do that before a while as I need to learn the parameters. Please keep us posted on progress!
Rob, I want to say that I recognize the work put in CM. It is a great tool to get a noob like me started.
To be very frank, I am really split between ease of use and reasonably using my machine at all. It sure is not very noisy but noisy enough that I can’t work next to it all day. Also the Mac is for my job; the linux is for experimenting and I’d like to keep them separate.
This is why I am so interested in a linux solution (even less sexy than CM). I understand well it is not a top priority for CM.