V2.0.02-RC1 GRBL continuous jogging has issues

LightBurn Hardware Compatibility GRBL
, ,
1

I keep seeing change log items referencing “jogging fixes” or the like, but its still broken for grbl.

The basic issue/problem seems to be the $J= jog command args are using G53 in V2.x vs. the WCS (G54 usually) in V1.x. V1.x works, V2.x doesn’t. The soft limits grbl config ($20=1) influences if a grbl error 15 is thrown or not when attempting to jog X+ or Y+, but regardless of soft limit state, the direction of control point motion for X- and Y- jogging is wrong. As for soft limits, I prefer to operate my machine with it enabled.

My grb CNC has the upper back right corner as G53 (machine coordinate system or MCS) X0Y0Z0. I believe this is typical of grbl, and encourages users then to set a WCS (work coordinate system) such as G54 offsets to another point in the negative MCS space, again typically this is lower front left corner but can be anywhere. I believe this setup/config is typical for this flavor of controller and CNC processing. I use another Gcode Sender (UGS) for non-laser CNC work, aka when not using LB, and this machine config is certainly normal and compatible with that and other Gcode senders I know of. Again, this setup has worked with LB v1.x just fine, and in fact the LB doc recommended it for grbl machines and some others.

The new LB v2.x device controls of “CNC Machine” and “Machine Coordinates” do flipflop the jogging limit values and interpretation of control point position, but don’t change the fact that $J= jogging is always using G53 0 or positive value arguments which simply don’t work in the config described above.

setup: GRBL device, tried both inherited from V1.7x and new w V2.0.01-RC1, same results.

I’m running v2.0.02-RC1 now, since I don’t want to clobber my V1.7x install (which works fine) yet.
Win 11, GRBLv1.1i

when I ‘Show all’ in console, I see the continuous jog cmds from Move window UI arrows as:
Down: $J=G21 G53G90 Y0 F2000 – no error, motion is opposite direction, towards Y+
Left: $J=G21 G53G90 X0 F2000 – no error, motion is opposite dir, towards X+
In both cases of Down and Left UI clicks, motion is towards G53 Y0 X0 respectively, exactly as the jog command was given. My machine coord system 000 is upper back right corner. btw- I don’t believe the G90 after G53 makes sense as G53 is the machine coord system, adding ‘absolute’ mode also is redundant, there is no relative mode in G53.
Up: $J=G21 G53G90 Y860.5 F2000 – error:15, Jog target exceeds machine travel. Command ignored.
Right: $J=G21 G53G90 X890.5 F2000 --error:15, Jog target exceeds machine travel. Command ignored.
so applying the same logic, the G53 command is out of bounds on my CNC, non-zero values should be negative when G53 is used.
Further, I tried all combinations of the switches “CNC machine” and “Machine coordinates” in the device settings window, no change yielding correct continuous jog behavior.
My config has not changed from V1.7x other than my work area was X891 Y861 allowing for 0.5mm buffer from my G54 offset values. Those values failed also on V2.0.02-RC1.

btw- there is also a problem with “Show all” in console, LB seems to randomly drop the “show all” behavior while the switch state has not changed, still green. Toggling the switch enables “show all” behavior again, for awhile. I haven’t recognized the pattern causing it to misbehave.

image
image985×579 37.8 KB

$$
$0=10
$1=255
$2=0
$3=14
$4=0
$5=0
$6=0
$10=0
$11=0.030
$12=0.002
$13=0
$20=1
$21=0
$22=1
$23=1
$24=50.000
$25=1000.000
$26=250
$27=5.000
$30=1000
$31=0
$32=1
$100=57.337
$101=57.329
$102=200.000
$103=13.333
$110=8000.000
$111=8000.000
$112=2400.000
$113=8000.000
$120=400.000
$121=400.000
$122=400.000
$123=1000.000
$130=891.000
$131=861.000
$132=88.000
$133=2160.000
$#
[G54:-890.500,-860.500,-5.000,0.000]
[G55:-837.001,-612.568,-79.900,0.000]
[G56:-890.000,-222.205,-6.145,0.000]
[G57:-847.725,-764.552,-5.000,-1080.000]
[G58:-445.000,-430.500,-5.000,-1080.000]
[G59:-890.000,-861.000,-5.000,-1080.000]
[G28:-886.000,-5.000,-5.000,0.000]
[G30:-445.001,-660.044,-5.000,0.000]
[G92:0.000,0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000,0.000:0]
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]

