Bug Report in v1.4 (possibly)

Hello. It is possible that v1.4 has a bug. When setting the X, Y and Z height and pressing set origin, the X and Y values are correct and the laser head traverses correctly to the selected origin point.The Z value stays at its maximum height at the time the start arrow is pressed. If the Z height is manually set before pressing start and the laser head is at the correct XY position then the burn proceeds as expected. Normally, I have been used to setting the three values as my origin point and then pressing start moves the laser head from home to the correct start location and height.

I use a Shapeoko S3 with J-Tech 4.2W diode laser. Running on a Mac running Mac Os Big Sur 11.7.6 (This was not an issue with LightBurn v1.3 ) Thank you.

Thank you for reporting this.

I’d like to confirm a couple of things about the Machine State and the selected coordinate systems.

Are you using User Origin and setting the User Origin after homing?

Please capture the screen with your device settings. I’d like a better understanding of your z axis setup.

I’ll look into changes on our end and come back to this.

I confirm that I use the user origin. I always have set the User origin when I am locating the centre of my workpiece in X and Y.

My previous use was always to find the centre of my workpiece in X & Y locations and then lower the Z height until it is 3.175mm above the zero Z height on the workpiece. I use a gauge block of exactly 1/8" and lower the shroud of my laser onto it in increments of 0.01mm. When it is correctly located for X, Y & Z, I press set origin.

I then add 60% of the total workpiece width to the X direction and locate the laser at that point. I then press the Set Finish Position. I then home the laser head and then press start.The laser used to go to the location specified in X,Y and Z and the burn would begin. After it has finished, the head would traverse to my Set Finish Position location.

What is not happening is the Z location that I enter at the set User Origin point does not appear to be saved or persistent. The machine has no recall of that saved position and the laser head is at maximum height above the workpiece even though the head has correctly located itself at the saved X and Y location.

The images show the settings which I have used ever since having LightBurn and I have not seen this behaviour before. I do not know if I have done something to invoke it. Thank you for your help. I appreciate the assistance to straighten this issue out.

1 Like

You have “Relative Z Moves Only” enabled. Is it possible that the behavior you’re thinking of only works when that is disabled?

1 Like

I don’t think this is the reason. I have always used LightBurn set like this. I will check it after I have done a few chores and can get to my CNC machine.

I wasn’t aware that LightBurn would factor in Z-axis position for origin until you had mentioned it.

However, after thinking through it I didn’t see how one could set a specific Z position for origin without disabling “Relative Z Moves Only” since I assume that would require some knowledge of absolute position. It’s just a hypothesis based on that notion but could be wrong.

I don’t set a material thickness since my workpieces are many different thicknesses. My initial measurement of Z height is precisely 3.175mm above the zero height of the workpiece. This provides me with a sharp focus of my laser beam every time because its sharpest focal point is at 1/8" from the bottom edge of the shroud.

