<p>Thank you all for your suggestions and help.</p>

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

<p>Oh well.. comes under the heading "pay attention" I guess!</p>

CC BY-SA 4.0
2017-07-21T01:57:26.947Z
2018-08-16T09:28:43.297Z
2018-08-16T09:28:43.297Z
Pomonaill220
<p><strong>Have you checked the supply voltage?</strong>  With everything turned on (steppers stepping, laser on, etc) you may be pulling too much current and the supply voltage is drooping.  </p>

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

CC BY-SA 3.0
2017-07-14T18:17:18.040Z
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).
Pomonaill220
CC BY-SA 3.0
2017-07-14T18:23:36.230Z
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...
Pomonaill220
CC BY-SA 3.0
2017-07-14T18:27:40.193Z
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.
Pomonaill220
CC BY-SA 3.0
2017-07-14T18:29:55.850Z
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.
Pomonaill220
CC BY-SA 3.0
2017-07-14T22:36:45.080Z
What does the signal on the laser look like?
Also, can you put your Marlin files somewhere I/we can see them?
markshancock
CC BY-SA 3.0
2017-07-16T02:36:21.610Z
I will reconnect the board and get some waveforms for you.  I took a chance and ordered a real Arduino Mega 2560 rather than a clone, although I am somewhat doubtful that this will fix it.  Which Marlin files would you like to look at as there are quite a few.  I have a dropbox account that I can post my scope traces to and upload the Marlin files that you would like to look at.  BTW.. I did more investigating and noticed that when Repetier sends commands to the printer, the printer pauses for about 250 mseconds while it processes the comman.  This is where the problems occur.
Pomonaill220
CC BY-SA 3.0
2017-07-16T02:42:46.280Z
I had to slow the feedrate down to about 10% to see this, but it was there, and the laser pulse was also delayed/skipped/stretched when it happened.  hhmmmm... a clue????  This is what prompted me to purchase the Mega as a stab in the dark that maybe the clone is having problems processing the data from my computer.  Also, I have never been able to us my SD card so possibly a related problem... don't really know...YET
Pomonaill220
CC BY-SA 3.0
2017-07-16T02:55:11.963Z
@Pomonaill220.  Stock Marlin files are at https://github.com/MarlinFirmware/Marlin.  I would like to see the files that are not stock (your config)
markshancock
CC BY-SA 3.0
2017-07-16T02:56:47.840Z
@Pomonaill220 there are a LOT of overlapping features on Marlin.  It is really easy to get the config setup so that more than one thing is controlling the same output.
markshancock
CC BY-SA 3.0
2017-07-16T03:34:30.110Z
The time where the pulses are missing is where the printer is receiving data (commands) from the computer.  A few times the pulses actually stayed on, but I couldn't capture that for some reason.
Pomonaill220
CC BY-SA 3.0
2017-07-13T14:49:49.230Z
2017-07-13T14:49:49.230Z
markshancock
<p>You should insert <code>M400</code> commands before each and every <code>M42</code> command. The reason is that <code>M42</code> skip the normal command queue. Each <code>M42</code> 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 <code>M400</code> before <code>M42</code> will ensure that the printer finishes all moves before <code>M42</code> changes the pin state.</p>

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

CC BY-SA 3.0
2017-07-18T02:34:33.470Z
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!
Pomonaill220
CC BY-SA 3.0
2017-07-18T02:49:34.187Z
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!
Pomonaill220
CC BY-SA 3.0
2017-07-18T04:06:47.053Z
@Pomonaill220 Are you aware that only the negative side of the fan is switched? The positive terminal is always at +12V.
Tom van der Zanden
CC BY-SA 3.0
2017-07-18T04:37:45.050Z
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?
Pomonaill220
CC BY-SA 3.0
2017-07-18T11:13:35.517Z
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.
tjb1
CC BY-SA 3.0
2017-07-19T04:46:42.287Z
@Pomonaill220 You might be able to make a self-answer to this question, if the problem was that you were running too fast.
Tom van der Zanden
CC BY-SA 3.0
2017-07-18T01:46:01.450Z
2017-07-18T01:46:01.450Z
Tom van der Zanden
<p>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. </p>

