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

Profile photo of Noname007Noname007
Post count: 29
#8068 |

Ok, first off:
At level 6 the laser starts to work, so far I have not used anything above 35 on wood as otherwise there is just too much burning.
The laser usually operates at 60kHz and PWM control is working just fine except that it only works in full increments.
Tested it with the stock standard Marlin on my 3D printer and confirm that Marlin is unable to handle digits.
Even before changing the crappy controller PWM was working fine, just only through the digital input on the panel – from 0 to 100% in 0.01% steps – confirmed with my oscilloscope.
Those values are also what I used in the firmware as the default settings for pulsed operation – yes the pulse control works fine too.

I had some engravings done with GRBL, the version for the Ramps 1.4 board.
There the PWM control goes from 0 to 1000 and the engraved results have not been that bad, although I gave up on GRBL before finetuning the settings.
So the hardware is quite capable, I only need to find the right stuff to transfer commands into motion.

The above was done with the speed, acceleration and jerk set to max values but it dit not reall change from the one before done at just 1200mm/m.
I assume that due to the firmware forced pause when handling M3 commands as a single command instead of within the G1 movement the pinholes happen.
Grbl was much faster here but had too many other limitations that right now I neither have the time nor will to look into.
Marlin I know a bit GRBL properly for my machine would mean massive hardware changes, by massive I mean the need to take the entire machine apart to fix enstops and motors to be conform with grbl.
I did change the code again to include the laser commands into the G1 commands but it only slightly improved performance.
The massive amounts of tiny movement commands flood the look ahed buffer as well as the serial buffer.

If I find some time and the right mood I will try to change the firmware from the defaults to using more memory for the buffering and serial commands.
So far I am on the lower end of the scale using the same values that worked good on my 3D printer.
But I don’t think that 32kb more would make a massive difference.
So I will do the next test with a simple Gcode sender if I find one that like me 😉
My persoal favourite would of course be to change the Marlin firmware so that the PWM stuff for the laser can go from 0-1000 instead of just 255.
10000 would be better, especially for more sensitive materials and I think it would not make much difference in terms of the coding.
Only problem is that I have no clue where to even look.
In some reference I found that the internal clock signal is used and that instead of the fixed 255 a user defined value can be used, but of course nothing about how to do this LOL
I am quite reluctant to go back from an otherwise perfectly working system to GRBL just to be able to do 8bit engravings -there has to be another way…

By the way, the guys at Piclaser said that a CO2 laser is only compatible with their CNC plus laser stuff and there just for bitmap engravings.
If I want to do bitmap engravings I just do them through Inkscape free of charge 🙂

Last one for today:
I don’t know about the standard firmwares you guys use for the laser but Marlin supports Base64 encoding for raster engravings.
Well, not just for the laser stuff but there is so far no real use for it on a normal 3D printer…
What I was thinking is to comine all those G1 commands with no laser power change into a Base64 string.
If there is a power change and only a few movements after this till the next power or line change the encode line will just be short of the standard length.
This should allow for a code reduction of about 60% comapared to what the V6 version offers, plus a massive performance gain as the machine does not need to handle so many commands.
But I have no clue how hard it is to implement and if it works on all firmwares, GRBL of course sticks to CNC standards and won’t support it.