All UI buttons must have keyboard shortcuts so that USB keypads can be used as pendants or otherwise make keyboards useful..

Trying to set up a Logitech G13 as a machine pendant.

Ack that getting the LCD screen working is currently a bridge too far - but setting up regular keys should be an easy option that does not require any work on the part of UGS.

Logitech has software that allows programming the keypad to issue whatever keyboard commands you want - which only works if the UI has keyboard shortcuts.

Note that I'm not looking for "smooth jogging" or similar here - one keypress == 1 mouseclick on that particular UI element is what I'm after.

Please do not close this ticket until these are implemented.

Order of March:

X+ X- Y+ Y- Z+ Z- Home Machine Move to Work Zero Clear Alarm Zero X Zero Y Zero Z Zero All Move to X Max (See https://github.com/winder/Universal-G-Code-Sender/issues/983) Move to Y Max Move to Z Max (Z limit switch) Move to X Work Zero Move to Y Work Zero Move to Z Work Zero Add 1.0 to XY Jog Add 0.1 to XY Jog Add 0.01 to XY Jog Add 0.001 to XY Jog Subtract 1 from XY Jog Subtract 0.1 from XY Jog Subtract 0.01 from XY Jog Subtract 0.001 from XY Jog Set XY Jog to 1 Set XY Jog to 0.1 Set XY Jog to 0.01 Set XY Jog t0 0.01 Add 1.0 to Z Jog Add 0.1 to Z Jog Add 0.01 to Z Jog Add 0.001 to Z Jog Subtract 1 from Z Jog Subtract 0.1 from Z Jog Subtract 0.01 from Z Jog Subtract 0.001 from Z Jog Set Z Jog to 1 Set Z Jog to 0.1 Set Z Jog to 0.01 Set Z Jog t0 0.01 Spindle On Spindle Off Coolant On Coolant Off Add 1 to feed rate Add 10 to feed rate Subtract 1 from feed rate Subtract 10 from feed rate

All but the following are either already exist, can be implemented by macros, or already have something close enough that I don't think additional buttons would be needed (i.e. subtract 1/0.1/0.01 has Increase/Decrease and Miltiply/Divide by 10).

Move to X Max (See #983)
Move to Y Max
Move to Z Max (Z limit switch)
Add 1 to feed rate
Add 10 to feed rate
Subtract 1 from feed rate
Subtract 10 from feed rate

Of this list I think only the feed rate ones need to be added.

Where are they listed?

I'm not looking for additional UI elements, but any existing UI element should have a keystroke mapped to it.

OK, I found the kemapping... part of the problem is that the default keymap is set up to use keys that don't exist on Windows - no "meta" key.

Can't map to "up" either because the keymapper sees "up arrow" as an attempt to manipulate the keymap selector rather than capture the key.

The solution might be to add the keyboard shortcut to the UI so you can see it.

Wait out. Lemme futz with this.

So here is what I found:

X+ YES X- YES Y+ YES Y- YES Z+ YES Z- YES Home Machine YES Move to Work Zero YES (Could be renamed to be clear on which zero we are talking about) Clear Alarm NO Zero X NO (Rename to Set Work Zero X) Zero Y NO (Rename to Set Work Zero Y) Zero Z NO (Rename to Set Work Zero Z) Zero All YES (Should probably be renamed to " Set Work Zero All) Move to X Max (See #983) NO Move to Y Max NO Move to Z Max (Z limit switch) NO Move to X Work Zero NO Move to Y Work Zero NO Move to Z Work Zero NO Add 1.0 to XY Jog NO Add 0.1 to XY Jog NO Add 0.01 to XY Jog NO Add 0.001 to XY Jog NO Subtract 1 from XY Jog NO Subtract 0.1 from XY Jog NO Subtract 0.01 from XY Jog NO Subtract 0.001 from XY Jog NO Set XY Jog to 1 YES Set XY Jog to 0.1 YES Set XY Jog to 0.01 YES Set XY Jog t0 0.01 YES Add 1.0 to Z Jog NO Add 0.1 to Z Jog NO Add 0.01 to Z Jog NO Add 0.001 to Z Jog NO Subtract 1 from Z Jog NO Subtract 0.1 from Z Jog NO Subtract 0.01 from Z Jog NO Subtract 0.001 from Z Jog NO Set Z Jog to 1 NO Set Z Jog to 0.1 NO Set Z Jog to 0.01 NO Set Z Jog t0 0.01 NO Spindle On NO (There is a Spindle but it doesn't seem to do anything) Spindle Off NO (see above) Coolant On (can't test) Coolant Off (can't test) Add 1 to feed rate NO Add 10 to feed rate NO Subtract 1 from feed rate NO Subtract 10 from feed rate NO

HOLY CRAP THE KEYS DEPEND ON WHICH WINDOW YOU TOUCHED LAST

I have HOME - PAGEUP - PAGEDOWN - END configured as "set XY jog 1 - .1 - .01 - .001" respectively, and if you click on a UI element in the jog window they do just that. But click in the probe module window and now PAGEUP sets milimetres and PAGEDOWN sets inches.

Clicking in the jog window does not reset the functions - you have to click on a UI element first to enable them.

That is super non-intuitive and has the potential for disaster on a machine.

So let's add to this ticket "Keyboard shortcuts must provide the same function regardless of which module is active"

Having single keys configured as shortcuts is generally a bad idea. For instance, what is expected when END is pressed in a multiline text area? You should use a key in combination with a modifier such as ALT, CTRL and/or SHIFT that is not used by anything else in the operating system or in the program.

OK, so that conflates two issues.

The argument that any keystroke that moves/affects the machine should be hidden behind a "deadman switch" (like a Crtl+ or Alt+) is a reasonable one. It reduces the chance that an accidental keypress does something to the machine.

So I have no issue with that. And given that keybindings are configurable both within UGS and within my keypad configuration software means that this requirement does not interfere with my expected workflow.

So a default keymap that has everything related to machine changes (like jogging) configured as Ctrl+[whatever] I have zero issue with.

My issue is that keypresses do different things depending on which UI element you touched last, and that is not at all acceptable. If you have Crtl+d configured as "Jog X+", then pressing Ctrl+d should jog X+ no matter what window within UGS has focus.

If that means that certain keys can no longer be available to be reassigned because they are needed for UI manipulation (like maybe the arrow keys) so be it - but once a key is configured to do something, that is all it should do as long as UGS has focus.

The idea here is that UGS is a virtual standin for the control panel on a machine like a HAAS CNC mill. While it doesn't have to look like a HAAS control panel (and arguably should not, given that a bunch of HAAS real estate is given over to manual entry of gcode programs and support of functions (like spindle load) that UGS cannot support) but the base concept that UGS is your machine control panel is valid. And that means that machine controls MUST always work the same, no matter what part of the program you are in.

@RecceDG UGS is a regular UI, and native operating system behaviors apply to the control elements we use. It isn't that different windows have different behaviors, it is that active controls have certain behaviors. For example, suppose you had a key bound to a and currently had a textbox focused, what would you expect to happen? In your example the Units combo box in the probe settings had focus, in that case page-up/page-down let you scroll through the combo box. If you wanted you could press tab to cycle through the focused control. When the active control doesn't use the keybinding it propagates to the expected event.

I don't disagree that it is frustrating when OS behaviors get in the way of what you want. We've discussed the issue before: https://github.com/winder/Universal-G-Code-Sender/issues/709#issuecomment-324061451

@RecceDG as for UI being intuitive and consistent with the OS, I totally agree with you.

My issue is that keypresses do different things depending on which UI element you touched last The problem is, I could only repeat this in one case (see below). Could you provide an example of that, which is not something that would normally happen in, say, MS Word or similar?

I was only able to repeat the PGUP/PGDN issue you mention, and why it does what it does makes sense. PGUP/PGDN should change an active combo box. When you open the Probe Module Settings tab, the Units combo box is selected, so PGUP/PGDN should change that. When you select the WCS combo box, PGUP/PGDN will change that combo box instead.

I hope I don't come off as facetious or arrogant in saying this, but this is actually intuitive behaviour. The OS (Windows/Mac/Linux) wants to intercept and handle keystrokes before potentially sending them on to UGS, because the key strokes may have to do something else. It's all about priorities and sending things up and down stacks. For example, WIN+R will probably pull up a dialog box asking you to run some software, even if you configure UGS to do a soft reset. Possibly GRBL will be reset, but Windows will definitely show the dialog box.

I would suggest when setting up the keystrokes to first check if they do something else before assigning them a task.

As for the use case behind the ticket - having an Arduino with a bunch of custom labelled buttons (and maybe a rotary encoder) to send keystrokes as USB keys seems like a really neat idea, something I want to do now! :+1:

I hope I don't come off as facetious or arrogant in saying this, but this is actually intuitive behaviour.

No, not at all. We're engineers talking about a technical issue - no need for anyone to get angry.

So you are falling prey to a very very common issue amongst software developers, which is mistaking that the way computers work (particularly UIs) is the way people work.

I started off in software myself, so I totally get that. I've been there, done that, pissed off my users. :)

But I'm also lucky enough to have spent nearly a decade working as a mechanical engineer designing race car parts and working hand in glove with a really good machinist - and nearly everything I designed went to a CNC mill. I spent a lot of time with that mill, learning the hows and whys of the workflow to go from CAD model to CAM toolpaths to gcode to cut aluminium (or steel or titanium or whatever). And it is key to understand that the workflow was heavily optimized for two things: speed and safety. Speed, because an idle machine makes no money, but an idle engineer & machinist burn a lot of money, and safety, because a HAAS will do exactly what you tell it to do, even if that means running a 3" face mill at 3" DOC at rapid rate directly into the Kurt (not that I ever did that).

It is worth looking at pictures of what is on a HAAS control panel and where it is relative to the bed of the machine. It is set up so that the operator can have the machine door open and have one hand on the control panel while the other hand is on the spindle etc. The jog controller is a crank wheel (which is really a digital rotary encoder) and there are buttons right next to the crank that select what the crank wheel does. Typically, the main controls were X, Y, Z, Feed Rate. So press X and now the crank wheel jogs X depending on which way the wheel goes. Press Y and now it jogs Y.

You have 1, .1, .01, and .001 buttons that control jog rate, so you can go from coarse moves to fine. And there's a work zero button that zeroes the current active axis.

With this setup, the process of moving the spindle (actually, the spindle is stationary and the table moves, but whatever) looks and feels a lot like cranking the handles on a Bridgeport knee mill. It's intuitive and fast.

OK, so we don't have a jog wheel (well those controllers exist, but they are rare). What we have is a keyboard. So now you put the keyboard in the same spot as where the HAAS controller goes (ish) and you control the machine with the keyboard. And here's an important part - you might not even be able to see the screen.

I have one of those Logitech mini keyboards. I can hold it in one hand, and I don't need to look at it. Using it, I can jog the machine to do things like set up zero with my eyeball firmly on the spindle/bit. One hand has the feeler gauge, the other on the keypad, and I can rough jog, fine jog, and super-fine jog to the zero point without needing to look at the screen.

Mind you, things aren't perfect yet, because I can't set zero from the keypad, nor can I set the Z axis jog rate - but when these key shortcuts get added, I'll be able to do a complete toolchange and zero set from the keypad without needing to look at the screen or touch a mouse. That is a huge productivity win.

But this only works if the keypad (meaning the keyboard) works directly 100% of the time in direct machine control mode. A change in window focus should not suddenly disable the keypad, or worse, keep the keypad functional but make it do something else.

Now I ack that setting that up is tricky, and some keystokes are overloaded to UI control functions - and there is value in preserving the expected UI functions. So maybe there needs to be a super obvious UI element that puts UGS in "machine control mode" and that locks focus into that window and dedicates all keyboard functions 100% to machine control. In "machine control mode", the UI and keyboard is a virtual HAAS controller (not that it has to look like a HAAS controller - you know what I mean) and outside of "machine control mode", it's just a keyboard.

It's worth noting too that when a program was running and the HAAS was cutting, the operator usually had the jog controller in "feed rate" mode, and he was constantly tweaking feed rate up and down according to the spindle load meter and the sound the cutter was making. Machine control in a production shop is a very active process...

Mind you, things aren't perfect yet, because I can't set zero from the keypad, nor can I set the Z axis jog rate - but when these key shortcuts get added, I'll be able to do a complete toolchange and zero set from the keypad without needing to look at the screen or touch a mouse. That is a huge productivity win.

I created a macro for doing a moving the table to what I nickname the "Tool Change Position" (where I plan to have a Z height pre-setter down the line). Alt+Shift+T moves the table to that position. I have a similar one for "parking" the table when I shut the machine down, Alt+Shift+P.

What I suspect I'll wind up doing is making a small box with a bunch of buttons on it, and they'll tell an Arduino (or similar microcontroller acting as a USB HID keyboard) to do all the custom keystrokes (software, elec and telecomms engg, and now interested in mech+machining). I push the Tool Change Position button, change the tool out, push the "probe Z" button (maybe jog the machine to about the right height for short tools), and then return to WCS 0.

Coming back to your point concerning usability and how people work - what I was driving at before is that it does feel intuitive to let the OS handle UI/UX before passing things on to the application to handle the functional requirements of the application, and that if a user tries to do something that's a bad idea (which in the case of PGUP/PGDN, it probably was a bad idea given it can interact with UI elements), often we let them. Perhaps some sort of a warning popup should be issued for potentially hazardous keystrokes?

Possible 'hazards' I can identify would be:

keystrokes that try to move a cursor (eg arrow keys)
keystrokes that try to move some selection criteria (eg PGUP/PGDN)
keystrokes that try to change / toggle / confirm selection criteria or UI elements (eg space bar / enter)
characters (virtually most of the keyboard unless Ctrl / Alt is used as a modifier); most of these characters would be valid to enter during conversational mode, we don't want the machine doing stuff unexpected!

Example user story: As an end user, I want to assign PGDN to jog down the Z axis. A popup to warn that, unguarded, it may have unforseen consequences, (maybe not explain the full details in the popup, but a link to a wiki entry could be advantageous - something saying that most OSes, it will try to do things with particular UI elements before it is handled by UGS).

Example user story: As an end user, I want to assign Left Arrow to jog the X axis left. A popup to warn that, it may have unforseen consequences, (Left will move a cursor, Shift left will select while moving the cursor, Ctl+Left will want to move the cursor left until the next space char, Ctl+Shift+Left will want to do the same but make a selection, Ctl+Alt+Left is common with window managers on Linux to snap an entire window to the left, which leaves Alt+Shift+Left and Ctl+Alt+Shift+Left... Starting to run out of fingers, and it gets frustrating, but because it's just a warning, advanced users can dismiss the warning as they may (like me) have modified the window manager config, or built a pendant to push 4 buttons simultaneously. It's worth reiterating that all of the potential issues in this paragraph are not UGS specific, and it to intercept and prevent the OS/WM from doing something with those keystrokes may be more trouble than is worth investing time in given the wide range of operating systems and window managers for those OSes. Then there's the testing, which we can probably never get adequate coverage for ;)

BR Adam

On Wed, 4 Apr 2018 at 09:37 RecceDG notifications@github.com wrote:

I hope I don't come off as facetious or arrogant in saying this, but this is actually intuitive behaviour.

No, not at all. We're engineers talking about a technical issue - no need for anyone to get angry.

So you are falling prey to a very very common issue amongst software developers, which is mistaking that the way computers work (particularly UIs) is the way people work.

I started off in software myself, so I totally get that. I've been there, done that, pissed off my users. :)

But I'm also lucky enough to have spent nearly a decade working as a mechanical engineer designing race car parts and working hand in glove with a really good machinist - and nearly everything I designed went to a CNC mill. I spent a lot of time with that mill, learning the hows and whys of the workflow to go from CAD model to CAM toolpaths to gcode to cut aluminium (or steel or titanium or whatever). And it is key to understand that the workflow was heavily optimized for two things: speed and safety. Speed, because an idle machine makes no money, but an idle engineer & machinist burn a lot of money, and safety, because a HAAS will do exactly what you tell it to do, even if that means running a 3" face mill at 3" DOC at rapid rate directly into the Kurt (not that I ever did that).

It is worth looking at pictures of what is on a HAAS control panel and where it is relative to the bed of the machine. It is set up so that the operator can have the machine door open and have one hand on the control panel while the other hand is on the spindle etc. The jog controller is a crank wheel (which is really a digital rotary encoder) and there are buttons right next to the crank that select what the crank wheel does. Typically, the main controls were X, Y, Z, Feed Rate. So press X and now the crank wheel jogs X depending on which way the wheel goes. Press Y and now it jogs Y.

You have 1, .1, .01, and .001 buttons that control jog rate, so you can go from coarse moves to fine. And there's a work zero button that zeroes the current active axis.

With this setup, the process of moving the spindle (actually, the spindle is stationary and the table moves, but whatever) looks and feels a lot like cranking the handles on a Bridgeport knee mill. It's intuitive and fast.

OK, so we don't have a jog wheel (well those controllers exist, but they are rare). What we have is a keyboard. So now you put the keyboard in the same spot as where the HAAS controller goes (ish) and you control the machine with the keyboard. And here's an important part - you might not even be able to see the screen.

I have one of those Logitech mini keyboards. I can hold it in one hand, and I don't need to look at it. Using it, I can jog the machine to do things like set up zero with my eyeball firmly on the spindle/bit. One hand has the feeler gauge, the other on the keypad, and I can rough jog, fine jog, and super-fine jog to the zero point without needing to look at the screen.

Mind you, things aren't perfect yet, because I can't set zero from the keypad, nor can I set the Z axis jog rate - but when these key shortcuts get added, I'll be able to do a complete toolchange and zero set from the keypad without needing to look at the screen or touch a mouse. That is a huge productivity win.

But this only works if the keypad (meaning the keyboard) works directly 100% of the time in direct machine control mode. A change in window focus should not suddenly disable the keypad, or worse, keep the keypad functional but make it do something else.

Now I ack that setting that up is tricky, and some keystokes are overloaded to UI control functions - and there is value in preserving the expected UI functions. So maybe there needs to be a super obvious UI element that puts UGS in "machine control mode" and that locks focus into that window and dedicates all keyboard functions 100% to machine control. In "machine control mode", the UI and keyboard is a virtual HAAS controller (not that it has to look like a HAAS controller - you know what I mean) and outside of "machine control mode", it's just a keyboard.

It's worth noting too that when a program was running and the HAAS was cutting, the operator usually had the jog controller in "feed rate" mode, and he was constantly tweaking feed rate up and down according to the spindle load meter and the sound the cutter was making. Machine control in a production shop is a very active process...

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/winder/Universal-G-Code-Sender/issues/984#issuecomment-378432852, or mute the thread https://github.com/notifications/unsubscribe-auth/AAdYqDADhizHjJ83pLxSRMjzKGhkgb0iks5tlAeogaJpZM4TC6Vm .

Thanks for all the thoughtful discussion. I like the idea of having some sort of "Focus" element. Maybe a button you press which specifically captures keystrokes and somehow sends them up the tree. It's a little ironic that UGS Classic used to have the exact opposite problem, they key listening was done at a higher level and could steal keystrokes from other control elements like text boxes and move the machine unexpectedly.

In any case, the following missing actions have been added:

Increase/Decrease/Multiply/Divide feed-rate/Z-step-size
Set Z step size to 10/1/0.1/0.01/0.001
Reset X/Y/Z actions

I believe the ones still missing can be implemented with macros (ie spindle start/stop, move X/Y/Z to min/max)

hello all and set my ps3 control without problems from increasing the feed rate or decrease, move to x +, x-, y +, y-, z +, z-, play, pause, stop, reset zero, return to zero, etc. , I will be doing a tutorial with everything necessary for the configuration and everything will be done automatically from uploading the UGS, controller for the control and the program to do the mapping and everything goes up automatically from the laptop or PC.

winder / Universal-G-Code-Sender

All UI buttons must have keyboard shortcuts so that USB keypads can be used as pendants or otherwise make keyboards useful.. #984