I am trying to control a laser with the fan (D9) and ran into problems. So I tried P44, no good then P6 also not good.\ What my problem is I am trying to "burn" a group of vertical lines spaced about 0.75" apart, and randomly the drive to the laser power supply is either "skipping" (missing the control pulse) or stretching the pulse. This results in missed burns and/or "streaks" where the laser does not turn off. I am using Marlin 1.1.4 on a RAMPS 1.4 board (clone) on an Arduino close also. When I am not printing, the pulses are perfect and I can control the pulse width with M42 P6(or 44) S0 (to 255) and it follows just fine. It is ONLY while I am printing and the steppers are moving that things go south. This also occurs on D9 (fan) and that is why I am trying these other outputs. These other outputs use different timers in the 2560 as well. I have tried all sorts and combinations of firmware settings, different USB cable and different USB ports on my computer, with no change. What might I be missing?

  • $\begingroup$ This is not an answer but a related question. I'm assuming (hoping) that you are using Marlin to read the g-code. What are you using to generate the g-code and how are you "telling" it that the fan control is really the laser control, or are you manually editing the g-code? Walt $\endgroup$ Aug 22, 2017 at 23:02
  • $\begingroup$ @WaltScrivens - SE is not really a forum of threaded messages, but a Q&A site. Would you like to post your own question, using the Ask Question link at the top of the page? You can link back to this question for reference, using the URL. I am afraid that unless you do so, you won't get an answer, as answering in comments isn't allowed. :-) $\endgroup$
    – Greenonline
    Nov 10, 2018 at 15:49

4 Answers 4


Thank you all for your suggestions and help.

It appears that I was just running the printer too fast and slowing it down to about 10% of my original speed "fixed" my problem. I don't know where i got the rediculous speed from, but 1200 mm/min is WAY too fast. More like 150 to maybe 200 mm/min is what it should have been.

Oh well.. comes under the heading "pay attention" I guess!


Have you checked the supply voltage? With everything turned on (steppers stepping, laser on, etc) you may be pulling too much current and the supply voltage is drooping.

Use DVM to measure the DC voltage. Also you will need to check for supply ripple. For that, either an oscilloscope or use DVM set for AC voltage.

  • $\begingroup$ Thank you Mark for responding! Yes, I did watch the power supply with a scope while a burn job was running, and it is rock solid. The supply is a 12V 20A switcher, short #14 cable (Malibu low voltage wire), a 6 pin/10A Cinch-Jones connector between the supply and the printer, #16 low current wiring and #14 heated bed wire (not used for laser printing though). $\endgroup$ Jul 14, 2017 at 18:17
  • $\begingroup$ To eliminate any possible unknowns, I unplugged all the steppers and disconnected the laser diode. I was able to "fake" the endstops as well and while scoping the PWM drive to the laser supply, this problem still existed with no apparent change. I even reduced the feedrate (which slowed down the print speed), and some of the problem improved, but was still there at 50%. I have ordered a REAL Arduino mega 2560 and will try that... $\endgroup$ Jul 14, 2017 at 18:23
  • $\begingroup$ Another clue that might be related is I could never get the SD card working. Checked all connections, short cable between the display board (with SD card) and the RAMPS board, read many forums and really went through the firmware, and still couldn't read the card. My processor board is an Iduino mega made by Geeetech, so I know it is a clone and I was always suspicious of it. The soldering isn't very good and I had to do some touch up when I got it. $\endgroup$ Jul 14, 2017 at 18:27
  • $\begingroup$ I know others aren't having this problem, and I haven't gotten many responses probably due to my unique problem that others don't have. I might try and scope the processor's power supply after the onboard regulator and see if it is clean. Thank you again for your help and suggestion. $\endgroup$ Jul 14, 2017 at 18:29
  • $\begingroup$ What does the signal on the laser look like? Also, can you put your Marlin files somewhere I/we can see them? $\endgroup$ Jul 14, 2017 at 22:36

You should insert M400 commands before each and every M42 command. The reason is that M42 skip the normal command queue. Each M42 command is processed as soon as it is read, and may be executed well before the G-code (moves) preceding it have actually been executed. Inserting M400 before M42 will ensure that the printer finishes all moves before M42 changes the pin state.

