Well, there it is. My first piece wrecked by Carbide Motion, specifically how it handles feedrate over-rides.
The very last, 2 minute operation is whoops running at 200% because why the hell not, it’s not like I loaded a new file or anything so obvious a signal that perhaps the feedrate should be reset. Of course there’s absolutely no warning or anything, CM just charges off at the wrong feedrate.
Overrides should be temporary. Load a new file, reset to 100%!
I know the argument against resetting (“The software should do what I tell it, no more, no less.”). Obviously, I disagree. This would not be just randomly changing, this would be CM running in an expected and predictable way, i.e. CM should run the file as written as the default, and overrides should have to be specifically applied, not kept by default.
I have a variety of GRBL senders, and a few industrial CNC control interfaces. I believe feed override is persistent on all of them. On the industrial interfaces, cam programmed feeds/speeds can be completely ignored, and replaced with values directly from the interface. All feed rates, plunge, change of direction feed, spindle speed ect ect. These are all persistent. In fact, when I purchased these machines from their professional environments, all of the interfaces were set to just that. Speeds directed entirely from the interface, not the program file. I’d guess they had simply production roles.
I will concede that CM doesn’t offer me(personal preference) a preferable interface, but it does work, and I do use it on occasion. Instead of having a single window with all relevant control and status information, you have to tab around. I find I am more prone to make little mistakes while using CM. But making an assumption regarding design intents, I am probably a outlier.
That’s interesting, if industrial machines persist the feed override then it makes sense for CM to do so.
Perhaps a relatively simple UX compromise would be for the “Override: XX%” on the run job page to switch to amber or red text when not set to 100% as a visual reminder that you still have something other than the job programmed feed running?
I like the idea of highlighting the feedrate when not 100%. The ‘Run’ tab has ACRES of space to it, there could be an information window that provides info about the job (including this). For example, if the machine disconnects during a run, it could say what line is was running at the time, to make recovery a bit easier. This would need a re-vamp of the disocnnect behavior, since right now it just aborts everything and goes straight to the connect page.
Re: industrial machines - it would make sense to follow that convention when designing a new industrial machine. Whether it is ‘right’ or ‘wrong’ doesn’t matter, since it is a convention. However, the Shapeoko is not an industrial machine, and I think it has a different audience. In addition to the folk that have experience on industrial machines (and hence keeping feedrate is ‘correct’), the users run the gamut all the way down to CNC newbies (for example, myself). Modal behavior between files? Yuck!
Most other apps don’t do this - if I’m typing bold text in Word, and open a new document, I don’t get bold text in the new document. Resetting to default behaviors is pretty much the norm for most apps when a new file is loaded, and hence is also an ‘expected’ behavior.