Which UI?

rodw wrote:

Feed per tooth is normally done in CAM. Fusion 360 does this well 
 

This is unfortunately barely true, and I would argue that Fusion 360 barely acknowledges that FTP exists. It can be implemented there, but it's sloppy. NX is far better.

I could get into a philosophical debate about FTP being done only in CAM - if I get your comment the way you intended to make it - but I will say that I totally disagree with you, fundamentally.

JT wrote:

There's a new GUI I'm working on that's in Beta mode you might want to check it out. You can have as little or as much as you want in the GUI. You build your GUI by drag and drop then give the widget the correct name... it's just that  simple. And thanks to some help here I now have HAL buttons, checkboxes, and radio buttons that create and connect a HAL pin which you can connect in the post gui hal file.

gnipsel.com/linuxcnc/flexgui/index.html

JT
 

I am considering LinuxCNC, but I do not currently use Linux in any way. Literally all of it is a mystery - I don't even know where to start, and I don't necessarily want to have Linux as a hobby. I just want a good UI for a CNC controller!

I installed a VM of Debian GNU Linux, I think directly from Parallels, but I haven't figured out how to even open anything yet. That's where I am in this!

Thing is, PC-based CNC controllers have a plague of really really awful UI. As in, I have never seen a single one that I would ever want to use, and every implementation of LinuxCNC is worse than the next. Most of them seem to be laid out by amateur machinists that don't have the kind of industrial experience that would give them insight into what a proper workflow would look like, and what information is relevant. For example, I have ZERO use for a graph, but most of them take up the vast majority of the screen and can't be turned off.

I am going to dive in to your beta QT Designer documentation. It looks like exactly what I was looking for, except I currently know nothing about Linux. I'm willing to put in the time, but I don't want to find out at the end that I can't display surface speed in meters per minute or feed per tooth in a DRO. As long as that is easily implemented, I would love to use your beta as my introduction to Linux.

OP - 

Are there any other non-negotiable functions/features you can think of which would drive your decision about which CNC control to use?

I'm asking because LCNC has it's quirks if you are used to industrial controllers.  It's extremely flexible, but there are things that may be show-stoppers for you that you don't know about until after you've spent a fair bit of time working out your GUI wish-list.

If I could suggest something... maybe pick one of the least-objectionable GUI's and write/generate some gcode.  Run these programs as you would like to, but simulated, and see if there are other 'features' that drive you crazy.  Some of these are easily fixed or changed in the GUI, but some may not be easily changed.

So as not to be cryptic, here are a few quirks from LCNC that may be different from what you're used to:

• no GOTO statements in g-code
  • If you are used to Fanuc Macro-B or similar macro language, have a hard look at the g-code section of the LCNC manual and see if it'll drive you crazy.
  • LCNC has plenty of functionality to accomplish everything you might want in g-code, but quite a lot may be pretty foreign to a professional machinist used to Fanuc, Siemens, or HH dialects.
• no SINGLE-BLOCK feature
  • LCNC has a 'STEP' command, which will execute one group of commands.  Not a single line of code, but a group of lines which includes one line with motion in it.  for example:
    • N10 M7
    • N20 M8
    • N30 G4 P2
    • N40 G1 Xnnn Fnnn
    • N50 G1 Ynnn Fnnn
  • N10-N40 will all be executed together with a single press of the 'STEP' button/command.  N50 will be excuted at the second press of the 'STEP' button/command.
  • This is rather different than typical industrial controllers as they tend to have a single block 'mode', and use cycle start to step through each line of code - regardless if there's a motion word on that line.
