M3 M5 and other M-code: early / delayed execution

resam

Hi,

I'm running a laser with [c]M452 P3 I1[/c]. I can control the laser power with [c]M5[/c] (off), [c]M3 S255[/c] (full power), and e.g., [c]M3 S100[/c] (medium power).
I'm having problems which seem to affect the timing of when the laser is turned on or off. I think the M3/M5 commands get executed too soon or too late…
Since the cutting line itself it quite thick and the underlying cardboard was also burned, laser power should be good enough to cut a normal sheet of paper.

Here a picture of my latest "print":

As you can see, the letters are not fully cut, and short paths (e.g., inner path of P) are not cut at all.
I think I read multiple posts on the forum that indicate that some M-codes get delayed or get executed early, basically out-of-order with normal movement g-codes G0/G1. I tried to play around with adding M400 - but no luck so far.

Here is the gcode that "printed" the above picture: https://www.dropbox.com/s/log5cmvqr8nmlqg/pew-pew-kinda-working.gcode?dl=0
(generated with LaserWeb 4, 1.0.17 with customized start/stop/tool gcode scripts)

I'm I on the right path here, or should my setup generally work as expected?

P.S.: Hello to all my VORON fellows!

dc42

Unless something has gone wrong with the synchronisation code, M3, M4 and M5 commands are synchronised to the G0/G1 commands that they are mixed with. The queue for synchronised M-codes is only 8 entries long, whereas the queue for GCodes is up to 20 commands long. So it's possible in theory to run out of queue elements; but in practice this is very unlikely because the queue depth is limited to 2 seconds of movement + 1 move, and when printing curves as you are doing I think there will usually be several G1 commands between each pair of M3 and M5 commands.

I think it's more likely that your laser isn't starting immediately but is taking some time to start up. This is quite possible, because many semiconductor lasers switch from generating no output to generating enough output to damage themselves with only a small increase in current. So the controller may be ramping up the current slowly so that it doesn't overshoot when it sees the laser start to operate. However, I have no experience with diode lasers (only with CO2 lasers), so I could be completely wrong.

How are you feeding the laser power signal to the laser controller?

May I suggest you try some simple test patterns. For example, print a square with all 4 sides using the same feed rate but the laser only turned on for two opposite sides. Then you should be able to see more easily whether the problem is delayed turn-on or a more general synchronisation problem.

resam

Thanks for the thorough explanations!

Yes, there are multiple G1 commands between M3 and M5.

However, I think I noticed that with slower speeds my paths are "more complete" - I have to make more tests about that.
I think the picture was taken with 6mm/s.
My initial tests were with 50mm/s where basically non of the paths were cut correctly. Only a few dots, likey beginnings/ends of paths…

My 2.5W laser diode is powered from the PCB that came with it - a bunch of ICs, DC-DC step down convertes, and an op-amp. The "datasheet" says 0-5V TTL, which I connected to HEATER_3.
The power input for the laser PCB is a 12V DC-DC converter that is fed by my 24V PSU.
The laser fan (12V presumably) is connected to the laser PCB, and is always on. So there is always a small load on the 24V->12V converter.

I will do more test patterns, and maybe add a big electrolytic cap on the buck converter.

edit:
I used http://jherrm.com/gcode-viewer/ to simulate my gcode - and I think the incomplete paths are from the beginning, i.e. The laser is turned on too late (or reaches full power too late). This results in a few moves already being completed before actually cutting happens.