Reply To: Image2Gcode – Free Raster Image Laser Engraving Software – Modified for MPCNC

New Home Forum Software Development Image2Gcode – Free Raster Image Laser Engraving Software – Modified for MPCNC Reply To: Image2Gcode – Free Raster Image Laser Engraving Software – Modified for MPCNC



First off I have to say that Leo69’s last version is the best tool for 8bit engraving on a china CO2 laser!
I tried a lot, messed around a lot but nothing ever worked in a similar way as with these low power laser diodes.
I love the approach of finally allowing the S values to be changed in tiny increments rather than full S values.
Still waiting a few hours for my first (hopefully) good engraving to finnish, will upload a pic when done.
So I though I could spend the time waiting by giving a little review and by being a little pain in the b…. with some suggestion to make the program even better.

Hardware: K40 clone from china, CO2 power: 40W (claimed anyway)
Firmware: Turnkey Tyranny Marlin release with some slight mods to make it work properly on my machine
Running on an Arduino Mega2560 with full graphics display, SD support and encoder
Usual cutting and bitmap engraving: Turnkey Tyranny Inkscape plugin

General problems with CO2 lasers when you want to do 8-bit engravings (from my personal point of view):
The laser is very powerful and the wavelenght extrem efficient on all organic material.
This means a slight increase in power can totally change the outcome of any engraving.
Some of this can be compensated by good hardware and a fast processing of the g-code commands.
GRBL is quite good in this field but at least for my a pain to set on with a Mega on Ramps.

The V5 version of the program generates code that for the first time produces usable results on my machine.
Although I realise it not designed for my personal setup I noticed some things in the gcode could be improved on.
I use the gray scale 8 bit mode and M03 S / M05 for the power settings.
But the resulting code always contains M106 commands for the power level at the beginning – not sure if it is intentional but for me it is at least confusing.
Also the move to start the image seems to be calculated wrong as there is no dot.
Here is a code example:
Code example
1. the CR and LF linefeeds are inconsistant, not really a problem unless you need to use some scripts to modify the code (like me šŸ˜‰ )
2. Line 11 and 12 show the problem with the wrong calculations from above.
3. Line 14 and 22 have M106 commands although the M03 S was specified for this.
4. Line 15 to 20 make no real sense to me – could you explain this part a bit please?
5. Between every command is an empty line generated, this blows the file up and slows processing – would it be possible to remove those empty lines?

Some more general questions:
If I assume correctly then unless a change in speed or power is applied, or it is changed from G1 to G0, power and speed stay the same.
If on top of that there is no change in Y or Z direction, it would mean that every G1 move does the same thing too, only a bit more to the left or right.
So I have to wonder: Wouldn’t it be possible to combine all these tiny G1 moves with no other changes into one single move until the next speed, power or Y axis change?
Together with the removal of empty lines this would shrink the file drastically and speed up processing as well.
(If I understand the logic behind the program correctly than these tiny moves are the result of addressing the single pixels in an image?)

With most firmwares it is possible to compbe the S command with the movement, if possible here it would also shrink the file further.
Is you way of the implementation specific to the MPCNC project or could you allow for the S command to be added to the movement?

Since Co2 is powerful it would be great to be able to use some decimal digits for the power settings in the laser profile.
Currently there comes a warning and no . or , is allowed.
Is it a big problem to change this?

Due to my setup I have to flip every image – that is no issue, but the placement often is.
It would be great to allow for an offset for the start of the engraving so you can engrave in the center of something bigger like a name plate.
Is it possible to add a box for a X and Y value offset from the origin?

Ok, I know I’m a pain but I could not resist as this program is really great and I would love to see it taking on Picengrave as a freeware replacement šŸ™‚