2
\$\begingroup\$

I converted my Monoprice Maker Select IIIp 3d-printer into a laser cutter by mounting a 4W diode laser to the printhead, and using the cooling fan leads to control the laser beam, via a simple optocoupler circuit.

This unit is powered by a Melzi Hybrid board with stock firmware, as shown here: melzi board

The gcode command M106 is used to turn the fan on/off. Laser control is inverted, which means when the FAN ON command is sent (M106 S255), the laser is OFF, and when the FAN OFF command is sent (M106 S0) the laser is on.

This works fine: the laser turns on and off as expected.

However, at certain points during a cut (always the same points), the laser will turn off, leaving uncut areas as shown here: uncut areas

Since the uncut areas are always in the same spots, it leads me to believe something in the gcode causes the laser to turn off, and I can conform with an oscilloscope that the laser control pin (fan pin) does change states at those points.

Here is the gcode for this cut:

M106 S255
G90
G21
G1 F3000
G1 X173.0012 Y130.6131
M106 S0
G1 F600.000000
G1 X175.2259 Y130.6131
G1 X170.6494 Y114.3413
G1 X116.6217 Y114.3413
G1 X116.6217 Y116.5659
G3 X120.7342 Y117.4328 I-0.0 J10.1886
G3 X123.105 Y119.4262 I-2.2337 J5.0631
G3 X124.4119 Y122.4929 I-6.8964 J4.7508
G3 X125.0754 Y129.0241 I-31.8131 J6.5312
G1 X125.0754 Y175.9329
G3 X124.4436 Y181.7531 I-27.1242 J0.0
G3 X123.2321 Y184.323 I-6.2392 J-1.3707
G3 X121.0559 Y185.9537 I-3.7934 J-2.7951
G3 X116.6217 Y186.7384 I-4.4342 J-12.1356
G1 X116.6217 Y188.8995
G1 X143.3177 Y188.8995
G1 X143.3177 Y186.7384
G3 X139.2891 Y185.9165 I0.0 J-10.2846
G3 X136.898 Y184.0052 I2.233 J-5.2449
G3 X135.6276 Y181.072 I6.5823 J-4.5923
G3 X134.9911 Y174.9794 I28.838 J-6.0925
G1 X134.9911 Y125.1468
G3 X135.5657 Y121.2733 I13.3428 J0.0
G3 X136.7073 Y119.4898 I3.7337 J1.1327
G3 X138.6839 Y118.4965 I2.9918 J3.4904
G3 X143.4448 Y117.9643 I4.761 J21.0275
G1 X158.2548 Y117.9643
G3 X164.8252 Y118.7575 I0.0 J27.6076
G3 X167.8527 Y120.3161 I-1.7393 J7.0983
G3 X169.9995 Y123.1091 I-6.1218 J6.9273
G3 X173.0012 Y130.6131 I-43.5237 J21.7618
G1 X173.0012 Y130.6131
M106 S255
G1 F3000
G1 X85.7305 Y159.6089
M106 S0
G1 F600.000000
G1 X87.9552 Y159.6089
G1 X87.9552 Y141.4937
G1 X85.7305 Y141.4937
G3 X84.0908 Y145.9635 I-22.3371 J-5.6587
G3 X82.8066 Y147.4686 I-3.574 J-1.749
G3 X80.9476 Y148.225 I-2.5686 J-3.65
G3 X75.3063 Y148.6762 I-5.6413 J-35.0353
G1 X56.8098 Y148.6762
G1 X56.8098 Y121.9802
G3 X57.2033 Y119.3527 I8.9673 J0.0
G3 X58.0175 Y118.0393 I2.9004 J0.8888
G3 X59.4327 Y117.2705 I2.3119 J2.5688
G3 X62.2761 Y116.8952 I2.8434 J10.5837
G1 X75.3063 Y116.8952
G3 X82.2598 Y117.1693 I0.0 J88.3503
G3 X84.9678 Y117.658 I-1.0873 J13.772
G3 X87.4333 Y118.7488 I-2.6873 J9.4057
G3 X89.4807 Y120.4547 I-5.0344 J8.1238
G3 X91.099 Y122.6973 I-10.852 J9.5366
G3 X93.4215 Y127.1923 I-41.7376 J24.4126
G1 X95.6462 Y127.1923
G1 X92.2138 Y113.2722
G1 X38.5039 Y113.2722
G1 X38.5039 Y115.4969
G3 X43.0815 Y116.3318 I-0.0 J12.9657
G3 X45.2415 Y118.0393 I-1.6028 J4.2474
G3 X46.3657 Y120.8228 I-6.3567 J4.1861
G3 X46.9577 Y127.1923 I-33.9705 J6.3695
G1 X46.9577 Y173.7832
G3 X46.3343 Y180.3878 I-35.2977 J0.0
G3 X45.1779 Y183.1268 I-6.9642 J-1.3265
G3 X42.9703 Y184.8474 I-3.9043 J-2.733
G3 X38.5039 Y185.6693 I-4.4663 J-11.7241
G1 X38.5039 Y187.8304
G1 X92.2138 Y187.8304
G1 X92.2138 Y175.3723
G1 X90.8155 Y175.3723
G3 X89.1315 Y180.3765 I-22.7912 J-4.8838
G3 X87.5102 Y182.4277 I-5.1756 J-2.4246
G3 X85.1712 Y183.5494 I-3.3087 J-3.8996
G3 X78.2937 Y184.2074 I-6.8774 J-35.6154
G1 X56.8098 Y184.2074
G1 X56.8098 Y152.2993
G1 X77.6581 Y152.2993
G3 X81.6997 Y152.8233 I0.0 J15.8484
G3 X83.4423 Y153.8248 I-0.9829 J3.727
G3 X84.6139 Y155.5698 I-3.4185 J3.561
G3 X85.7305 Y159.6089 I-18.2451 J7.2179
G1 X85.7305 Y159.6089
M106 S255
G1 F3000
G1 X0 Y0

