Framing issues when saving to gcode

Using a Longer Ray5 and just added the limit switches and updated the firmware. I have set the home and all of that is working as it should.

When I have my laptop connected to the machine via usb, it will properly go to home on startup, frame out the image I want to burn and fire the laser as it should, then I set the laser to go back home “IDK why it’s not doing this automatically after framing” I now take this and export it out as gcode to sd card, insert it into the laser and try to frame it. The laser just draws out like a 200x200mm square. Never fire the laser for the frame, etc. But if I hit engrave it will go to the correct position and start as it should.

Video of what it’s doing -

I have tested with the sample gcode images that come with it and they are all working fine.

Before I did the limit switch and firmware update the gcode was working, so not sure it I am missing a device setting now that needs to be changed due to the laser updates or what exactly I’m missing.


Can you provide the following:

  1. upload the sample gcode where this is working correctly
  2. run these commands in Console and return the full output:

Note that the first command will home the machine so be prepared for it.
3. Explain how you did this:

The gcode that I was using before the limit switch and firmware upgrade was overwritten on the SD card. So unfortunately I don’t have a copy of it anymore. I did about a dozen burns with that prior but needed to make minor text adjustment change in lightburn after the upgrade and this is how I found the framing issue as I rarely connect the laptop to the machine as they are in different rooms. So I just save it to the sdcard and insert it into the machine as I’m typically burning the same logos over and over again.

[MSG:Using machine:LGT RAY]

Home was set using the HHOME option with the machine control settings. I don’t think I did anything in lightburn with it, but I have been messing with a bunch of things lately trying to figure out the framing issues.

The output of the final command is missing:


Can you run these commands one at a time and return the output?

Can you elaborate on this? Where do you do this? Is it done on the remote control panel of the laser?

Also, can you provide the following:

  1. full screenshot of LightBurn with a design loaded and ready to burn
  2. save the gcode for the design and upload here

I think what may be happening is that your laser requires a special header file for the framing to work correctly that LightBurn doesn’t generate. But you indicated that the framing worked prior to the installation of the limit switches and firmware update. So still trying to narrow down what might be causing the issue.


Yes, The HHOME is within the remote control panel itself. I go into Control form the main screen and press the HHOME. It goes and calibrates the home position with the limit switches.

Yes, the framing was def working prior as I used it to position my pieces and then to create an outline jig on my scrapboard to position them exactly each time.

I also thought maybe the firmware changed something, but the sample files that shipped with the machine are prior to the firmware and they all still work. I’m uploading a sample gcode form longer that frames and fires the laser properly also.

Logo - RAY5 10W basswood engraving.gc (28.5 KB)

Screenshot from current project and the gcode generated from it.

MadeInUSA.gc (49.5 KB)


The output of the commands looks fine. I don’t see anything obvious there. It’s not clear what the HHOME is doing but I’ll assume for the moment that it’s okay.

In reviewing the gcode I’m noticing a couple of things:

  1. The sample “working” gcode is using “Current Position” as the Start From mode. I’d suggest trying the same for your own work.
  2. Somehow your device is configured as a GRBL-M3 device which you almost certainly do not want. Push Devices button in Laser window, then click on the name of your laser, then Edit. Change to “GRBL” and complete the wizard.

What the HHOME does it moves the X & Y axis until they hit the limit switches, this configures the hard home stops.

Yes I switched the device to the GRML-M3 from GRBL based on a thread I found here, someone had mentioned it may resolve framing issues, it did not and I just didn’t swap it back.

I did try swapping to using Current Position from Absolute Position, this just caused the laser to hit the hard stops when framing from the laptop and worse it crashed into the far X axis when I tried to frame from the gcode on the SD card. Both times I had the laser at 0,0 home position.

Where did you have the job origin when you generated the gcode? I assume you’d want it set to bottom-left corner if you were starting from 0,0.

Yes, I always have it set to bottom left corner.

I’m away from the shop for the night so won’t be messing anymore with it till tomorrow. I’ll try the position settings again tomorrow. Thanks.

I switched the device back to GRBL.

With the laptop connected I tried the current user setting and it would just frame it in the bottom left corner which is not what I need. I switched it over to user origin and the laser moved to the middle, framed it with the laser on and returned home, exactly how I want it to do. I exported that out to gcode and selected the file form the touchscreen menu on the laser and it crashed the laser, full reboot. Tried again and the same thing happened. Moved the head out a little bit and now it draws a big square like it did before.

