Marlin M600 change filament command: trigger it by external input

Hi, i'm searching for a method to avoid air printing. I've see the p-stop function on sailfish firmware on makerbot.
After some searching on forums and github i've found 2 branches of marlin V1 (one from buildrob and the official by ErikZalm).

My idea is to create a sensor to detect a slippage in the filament and trigger the m600 when slippage is detected.
Then the machine automatically park the head outside the plate and i can manually feed the filament.

Someone has had the same idea? Is it feasible?

Best Regard

no one?

[forums.reprap.org]

I have been thinking about coming up with something like this for a while now. More than just a filament break/end sensor, I also want to detect nozzle clogs/filament jams. To do this I was thinking of making a small breakout board with an Atmel ATTiny85 that monitors the filament and extruder and sends a signal if it detects that the filament isn't feeding properly.

It would do this by having 5 inputs and one output set as:

1) Input connects to the step pin on the extruder stepper driver so that it can count the number of steps the extruder is making
2) Input connects to the dir pin on the extruder stepper
3&4) 2 Inputs monitor an optical encoder wheel attached to either the drive bearing, or preferrably on a small shaft with a rubber wheel rolling along the filament (I am planning to use one I ripped out of an old ball mouse, but any rotary encoder might work, as long as it isn't too stiff).
5) Input connected to a mechanical switch to detect end of filament/break (slightly redundant, so possibly optional)
6) Output to printer board, acting as an endstop to tell the printer board if the filament isn't feeding properly

I haven't written the code yet, but it should basically monitor the extruder steps, and compare it to the encoder steps. If the ratio between them changes drastically in a short time span, or the encoder steps don't increment at all, then it will output a stop. If at any time the mechanical switch opens, a stop will be sent instantly. I am not sure how I will implement the code exactly, as the tiny has some advanced features such as externally clocked counters that could make the system very fast, and I may need some other components to round out the circuit, but I have ordered the parts and am planning to work on it soon.

Would love to hear feedback on the idea, and if people are interested, I will try to update on my progress.

The only filament feeding failures I see are caused by the extruder losing its grip on the filament. So collating the movement of an optical encoder driven by the filament with the step commands would be the way to go. This would be quite easy to implement in RepRapFirmware for Duet electronics, which already has the facility to run a macro file in response to a pause command, and plenty of spare inputs for the encoder.

---

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

What I am worried about is the processing time taken up by the filament monitor if the encoder is directly connected to the main printer board. Also, having the sensor only output to one pin on the printer, and only when a fault is detected, means it is more universally useful. While using an attiny increases the cost, and makes it difficult to reprogram once implemented, the advantage of pushing the load to an external processor makes up for it I think.

I'm usually in favour of offloading this sort of thing to a separate microcontroller such as the attiny. However, my enthusiasm is tempered in this case by having to feed the extruder STEP and DIR (and possibly EN) motor driver signals to the attiny, which complicates the wiring as most controller boards do not make these signals available. The CPU load needed to monitoring the filament might be significant on an 8-bit 3D printer control board, but I regard those as obsolete these days, now that 32-bit MCUs cost much less than high-pin-count 8-bit MCUs.

---

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

For newer printers with 32 bit mcus I agree that breaking out the step and Dir pins may not be the better solution. Unfortunately, many current 3d printer designs, including mine, are still using an 8 bit MCU, with limited io capabilities. Also, to use the main MCU means modifying the firmware, which has advantages and disadvantages. If it were integrated into the main branch of a common firmware, this would not be an issue. For now, I think demonstrating it works well on the most common setups such as RAMPs etc. would be best, so using the tiny is more logical. The device would then function, as far as the firmware is concerned, like a p-stop, which has already been integrated into some firmwares.