Any ideas why is this happening? I'm leaning toward a firmware bug (or feature) which may trigger the fan to go on/off at various stages of progress... or is there something in the gcode that I'm missing here, that instructs the fan to cycle at those points.

I hand wrote a very simple gcode file, simply cutting a horizontal, then vertical line, then a curve, and the laser stayed on and did not skip.

I would greatly appreciate any advice. If this is the wrong forum, I apologize - please kindly point me to the correct place to post this.

\$\endgroup\$
2
  • 3
    \$\begingroup\$ Not sure about the code and stuff, but it looks like it is happening whenever *both X and Y motors are running. That could be a power issue. \$\endgroup\$ – Eugene Sh. Dec 5 '19 at 16:17
  • \$\begingroup\$ This is really an off-topic "usage" question rather than an electronic design one. First concern would be that such improvisations tend to lack safety shielding. If yours actually has that and you want to debug this, you should do things like a dry run with the laser safely removed and replaced by an LED or inverted-sense buzzer, or a storage scope connected to that signal. Since the firmware of the controller is presumably open source (or there are open source firmwares) you can debug any glitches there. And you should try using a distinct power supply. \$\endgroup\$ – Chris Stratton Dec 5 '19 at 16:21
2
\$\begingroup\$

Report the problem to OEM and get an updated microcode then upload it.

or

Replace the driver card. low cost UNO + CNC shield, GRBL code or easier REPRAPpro

Your Gcodes produced the below letter

enter image description here

Same thing different letters

It's your not your fault.

enter image description here

\$\endgroup\$
11
  • \$\begingroup\$ Sorry, I'm a complete idiot. I posted the wrong gcode. Corrected! \$\endgroup\$ – Ryan Griggs Dec 5 '19 at 16:55
  • 1
    \$\begingroup\$ You're WELcome. \$\endgroup\$ – Tony Stewart EE75 Dec 5 '19 at 16:56
  • 1
    \$\begingroup\$ To clarify: the laser is powered by a separate 120VAC to 12VDC power supply, completely separate from the 3D printer supply. The control signal is extremely low-current in that it simply drives an optocoupler LED through a 1k resistor. Watching this line with a scope shows clean outputs and clean transitions. It looks more likely that the firmware is either 1) changing the pin state intentionally, or 2) there's a firmware bug that causes the pin to pulse momentarily. \$\endgroup\$ – Ryan Griggs Dec 5 '19 at 17:11
  • 1
    \$\begingroup\$ Note also that when I use the unit for 3D printing, I can sometimes see the fan 'jerk' a few degrees during the print, indicating a momentary pulse sent to it. I always thought that was odd behavior, and assumed it was interference, but by watching the scope it appears to be initiated by the microcontroller. \$\endgroup\$ – Ryan Griggs Dec 5 '19 at 17:14
  • 1
    \$\begingroup\$ I'm betting the firmware is doing some bit-banging on the output ports, and they just forgot to mask out the fan pin, since it would not be noticeable as a fan. \$\endgroup\$ – Ryan Griggs Dec 5 '19 at 17:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.