Repeated it all with video -

MadeInUSA.gc (51.5 KB)

Are you consistently moving the head of the laser by hand? If so, that’s likely a factor in some of the unpredictability.

Your laser is equipped with open loop stepper motors. The effect of this is that the controller is unable to track motion that isn’t a result of commands sent from the controller. Meaning that manual motion of the laser head results in unaccounted steps.

Once the machine is homed you must exclusively use jogging controls either from LightBurn or on the panel to avoid loss of position.

No, but it’s necessary sometimes. This laser doesn’t come with limit switches by default so homing was done manually prior. Manually moving the head now stops it from crashing due to the bad gcode that lightburn is producing.

Case and point, I frame the job with the laptop attached from home and it frames it and returns home. Using the gcode lightburn produces, sd card into machine, press frame button, the head crashes going the wrong direction. even if the head is home. If I bump the head out manually like 1mm on X & Y, then the gcode frame works.

With Absolute positioning it should know the head is at 0,0 and move to center to frame, With current position it should just frame it where ever the head sits, and user position should frame it wherever I set the point. None of that works when saved as gcode.

Regardless of the positioning issues as I can work around them, I can’t work around the framing issues. The image I am working with is only 30x30, but the gcode framing lightburn produces is like 200x200. That is the only issue I’m concerned with that I need to find a resolution on.

LightBurn uses the same code while connected via USB as to what gets generated with saving the file. You can prove this out by saving the file and then using “Run Gcode” in Laser window to run the same gcode file.

Note that LightBurn isn’t directly involved in the mechanism that the machine uses for framing. Either the machine is deriving framing extremes from the g-code or is parsing the header but it’s not clear which one.

The relationship is actually backwards. Absolute Coords requires that the head is positioned where the controller indicates that it is. There’s no knowledge of absolute physical position or that the laser head is physically located where 0,0 is expected to be. If the controller reports current position at 0,0, everything will run with that understanding irrespective of actual physical position of the laser head.

Yes, relative to the job origin position.

If I’m reading this correctly this may not be right. User origin is similar to absolute coords but with an offset origin and the flexibility to add the job origin.

Can you confirm that jogging controls in LightBurn work as expected? Up moves up, down moves down, left moves left, and right moves right?

Also, can you confirm that you’re consistently working millimeters?

Running gcode from lightburn isn’t an issue as when it actually does the burn it goes to the proper spots when set to User or Absolute as it should.

Here is some testing down with the gcode output. I took an original sample file gcode and pulled it into lightburn. I saved out the gcode using absolute, current and user and here is how each behaved.

Original - frames properly and burns in the lower left corner
Current - frames properly and burns to the lower left corner
User - frames a huge 200x200 square, moves to center of board and burns as it should
Absolute - frames a huge 200x200 square, moves to center of board and burns as it should

So the question comes then is why are User and Absolute not framing properly? I don’t know enough about gcode to decipher it just yet.

Bird_Absolute.gc (96.7 KB)
Bird_Current.gc (76.2 KB)
Bird_Original.gc (86.7 KB)
Bird_User.gc (76.3 KB)

This is the core of the misunderstanding. The gcode does not instruct how to frame. That’s purely a function of the controller. The gcode only contains instructions for running the job.

The controller/remote is deriving something from the g-code to frame. Try this, remove all the comment lines of the header from the Current Position version of the gcode. Then try framing. If it still frames correctly that means that the controller is likely going through the gcode and identifying min-max of all X and Y related commands to determine the bounds. If it doesn’t work that means that is uses the bounds area in the header to determine bounds.

Are you certain that framing worked correctly with User Origin and Absolute Coords prior to your recent changes? Is it possible that it has only ever worked with Current Position?

I figured out the problem. When I did the limit switch upgrade and updated the firmware I didn’t realize that the guide I followed wasn’t actually linking to the manufacturers download site, so the firmware I downloaded was prior to the version I had installed. I updated to the correct new version and now everything is working properly. :man_facepalming:

Thanks for the help on this.

1 Like

Excellent. It fits that it was a firmware issue so you got that going for you.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.