• Multiple 'START' command sources
  • This is hard to explain... but I'll try.  Every 'industrial' control I've used has exactly one way to initiate machine motion: the cycle-start button.  There are a few exceptions, but these are usually MTB-specific diagnostic pages or require some sort of 'admin' thing for axis/servo calibration.
    • Run a g-code program? cycle start button
    • Run MDI? type in what you want, maybe multiple lines, then cycle start button
    • Tool change? M6 Tnnn then cycle start button
    • Probe routine? Even with a control that has graphical, conversational probing... you enter what you want but the probe doesn't start until... cycle start button.
  • On the other hand, LCNC has what feels like an infinite number of 'things' which can initiate machine motion.  You could have a physical cycle start button, an on-screen cycle start button, the 'enter' key on your physical keyboard, the 'enter' key on an on-screen keyboard, and even a little probe or 'tool change' button(s) in your GUI somewhere.
    • ALL of them can make the machine move.
    • And they're all 'necessary' because of something that's not obvious unless you're a computer person: the GUI's are completely separate programs from LCNC.
    • If you need a separate program to control LCNC (i.e. touch-screen controls), then LCNC has to accept external command messages. Once you open that Pandora's box there's no end to it.  Any GUI can send a "DO XYZ" command to LCNC.  Which means someone can program a GUI however they'd like.. and maybe they got annoyed at having to load a probing routine, then press a physical cycle start button.  Be nicer if you could just have a screen button that does exactly what you want all with one click, right?
  • To someone coming from the industrial environment this can be rather disconcerting.  You type something in an MDI field, hit enter and you expect what you've typed to be ready to execute when you press the CS button...  But the machines takes off as soon as you touch the keyboard 'enter' key.  Yikes.
  • Can you short-circuit this situation?  Yes: create a custom GUI that has no command functionality, or take an existing GUI and neuter it so it's data display-only.  But that takes work...
• Keyboard jogging
  • This is really a thing, and all the GUI's have it.  And it's not obvious (at least to non computer people) how to completely disable keyboard jogging, 'hotkeys', and similar unsafe functions. Like everything else in LCNC this stuff can be disabled, but it's not merely a one-click setting as this stuff is buried in cryptic code somewhere.
• Tool table
  • No wear offset field
  • No flute count field
  • No max/min RPM field

These are just a few examples that have caught me up as I've been trying to learn LCNC over the past couple years.  I've probably butchered the explanations and made some mistakes; someone may come along and correct me, or at least offer up a justification of why things are the way they are.

Your GUI-related concerns are real (I can sympathize with your assessments), but you might want to explore LCNC a bit before spending time on a custom GUI.  If you find LCNC's quirks are no big deal - great!  Now you can cook up a GUI that doesn't drive you up the wall.

Don't get me wrong, I really enjoy LCNC and there's nothing else remotely affordable which has the capabilities I want... but it can be frustrating to someone with prior experience on other controllers and/or zero computer programming skills.

andypugh wrote:

Touchy doesn't. Touchy has a design criterion that nothing happens without a physical button being pressed.(with the exception of homing, and maybe that ought to be fixed)
Touchy has quite a neat MDI screen too (and only adds the block to the queue when you press cycle start. But it does support MDI queuing, which I like and use a lot, but know that there are other opinions)

Touchy doesn't have a graphical preview though (but it can be added in a custom tab)

Thanks Andy.  I know I'd forgotten something as soon as I posted, but with this forum editor...

In addition, Qtpyvcp has recently added a keyboard jog on/off feature to the INI file.

JT wrote:

Can you define what feed per tooth is? I just want to be clear as to what you need.

JT
 

JTAciera already covered it, but FPT (sorry, I mixed up the letters earlier LOL), AKA "CHIPLOAD" is the driving value for ALL milling operations. It tells you exactly how much each flute cuts, per revolution of the cutter. All of the inputs, like RPM, feedrate, cutter diameter, etc. are just that: INPUTS. They don't tell you anything on their own. Many machinists simply commit to memory good combinations of these values, but it's far more relevant to set a target for feed per tooth and then adjust the parameters until you get the optimal result, and a lot of social media machinists will call this a "recipe", without realizing that they are just reinventing FPT.

Surface speed? YES. Surface speed is far more relevant a data point than RPM. Again, RPM and feedrate and simply INPUTS to a formula which every machinist should be using to get to the OUTPUTS of surface speed and feed per tooth, which are what actually matter.Haas includes this data in real time in their NGC DRO, and it populates if you include the flute count and nominal cutter diameter in the tool library page. You have to scroll right pretty far, and I have never met anyone other than me that bothers.

If I were to start using LinuxCNC, I would want to recreate this little screen:
 
Outside of that, I want to tweak some of the UI like getting rid of the graph. I should only be looking at numbers and gcode scrolling by.