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
load GCODE
home
check length
Set zero in manually (multiple steps)
Click Begin Project
home
insert tool request (uh ?)
check length
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.
Good to knowāI tried using GCode Sender, but it doesnāt want to connect to the machine, so I have to figure out how to make it actually hold a conversation first, before I try to make it do anything.
I hear you about the tool-changes and the likeālooking forward to the continuing development of CM then!
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.
Is this going to be a feature soon? It would be VERY helpful. I just had to abort a seven hour operation after hour five because my girlfriend came home early.
Somebody proposed a CLI - if the GUI is difficult to port, a CLI would be way good enough!
Somebody proposed a CLI - if the GUI is difficult to port, a CLI would be way good enough!
