Extruder DIR pin change of state on any G1 XYZ command (Easy LASER with Slic3R/Marlin)

[gtremb]

M571 command could be implemented on Marlin to allow turning on and off a pin when extruding (as reprap firmware). This could lead to a direct use of Marlin to do laser cutting and plasma. The pin could be on a PWM to allow TTL modulation of intensity.

Here an example i did without this M571 command (always ON) https://youtu.be/tyIXTN9wyao

[Wackerbarth]

This proposal has been made previously. Unfortunately, it is not as easy as it might seem because the laser control really needs to be carried out in the motion queue rather than at the point where Marlin presently handles the commands of this nature.

In any case, it is something to be considered for future development and not directly related to the current capability. Therefore, it needs to be proposed within the context of "development" in MarlinDev.

[gtremb]

Actually, There is another easy way to obtain the same effect as M571, but Marlin firmware will need to quick fix to achieve it. We could use the DIR pin of the extruder to activate or desactivate a relay. It would be basically the same effect... However, by doing this, I discovered that there is a cross talk between G1 on X, Y or Z and the DIR pin of the extruder. Quite odd as there should not be an effect on one motor when sending a command on another one.

For instance, if you do: G1 E-1; Retract the filament (E0 DIR pin to 0) G1 X1; Move only on X axis... but E0 pin is changed to +1!

If this cross talk was fixed, we could directly tap in the Extruder DIR pin and activate/desactivate the laser/plasma. :-)

[AnHardt]

@gtremb I would not call it interference.

stepper.cpp

/**
 * Set the stepper direction of each axis
 *
 *   X_AXIS=A_AXIS and Y_AXIS=B_AXIS for COREXY
 *   X_AXIS=A_AXIS and Z_AXIS=C_AXIS for COREXZ
 */
void set_stepper_direction() {

  if (TEST(out_bits, X_AXIS)) { // A_AXIS
    X_APPLY_DIR(INVERT_X_DIR, 0);
    count_direction[X_AXIS] = -1;
  }
  else {
    X_APPLY_DIR(!INVERT_X_DIR, 0);
    count_direction[X_AXIS] = 1;
  }

  if (TEST(out_bits, Y_AXIS)) { // B_AXIS
    Y_APPLY_DIR(INVERT_Y_DIR, 0);
    count_direction[Y_AXIS] = -1;
  }
  else {
    Y_APPLY_DIR(!INVERT_Y_DIR, 0);
    count_direction[Y_AXIS] = 1;
  }

  if (TEST(out_bits, Z_AXIS)) { // C_AXIS
    Z_APPLY_DIR(INVERT_Z_DIR, 0);
    count_direction[Z_AXIS] = -1;
  }
  else {
    Z_APPLY_DIR(!INVERT_Z_DIR, 0);
    count_direction[Z_AXIS] = 1;
  }

  #if DISABLED(ADVANCE)
    if (TEST(out_bits, E_AXIS)) {
      REV_E_DIR();
      count_direction[E_AXIS] = -1;
    }
    else {
      NORM_E_DIR();
      count_direction[E_AXIS] = 1;
    }
  #endif //!ADVANCE
}

An axis what has noting to do is set to +. If your code would be: 'G1 X1 E-1` everything would be OK.

{10 minutes}

[AnHardt]

Why do you want to use the direction output at all? The step_pin already provides all you want. If you want to cut some material you want a constant number of pulses/mm. That's absolutely the same as steps/mm. Even during acceleration and deacceleration of x/y the pulses/mm would be constant. Different materials could be set by different steps/mm for E. Engraving pictures in grayscale is different. Setting the E steps/mm would be needed for every pixel - the g-code size would explode, but even grayscale pictures are huge compared to line drawings.

[gtremb]

The objective is to get laser capability on any 3D printer without modification or reflashing the arduino.

The use of extruder DIR pin is actually an excellent one to do cuts and engraving (but not do grayscale of course). If you have a relay (or TTL) on the extruder DIR pin, when the printer is supposed to extrude, it activates the relay and start the laser. If it is not supposed to extrude, it stops the relay. This way, you can immediately use Slic3R with any low thickness shape. So no need to change slic3R (or any gcode generator for 3D printing) and direct use of a laser on any 3D printer. This way, if you do a print in "vase" mode, you cut the outter shape. If you print with a fill pattern, you obtain a full shape engraved filled with the infill pattern.