attention: @soniclab (has replied to similar issues) @daniellb (recent jogging video)

1 Like
After software update, laser is moving in reverse or mirrored action
Jog arrows not working properly
Move Tab Jog Settings more in same direction
2

This is a very good writeup and seems to explain why so many are having coordinate issues.

I do take exception with one of your statements. G54 is a work offset and not a machine offset. The way I offset the machine coordinates, when I had the laser on my 3018 Pro machine, was by using the G10 command. This allows the machine to report 0,0 when at the Home position. It also put my workspace in the first quadrant (+X,+Y) to make Lightburn happy and leaves G54 free as a work offset.

3

Mike, we agree, I think. My intent was that referencing WCS (work coordinate system) G54 has same meaning as the term “work offsets”.

re. your broader msg- Are you saying that you have LB V2.x using continuous jogging ($J=) on a grbl v1.1f+ controller with soft limits ON ($20=1), with the work area CNC origin (X0Y0) in the bottom left corner of the drawing grid ? If you do, or if anyone does, please share the config details.

More fuel for the fire… the old LB doc had instructions similar to the follow link, but I notice the sentence was added in this V2 doc- “If you’re using a version of LightBurn released before 1.6, follow these instructions to work with a machine that uses negative coordinates.”
2.0/Guides/GRBLConfiguration/#legacy-instructions-negative-coordinate-machines
GRBL Configuration - LightBurn Documentation

To be clear- my CNC config can and did continuous jog just fine before and up to v1.6x, and during v1.7x, with those instructions implemented, AND with soft limits ON. V2.x not so, but YES if clearing WCS G54 (G10 L2 P1 X0Y0Z0) AND turning OFF soft limits.

What’s missing are instructions that are bullet proof for releases after v1.6., unless I’m an idiot, which I have been at times.

5

Unless we had the same exact machine, this would be meaningless. Even then, the Chinese factory makes production line changes on the fly, without telling anybody.

I have found Lightburn does a pretty good job of telling me I am out of bounds with my current settings, so I turned it off in all my machines.

The G10 command does not clear the G54 offset. They are completely different and independent, even though they both affect positioning. G10 is a Machine command and G54 is a Program command.

This should tell you something about your position command in YOUR current coordinate system setup. Remember that operating in Quadrant #1 (all moves are + and - greater than zero, and more or less positive) is mandatory for Lightburn. Using Absolute Coords is not, but it is strongly advised.

Ready for an experiment?

  1. Enter $$ in the Console window and copy the parameters to a safe place. Or copy them from your posting above.
  2. Enter $RST=# to clear out the G54-G59 and G28/G30 offsets.
  3. Enter G10 L2 P1 X0Y0Z0 so you have no offsets set.
  4. Home the machine.
  5. Report the X,Y,Z values displayed in the Get Position line of the Move window.

I am betting they are close to X=-890.500, Y=-860.500, Z=0.

Having a copy of all the settings means you can put them back if you want to.

6

@MikeyH , I appreciate the help. All of the info you seek is given in my OP. I think we’re just taking two slightly different road maps to get to the same place.

I’ve since gotten a reply from LB support team that a developer is looking into the issue of using G53 in the continuous jog command. Using G53, especially exclusively with 0 or positive coordinates, is a mistake in my assessment, given the surrounding setup / config circumstances I’ve noted. Previous LB versions did not use G53 either at all or as such, hence previous LB versions worked fine with the setup / config I’ve noted.

1 Like
7

Hi, I’m the dev looking into this problem.
There’s one thing in your config that bothers me a lot:

If I’m not mistaken, that implies that your home position (0,0) is in the rear left of your machine (or top left if you look at LB), according to GRBL’s documentation

However, your G54 offset indicates it thinks you’re in top right. So something isn’t quite right there.

Now, regarding the G53 being emitted in $J jog moves, I’ve been testing with GRBL 1.1h loaded on an arduino to try and replicate the problem with the GRBL config you give above - but I would appreciate if you could upload your device configuration as a bundle so I can also replicate the LB side of things for understanding where this comes from.

