First off… I have just seen the updated version video on YouTube. That is a mighty amount of work that has gone into the update. I am looking forward to installing it. Well done guys, it appears to address many things that required an update. Thank you for your hard work.
I have Lightburn installed on my Mac running Catalina 10.15.7. I have a couple of macros which I use to flip the controls and the homing point on my ShapeOko SO3. I have had a long discussion with one of the users of the Shapeoko CNC and we analysed what the macros were doing, in response to an enquiry from another user.
The mystery is what is the command that is reversing the controls when Lightburn is loaded? The only one that appears to have a role in this is $10. In JTech’s macros there is no sign of the $10 parameter. Thank you for your assistance.
For Laser to CNC
$32=0
$10=255
$20=1
G10 L2 P1 X0 Y0
For CNC to laser
$32=1
$10=0
$20=0
G10 L2 P1 X-459 Y-415
Hello? @LightBurn or @Rick. Is it possible you guys had missed my question about the reversal of controls in ShapeOko CNC machines, necessitating the setting up of macros for selecting the CNC or Lightburn use?
Does the problem occur in your software, Carbide’s software (GRBL1.1f… AFAICT) or the JTech lasers? I would appreciate a response so that I can address the issue in my own workflow. I would like to work with @neilferreri on this issue over in the Carbide 3D forum. Thank you.
Exactly. On the CNC, work zero can be set anywhere within the work envelope. The most common location for work zero would be the front left of the workpiece, just as with Lightburn. I’ve not heard of anyone that uses MACHINE zero (back right) as they’re work zero on a grbl based machine. The $10 parameter just says how the position is reported, in machine coordinates or work coordinates. Grbl senders should be able to handle both status reports as the difference between Machine and Work positions is defined by the WCO (work coordinate offset).
I’m still not sure why your machine would run in reverse on any axis. Regardless of where your work zero is, right is +X and back is +Y.
It’s not reversing the controls, but it seems to as a side effect of what’s happening when you jog.
If you issue a relative move command in LightBurn, it first asks the machine “Where are you?”, then adds the amount to move from there, and issues the command to go to the newly computed position. The machine interprets move commands in workspace coordinates, but if it’s reporting positions in machine space, the computed target position will be in the wrong space, and the machine moves to the wrong location.
Because then we can’t verify that you’re not going to send the machine out of bounds. I’m not even sure I’m actually doing that at this point, but that was the intention.
In the console, if you turn on the ‘Show All’ toggle, you can see every command LightBurn sends.
Whoops! Late to the party… sorry guys. Thanks for talking with Oz, Neil. Thanks Oz. Have any other users reported this issue? Jay (at JTech) has provided a macro for ShapeOko CNC machines so he is aware of the issue.
Hi Oz, When setting up the work area in basic settings, I set that up to reflect the work piece size and my limitation of reach. My JTech laser is mounted on the front of my spindle and creates a considerable offset from my normal spindle position. If I specify my full sized spoilboard (400 x 400 approximately) I cannot reach the back of this spoilboard with the laser because of the mounting bracket derived offset.
I compensate for the offset by making the work area smaller and not sending the carriage beyond a boundary where it can work effectively. Is Lightburn not checking for the boundary according to the user defined work area? I do not put any workpiece outside of the area which I can reach with the laser beam.
If your machine homes at the back-right, you can just set the workspace in LightBurn to be shorter than the total workspace of the machine, and that should work.
Part of the reason for all of this is the recent support for continuous jogging - for that, we have to specify a jog target that is within bounds of the machine or it will be ignored, and we have to give a jog command far enough that it will cover the entire travel of the machine. With those two constraints, the command really has to be in absolute coordinates. If you’re not using continuous jog, we could use incremental commands, but it was easier just to make all the machines work the same way.
If only there was a button labeled “Extend Trial” or something that you could use…
The problem there is that on CNC machines those are negative, and we don’t support that, which is the whole reason the workspace offset is required. We will be improving this over time.
I see. I also understand the rationale but you will know that continuous jog, when set, leaves one without any means to set the height of the Z axis, if you are like me and not familiar enough with GCode to enter the commands at the console. The buttons on the move screen for moving the Z axis are greyed out in continuous jog mode.
I actually never used it on a machine…just played with an Arduino to help someone else out.