Well, this is what I did and it would be working perfectly if the extruder DIR pin was not changing for no reason when a move is commanded and X-Y-Z without asking anything to the extruder.

For the moment, I can increase the speed of the non extruding moves, but it is not as perfect (but the quality is quite good none the less) as it could be. So there is slight lines still visible.

[Roxy-3D]

The objective is to get laser capability on any 3D printer without modification or reflashing the arduino.

How big of a hurry are you in? I have an El'Chepo laser on the way and I'll be adding support for my printer to treat it as a 2nd extruder. I think I can control the power by giving it a servo entry and adjusting its frequency.

[Wackerbarth]

@Roxy-3DPrintBoard -- The difficulty is that there is presently a bit test down in the stepper code that looks at the sign bit of the number of steps required and sets the direction accordingly. To accomplish what @gtremb is asking, that test would have to consider zero to be negative. Such a test would be significantly more expensive in a relatively critical part of the motion code.

[Wurstnase]

You could simply test it and setup a new bit with the acceleration test in the planner. Make a global variable for the laser_on_off and put this in the stepper.cpp also.

[gtremb]

@Roxy-3DPrintBoard -- I am not in an hurry. I just want that everybody benefit of this extra laser feature at no cost and difficulty as soon as possible. :-) On my side, I can print and engrave with the laser for the moment, but it would be much better when the feature will be available to avoid unneccessary lines. It will also allow to use a double head (extruder/laser) on the fly. Not sure how you will manage to add the grayscale capability (pre-processor speaking (like Slic3r)). Here's some pics about my new laser head with liquid cooling and the print examples using directly Slic3r and Marlin.

[gtremb]

@AnHardt -- Here's 2 examples of what is possible to engrave using directly Slic3R and Marlin. (I have cuttings examples also, but it is as easy as engraving in "vase" mode. As you will note, there is some small lines still present during the rapid moves where the extruder should be retracting. Those lines would be gone if the extruder pin could avoid the crosstalk (check). Note the infill pattern. :-)

[AnHardt]

The title is still not good. For me it should read. "Extruder DIR pin change of state when a G1 -E command has finished."

Again. If you send

G1 E-1; Retract the filament (E0 DIR pin to 0) G1 X1; Move only on X axis... but E0 pin is changed to +1!

G1 E-1 Marlin will set the E-dir-pin to turn backwards, then will turn back one unit. Than this move is finished. With G1 X1 you send implicit G1 X1 Y0 Z0 E0. Zero is not negative, so E will be set to the positive direction again. The move in X direction will be done.

I you would send G1 X1 E-1 the X and the E move will be at the same time. E-dir-pin would be what you want during the move of X.

[Wackerbarth]

@AnHardt -- Yes, very true if you are generating custom G-code.

However, I believe that @gtremb wants to use the normal slicer which simply stops forward motion of the extruder while it moves from one path to the next.

Of course all of the fancy "games" that are played with the extruder to anticipate a change of flow rate (to compensate for the "ooze" factor) will play havoc with this approach unless he can turn them off. Unlike the hot end of an extruder which has pressure and heat flow issues, the laser has a very rapid "acceleration" capability. It can turn on and off much faster that we can move it about.

[polyprinter]

If you set M92 E-1 and then invert the direction pin's output polarity by changing the setting INVERT_E0_DIR, it might do what you want.

Moves like G1 X1 E1 should then produce negative step counts when you call for "extrusion". Non-extruding moves should have the opposite direction output.

Ed

[gtremb]

@Wackerbarth -- You're correct. The objective is not to write a new slicer as it is already existing.

[polyprinter]

I guess M92 E-1 is such a low number that it might cause problems with having no steps at all on some moves.

Perhaps M92 E-100 or E-1000 would be more practical settings.

[gtremb]

@AnHardt -- I changed the title just to add info about the laser as it might interrest many people and get more people in. :-)

I understood the first time about the explicit way to do moves with a retract during the move. You're right and I was doing exactly that last month when I was writing by hand my G code. In fact, the machine was connected with a router to cut aluminum as the relay was set for this the first time.