The long "streaks" you're seeing correspond to the printer processing a laser-on command too early, and the missed pulses correspond to processing a laser-off command too early.

  • $\begingroup$ AHHA! I will give that a try! Thank You! IF I use the fan pin (D9) and the M106 to turn the laser on, would inserting the M400 before the M106 work as well? I could add that to my laser on, and M107 for laser off. Example: M400 M106 S120 (for 120 power) and M400 M107... I'll give it a try and see what happens. Thanks again! $\endgroup$ Jul 18, 2017 at 2:34
  • $\begingroup$ Well the format of the commands didn't work... the laser never turned on. Soooo I will have to add the M400 before each laser command on a separate line... darn it! $\endgroup$ Jul 18, 2017 at 2:49
  • $\begingroup$ @Pomonaill220 Are you aware that only the negative side of the fan is switched? The positive terminal is always at +12V. $\endgroup$ Jul 18, 2017 at 4:06
  • $\begingroup$ Yes I am aware of how the fan output is driven y the FET. thanks for the note though! What I think my WHOLE problem is, is that I am trying to make all my moves too fast. I had the burn speed set at 1200 mm/min and non burn speed at 4500 mm/min. I slowed it WAY down to 150 mm/min and non burn to 4000 mm/min. Never skipped a beat! I think I might try seeing just how fast I can go before missing commands, but I did research and some are running at 60 mm/min... NOT 1200!!! I'll give it a try just to see. A little too enthusiastic I think... huh? $\endgroup$ Jul 18, 2017 at 4:37
  • $\begingroup$ In almost all cases, only one M code is allowed per data block (this is true for Fanuc controllers and likely applies to 3D printers as they copied most of the standard). You can have multiple G code per block though. $\endgroup$
    – tjb1
    Jul 18, 2017 at 11:13

This is a stab in the dark but maybe the Arduino (clone or genuine) and RAMPS1.4 combination is not powerful enough to handle the calculations required to control the laser and printing simultaneously (although I can't really see why the additional processing to control a laser would be over taxing the processor. However your comment about slowing the printing seems to help alleviate the issue, does back up the hypothesis). I have read that the ATmega256, and lesser AVR microcontrollers, can be working at its limits, when controlling a 3D printer and having to deal with arcs, or something that requires complex calculations.

Some printer control boards, such as the Smoothie, use different processors (ARM?) in order to supersede these issues. From 3D Printering: Electronics boards.

The above boards use AVR microcontrollers. While they work for what they’re intended to do, there are a few limitations. Arcs and circles are a little weird to program, and using these boards for something other than a cartesian 3D printer – a CNC machine, or a laser cutter, for example – is a bit out of the ordinary. The Smoothie board is the solution to these problems.

So, if you have discounted power issues, it could be due to computing power and it may be worth considering using a different, more powerful, controller?

  • $\begingroup$ I kinda thought that also, but wouldn't running an extruder in the 3D printer mode, with the extruder stepper, X,Y and Z axis all running, a coling fan and both the extruder heater and heated bed use more processor power than modulating one pwm pin and only the X stepper? Unless there is more going on for the laser than running the filament in 3D mode, I can't see that, although there may be something that I am not seeing! Also, the original printerboard was ALOT less powerful than the Arduino, and it worked for the 3D printer. Others are using the same setup for a laser and it works. $\endgroup$ Jul 16, 2017 at 17:37
  • $\begingroup$ I appreciate your input and thoughts, believe me! That is where two or more minds are alot better at solving problems! Thank you for your input. I have seen similar posts about the arc/circle being a tough thing for these 8 bit boards as well. Only thing is using a laser I am not cutting arcs/circles. Straight X travel and laser on/off during travel. $\endgroup$ Jul 16, 2017 at 17:38
  • $\begingroup$ I am heading towards this clone not handling communications correctly because of the "pause" when receiving data from the computer. Can't imagine why this would be different from clone to real board though, unless there is problem with parts? We'll get to the bottom of this! I don't give up easily AND I appreciate ALL the help I am getting too! Thank You. $\endgroup$ Jul 16, 2017 at 17:42
  • $\begingroup$ Another brainstorm thought.... I will try and get more scope pictures showing USB comm and laser drive to see if the two are related. I will post them on my dropbox and let you guys know. $\endgroup$ Jul 16, 2017 at 17:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .