Well, I’ve got another Noob question about using Lightburn… I have been having some issues with setting up projects, where the laser does not want to start a burn in the place I wanted. I have set absolute cooordinates, and (at least as I understand it) the starting point should be right where the design sits on the LB grid.
I think this is related to the Jog command ($J).
Here is some code I copied off the console when I moved the laser from Home to what should be the center of the table:
$H
ok (at this point the laser is at its home position, where X=1 and Y=1)
Starting Stream
$J G21 G90 X205 Y200 F6000 (sending the laser to the center of a 410 x 400 table)
Stream Completed in 0:00
Ok (And at this point the current position shown on the move console is x=205, Y=200)
? (And now I use the Move Window to query the laser location, and it updates the position in the Move Window)
<Idle|MPos: 321.350,311.337,0.000|FS:0,0|Pn:P> (which is reasonably close to where the laser ended up)
The actual position of the laser, according to the scales on the x and y rails is roughly X=318, Y=311. I can see that there is a little more axis calibration that needs to be done, but I want to tackle the move location problem before I do that.
When I have burned a square of 100mm x 100mm, it ends up being darned close to that 100mm, so my steps per mm setting is not seriously off. Also, the machine seems to know where it is, if queried, but the $J command is seriously overshooting the mark.
Possibly mechanical. Check belts for proper tension and pinion gears that they’re properly secured
You may be running too fast for the stepper motors to keep up. Check acceleration and max speed settings. Try dramatically reducing those. Does that eliminate the issue? If so, incrementally ramp up those values until skipping is identified, then dial back.
I doubt that it is acceleration/speed issues… if it was, the machine would undershoot the target because of missed steps. I don’t think it will jump steps.
Maybe I’m misunderstanding. The machine is reporting 321 on the X axis but is only at 318 in physical space. Sounds to me there are unaccounted steps. In other words, the controller has commanded movement that never occurred.
The machine was “Sent” to 205,200, and the position indicator in the move window initially showed that it went there. However, when I used the button to report the current position, it was at the 321, 311 position.
Yes, there are some small differences between the “real” position, and the queried position, but those are most likely due to belt tension issues, and axis calibration combined with more careful tensioning should solve that minor problem
The real problem is that the laser isn’t jogging ($J command) to the position it was sent to, and is in fact vastly overshooting the mark (by more than 50%).
The lines were simply transcribed from the console window, after activating the “Show All” switch. It’s possible I somehow omitted the “=” , but in any event, the Jog codes were what Lightburn sent to the machine… I wasn’t directly doing G-Code commands.
And yes, I have checked several times on the Width and Length of the engraving area. Width is 410, and Length is 400.
I’ll have a look at that and see… Might take a while, since I’ve got other chores to attend to for the next couple of hours.
If I recall correctly, $J jogging was never “enabled” in the settings page. I have hard limits for homing, but would need to also enable soft limits to use the $J without danger of the laser trying to run out-of-bounds. It’s an area I want to explore after I solve the mystery of why it overshoots its designated destination.
With regard to the $J enabling, I’m pretty sure that $J commands from the console command line will operate, even if it isn’t enabled within the settings. What it does (and please correct me if I’m wrong) is allow the use of your arrow keys to continuously move the laser head, and I think you can also do continuous moves by holding down the arrow buttons in the Move window. The enabling of soft limits simply allows the machine to ignore a command if it “knows” that it will send the laser outside the machine dimensions.
But back to the main subject, I am still puzzled by the odd behavior when the machine seems to overshoot when being sent to a specified x,y destination. I have tried to parse the g-code that’s being sent to the machine, but I’m not completely familiar with how all the commands actually work. One thing I don’t fully understand is the G54 command, which is a machine offset. As I understand it, that is telling the machine where the “zero” point is for subsequent movements. But how do I find out what that point is? When using absolute coordinates, it is supposed to be a corner or the center of an object to be engraved. I don’t remember seeing anything like that in the $$ settings, and haven’t seen any commands that would set that point.
And beyond that, is there anywhere I can find a good reference for the g-code commands as used by LB? For example, what is the M9 code used for? Standard g-code implies that it turns cooling fluid off, which certainly doesn’t apply to a laser engraver. Do they use this for air-assist control? Or what?
I am reasonably sure that my problems are related to some setting I have messed up either in the machine or in the LB settings, but at this point I don’t know where to begin looking for the error.
Yes. I believe this is correct. The toggle in LightBurn, as I understand, is to only instruct LightBurn to use $J commands.
I believe this should only be true if you enable the “Continuous jog” toggle in the Move window.
From memory, normal jog controls allow you to crash the laser even with soft-limits but $J respects these. But could be wrong about this.
This is a work offset and is a convention from CNC where you may want to have different virtual origins for different tool operations. However, your laser should not require G54 at all and would use Machine Position only.
Work offsets are not configured in $$ settings. You can see offsets using $# command.
GRBL does a pretty good job of implementing the LinuxCNC definitions, within the limitations of an 8-bit microcontroller teleported from the mid-1990s, so referring to the standard doc will get you a long way toward the goal.
Hmmm…? So, why does LB generate a g-code initiation string that includes G54 as a command? Following is a short g-code stream to engrave a simple square. It starts with me hitting the “Home” button, and ends with the query to show machine “status”, including position.
And the X0 Y0 position, as indicated in the final query is most definitely not what was expected, and shows that the machine knows its position, but is using a starting point different from what the absolute position of the square was as shown on the LB grid.
It puts you in G54 offset as to have a consistent starting mode. However, G54 itself does not have an offset defined so essentially this leaves you at Machine Position.
You can see this by running $#.
I think this is the actual source of your issue. You do have a work offset defined when you should not. You can see this in WCO.
Separately, did you by chance use a different program to connect to the laser? There are times where people get these inadvertent offsets but it’s not clear to me when/how this happens. There are programs that explicitly set these offsets but would think it would be more obvious when that happens.
Indeed, I have been trying out other programs… LaserGRBL and WebLaser. I like LB very much better, as it has much more intuitive layer management capabilities, and also some fairly good graphics ability.
I would report back on the $# results, but we are dealing with an ice-storm for the next few hours (thankfully, it’s a mild one for us – we are high enough in the inversion layer that any accumulation should be melted away by midnight), and we are having intermittent power outages/flickers. Still, we are far better off than those who live some 500 ft lower in elevation.
Would hitting the “set origin” button while in absolute coordinates mode (within LB) cause that offset to be generated?
No. As far as I know that Origin is only held in LightBurn memory as a position. I’ve never seen anything that would indicate that LightBurn is creating a work offset based on “Set Origin”.
I had thought that potentially pushing the Globe button in LaserGRBL could cause this but the short experimenting I did with it did not result in such. I may not have been doing it right though.
WebLaser I’ve never experimented with.
Yikes. Hope you stay warm and don’t lose power for a long duration.