<p>Some printer control boards, such as the Smoothie, use different processors (ARM?) in order to supersede these issues. From <a href="http://hackaday.com/2013/09/06/3d-printering-electronics-boards/" rel="nofollow noreferrer">3D Printering: Electronics boards</a>. </p>

<blockquote>
  <p>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.</p>
</blockquote>

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

CC BY-SA 3.0
2017-07-16T17:37:11.343Z
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.
Pomonaill220
CC BY-SA 3.0
2017-07-16T17:38:20.603Z
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.
Pomonaill220
CC BY-SA 3.0
2017-07-16T17:42:30.293Z
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.
Pomonaill220
CC BY-SA 3.0
2017-07-16T17:48:09.287Z
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.
Pomonaill220
CC BY-SA 3.0
2017-07-16T15:10:43.167Z
2017-07-16T15:10:43.167Z
Greenonline
<p>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?</p>

CC BY-SA 4.0
2018-11-10T15:49:09.900Z
@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](/questions/ask) 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. :-)
Greenonline
CC BY-SA 3.0
2017-08-22T23:02:02.360Z
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
Walt Scrivens
<ramps-1.4><laser>
Running laser on my printer
Pomonaill220
# Running laser on my printer

(Asked by: username_0 on 2017-07-13)

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?

**Tags:** ramps-1.4, laser
> **Comments:**
> **username_2**: 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  
> **username_1**: @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](/questions/ask) 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. :-)  

---

## 4 answers

### Answer by username_0 on 2017-07-21. Score: 6

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!


---

### Answer by username_3 on 2017-07-13. Score: 2

**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.

> **Comments:**
> **username_0**: 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).  
> **username_0**: 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...  
> **username_0**: 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.  
> **username_0**: 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.  
> **username_3**: What does the signal on the laser look like? Also, can you put your Marlin files somewhere I/we can see them?  
> **username_0**: I will reconnect the board and get some waveforms for you.  I took a chance and ordered a real Arduino Mega 2560 rather than a clone, although I am somewhat doubtful that this will fix it.  Which Marlin files would you like to look at as there are quite a few.  I have a dropbox account that I can post my scope traces to and upload the Marlin files that you would like to look at.  BTW.. I did more investigating and noticed that when Repetier sends commands to the printer, the printer pauses for about 250 mseconds while it processes the comman.  This is where the problems occur.  
> **username_0**: I had to slow the feedrate down to about 10% to see this, but it was there, and the laser pulse was also delayed/skipped/stretched when it happened.  hhmmmm... a clue????  This is what prompted me to purchase the Mega as a stab in the dark that maybe the clone is having problems processing the data from my computer.  Also, I have never been able to us my SD card so possibly a related problem... don't really know...YET  
> **username_3**: @Pomonaill220.  Stock Marlin files are at https://github.com/MarlinFirmware/Marlin.  I would like to see the files that are not stock (your config)  
> **username_3**: @Pomonaill220 there are a LOT of overlapping features on Marlin.  It is really easy to get the config setup so that more than one thing is controlling the same output.  
> **username_0**: The time where the pulses are missing is where the printer is receiving data (commands) from the computer.  A few times the pulses actually stayed on, but I couldn't capture that for some reason.  

---

### Answer by username_4 on 2017-07-18. Score: 1

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.

> **Comments:**
> **username_0**: 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!  
> **username_0**: 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!  
> **username_4**: @Pomonaill220 Are you aware that only the negative side of the fan is switched? The positive terminal is always at +12V.  
> **username_0**: 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?  
> **username_5**: 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.  
> **username_4**: @Pomonaill220 You might be able to make a self-answer to this question, if the problem was that you were running too fast.  

---

### Answer by username_1 on 2017-07-16. Score: 0

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](http://hackaday.com/2013/09/06/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?

> **Comments:**
> **username_0**: 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.  
> **username_0**: 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.  
> **username_0**: 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.  
> **username_0**: 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.  

---

