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

This topic contains 290 replies, has 44 voices, and was last updated by  Ryan 1 month, 2 weeks ago.

Viewing 30 posts - 61 through 90 (of 291 total)
  • Author
  • #8000


    Sweet! Thanks Bryan



    Wow, guys it is weekend here and I did not really expect a response so soon, let alone another version to test πŸ™‚
    Here you are already beating Picengraves support LOL

    β€œDue to my setup I have to flip every image – that is no issue, but the placement often is.”
    -Can you just flip your stepper plug around?

    β€œ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?”
    -I’m not sure I entirely understand what you’re saying. Can you not use the origin setting and pick the middle?

    I was thinking of just flipping the stepper and to change the config but there is more to it.
    The K40 machines have the origin and homing position in the top right corner, same for the limit switches.
    One day I might re-build the machine and do to it to CNC specs with the movements and axis orientation.

    Either I missed the origin setting somehow or fail to use it.
    No matter what I do the image is always placed right in the origin position – but will try that again with new program version.
    Maybe an example is better:
    You have a plate of 20x20cm but want to place a 5x5cm engraving right in the center of the plate.
    I might be able to mess around a bit with the origin setting but I see no way to be able to place the plate and get the engraving centered on it.
    Worse with bigger parts of course.

    Will get back in a bit after testing V6 πŸ™‚

    The start of the box is still messed up with the coordinates:

    ; Move to top left corner and begin box
    G92 X0 Y8607064

    Otherwise the code looks nice and clean now.
    I can offest the engraving with M92 command after setting the laser to the referenced image coordinates.
    For eaxmple a thicker piece of wood in the center of the table gets G01 X95 y85 followed by G92 X0 Y0 Z0.
    So I first move the laser to the right position for the image, then set this position as the home reference.
    Would be great to include this into the program instead of the
    “; Move to top left corner and begin box
    G92 X0 Y8607064”
    This way the user can set the origin and no need to fix the decimal problem πŸ˜‰

    The test engraving on 3mm ply ended badly as in some areas the laser burned through the first layer, currently trying again on a piece of hardwood.
    Only doing it in 0.2mm resolution this time to save some time.
    If it works out ok I will try the other side with 0.1mm and pulsed laser operation.
    So at least one image should be uploaded soon πŸ˜‰



    View post on

    Sneak peek of what else I’ve been working on tonight. Optimized rastering!!!!
    I’m going to be doing some testing on the code before I release it.



    things like this I actually do in a two step process:
    First a slight vector cut of the outlines, then just a normal raster engraving for the infill.
    Everything else I tried so far either ended in bad burn marks on the outlines or fine details missing.
    Considering the speed of the vector tracing the extra time on the machine can be neglected.
    You can see some example of this way here.
    Which should also show that I am not Andrew, just too lazy to leave my normal Nick here so people follow me around.
    Quite like it to be “the new guy” for once πŸ˜‰

    But I agree, if intergrated into your program it would give even more options and makes the use of other tools and programs almost a thing of the past.
    One thing that would be a really nice addition though is a g-code sender from within the program.
    Of course for spiled people like myself it would be great with a preview of the object in question on a plate with the size of the cutting area.
    Since it is free to, maybe it is possible to “salvage” some code from Pronterface/Printrun?
    Sending these massive amounts of code is a challenge in terms of right timing, checksums and so on, so somthing optimised for the few code bits we use here could improve stability during long engravings.

    And since I now outed myself here, would you mind if I include your program and a link to here with my laser related Instructables?
    I don’t see it as advertising if something good can get more attention especially not if it is so well supported freeware.

    Took the liberty to start some advertising here, feel free to leave a comment if you like.



    Ok, half way through the second attempt of doing it right I gues I found out why it was so bad in the prvious runs πŸ™
    Despite everything Marlin does not react at all to the decimal digits, only the stuff in front of the dot is recognised and used.
    With the power levels now just at 6 and 8 it becomes quite obvious as there is only 3 shades of grey now and all detail lost.
    Seems I now have to figure out a way to change the PWM handlin in Marlin from the default 0-255 to 0-1000 or better 10000 somehow.
    Tried this already a few weeks ago and utterly failed as I was greeted with compiling errors LOL

    Here is the last engraving, which was totally overburned.
    Done on hardwood (has too much resin in it too) with the power levels between 6 and 16.
    Before cleaning:
    On hardwood before cleaning
    After cleaning:
    On hardwood after cleaning

    As you can see there are also pinholes burnt into the wood, this happens almost every time the power changes or the head stops.
    Seems to be a problem in the Marlin firmware too or at least related to the slow processing of all the code.
    Bit longer and the other engaving is done for comparison.

    And here we go:
    Power between 6 and 8
    As you can see there are no 256 shades of grey, just next to nothing for withe and three more – everything from 6 to 8 in solid numbers only πŸ™
    Guess I am back to the drawing board for now.



    A while back one of the users on the forum concluded that piclaser performed better because it had the decimal power values.i dissected this wasn’t the case but i went ahead and made the change anyway.I’m still not sure if marlin can do anything with the decimals since your firmware isn’t really marlin.the turnkey tyranny firmware your using isn’t slightly modified.I’ve looked at it and it’s heavily modified in how it processes laser commands so the processing speed problem may possibly be there. I have zero speed issues running vanilla marlin firmware auth a diode laser. You also haven’t mentioned the TTL frequency of your laser driver. This is hardware related and will determine how quickly the power pulses can switch from one level to another.



    Leo, I’m not sure if your forum status allows you to edit your older posts. If you don’t mind I can edit your first post on this thread with the github link to try and make it easy to find the most recent version? -I’m about to do my first cncburn, making sure I had the most recent version!-



    Don’t mind at all. Best place for it.



    What is your feed rate here? If your laser is that powerful then you need to pick up the speed as far as the hardware limitations of your machine will allow you to. If you’re charring the wood at level 8 out of 255 then your laser may not even handle pwm input at all. A level of 255 is equal to 5v on Arduino so that means 51 power levels per 1 volt. A power level of 8 is only equal to less than .2 volts then! If you want to try something that may improve your results without much effort then try running the PWM output from Marlin through a resistor voltage divider that’ll bring it down to the low levels you need. This way you’ll get the full 255 step resolution from the Arduino PWM pin scaled down to a much lower level. Truthfully, I doubt it’ll work though because something just doesn’t seem right about your firmware/hardware set-up.




    Is there anyway I could persuade you to delete many of my posts in this thread? I blogged all over it not realizing I could reply to specific threads, meaning i overlooked the reply to the right of message. Dont want to ruin my chances of help in this forum or look like an idiot in posting like a crazy person.

    Leo and Bryan
    I absolutely love this software, however I have had much better luck with the previous version 4. Once I figured out how to offset the power levels and how to overcome the missed steps in y axis movement. In version 4 I use 10-12% wood at 5000 feed, which uses 0-28 or 30 depending on 10 or 12% in wood setting, but still amazing results on the few pieces I’ve ran. In version 4 the only changes I would have liked due to the power of my laser is the ability to use faster feed settings, for example if I set it at 7000 it still only moves very slowly at a predetermined feed rate, but one I would see more common with a feed of 1500. The feature I miss most when in image2gcode is being able to crop the image, but I dont mind editing image else where then open in image2gcode.

    I have tested the newest version 6 and at 35% under wood setting that puts max power of my laser at its max of 89. My laser goes from 0-100, but again I have found a way around everything by using lower settings. The only downside is the lack of intensity in any given in image, meaning most in here have 0-255 while I have 0-30. I will upload a few of the images generated via image2gcode but they will be completed with version 4. Oh I did notice when playing with version 6 that it would not allow for dither at all, I would click it but then it would revert back to greyscale?

    Sorry again for blogging all over the place and freaking out due to my lack of understanding in all this stuff. I got in way over my head and damn near drowned until finding this forum and also help from a friend.



    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.



    I wasn’t aware that grbl supported 10bit pwm on the spindle commands, maybe this change was made on the grbl for ramps version. Yes you can modify the firmware for more resolution on PWM but it does involve playing with timer prescalers. Before you do, make sure that the timer you’re modifying isn’t going to affect stepper pulses or any other time related functions that may be using the same timer. Plenty of timers available on the mega2560 but i think only two of them will support up to 16bit pwm. You’ll probably need to modify the firmware code that processes the fan/spindle commands too.It may just be using an analogWrite command for the pwm output and that command only supports8bit’ll need to write to the registers directly if you are going to 10 or12 bit.



    Thanks Guys for all the hard work!

    Things are working pretty smooth on my end. I did a nice portrait as a trial but The subject didn’t want her picture up here….bummer. I am having some small glitches that didn’t show up with some different software but I want to do some more tests before I say anymore about it.

    I did a little focusing script for repetier, I’ll do a separate thread for it.



    I like the honeycomb fan grill and that cool vortex twist on the end of your gonna post that design? If glitches seem speed related then it may be my fault for adding a bunch of decimals that Marlins 8 bit pwm can’t even process. I’ll make them optional on next revision.



    @andrew ,
    “In version 4 the only changes I would have liked due to the power of my laser is the ability to use faster feed settings, for example if I set it at 7000 it still only moves very slowly at a predetermined feed rate, but one I would see more common with a feed of 1500.”
    -You may have hit the max feedrate that is built into Marlin. You can delve into the firmware (Configuration.h) and bump up the max allowed feedrate and see if that solves the issue.

    “The feature I miss most when in image2gcode is being able to crop the image, but I dont mind editing image else where then open in image2gcode.”
    -I agree, cropping seems like a nice feature. I don’t really want this to become an image editing tool because that’s just more to maintain and troubleshoot, but cropping seems pretty benign to add.

    Unfortunately I do not have any experience/access to the K40 setup so you would have to look elsewhere for help on that.

    “Oh I did notice when playing with version 6 that it would not allow for dither at all, I would click it but then it would revert back to greyscale?”
    -Hmm, I will take a look into why that’s happening



    Thanks, I can post the design but right now it’s pretty part specific, Heat sink, and board at least. It also has some flaws right now, hard to put on a new lens because the heat sink kinda floats in there. I think when the resistors get here I’ll do another revision on it when I test the voltage divider. Not sure what is going on really, maybe its the power supply. some of the lines start late or end late and cause artifacts in the prints. I also think the slow accelerations in my firmware are causing some of the stuttering, I guess it could be the decimals, is that from the servo pins we are using, if the divider works and we use the fan port is it going to be different?

    You don’t need to answer any of that. I am super happy with the software you guys have adapted. I’ll stick to hardware and stay out of your way on the software.

    I found some 25mm stainless shower curtain rods….time to finally start the mpcnc updates. So much easier when I can test both sizes…



    I don’t think using the fan port will be any different. On your next burn try getting version 4.i think that is last pre- decimal version.If the stuttering goes away then I’ll definitely make the decimals optional. Using host software may slow things down too or your acceleration settings could be it too. I’m Sure you’ll meter that divider output before you connect your driver but it should work. I think there’s a FASTPWM definition that can be enabled on the fan pins. I’ve read some posts suggesting it improves laser grayscale definition but haven’t verified this.



    The “Dithering” function has been fixed. The inherited code is full of typos and I fixed “dirthering” to dithering, and well, that messed up some other references. It is back to the typo-d version until I have time to scrub the entire thing.

    I didn’t roll the version number so if you want dithering, just re-download it from the source.



    Awrsome job once again Bryan! I’ve never even tried the dithering. I hope someone will give it a shot and post pics for comparison to raster. Good stuff!



    Attached are three projects I created via image2gcode using cheap k40 laser with arduino+ramps 1.4 using a forked version of marlin modified for 40watt laser. I am super excited to have something finally working after months of headaches. The last image shows where my machine was sticking but printing now in diagonal the problem is solved again so freaking awesome.

    Bryan, I will check the firmware for the predetermined feed rate max and min, but when I use another program such as inksckape and set feed at 6000 or more I have no issues. At that rate of feed it is super fast but still the firmware does allow it?

    Also at a low feed rate say 250 or 300 and 100% power, my laser will come very close if not succeed cutting through 1/4 inch MDF, these images that I have attached were created at max power in image2gcode of 25.

    Thanks again and you’ve done an awesome job with this software, I am very grateful.




    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.




    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.


    //// 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

    //// 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_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 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 (

    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:,jxybeKL,UCLW8nU

    Please give it a shot and help me test it out!




    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.




    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.



    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.

Viewing 30 posts - 61 through 90 (of 291 total)

You must be logged in to reply to this topic.