File was too big, had to resize. Again was created using image2gcode version 4
@Andrew: Those CO2 lasers are powerful! If you or NoName007 get a chance, please try a voltage divider circuit. Sounds like you’re both engraving at a max power level of 25 which is roughly 10% of the 255 PWM limit. This equates to roughly .5 volts out of a 5V range. If you take a 9K and 1K resistor and create a voltage divider (other values will work-Google voltage divider calculator), you’ll bring down the 5v PWM output from the Arduino to a .5v output while still retaining the full 8bit(255 step) resolution. It may not work but it’s worth a try and will only cost about a dollar in parts and 5 minutes to solder. I’m VERY curious to see if this will improve your grayscale results.
Bryan
I looked into the code as suggested but didnt see an issue however I do not understand the code to begin with so I may be over looking it. Ive copied two parts of my config.h file regarding laser and the second part is regarding feed rates. I am still looking into how to clean up the code inorder to stop the low memory error I get when uploading firmware to ramps, other than that it all works great as is. The feedrate issues dont occur with inskape projects generated with inkscape plugin.
#DEFINE LASER
//// The following define selects how to control the laser. Please choose the one that matches your setup.
// 1 = Single pin control - LOW when off, HIGH when on, PWM to adjust intensity
// 2 = Two pin control - A firing pin for which LOW = off, HIGH = on, and a seperate intensity pin which carries a constant PWM signal and adjusts duty cycle to control intensity
#define LASER_CONTROL 2
//// The following defines select which G codes tell the laser to fire. It’s OK to uncomment more than one.
#define LASER_FIRE_G1 10 // fire the laser on a G1 move, extinguish when the move ends
#define LASER_FIRE_SPINDLE 11 // fire the laser on M3, extinguish on M5
#define LASER_FIRE_E 12 // fire the laser when the E axis moves
//// Raster mode enables the laser to etch bitmap data at high speeds. Increases command buffer size substantially.
#define LASER_RASTER
#define LASER_MAX_RASTER_LINE 68 // maximum number of base64 encoded pixels per raster gcode command
#define LASER_RASTER_ASPECT_RATIO 1.33 // pixels aren’t square on most displays, 1.33 == 4:3 aspect ratio
#define LASER_RASTER_MM_PER_PULSE 0.2
//// Uncomment the following if the laser cutter is equipped with a peripheral relay board
//// to control power to an exhaust fan, water pump, laser power supply, etc.
//#define LASER_PERIPHERALS
//#define LASER_PERIPHERALS_TIMEOUT 30000 // Number of milliseconds to wait for status signal from peripheral control board
//// Uncomment the following line to enable cubic bezier curve movement with the G5 code
// #define G5_BEZIER
// Uncomment these options for the mUVe 1 3D printer
// #define CUSTOM_MENDEL_NAME “mUVe1 Printer”
// #define LASER_WATTS 0.05
// #define LASER_DIAMETER 0.1 // milimeters
// #define LASER_PWM 8000 // hertz
// #define MUVE_Z_PEEL // The mUVe 1 uses a special peel maneuver between each layer, it requires independent control of each Z motor
// Uncomment these options for the Buildlog.net laser cutter, and other similar models
#define CUSTOM_MENDEL_NAME “Laser Cutter”
#define LASER_WATTS 40.0
#define LASER_DIAMETER 0.1 // milimeters
#define LASER_PWM 25000 // hertz
#define LASER_FOCAL_HEIGHT 74.50 // z axis position at which the laser is focused
// default settings
// AMRI Laser Cutter
//#define DEFAULT_AXIS_STEPS_PER_UNIT {167.20882, 167.20882, 4000/25.4, 1380/4}
//#define DEFAULT_MAX_FEEDRATE {165, 165, 50, 200000} // (mm/sec)
//#define DEFAULT_MAX_ACCELERATION {5000,5000,5000,500} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for skeinforge 40+, for older versions raise them a lot.
//#define DEFAULT_ACCELERATION 3000 // X, Y, Z and E max acceleration in mm/s^2 for printing moves
//#define DEFAULT_RETRACT_ACCELERATION 3000 // X, Y, Z and E max acceleration in mm/s^2 for r retracts
// Lansing Makers Netowork Laser Cutter
#define DEFAULT_AXIS_STEPS_PER_UNIT {157.4802,157.4802,6047.2440} // default steps per unit for Ultimaker
#define DEFAULT_MAX_FEEDRATE {500, 500, 10, 25} // (mm/sec)
#define DEFAULT_MAX_ACCELERATION {2600,2600,2.5,2.5} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for skeinforge 40+, for older versions raise them a lot.
#define DEFAULT_ACCELERATION 2000 // X, Y, Z and E max acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION 2000 // X, Y, Z and E max acceleration in mm/s^2 for retracts
// Offset of the extruders (uncomment if using more than one and relying on firmware to position when changing).
// The offset has to be X=0, Y=0 for the extruder 0 hotend (default extruder).
// For the other hotends it is their distance from the extruder 0 hotend.
// #define EXTRUDER_OFFSET_X {0.0, 20.00} // (in mm) for each extruder, offset of the hotend on the X axis
// #define EXTRUDER_OFFSET_Y {0.0, 5.00} // (in mm) for each extruder, offset of the hotend on the Y axis
// The speed change that does not require acceleration (i.e. the software might assume it can be done instantaneously)
#define DEFAULT_XYJERK 20.0 // (mm/sec)
#define DEFAULT_ZJERK 0.4 // (mm/sec)
#define DEFAULT_EJERK 5.0 // (mm/sec)
I’ve released version 1.0 on GitHub (https://github.com/Uthayne/3dpBurner-Image2Gcode)
This update includes:
-New optimized raster algorithm. Skips white space in the image to prevent unnecessary travel moves. This includes getting rid of all the extra move commands. This feature is currently only available in horizontal scanning mode. On the attached picture, this resulted in a file memory size decrease by 42%! (11 MB to 4.6 MB) and an estimated time savings of over 36 minutes (1:21 vs :45)
-Optional decimal precision on laser power levels. Still undetermined if this matters or not, but the feature is here by request from @Leo69.
Pictures and evidence below:
https://giphy.com/gifs/BNOxd0v1ILEac
Please give it a shot and help me test it out!
Thanks,
Bryan
This is a significant revision.great job Bryan! The decimal option definitely useless on stock marlin firmware since the windows gdi graphics only do 8 bit grayscale and that’s the image source. Probably useless on any controller for that matter. The only reason i thought it might serve a purpose is because someone had mentioned that piclaser used decimals and had better results with them.i guess its pretty harmless as an option though. I did manage to add laser functions to my marlin lcd menu and am testing 10bit and 16bit pwm. This will (hopefully)be a big improvement for grayscale resolution when burning at less than max power levels. Looking forward to trying your revisions.I’ve only seen this feature on one other software, commercial of course.
Nice work Bryan. I will run the same image with the same settings as I did b fore to see what the results.
Bryan
This is awesome, although I will not be able to test it until I replace my slide bearings. I did order/receive them however I just got everything back in to place and aligned. I Hate going through the process of ripping everything out and realigning, such a hassle. It is a necessary evil though especially when needing to lube everything up and clean mirrors/lens. As of right now I can only print in diagonal using image2gcode v4. I may change out bearings this weekend just to be able to use this new version 
Thanks again for all the hard and tedious work, I could not look at a screen that long. My eyes would kill me lol
Oh btw, I used the image2gcode to print into acrylic to allow for addressable leds to light up image like neon sign, I also burnt image into tile, although further research suggests that a product called cermark needs to be sprayed/rolled on for best results. Regardless the software is working awesomely.
Andrew,
I am planning to update the optimized algorithm to the diagonal scanning method too, its just going to have to take a different approach and a little more thought.
I’d be interested to see what you did with the acrylic and LEDs once you have finished it.
If you find initial success with your marlin edits, I’d be more than happy to help you further test them out.
Do you have piclaser? I have not used it but I’d be interested to see what other features they have included that I could adapt for image2gcode
Ok, it’s been a while, so time for some news from my end:
Will test the new version on the weeken - if I manage to fix the Marlin code to my liking.
I was able to find the algorithms for the laser power in the Turnkey release and to my surprise all previous postings I read about it failed to state the right facts.
According to the algorithm used the output is regulated between 0 and 100% - just like on the analog/digital panel running the original controller.
But to make things worse everything above 100 is simple cut off!
That means you get true percentages for the laser power - guess that’s why there are several safeguards to set all values above 100 down to 100.
Problem with this approach is that no only the bandwidth of the PWM signal is limited but also the available output.
I guess some people here are using these chinese K40 clones, so I will upload the hex file of my firmware once I got working with a more defined PWM system.
It is for the standard conversion using two pins, one for laser on/off, the other for the PWM signal.
Let me know if anyone wants to test it once working and I will include the basic shematics and pinouts just to be sure we are on the same project here.
Can’t wait to test the new software with proper PWM levels, although it will take me a while to modify the safeguards and change the algorithm.
Means I have to connect all to my oscilloscope, check the original PWM signal and compare it to the modified version.
What I want to achieve (if possible) is to increase the limit to 1000.
Meaning 1000 is full power, 500 equals 50%, 250 25% and so on.
Based on my tests with the previous I2G version this range should be sufficient for 8bit engravings on our CO2 systems.
Also found some code bits during my search in regards to the buffering of the movement commands.
Have to see if I find it again but it looked like everything was modified so that only G1 and G7 moves end up in the buffer - but not single M or S commands.
This explains why there is always a stop when speed or power levels change - the buffer is emptied with the last movement command and being filled again with the next set of movement commands.
But before I even start messing around here I will do some more tests with all commands integrated into the G1 and G0 strings.
Ok, looking very good so far 
The first try with the changed firmware seems to overburn in the dark areas but that will be addressed with lower power levels for the next run.
For the first time ever I can control the laser power with around 13byte accuracy, yes had to adjust the available power levels from 0 to 10.000 in order to get the control range required for these insane power levels.
But there is still some flaw in the gode generated by the V1.0, please have a look:
(Generated by 3dpBurner Image2Gcode v1.0)
(@Feb.26.2016 22:24:37)
M05
G90
G21
F3600
G0 Y7377483; Move to top left corner and begin box
G92 X0 Y7377483
M03 S5
G0 X60
G0 Y0
G0 X0
G0 X0 Y73.8
G1
M03 S0
G1 X0 G1 Y73.7
M03 S508
G1 X0.1
G1 X0.2
The move to begin the box is still messed up and calculated wrong.
“G0 X0
G0 X0 Y73.8
G1”
Why?
This first G0 and the G1 command seem a bit useless to me.
Apart from being burnt deep in the dark areas the engraving so far has a never seen level of detail.
Will see to get the power parameters optimized so I can do a proper engraving on 3mm plywood.
The speed is still painfully slow, so the next step will be to search the code for a way to optimise the command buffering for both the serial and the Gcode commands.
This involves messing with the look ahead buffer memory allocations and possibly more, so proper testing will be required.
I just love Image2Gcode
So I have to ask again: do you guys mind if I promote it a bit more?
Here are some of the test engravings so far:
This was done with the original Turnkey Tyranny firmware, as you can see there was no chance to get results.
This was the first engraving with the modified firmware but the power settings were far from good.
Same one but with the burnt stuff removed.
Here we are with the final firmware mod and some more defined settings for Image2Gcode.
And here afer the cleaning…
So who said 8bit photo engravings can’t be done on a CO2 Laser machine?
All it takes is the great guys here giving us a fantastic tool and some Arduino with the tight firmware.
No expensive 3000$ machine or Picengrave, just chinaware combined with good freeware
Like Hannibal always said “I love it when a plan comes together!”
Wow! That looks great! I’m happy you were able to dial in the settings. Was that using the optimized rastering? I’d be interested to know what your file size and estimated time were before/after optimization. The threshold value is another thing to fiddle with. It ignores any power level less than that percentage of the maximum laser value. (I never made that clear in my original posting)
I’m a little puzzled why you keep getting wrong values (or missing decimals) for the bounding box… its all based off the image size. As far as the moves, it is based off of standard CNC axis (bottom left corner is 0,0). It first jogs to the upper left corner (no matter where you had it set via the origin control panel) and then jogs clockwise around the limits of the picture.
Does this happen with every image? Because I have not been able to reproduce the same results
Image size is about 60x73mm.
Resolution 300DPI, estimated time in pronterface was 13minutes but took 42minutes to do.
And done just with standards, not the optimized rastering, this will come in the next testrun.
Will also fiddle with the threshold to check how it works.
But as said, so far I am impressed.
Guess it means you have beaten Picengrave on all accounts here
Not sure if you can spot the bright areas left of the chin and under the chin - they are actually toally black in the original image but for some reason did not get any laser power during the engraving, like being reversed out.
And as requested with optimized rastering, set to 1% as everything higher will ignore too much image.
Maybe finer settings here would be nice.
Estimated time in Pronterface: 8:07, real time 35:50min.
But this time I used a resultion of 0.12 to see if there is much difference in detail, also power was between 560 and 815.
Ok, currently doing some test on glass - anyone interested?
If so I leave some pics
I’d love to see the results on glass, though my 2.8w laser isn’t capable of it.
Here is a first impression on glass:
What seems to look hlaf decent is in fact total crap 
Turned out the photo is created by tiny pieces of glass that exploded off the surface and melted together, almost like frosted glass.
When you clean it off to get rid of the fine glass particles with a brush you are left with surface that looks like a big shard the shape of your image was chuked out.
Have to try it again as I dropped the wet glass.
Next one will be with less power more laser pulses per mm in the hope to stop the fusing of the glass.
If that is no good I will try find a way to fuse them together more permanently.
That’s the bad thing about glass, it shatters but does not burn away like wood LOL
Almost how I would like it:
I noticed some coding issues in my last test, apart from the ones mentioned above.
When setting the resolution to 0.12, 0.13, or 0.14 with a bigger engraving I got a lot of weird Y-axis moves before the actual job begins.
Like as if it is trying to engrave the first line vertically instead of horizontally.
There is also often a massive difference in filesize when going up or down just 0.01 for the resolution.
As if sometimes mostly lines instead of dots are used.
This last one made me think again about experimenting with the code to combine the movements and later to include the power settings into the movements as well.
On a simple calibration graph the time went down from 11minutes to just over 3minutes.
But for this to get the same result I had to increase the power levels manually to adjust for the higher movement speed.
The current way of generating the G1 moves blows the files up too much.
As long as there is no change in power all G1 commands before the last can be deleted to create a single line instead of dots.
Currently I have to set the resolution to 0.2 and the image DPI to 100 to be able to engrave a 23x17cm image, would be great to try that again in a much finer resolution