1 Like
8

That’s correct, the G10 command given above actually sets the G54 offset values.

1 Like
9

Welp, unfortunately there was a collaboration of multiple folks on this, and a bit of internal back and forth over which coordinates we preferred using. This resulted in some unfortunate bugs being left in the safety mechanisms regarding jog clamping for gcode machines.

The Gcode support has become tremendously more complex, especially with MillMage coming out, so LightBurn is now capable of working in G53 coordinates for users who want to use this.

I found the issue, and I will do my best to get a fix out in 2.0.02 that should resolve the current problems.

Regarding G53 in $J commands, those should only really appear in continuous jog movements, and I’ll fix that as well.

1 Like
10

I must have dozed off in GRBL 101 class. I did not know this!
Thanks!

11

Eh, when you’re writing tools that need to use the language you actually dive deeper into the specs of it :slight_smile:

That said there’s plenty of considerations we need to account for, and some of them are complex. Most purpose-built GCode laser systems will use the machine origin as the workspace origin, even if that means the direction of X and Y is flipped compared to CNC machines.

It makes the whole coordinate management complex - not because of the possibilities - we have the capability to do it in code, but because of how we want users to be able to tell the software what configuration they have.

It’s honestly probably a better idea to try and re-create your Gcode device from scratch if you had a previous profile, with G54 offsets being 0,0. The origin selection and CNC machine toggle should just get you to work as needed in that case.

If you set your CNC (homing top-right) to use a profile with origin top-right and toggle “CNC Machine” in the device settings, you’ll probably have a perfectly usable profile.

12

@goeland86 , sorry I’m behind the pace of replying to your question re. my config of G54, I was working on this reply when you posted last.

@goeland86 Jon, you have decoded the grbl config correctly, the machine homing switches are upper back left corner. However, I have to disagree with you that “home position(0,0)”, as in X0Y0, is also at the location of the “homing switches”. That does not have to be the case, nor is it the case on my CNC.

So what is “home” and what are “offsets”. I believe it depends on context, the context being the coordinate system. RS274 defines “home” in terms of G28 and G30 positions within the “absolute coordinate system”, a definition which is not at all as we tend to use the term “home” in CNC software UI, documentation, and therefore not as we tend to universally or generally understand it. In fact in my config, I use G28 to get me near the homing switches at rapid speed. I use G30 similarly but destination is a nice convenient location to change a tool or focus my laser. Neither is considered “home”.

I don’t mean to bloviate, rather I believe these terms should be well understood and documented by team LB because it’s no secret that LB can be a pain to configure for some CNC controllers that are not purpose built for laser process, aka grbl (any) and I suspect LinuxCNC to name a couple. Add to that CNCs that are dual or triple process like mine, and this is where we have evolved to now. Look, I am not challenging the competence of team LB, I love you guys and gals, and Oz is the man, no question. I am a huge fan of LB. I just think team LB has grown fast over the last few release cycles and some very fundamental and necessary CNC consistent vernacular has to be understood and applied (used), because inconsistencies are leaking into released code and UI labels, and perhaps doc; especially since MillMage has emerged.

RS274 defines two coordinate systems: the ‘absolute coordinate system’ (one and only) and ‘program coordinate system’ (of which there can be up to nine, P1-9 or G54-G59.3 respectively). The ‘program coordinate system’ is often synonymous with ‘work coordinate system’ (WCS), ‘coordinate system’, or just ‘offsets’. (unfortunately @MikeyH and I got tangled up on those terms).

Aside from RS274, the CNC programming and user community tends to equate ‘machine coordinate system (MCS)’ with RS274’s ‘absolute coordinate system’. This may be what you were referring to as “home(0,0)” in your above quote. The 000 of ‘absolute coordinate system’ is also the machine power-on XYZ position, which leads to conflating this position with “home”. For obvious reasons, LB and MillMage can’t use ‘absolute coordinate system’ for this position, as a very similar term is already used as a choice in Laser / ‘Start from:’ field, which represents the full LB work area (drawing grid), an area btw which RS274 defines as the ‘programmed coordinate system’. I hope you are seeing where this can lead… when referring to ‘home’, but even when referring to an unqualified X0Y0… it’s a mess.

