GCODE M104 processed with delay?

Hi all, I've been building a laser cutter, and the machine works damn fine. However, when I'm cutting something, the laser tends to turn on around 200ms too late and at the end of a path it turns off 200ms too late.

Now, I have added a 'dwell' or G4 P200 (pause for 200ms) command into my GCODE, so that the movement is halted, and the laser has time to turn on, however, at the end of a path, the laser still stays on for 200ms too long.

Now, I have made a few cuts where this doesn't happen and there is no way that I can find out why this happens. I could add in another G4 P200 at the end of each path but I already did and this doesn't work.
I am quite sure there must be another gcode that fixes all of my problems without these 'dwell' workarounds.

My generated GCODE now looks like this:

G90 ;Set to Absolute Positioning
G21 ;Set Units to Millimeters
G28 X0 Y0 Z0 ;Home all Axis
M82 ;Set extruder to absolute mode
M106 S255 ;Turn fan on
G1 Z0.100 F14400.000 ;Set Z to 0.1mm
G0 X212.5675 Y31.878 ; First move in generated Gcode

M400 ;Wait for current moves to finish <<<<- without the M400, the M104 S100 command doesn't work, in a way that the printer already immediately starts up the M104 S100 command when the print starts..
M104 S100 ; Turn on laser
G4 P200 ; Dwell for 200ms
G1 F700.000000 ; Set speed for cutting
G03 X212.3225 Y31.9014 I-0.5294 J-4.2408 ; Rest of generated Gcode comes after and looks flawless

Expectations


Bitter cold reality


Edited 1 time(s). Last edit at 01/19/2015 08:13PM by Ohmarinus.

---

http://www.marinusdebeer.nl/

I am not aware of any gcode to advance the laser on/off with respect to the movement. However, I am considering adding a similar feature to my fork of RepRapFirmware for Duet electronics. An extruder has much the same issue: the plastic takes some time to start and stop flowing. I already added a facility to amend the extruder movement profile to account for elasticity in the Bowden system, including reversing the extruder movement near the end of a move when necessary to reduce the pressure, but the results are disappointing. So I'm wondering whether having the extruder movement lead the xyz motion by a few tens of milliseconds might work better.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hmm yeah definately worth checking out. After a good night's rest I realize that maybe if I add 'fake' retracts in the gcode, it might work as a way of telling Marlin when to start and stop the laser beam on/off.

Strangest thing is that yesterday, the cutting has gone right for one time, and I could not reproduce this. It might be the Ramps, but I'm not sure how this can be caused.

More experimentation has to be done.

---

http://www.marinusdebeer.nl/

Okay, I have solved the effect, not the issue.

By making a workaround with the 'dwells' (G4 P300) as they are wonderfully called (if you're into philosophy: Heidegger - Building Dwelling Thinking) I could force the printer to halt movement momentarily to initiate the delayed M104 command to turn on (S100) or off (S0) the laser beam.

The gcode at the beginning of each path it:

M400
M104 S100
G4 P300

The gcode at the end of each path is:

M400
M104 S0
M400
G4 P300
M400

Especially the gcode at the end of each path was difficult to get in the right order of commands, but when I woke up this morning it suddenly hit me. There is a difference between buffered and non-buffered commands, and because I am 'abusing' Ramps and Marlin to do laser cutting, this buffering messes up the cutting as the laser if more sensitive to real-time changes in gcode. Interesting fact is that I now realize a lot of 3D-printers might be under-performing because of small buffer problems that you don't really see typical artifacts of.

Anyway, I'm happy, it works and I can cut what ever shape I want, when and where I want it.

Results:

Repetier Host window view shows correct code:


Old cut from yesterday (black), with the new one from today on top (core):


Random meme to show I'm not too much of a serious person:


Edited 3 time(s). Last edit at 01/20/2015 06:33AM by Ohmarinus.

---

http://www.marinusdebeer.nl/

Hey,
I run into the same problem using M107 to turn the laser on and off. I came to the same comclusion as you, that it is a buffering problem. I'm currently trying to turn the laser on off with the retraction looking at the Z movement. But I have a hard time understanding the code so far So this could take a while.

It depends on what you're trying to do.

Do you use Inkscape to generate the GCODE, or do you use Slic3r in a modified state to run the laser? I have solved all errors I've come across so far in both methods Soon I will release a short guide in the laser workshop forum.

---

http://www.marinusdebeer.nl/

I have a Arduino and Ramps to control the laser. First I used Cura to generate the Gcode but now I use the CAM process from the Inventor student version. The laser on off Pin is connected to the FAN output that's why I use M107 S0 /S255 to turn the laser on and off.
After I generate the Gcode I use a phyton script to replace all Z movements with laser on/off commands ( Z movments normaly push the cutter into the material to start). I didn't want to dwell the laser because I imagine it burns a bit of the material every time it dwells. So my ideal solution would be to dig into the Marlin code and instead of moving the Z axis turn the laser on off. That would give perfect timing and I could get rid of the phyton script.