It is recommended that the .nc file generated by laserGRBL can add coordinate information at the beginning of the file

[solawc]

Is your feature request related to a problem? Please describe. Hello, we have designed the main board of the engraving machine, and we are very smooth in the development stage until we encounter a problem. Because we hope to design a product with offline function, and the function is no less than online engraving, such an ordinary MCU can not match the PC's CPU. Therefore, I encountered this problem when using LaserGRBL: I used the offline patrol function, because the patrol needed to read the entire file on one side to get the maximum and minimum values. When the file reached 50M and larger, the opportunity would need to wait for almost one. Hours, this is disheartening.

Describe the solution you'd like In fact, it is very simple to solve this problem. I suggest that laserGRBL add file information at the beginning of the file when generating the .nc file after parsing the file, so that when the user uses laserGRBL, The lower computer can directly obtain such coordinate points to obtain a faster side patrol experience.

[gmmanonymus111]

While it may be a good idea to implement a feature like this, please note that the format would be no standard, and everyone would need to implement their own parser, if they want to use it. Also, I'm not really sure if offline controller enhancements are in the scope of LaserGRBL. If it falls outside of the scope (or until it's implemented), you can try adding such info manually or using some post processing script to do it automatically.

[arkypita]

Good morning

I think I can accept your request and insert some information about the job, including the expected size, at the beginning of the file within the gcode export procedure (a sort of header).

The information can be expressed in the form of a comment, prefixed with a semicolon, so that they are ignored by any gcode parser that is not interested in them.

This is the format I suggest:

;Generator.Name: LaserGRBL
;Generator.Version: 4.4.1
;Header.Version: 1.0
;Job.Offset.X: 11.0
;Job.Offset.Y: 5.0
;Job.Size.Width: 82.0
;Job.Size.Height: 52.0
;Job.Unit: mm

• Decimal separator will be always a dot "."
• Offset can be negative
• Header.Version: Indicate the version and format of this information. If I need to add new information in the future I will increase this number

As @gmmanonymus111 pointed out, this will be the format in which LaserGRBL will write them and, as there is no standards about this type of information: other software may decide to use different conventions.

It is therefore your task if you want to support other programs to understand how to read this information from various file types.

[solawc]

Good morning

I think I can accept your request and insert some information about the job, including the expected size, at the beginning of the file within the gcode export procedure (a sort of header).

The information can be expressed in the form of a comment, prefixed with a semicolon, so that they are ignored by any gcode parser that is not interested in them.

This is the format I suggest:

;Generator.Name: LaserGRBL
;Generator.Version: 4.4.1
;Header.Version: 1.0
;Job.Offset.X: 11.0
;Job.Offset.Y: 5.0
;Job.Size.Width: 82.0
;Job.Size.Height: 52.0
;Job.Unit: mm

• Decimal separator will be always a dot "."
• Offset can be negative
• Header.Version: Indicate the version and format of this information. If I need to add new information in the future I will increase this number

As @gmmanonymus111 pointed out, this will be the format in which LaserGRBL will write them and, as there is no standards about this type of information: other software may decide to use different conventions.

It is therefore your task if you want to support other programs to understand how to read this information from various file types.

Hello, good morning, thank you very much for your support. I have been using LaserGRBL with my engraving machine motherboard. It makes me feel very convenient to use and simple to operate. Regarding this format, I think it is possible. The rest is my parsing task. Before this format came out, the bottleneck for me was the parsing of file information. After all, I received the MCU's frequency limit. When there is this piece of information, it is undoubtedly a gospel to the designers of the engraving machine motherboard. It will be more convenient for the motherboard to achieve more actions.