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
Now with everything working at least half decent I took some time to check on the problem of stuttering during the engraving.
After maxing out the hard- and firmware settings for speed I was back to the Gcode to find the cause.
One thing just to be clear here:
These speed issues might not affect everyone with a diode laser but the info might still be of value for those with a CO2 system or with the need for more info.
All Gcode is tansfered through a serial connection no matter if you use UBS or the SD card, but the SD card requires less processing power.
This means that systems like mine should better use a display with a parallel connection or no display at all.
The Smart Discount Controller uses a serial connection to provide quite some info on the screen and even with lowered refresh rates it interfered with the engravings.
At high speeds it was enough to go through the meu settings to make it all stutter.
I tried to direct the SD stuff through a software serial connection, did not work, and if done for the display I was unable to find a onfiguration that would not mess with other factors.
So all further tests have been done with the display completely inactive and the controller only used as a card reader.
Being aware now that the Gcode is transfered through a serial connection that relies on the CPU timing my first attempt was to use a slower SPI rate of quarter instead of full speed for the SD.
It did not improve much but I left it that way.
Increasing the serial buffer of the Mega from 64 to 256 gave quite better performance but still massive stuttering at higher speeds.
At this point I started to think that the slimmer code already made a big difference so maybe it is the amount of data that needs to be transfered?
Mind you the SD uses 9600baud for the serial transfer – this is an important factor!
The higher the engraving speed the more commands per second need to be transfered through this serial connection.
From here they end up in a buffer that is used for the movement calculations – the RX buffer that was increase to 256.
So everything that goes into the buffer has to come out as well, this means the buffer must be filled before it runs empty and can’t be allowed to overflow either.
As a result the 9600 baud are one limit, the buffer handling another.
If we take into account all the othe code the CPU has to process it becomes clear that more Gcode is transmitted per second the faster the firmware and arduino will reach their limits.
Without claiming I understand all the inner working of Image2Gcode I think that the pixel information becomes more detailed the higher the image DPI and the set resoltion in the program is.
You can basically adjust how many power changes happen in an engraving per mm of line.
Taking all this into account I think it could be possible to create a calculator for the max speed.
Quite a few variables I know 🙁
My tests showed that images with less power changes allow much higher speeds than let’s say landscape images.
Also of course that the higher the resolution settings in Image2Gcode the lower the speed has to be to get proper results without stuttering.
So using a dedicated Gcoder sender will not really help much here.
I think one way of optimizing would be to eliminate the resultion settings in favour of a calculation based on laser spot size and image resolution.
Meaning that the image informartion is not calculated based on the pixel information but instead the pixel value for the laser spot size/image resolution is averaged.
This way the engraving quality in terms of data generated will be based on physical factors that reflect the machine and should provide optimized results on all systems.
I did some test trying to figure out a way to implement this but it over my limited capabilites.