Jon, I’m glad you and team LB seem to be re-assessing the $J= jogging command(s) to use, at least for grbl, my guess is LinuxCNC will also benefit. It’s first of all unfortunate that this all changed from v1.7x to v2.x, but its double unfortunate if those of us with multi-purpose controllers have to run a CNC config specifically for LB UI and control vs. the rest of the universe.

Where’s the love ?

1 Like
13

@goeland86 , first of all, thank you for that post, I can see that you understand the mess. Like I said, we were typing replies at largely the the same overlapping time.

To your quote above: I understand that, that is why I’ve emphasized that I run with ‘soft limits’ ON, and as you know, that doesn’t work with ‘soft limits’ ON. Btw- for those that wonder why I use soft limits, if they had a machine with >500+ oz.in. of motor torque on the axes, then they’d know it’s not economical to crash the rail stops.

To your suggestion, I believe I did get LB v2.x and my grbl config to behave together when $J jogging with a config as such, but 'soft limit’s are then OFF. I will concede to that being the answer if it has to be, but be prepared for more and more LB / MillMage customers to be unhappy and confused, perhaps to the point of finding another CAD/CAM. I’m not in that camp, like I said earlier, I’m a big fan. This is fixable, including improving the terms used for these important land mark positions as we config LB, navigate the UI, and study the doc. LB should improve on it before it gets propagated worse.

1 Like
14

Lightburn is the first software I encountered for CNC operation that was limited to the first quadrant. I suspect it simplifies computational math and gives higher processing speeds. Or maybe not, but I like it because it simplifies the coordinate systems for new users.

In other quadrants, a (+) move could result in a relative (-) motion. I have seen Engineer Programmers crash $125,000 machines because they got confused. In one case, the machinist was required to run a program with no material or cutting tools to validate the engineer’s work.

The beauty of all this is that it definitely not boring, right?

3 Likes
15

To your point, yes the “absolute coordinate system” that we consider internally are machine coordinate, or MPOS (machine position) as you’ll see it marked in the MillMage, as opposed to the program coordinates, or Workpiece (WPOS) position, which we default to be set with the G54 offset.

So when I speak of homing, or going to the home position, I mean the position that redefines the machine’s absolute coordinate reference (MPOS 0,0,0).

Lightburn then manages all other coordinate references without depending on the firmware (since we have similar functionality for non gcode controllers as well).

However to get the movement correct, LightBurn needs to be told what axis orientation the machine has. I was explaining this to someone else today as well, a lot of purpose built gcode lasers use the machine home position at the 0,0,0 position, but x+ could be left or y+ could be towards the front.

That’s where LightBurn does its axis realignment based on which corner the machine homes to. This works well when the firmware works in the positive quadrant only. And that’s been the majority of our users.

With MillMage coming onto the scene, however, the gcode protocol had to be reworked to also be able to handle negative quadrants. This unfortunately leads to a tremendous amount of complexity on the UI in LightBurn if we need the user to tell the program where the homing corner is and whether or not that corner is in fact 0,0,0 in WPOS as well or if WCO 0,0,0 is offset from that given the homing corner.

The transition is unfortunately painful, and we do apologize for that. But potentially recreating the device configuration without the G54 offsets and the CNC machine toggle on is the simplest way for configuration like yours.

Note that with MillMage you’ll be able to define off you want it to work in G54 or G55 etc instead, so you can potentially simplify your operation mode across packages that way. Using the same origin means you’ll be able to do part of the worth with the laser head and the rest with the CNC (or vice versa) using the same project file.

2.0 is a major shift in many ways, and unfortunately this happens to break the way things used to work a bit more than we have in the past. But hopefully once that reconfiguration is complete, the software will be as reliable and more productive than previously.

1 Like
Using Lightburn and UGS on same machine
16

What? wait! You said something I believe is wrong (first quote), and I’m not sure what you’re saying in the second quote I reference.