However, to help everybody with a simple solution using existing software (Marlin/Slic3R/Pronterface) with no learning curve, I still believe we could do something about this. You're point is interresting about the implicite 0 moves. If a 0 was not considered positive, but a "no change", it might solve this problem.

[Wackerbarth]

"If a 0 was not considered positive, but a 'no change' " -- Look at @polyprinter's suggestion about inverting the dir. Particularly if you were to set the laser up as a separate "tool" (not the E0 the you use to extrude plastic) then it might work as you expect. If should be worth a try.

[AnHardt]

You could experiment with planner.cpp Line 598 (in RCBugFix)

  #endif
  if (de < 0) db |= BIT(E_AXIS);
  block->direction_bits = db;

to

  #endif
  if (de <= 0) db |= BIT(E_AXIS);
  block->direction_bits = db;`

but then, i guess, all your moves where the laser should be on, are off.

There is no simple way to detect if the sign was set because the way for E was positive, negative or Zero. Ether we have no info about the previous move or no info about the way (at the different involved functions).

[gtremb]

@AnHardt -- Brillant. Your last comment seems to solve the issue. For tonight I can only test by sending manual commands and it works for what I see. Tomorrow or Thursday I will be able to do more testing with the laser itself.

By adding the "<=" instead of the "<", if I reverse the extruder, the relay is off. If I send a G1 X1 command, it stays OFF. If I press on extrude, the relay turns ON.

To do on my side: -I will need to test with Slic3R code to see if the behaviour is OK with generated code. -Test 3D printing to see if there is negative impact. For this, it might takes few days... The extruder in hanging free as the extruder and the nose need to be changed.

[gtremb]

Here's an example (about 2cmx3cm). No more redundant laser lines during non extruding moves. It is not perfect yet, but at this point, the only way to improve will be to use a MOSFET or a transistor to activate/desactivate the laser (or the TTL module on the driver). There is a very short delay due to the relay, but nothing terrible and the result is now quite good!

I didn't tried the 3D printing yet with this mod. It will need to be tested if people want to use this in the standard Marlin firmware.

Good job!

[Roxy-3D]

I want to use a laser as a 2nd extruder to shoot perfectly horizontal and trim off any curling upward edges.

On Wed, Dec 9, 2015 at 7:03 PM, Guillaume notifications@github.com wrote:

[image: p_20151209_195109] https://cloud.githubusercontent.com/assets/16059704/11703646/ee8a38e2-9eae-11e5-9880-c1bb4967bf08.jpg Here's an example (about 2cmx3cm). No more redundant laser lines during non extruding moves. It is not perfect yet, but at this point, the only way to improve will be to use a MOSFET or a transistor to activate/desactivate the laser (or the TTL module on the driver). There is a very short delay due to the relay, but nothing terrible and the result is now quite good!

I didn't tried the 3D printing yet with this mod. It will need to be tested if people want to use this in the standard Marlin firmware.

Good job!

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2809#issuecomment-163453577 .

[lrpirlet]

@​Roxy-3DPrintBoard

I want to use a laser as a 2nd extruder to shoot perfectly horizontal and trim off any curling upward edges.

You really want to use a power laser horizontally ... Do not ever look you printer... do not let fascinated kids around... this would be the last time they look... Sorry, I feel this to be extremely dangerous... of course this is your decision, I would be afraid for the possible consequences...

2015-12-10 5:41 GMT+01:00 Roxy-3DPrintBoard notifications@github.com:

I want to use a laser as a 2nd extruder to shoot perfectly horizontal and trim off any curling upward edges.

On Wed, Dec 9, 2015 at 7:03 PM, Guillaume notifications@github.com wrote:

[image: p_20151209_195109] < https://cloud.githubusercontent.com/assets/16059704/11703646/ee8a38e2-9eae-11e5-9880-c1bb4967bf08.jpg

Here's an example (about 2cmx3cm). No more redundant laser lines during non extruding moves. It is not perfect yet, but at this point, the only way to improve will be to use a MOSFET or a transistor to activate/desactivate the laser (or the TTL module on the driver). There is a very short delay due to the relay, but nothing terrible and the result is now quite good!

I didn't tried the 3D printing yet with this mod. It will need to be tested if people want to use this in the standard Marlin firmware.

Good job!

— Reply to this email directly or view it on GitHub < https://github.com/MarlinFirmware/Marlin/issues/2809#issuecomment-163453577

.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2809#issuecomment-163486314 .

[Roxy-3D]

Sorry, I feel this to be extremely dangerous...

Yes, I understand. It is very unlikely I'll set my laser up this way. But it would be really cool to be able to cut off edges of the print that curl upward.

[gtremb]

@Roxy -- With a good opaque enclusure (or cardboard box) and proper air extraction, you could manage to modify your printer... but after your comment I tried to cut PLA with the laser and it is not doing a nice job. bubbling, warping, melting and smelling the $%$%/*. Just with the smell... it might harm. However, I was surprised to discover that the PLA is regenerated (nice round shape and finish) after the "dammages" done by the extractor.

[Roxy-3D]

I wonder if black PLA would cut or trim better?

[gtremb]

I did some 3D prints with the proposed solution:

endif

if (de < 0) db |= BIT(E_AXIS); block->direction_bits = db; to

endif

if (de <= 0) db |= BIT(E_AXIS); block->direction_bits = db;`

