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?
4 Answers
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!
- 22,760
- 13
- 53
- 106
- 101
- 5
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.
- 2,500
- 2
- 15
- 35
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.
- 15,057
- 2
- 37
- 65
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?
- 6,748
- 8
- 40
- 68