Extruder DIR pin status changed by default on XYZ move.

On any move X-Y-Z with no extruder request (extrude or reverse), Extruder DIR pin (pin used to set the direction of the extruder) is set to extrude by default instead to keep the actual DIR status.

As an example, set the extruder to retract -1mm of filament, send G1 X1 command and you will notice that the DIR pin is erroneously falling back to the Extrude status by default instead to keep the actual status.

You haven't said which electronics and firmware you are running that exhibits this behaviour. But it's not a bug, because the state of the DIR pin only matters for a few hundred nanoseconds before and after the rising edge of the STEP pulse.

Edited 1 time(s). Last edit at 11/27/2015 10:38PM by dc42.

---

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].

Hi,
I forgot to mention I have Marlin 1.1 on Arduino Omega 2560 (in mode Extruder, Fan, Bed).

I will rephrase the problem. Issue is that the Extruder DIR pin state is changed when a command is sent to move X, Y or Z only. For example do:

G1 E-1; Extruder DIR pin will be 0
G1 X1; Extruder DIR pin change by itself to 1 even if the command was sent to move X only. Extruder and other axis should not be cross linked.

The impact I have is that any 3D printer can do easily without modification laser printing/engraving by using a standard 3D model, Slic3R and using the DIR pin to activate or desactivate a relay (laser ON when the 3D printer think it extrude and OFF when it think it retracts). However, this cross talk between the axis/extruder is detrimental to achieve that.

I did this quick video a while ago :-)
[www.youtube.com]

Edited 2 time(s). Last edit at 11/27/2015 09:09PM by g.tremb.

Surely you would need the firmware to positively set the direction to 0 on any non-extruding move? Otherwise the laser would be left turned on if you had an extruding move that wasn't followed by a retraction.

It sounds to me that an implementation of [reprap.org] would better meet your needs.

---

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].

Effectively, M571 would work great if implemented on Marlin. However if the extruder DIR pin wasn't coupled it would already be functional. For the moment, to send a command to move X and to see an effect on the extruder (DIR pin) is quite odd.

M571 could be implemented on Marlin? It would be nice to use one of the spare pin on the RAMPS. Maybe one of the spare servo pins?

I feel that M571 was developed as a work around for this issue that should have been solved.

M571 provides a guarantee that the output will become inactive when extrusion stops, without the need for a retraction. It also allows the PWM ratio to be set on the output. Also, there is no guarantee that all printer electronics will have a separate DIR pin for each motor, because it is entirely possible to share one DIR pin between all the motors.

However, if you are talking about a specific firmware such as Marlin on specific hardware such as RAMPS, then of course you can modify the firmware to do what you want with either the extruder DIR pin or any other pin, and you don't need to implement M571 unless you want the variable PWM capability.

---

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].