My understanding of the relative Z setting is that it moves the laser head relative to the first entered value of Z height (1/8" from the bottom edge of the shroud) which is exactly the behaviour I want. In any event, regardless of this setting, the Z height used to be persistent and could be a part of the user set origin. Now it is not persistent and is not saved.

I’ve always interpreted Relative Z Moves only to allow for moves relative to current position at start of job, so with no reference to an exact position. But then again, I never experimented with trying to set user origin at a different Z height. I’m curious if this is perhaps a difference between gcode and Ruida device behavior.

Was worth a shot.

Do you know if previously after setting origin that you could at any time push “Go to origin” and the laser head would go to the set origin including Z position?

Yes, that was the exact behaviour. All user locations were persistent unless the software was switched off.

Edit: I forgot to say only if cutting the same job, would the stored Z height be used. Otherwise the laser head would only go to the stored X and Y locations (from set user position).

Hello John. I was curious as to whether you were able to replicate the behaviour to which I referred. If you did, do you have any progress to report? Thank you.

Hello @JohnJohn. Is there any news on this possible bug in v1.4? Thank you.

Nothing yet, that’s largely on me.

There are a few variants for this machine. Does your engraver have Switches on each end of the three axes? Does the engraver pull-off an upper z-limit switch as expected?

After homing, with the origin set as you would, please type the following report requests into the Console window in LightBurn:
$i
$#
$G
pressing enter after each one.

Please copy and paste those reports into a reply here.

Thanks for this response. I will check it on Sunday as I am just preparing to leave for an exhibition and will not be home until then.

There are fully functioning limit switches on each axis of the S3 CNC machine.

I don’t understand this question.

I will do all of this on Sunday. I think I may also make a short movie clip of the behaviour.

1 Like

Perfect! That helps with the scope of this.

When a home switch triggers, the controller should move the engraver away from the switch to return it to the rest state. It shouldn’t sit on the maximum. The z-axis geometry can be quite different from x-axis or y-axis geometry so I was probably holding on to the idea that the upper z-axis pull-off, pull-back or pull away which returns the switch to the rest state may not have been present or easily observed.

I’m glad the switches are confirmed working. I’m attempting to drill down a little bit to understand how they might be configured.

When troubleshooting I have seen working switches (in the wild) that were outside the constraints of the machine so they worked when finger-tested but never activated in service and didn’t demonstrate the pull-off behavior. I have also seen absent pull-off behavior, difficult to observe (slow) pull-off behavior, and insufficient pull-off distance.

If the home switch for Z is on the end of the axis closest to the work and if the furthest Z position is counted away from the close end then the upper Z axis switch shouldn’t trigger or pull-off.

If the home switch for Z is furthest from the work the engraver should home toward it and pull back.

If the Z axis isn’t homing or if Z-home isn’t defined then there’s a slim chance that the Origins are defined in a problematic way.

1 Like

$i

[VER:1.1f.20170131:]

[OPT:VNPR,14,128]

Target buffer size found

ok

$#

[G54:-459.000,-415.000,-64.500]

[G55:0.000,0.000,0.000]

[G56:0.000,0.000,0.000]

[G57:0.000,0.000,0.000]

[G58:0.000,0.000,0.000]

[G59:0.000,0.000,0.000]

[G28:0.000,0.000,0.000]

[G30:0.000,0.000,0.000]

[G92:0.000,0.000,0.000]

[TLO:0.000]

[PRB:0.000,0.000,0.000:0]

ok

$G

[GC:G0 G54 G17 G21 G90 G94 M5 M9 M56 T0 F0 S0]

ok

I will upload a video clip very soon

@JohnJohn
Here is the short amateur video clip. I hope it makes the issue clear. The Z height is not saved as a part of the saved origin location. It means that he Z height has to be measured again and then the burn run from that location. When the requirement is to run two or more jobs from the same position and of the same type, the Z height is not persist6ent and has to be reset every time. The previous iteration of LightBurn saved the Z height for starting the work and that too was persistent between jobs. Forgive the amateur video clip but you will get the idea from its stuttering along.

Hello @JohnJohn. Has the video clip, along with the reports for the values for $i, $# and $G, highlighted any issues? This is notwithstanding that I have successfully used the same machine and LightBurn since 19th September 2020 without incident. I have engraved hardwood, softwood, glass, ceramic and slate and cut plywood so that indicates to me that my setup is good.

I am replacing the input lead from my GRBL 8bit CNC control board to my J-Tech laser control board. I will do this within the next few days (awaiting the lead from the USA) so I will not be able to run any tests that require the laser to do any further testing work until the lead has been changed.

1 Like

$i shows me the 1.1f is an older (2017) build but this is an excellent stable version to have.

Under OPT the letters VNPR represent:

  • V for Variable Spindle
  • N for Line Numbers
  • P for Parking Enable
  • R for Parking Override Control.

grbl/build_option_codes_en_US.csv at bfb67f0c7963fe3ce4aaf8a97f9009ea5a8db36e · gnea/grbl · GitHub

I don’t see H for Homing or L for dual limit switches.

The $# report showed me that you have three negative offsets.

When Park is enabled, G54 is used for Park.

A few months back I ransacked an .lbprefs file and discovered the User Origin had persisted past workspace size changes.

I’d like an opportunity to attempt to compare two lbprefs files to see if the ‘preferences’ continue to share the same structure, or if data, or settings changed when the update was done.

The files are saved with a date in the Filename. There are usually plenty to choose from. Please do a brute-force search of your hard drive and find the files with the lbprefs extension.

Please share one file dated from when LightBurn was working with your workflow (before your update to 1.4.00) and a more recent one after your update.

If the files resist uploading here, simply change or add .txt as a file extension.

Thank you for this information. I will be able to deal with this in a few days time. I am unavailable for 10 days.

1 Like