I’m not new to LB, and Just bought my second laser, a Creality Falcon 2. I just put LB on a Linux Mint PC and that’s all wonderful. But, I am one of those unlucky ones I guess, who can not get keyboard jog working. It did not work properly on the Windows 7 laptop I had it on earlier either. Thought they’d surely have keyboard or external hardware jogging sorted in the latest versions.
Yes, I have read every topic I can find in the forum. And Yep, all the settings for jogging are right. I see others pointing out they get exactly what I get. My numpad will only give a little jerk in the X+ direction when it feels like it… and that’s only on on rare occasion. Nothing shows up in the console when it doesn’t want to move.
The keyboard “three finger commands” Ctrl+Alt+[ do seem to work, but I’m not an octopus. My keyboard is not sitting on top of my laser work area, so seeing where I want to jog and holding those buttons is a ridiculous impossibility.
Unfortunately, they fail to work when I try any form of keyboard emulation with any of the joysticks/emulator programs I have tried. This should have been easy. Never had this much trouble with an emulator.
I’ve seen people say it would be confusing to allow the regular arrow keys jog the machine. I disagree. I have numerous other CNC machines with various controls. None of them will let you Jog unless you are in a Jog MODE (like just being in the MOVE Window perhaps ?) . Couldn’t be simpler.
Does everyone else’s LB installation Jog via Keyboard ? or do they just always fight with the little buttons ?
To confirm, you have numlock engaged, correct? If not, enable numlock.
Also, focus needs to be on the workspace for this to work. With both of those engaged number pad jogging should work correctly.
I just tested this in Nobara Linux but it should work the same way in Mint.
Are you saying that this does occasionally work? But that the movements are shorter than expected? Are you using “Show all” in Console to check for commands?
Yep. Numlock enabled. That’s the only time it will make a move, again, when it feels like it. Very inconsistent. It seems it makes a small move once, then ignores attempts for a while. So far I have not found an actual pattern.
Doesn’t give me enough chances to examine what distance it is moving. And, again, seems it only cares about X+ moves. The rest it ignores.
Show all has been checked on. A guy can press the 4 numpad arrow keys and only once in a while will you see an update in the console.
I’ll need to try it all again in a few days when I am off of work.
I tend to agree with your comments. Having to move the focus back to the editing window each time I make a change in the move windows is irritating. I dealt with the issue by using my phone with a bluetooth keyboard emulator. I set up a custom keypad with only the four LB move keys defined.
When I’m trying to position my laser, I set up the move window, shift the focus to the editing workspace and then walk over to the laser with my phone and do the fine adjusting. Lightburn thinks that my phone is the keyboard and issues the move commands for me. The emulator runs on bluetooth so I can be several feet away from the computer and it still works.
I wonder if by some chance the focus has been jumping out of the workspace right after I get the one single move. I mean, cripes, ya, when it stops letting me use the one key that seems to work here and there, I do end up clicking on the job buttons to move the thing around. Console always shows that activity.
Well, that is good news… you do have an emulator working of some sort. Gives me some hope. BUT, I also was just looking at keyboard shortcuts and they have nothing listed for anything in the MOVE control window. That’s a problem. I assume you jog your machine to where you want, then have to walk back to the PC to “Set Origin” as I see no key command for that ? Likewise then, no commands for Frame, Start, Pause etc. A lot of those controls across those two windows make for a good deal of back and forth (like not having “go to Origin” on the move tab for instance).
I sure hope the LB team looks at some non GRBL based CNC controls before they release something without these obvious options for Routing/Engraving machines ! The first thing people will demand is encompassing jog/move/set zero functionality.
I just went back to the machine to try something. What it seems to do is, lets say I make a change to “speed” or “distance”, then immediately press the Right Arrow on the numpad. The machine will jerk in the X+ Direction, then, no longer will any arrow key respond… Until, I click on the workspace. Then it will jog with all 4 arrow keys, albeit somewhat jerky and not as reliable as the actual buttons move the machine.
Now, it is curious as to that first move that happens without any click on the workspace. Too, I slapped in a Logitech game controller and opened antimicro emulator. That does jog, but without the first move issue. I have to click on the workspace for it to do anything. I’ll play with it more this week.
Now, I was totally unaware of the whole having to click on the workspace EVERY time you make a change in the move window, and frankly, I never came across that in the jogging discussions I ever read thru. That concept makes no sense to me. I tried to tab my way out of the jog window into the workspace but did not see any visible proof I could even do that.
Sad thing is we all know that LB is the best thing out there for laser hands down. Even keyboard jog is clumsy at best. But, not being able to use any of the readily available cheap remote devices effectively to jog, set origin, start, pause or stop from it is a bummer !
That’s odd. It should work exactly the same as pushing the jog buttons. It will move the increment as defined by the Distance value.
That’s odd indeed. If you haven’t already tried it, enable “Show all” and see if anything is showing there when you do that.
It’s not so much every time you make a change in move window. It’s more that you must be focused on the workspace. You could make a thousand changes in the Move window, then focus the workspace and it will work. The net effect, though, is that if you ever shift focus away, then yes, you’ll have to refocus workspace.
I’m not aware of a hotkey that focuses the workspace. There may be one I’m not aware of.
Perhaps use the global movement hotkeys in antimicro instead of the numeric keys.
I don’t know if it’s already clear, but you need to enable “jogging” in device settings to have a continuous motion. And the firmware of your laser has to support that. Just in case…
First off, I appreciate the help and and happy that the forum is an active one. While I have used Lightburn on and off for a few years, I did not get into it because my prior laser was not all that useful. This Falcon is a bit more worth my time.
Jogging, “Enabled”, and yes, the laser must support everything it should because using the on screen buttons, everything moves reliably and exactly as one would expect a grbl type control usually does. My curiosity has allowed me put grbl on a few small engraving type machines, so I am familiar with its good things and minor limitations. Now I am not saying that the Falcon 2 uses grbl… but it would appear so.
I tried again this morning and indeed the keyboard jog is not near as reliable as the screen buttons. And, I also tried again emulation with just a Logitech game pad and it was worse yet.
I have to work a few days now, but will first check into the key repeat/delay settings in LMint. I did see some discussion in a Mint forum about a possible bug in LMint 21’s keyboard rate settings. This PC will not be used for drawing much. Just as the control for the Laser. Its not convenient to have the laser next to the drawing station I use to create tool paths for other machines as each machine has it’s own networked controller.
I guess what has me most confused however is why one would program LB to not move unless the workspace has focus. If workspace has focus, you could just use the regular arrows to move entities around like it does. If the Move window has focus, THAT is what you are trying to do… MOVE ! Just let the arrow keys move the machine. If you are going to go back to drawing, you have to highlight something first to move it with arrow keys regardless, automatically assuring focus is back on the workspace.
And, making available key commands for other things in the MOVE window would also be essential to how most mainstream controls would work. Few people enjoy the Mouse use on any CNC machine.
Thanks you everyone… I’ll play more and see to what point I will be stuck using it.
Spent some more time today with the Keyboard jog issue. Sadly, the only way the program keyboard jogs with any reliability is with all typematic rates and delays completely turned off in Mint, and while NOT in continuous Jog.
In Continuous Jog, it acts like you have the distance set to 1mm and a keyboard repeat on, just jerking its way around.
With all typematic rates off, at least when I’m in step jog, I can set a step/travel distance, and have it move cleanly and dependably the set distance each time I press one of the keys.
Couldn’t tell you if it is Linux Mint 21, The Creality Laser, Lightburn, or maybe just the Laser Gods hate me. I did try more than one keyboard so it’s not that.
Next chance I get, I will drag a Windows PC over there and see how it reacts.
Based on another Topic exploring numpad usage, it looks like numpad uses absolute coords for jogging rather than relative moves. In that case it’s not clear to me how continuous jogging would work.
Can you check for this by enabling “Show all” in Console and testing both keyboard jogging and Move window based jogging?
In the world of most controllers, jogging does not actually have any designation between relative or absolute coordinates. It just moves which ever way you want to go. I’m not sure why Jogging would be any different in LB, and frankly, I have not seen this particular unreliability with keyboard jogging in any of the numerous grbl front ends I had played with on other small machines.
I have a lot of respect for the grbl environment, and again, have put it on a few machines I have built, but I’ll never refer to it as a “real cnc controller”. Jog any other control and the axis just move, then the DRO displays the coordinates the machine is at, more often than not, displaying at least BOTH relative from a previously set origin, and the absolute coordinates from machine zero usually dictated by limit switches or manually setting machine zero where desired. My favorite controller shows 4 DRO’s simultaneously.
The grbl world is a little weird in this regard and always will be probably due to limitations in space to program any more function onto that chipset.
For this particular environment, I have only used the “Get Position” button to find out where I wanted to indicate my Park position should be after a job. I’d assume that the Get Position display is always absolute in grbl. Unlike a mill or a router, we tend to just drop something on the laser grid and find whatever corner or center point we want to use for an Origin, set it and run.
I might mislead someone with that last comment. When Jogging, I guess I should have said that all machines use absolute positioning so it knows where the travel limits are before they smack into the end of travel. Relative moves just move whatever distance you have asked it to, also knowing where the travel limits happen to be.
So my point really is that Jogging is just jogging. The controller keeps track of where it is in absolute, and in most controls, just does the math for you in telling you where it would be related to the origin or program zero that had been set.
I think you may have misunderstood my earlier statement.
I’m saying that the commands sent when using the numpad keys generated movements specified in absolute coords. So if the increment was in 5mm, the generated code was an absolute coordinate position that’s 5mm increment from the last known position.
This was in contrast to pushing the jogging buttons which created relative motion commands.
I was speculating that continuous jogging might not be possible if commands are being sent as a series of absolute coordinate moves.
GRBL is great when used for what it was intended (you don’t haul dirt in a Porsche). It is an open loop controller, meaning no position feedback. That comes from resolvers, encoders, and linear scales, which feed DRO’s. If the 4 DROs are not fed by any of these feedback sources, They are operating just like the GRBL controller is.
I think the ability of GRBL to handle IJK Gcode commands is amazing, and I am pretty hard to impress.