I believe the proposed firmware modification is not introducing a regression. However, I did a lot of modification on my 3D printer (mechanical and electronics) and I now have a drift on the Y axis and a smaller drift on my X axis (drift is systematic and perfectly predictable)... Modifications were to go from a 0.3mm extruder nozzle to a 0.8mm. I am still investigating where this drift might come from. I suspect the bed auto levelling I just added might mess the process... I will reflash everything with my older firmware to check. Otherwise, it might be a problem with the larger extruder nozzle...

[gtremb]

By the way... I did the 3D print with AND without the proposed firmware modification and I still have the drift... So if somebody could test by doing any 3D print and check if there is a negative impact, it would be nice.

[gtremb]

@Roxy-3DPrintBoard - I will need to check if I have a roll of black PLA or ABS. I have probably 16 rolls of different colors around the workshop... I will let you know. :-)

[gtremb]

About 50 3D prints later with the mod for the laser... No Problem! Great!!!! Laser and 3D printing without messing with the firmware in between!

[coalman321]

i have a small question. If you have tried this proposed change, does is seemingly systematically skip areas? any ideas here is a pic of what it is doing to me.

[gtremb]

Hi, Nice to see that I am not alone playing with lasers and Marlin. No, I didn't noticed such issue. I only notice very very short missing beginning of lines (maybe less than a mm because I am still using a relay. On fast moves, it makes a difference a relay vs a Mosfett or Transistor. Le 2016-01-31 19:33, "coalman321" notifications@github.com a écrit :

i have a small question. If you have tried this proposed change, does is seemingly systematically skip areas? any ideas here is a pic of what it is doing to me. [image: img_0453] https://cloud.githubusercontent.com/assets/5054270/12706368/51a6daa4-c851-11e5-8d42-1ebda629ce7e.JPG

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2809#issuecomment-177674600 .

[coalman321]

From what I'm seeing, it would appear to be that the extruder is just stopping there because soon after, the G92 E0 command is sent and it begins working again. Also I have tried other shapes and it does very similar things, so it does not appear to be location. Could it be because of a slicer setting?

[gtremb]

I was just think about it at the moment. The laser diode can lower a lot its intensity if you are too close of its thermal limit. It could result in such behaviour.

Also, you can do an easy test. Simply generate by hand a gcode with many lines (easier if they are the same length and parallels with a copy paste) and use it. Do you have the same issue? Lines are regular or all of different length? That would help for your trouble shooting. Le 2016-02-01 07:45, "coalman321" notifications@github.com a écrit :

From what I'm seeing, it would appear to be that the extruder is just stopping there because soon after, the G92 E0 command is sent and it begins working again. Also I have tried other shapes and it does very similar things, so it does not appear to be location.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2809#issuecomment-177956452 .

[coalman321]

this does not appear to be due to thermal issues. the whole laser is well cooled. IE large thermal mass of the printer itself however I am using a mosfett on the ramps board to achieve this. also it only appears in procedurally generated code, if i were to write it, it seems to behave correctly.

[jbrazio]

Thank you for your interest making Marlin better. You should re-open this topic on MarlinFirmware/MarlinDev for proper followup from the development team. We suggest you to use the MarlinFirmware/Marlin#<topic id> markdown to link back to this original topic.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.