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.
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.
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.
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.
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.
@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.
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.