GCODE import to LB - problem with imported image dimensions

Hello everyone. I’m new here. I’m just testing my first laser engraver (Atomstack A10 PRO) and I’m having a weird problem importing GCODE files, it’s about image dimensions.
A test GCODE file is included with the device. I opened it for a test in LaserGRBL, the dimensions look correct (I didn’t run the engraving though). I then ran the file engraving on the device (VIA SD-card - Atomstack has an offline controller). Everything worked out fine. Then I imported the same file to Lightburn and the dimensions of the imported image significantly exceed the working area of the engraving machine (410x400mm). The file is actually 64x45mm. What happened? Is this normal Lightburn behavior or am I doing something wrong?
I’m using the latest trial version of LB, all configuration (I suppose) was done exactly according to the instructions from the LB help page.
I also observed a similar problem earlier, but I assumed that it might be a wrong configuration of the device (I didn’t have a laser at the time, I created a configuration for dummy one).
Anyone help?

I just imported a bunch of Gcode (.NC) and DXF files into Lightburn for viewing. Some came in as tiny, others as much larger than the working area. I expect this is normal because the imported file would have no knowledge of your work area size or the measurement system you have chosen. I found I could resize from both large and small to fit the work area in just seconds. Hopefully you see this as a non-issue as I do. Have fun with your new toy!

Thanks for your reaction. If I can’t rely on the dimensions in the .nc file, that’s a big problem for me. I’m going to use the engraving machine to make PCBs for electronics and other components/parts for RC models for myself and a few colleagues. So dimensions are absolutely crucial, I wouldn’t want to tamper with files provided by another person. I thought the GCODE file was fully unambiguous. If I don’t find a way to deal with this problem, I’ll have to look for another solution, software, whatever.
Is there any other format that can be fully trusted in terms of dimensions? Native Lightburn format is out of the question, I can’t force anyone to use a specific software, it seems most will choose LaserGRBL because of the cost. SVG is also problematic, not all programs generate it correctly. What is left to choose from the popular formats? Raster formats, but that looks risky too.

Could the G-Code file be in metric and you have LightBurn set up in inches?

If the G-Code file doesn’t include a G21 at the top to announce its intention to use millimeter, then LightBurn would interpret the numeric values as inches, producing a 25.4 blowup.

Not including either G20 for inches or G21 for millimeters is bad practice, but that subtlety might have fallen off somewhere along the way.

Yes, that looks right. None of the problematic files had the G20/21 parameter. After manual editing, everything looks immediately better.
This leads to two conclusions:

  1. Many GCODE generating programs ignore the need to add this parameter.
    2.1. Lightburn arbitrarily assumes that the unit is inches, even though I have set everything possible to mm in the settings.
    2.2. This case is similar to the situation with other files (probably dxf, I don’t have a PC at hand to check). But in this case there is an option in the settings to force LB to interpret unitless dxf files as metric or imperial. Might be worth considering adding the same option for GCODE files, it’s the industry’s primary format after all.
    I regained hope in being able to use GCODE as an interchange format.

Not sure I understand the problem. Did a quick test with LB, box, set LB to IPM, generated Gcode. LB put a G20 in the code. Stripped out G20 and saved so there is no indication of measurement system. LB set to inches, file came in as inches. LB set to metric, file came in as metric.

Put G20 back in and LB set to metric. With G20, file came in as metric. But I set LB to inches and box was exactly the size it was supposed to be, in inches.

So I now save the file as metric. I get metric X and Y values in the code. Now if I shoot these files to the controller without the G20/G21 instruction, I will get very different cut paths. Is the controller supposed to know which measurement system is in play without being told? LIGHTBURN does not care because you control the measurement system. The Laser/CNC does care because it has to know if the X2.54 is inches or mm.

In other words, you have to know what you got/purchased so you can tell your machine, by either the G20/G21 in code or usung the machine control panel. Just so you know, if you import a file without G20/G21 and Save Gcode, LB will put whatever you have in the Settings in the output file, with the correct X and Y values. Sounds like LB has got you covered but you have to do your part too.

The problem lies elsewhere. LB generates the GCODE correctly, that’s clear. However, it incorrectly imports GCODE files lacking G20/21 instructions. At least that’s how it looks in my case. Since I will be dealing with files of various origins, I have to check whether the file contains the G21 instruction or not and add it manually if necessary.
Now I know it, but when I started the thread, I had no idea how GCODE is built and works, so I was completely surprised by the results.
Hence my suggestion to implement a similar option in the LB settings as in the case of DXF:
DXF
Might make someone’s life easier.

Yes, I guess they could parse the Gcode for G20 or G21, but all that would do is flip the in/mm switch. When I imported the MM file LB=mm and without G21, it did come in larger than my work area. but that told me the file was full of X’s and Y’s over 100, and probably metric.

Yes, it would be great if everything was plug-n-play, but if I were going to import an unknown Gcode file, I would want to have some idea what it was going to do to my machine.

Thank you for this dialog. Until today, I had no idea why Gcode files came in small, medium, and large. I really never had an issue with this property.

The default behavior for G-Code files in CNC machines was “it depends”, per the LinuxCNC doc:

Perhaps the most critical modal setting is the distance units—If you do not include G20 or G21, then different machines will mill the program at different scales.

By and large, anything goes when the file doesn’t nail down the details.

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