We have a couple of new products to roll out in the near future (accessories, not new machines) that will require changes to Carbide Motion so we’re interested in other things that users are looking for while we’re digging into that code.
Here’s what we know:
You want the ability to restart gcode on a particular line (Big job, we’ll get to it at some point)
Some of you want us to open source it. (Not something we’re interested in)
So, other than those items, what do you want to see added? What do you hate now?
Either the use of the GRBL limit settings, or a way to set the soft limits (the current settings for the HDZ apparently include having a SuckIt + wings on it. And then there’s the folks who swap their X plates…)
Take the “done” button out back, shoot it, light it on fire and then bury it in a shallow grave. Dance on the grave.
A bonus thing would be some sort of preview. Okay, three things.
I vote to remove the done button in the jog screen that has no utility whatsoever, put rapid positioning on the same screen and zeroing too.
A timer would be nice bonus point for a countdown to finish.
Keeping a display of the GCode line number sent to the controller to figure out where things went south and restart the job manually until you can implement in software.
Have several user determined preset positions so I can go to the place I want to start a job without having to jog there or to change bits.
Ability to measure and reset zero automatically when changing bit like the nomad probably using the Carbide probe as it is done with Macros in CNCjs.
Cue several toolpaths in order required for a job.
Without being open source, the ability to create and run macros.
You should look at the functionality that @neilferreri has created through macros.
being able to re-probe Z on tool change (mini version of the JOG screen probably)
list tool names from carbide create (likely as comment in gcode or whatever) not just tool numbers
ability to “dry swim” the boundary of a program. What I mean is calculate the X/Y bounding box and have the tool run (either at max or current Z, not sure which is the best answer) the boundary of that, so you can see if the stock and clamps are in the right spot/etc
detect the magic “zero clearance Z” condition and warn
detect if the program is going to go outside of the machine boundaries before starting to cut
(so machine coordinates not the zero point) and maybe just display a warning… likely only possible on machines with homing switches.
‘restart on line’ is hard… but ‘restart on toolpath start’ might be easier… more human friendly if CCreate would put toolpath start points as comments in the file
a way for CCreate to put the time estimate per toolpath in the file as a way to get time estimates for the remaining cut
Live preview, with ability to rotate view using click+drag, and option to align view with axis (i.e. a button to snap to top down, or side on etc)
when start job button is hit, LinuxCnc will warn you if the machine will go outside its limits. Particularly useful when safe z has been set too high. Please add this
Soft limits (not sure if this is already in place) also these need to be able to be changed if a dustboot is installed
Probing, with a drop down box in options for C3D probe, or touch plate that the user can input thickness of
manual spindle control (could be a hidden option until a box is ticked in settings)
ability to adjust jog feedrate. Useful when milling slabs flat
some sort of tool table that could be the same file type as Carbide Create. Make it smart enough to prompt to 'insert tool 5 - 1/4" flat endmill #201 then click ok" or similar
I vote for the live preview. I want to see what the toolpaths look like, like how UGS shows it. It also shows the extents of my toolpaths in measured units so I know to have stock the right size and not to have clamps in the way.
Boundary Box check (as mentioned above) - I have this on my small laser engraver and its extremely useful to allow performing a sanity check prior to actually running the code
Timer (as mentioned above)
Use a larger font or at least a BOLD font for the texts. The one that always makes me put my reading glasses on is the increment value on the jog screen. I can never see that “.” for a 0.1 mm increment especially when there is no leading zero being used.
The one on the jog screen at least - I’m basically looking for what Luc said above. My specific annoyance is that there are “menu” items (Jog, Run, MDI, Settings - that stuff) in view at all times - if I click on one of them, I should go there immediately. As it stands, I’ll jog things into position, go to “Run,” remember that I can’t unless I click “Done” first, grumble a bit, click “Done,” move on.
Having plenty of experience designing and coding user interfaces, I am extremely aware of exactly what I’m about to ask as my first request. Yes, it can be annoying to design. Yes, it can be quite tedious to code. Still, it’s what separates a good program from everything else.
Every element must have a keyboard shortcut (generally equivalent to clicking on the button, menu, tab, text field, or whatever).
This is the single thing that makes the most impact on the actual use of the program. While there is no requirement that a person use only a keyboard, being able to do everything with only a keyboard means that you are making things easy for both the power users (who can then script things with keystrokes) as well as users who may need the assistance of accessibility tools.
As an aside, I’d also highly recommend Pause/Stop should have a keyboard shortcut that works no matter where in the UI you are. This adds a bit of code to make it happen, but it means that a user can, for example, assign a keyboard macro to a USB “easy button” and have a clear software rapid stop.
And now, on to a couple others:
Text entry fields must treat lost focus (e.g. clicking or tabbing away) the same as hitting enter/return. An unapplied value must never remain in a text entry field after the field loses focus.
Some applications use color cues or other design elements to denote an edited but unapplied value. This is non-standard behavior and introduces confusion. (I’ve even seen apps using red/green changes as the cue, which is a terrible idea considering impaired red/green vision is the most common.)
Pressing Esc to cancel editing a text field and return it to its previous value is common. I would encourage that being implemented, as being able to cancel an accidental wrong-box edit makes users (including myself) happy.
If there is not a pressing reason for a tab, dialog, or screen to be modal, do not make it modal. There is no reason to need to cancel/done back to a main screen to go to MDI, Jog, or what have you. (This is not nearly as tedious as adding all the keyboard control, thankfully, but yeah, it’s a small pain for happy users.)
And my personal wish:
Multi-line text entry for MDI.
I’ve intentionally kept this post pretty much confined to UI design and implementation, as in my experience, that’s the part that tends to most easily be overlooked. It’s also the area where expending a little tedious time and effort can make the most impact to users on both ends of the user spectrum.
A few or most of these have been mentioned in one form or another, but I’ll include them on my list:
1 - Yes, the DONE button is over done. So limit the times we need to hit it.
2 - On startup, have it connect to the machine and automatically go home. Right now it connects, then you have to try to Jog (or do another action) before the homing cycle kicks in.
3 - Multiple HOME positions - much like a radio preset. Allow me to have four or five jigs screwed to the deck, and just say start at Position B, then for the next op I’ll start it at Position D, then Position A etc. Keep all these reference points so you just have to click on B and that is the new HOME.
4 - Metric bit probing - we don’t all live in the USA! And be able to add my own bits to the drop down.
5 - Circle probing for the centre would be very nice (not my idea - but I strongly vote for it)
6 - Ability to restart the job at XX % after things went south badly. Again, not my idea - but a real good one.
7 - If you can’t do multiple HOME presets like mentioned in #3, give a quickly available readout of the current position relative to the absolute home. This way I could jot the X,Y dimensions down and somewhat more easily go back there when I wanted to. But I’d much rather have store-able presets.
That’s all that comes to mind now, but I’ll keep thinking for more.
-Do not allow Zoom (my mac zooms in with track pad gestures and it’s always getting in the way)
-Remove done button (slows workflow for no reason)
-Rapid positioning and zero on same screen (faster workflow)
-Timer would be nice
-Multiple Zero positions saved
-Option to re-zero for tool changes
-job restart at % or time
-job repeat (a minimal number of button presses way to just run the job again. Good for making many of the same part…
Would it make since to add a grid program to CM to run arrays of the same program? Or would this be better separate? I run a grid program on my old laser at work, that I would love to implement on my Shapeoko. You basically plug in part size, number of parts in x, y grid, the starting position, and the program to be run. I was thinking you could have these parameters in CM. I can supply the code.
If this is something that would be better separate, I’ll start another thread with the code so someone smarter than me could look at it, and maybe make it usable for our machines.
I was running a bunch of coasters last night…it gets old having to wait for the machine to go home, rapid to current zero, jog to new zero, restart program. There has got to be a better way.
I agree that having to re-home every time you press stop is VERY annoying. Except for the initial connections or doing something to miss steps (e.g.: crash), I don’t know why re-homing is required. Starting a homing cycle should be a separate button or at the very least ask do you want to re-home after you press stop.
Since I’ve made my own complaints, I think it is worth mentioning the thing I really like about CM (and what keeps me using it instead of, say, CNCjs) - the fact that it works well in “limited screen real-estate” situations. I’m currently controlling with a laptop with an anemic 13x7 resolution, and CM does a pretty good job of showing me the thing I need to see for a given operation and just that.
Nits about font-size aside (which I agree with), this is something I’d very much like to see remain. It can be at odds with all the stuff we’re asking for, but I think (hope) it is still do-able.
I’d love to be able to reference an axis to a known value. Example: my tool is 1” above the part. I’d like to be able to reference Z to 1.000. Just makes setting zeroes and making incremental adjustments more flexible.