To my knowledge and understanding of RS274, it does NOT state that homing switches “redefine MPOS 0,0,0”, nor have I ever seen that behavior on any of my grbl controllers. G0 G53 X0Y0Z0 causes coordinated motion to the upper back right corner of the work area, when the work area is the quadrant lower left of that point AND that is the quadrant from which the control point originates (that is, before the motion). period. And in that case of the lower left quadrant being the work area, G0 G53 X-10 Y-10 Z-10 will cause motions only to that quadrant. period

Homing switches do not redefine MPOS (I’ll use your term), to be clear MPOS 000 = ‘absolute coordinate system’ 000 per RS274 = slang ‘machine coordinate system’ (MCS) 000, and that’s about it. $23 just tells grbl which way to seek to look for homing switches, it knows $23=0 is the MCS 000, $23= 1 means look left for X, etc. That’s all.

I will humbly stand corrected if you show me the doc. Otherwise, absent of doc to prove otherwise, perhaps this is the fundamental misunderstanding of some on the team LB ?

I write this with disclaimer that I’m dyslexic and/wrong more than I like to admit.

17

@goeland86 , I stand corrected, my bad. It pays to disclaimer :wink: I also have brain farts more than I like to admit. I’m going to agree with you that MPOS 000 is redefined after a homing cycle, because prior to homing cycle, MPOS 000 is control point position at machine power-on, a point I made earlier as I now recall. In the case of my CNC, its redefined to the upper back right corner, but not the location of the homing switches, which I believe we squared away the latter point in a prior post exchange. And isn’t that post-homing cycle MPOS 000 corner inferred from the value of $23 ?, kinda where this rabbit hole began.

So, that leaves us with
a) the $J= jogging worked relatively fine in prior versions with the config I described above, which was a documented and supported config. Perhaps the part about running with ‘soft limits’ ON was not documented, but it worked given the $J= motion commands being relative to WPOS coordinate system.
b) terminology surrounding all this geometry is a mess and perhaps can be improved in LB UI and doc.

2 Likes
18

I think we are making this more complicated than it has to be. I went through some grief when I replaced the 3018 control board (USB socket fell off the board).

  1. Make a copy of the GRBL parameters.
  2. Clear out any G54 offset.
  3. Adjust parameters so HOME works properly.
  4. Adjust parameters for JOG direction.
  5. Repeat steps 3 & 4 until both are correct.
  6. Then use G10 or G54 to get zero distances at the desired corner.
19

Well, that’s the empirical way of doing it.

But with a 3018 you don’t risk tearing the machine apart of you get it wrong and slam into one end of the rails…

With bigger and more powerful machines it’s important to get it correct without giving around.

20

a) Yes, there was a bit of a bug with continuous $J jogging that always emitted the G53. However relative discrete $J works already in 2.0.01/2.0.02. (I missed the deadline to include the code fix into 2.0.02, sorry)

If it’s emitting G53 during discrete jogging movements, then you need to disable the machine coordinates toggle in device settings. If it still doesn’t stop doing that, please send me the device configuration bundle, there may be a big in that toggle behavior.

b) while I appreciate the in depth discussion we’re having about this topic, the reality is that most of the users of LightBurn aren’t involved in their machines as much as we are, and already require assistance understanding the simplified labels. MillMage has probably better UI when it comes to precision of language, because at the moment we’re not targeting complete beginners. We’re making a functional package first, and we will then gradually add functionality wizards to help beginners along their journey.

2 Likes
21

@goeland86 Jon, that sounds terrific ! Well done ! Thank you.
The problem has certainly involved continuous jogging, always. The specific symptoms re. which axis had wrong direction and which attempted direction throws the error 15, that will change depending on the position of the ‘CNC machine’ and ‘Machine coordinates’ switches. All of this is correctly recorded in the OP, part of which I clip and repeat below. To the best of my recall, incremental/relative jogging worked without error but could have still had wrong direction, I’d have to retest that to be sure. If it had wrong direction, my assumption was it would be fixed when continuous jogging was fixed first, that would have been my reasoning to have left any issues with incremental jogging off the OP writeup. Of course the other important condition is to test your fix with grbl ‘soft limits’ ON, $20=1.

I’m pressed for time this morning and would have to get to the shop in order to send you the device config bundle, but I’m not sure you need it now. It may be tomorrow before I can send it. Besides, go enjoy LBX, the fix can wait 'til next week.

3 Likes