Filament monitoring while printing via USB

timoschuett

Hello,

is there a possibility to enable filament monitoring while printing via an external host like Repetier-Server via USB?
Unfortunately the documentation states, that filament monitoring is only active when printing via SD-Card.

As the duet gets all information about xy moves without extruding, xy moves with extruding and extrude only commands isnt it possible to monitor all the time regardless of printing from SD?

I found this in an old thread:

"dc42 ADMINISTRATORS 25 May 2020, 12:14
How would the firmware notify Repetier that the filament has run out?

Even if Repetier paused, RRF would still empty the moves in its movement queue. Whereas when printing from SD card, RRF is usually able to stop without emptying the movement queue, and rewind the SD file position so that it can resume at the correct point.

Another issue is that RRF can't distinguish between commands received over USB that are from a file being printed, and commands being sent manually by the user.

I think the best we can do when RRF is not in control of the print would be to have a command that enables the filament monitor even when not printing from SD card, but when a filament error is detected it just sends a message to all channels saying so. It would then turn off filament monitoring until commanded to turn it on again."

Thanks in advance,
Timo

jay_s_uk

@timoschuett why not just connect the filament monitor to repetier or octoprint directly?

timoschuett

@jay_s_uk The problem here is that i want my clog detector to work with duet and repetier-server. "Normal" Filament sensors which check if filament is loaded or not shouldnt be a problem to directly connect them to the pi running repetier-server. But with the clog dectector it gets more complicated as the printing moves are compared to the actual movement of the filament.
As RRF already handles this very well i think this should work with external hosts aswell. I just dont know how to get RRF to always monitor this.

dc42

@timoschuett when printing from SD card, if a filament error is detected then RRF can normally pause the print almost immediately, stop executing commands already in the print queue and throw those un-executed commands away. When printing is resumed it rewinds the printing file to the first un-executed move. Sometimes it can even pause and resume part way through a move.

We could enable filament monitoring when sending commands from USB. In that case, you would have to configure the event macro to use M118 or similar to send a message to USB, and your GCode sender would need to recognise that message and stop sending commands. RRF would still need to finish executing moves in the queue, because your GCode sender is unlikely to have any mechanism to rewind its input file when resuming the print. This normally won't matter if the filament sensor is a simple filament presence detector installed some distance before the extruder inlet, because the filament won't actually run out while completing the moves in the queue. However, if you use a filament monitor close to the hot end, or you've detected a clog rather then out-of-filament, then you wold have to accept that up to about 40 moves may be executed between detecting the problem and the machine stopping.

With this in mind, do you still think it would be helpful to detect filament issues when printing via USB?

timoschuett

@dc42 thanks for the super quick reply.
I am aware that the duet would still need to empty the buffer, that’s totally fine as ~40 moves are not that much.

I got a testing machine which is running Klipper while printing with repetier-Server, same thing but it works.
I just don’t want so swap all machines from RRF to Klipper as they are currently working fine besides the „issue“ that the clog and filament monitors are not working.

Is it possible to manually enable this in RRF or would this be bigger changes in the firmware itself?

dc42

@timoschuett I can look at adding a S2 option to M591 which would be like S1 but enable the filament monitor even when not printing from SD card. You might find it too annoying to have the filament monitors active during startup, filament loading etc. so you may need to use S1 in your slicer start GCode and S0 in your slicer end GCode.

timoschuett

@dc42 That sounds very promising
If i understand correctly at this moment there is no point for me to manually enable this and a changes in the firmware need to be made from your site first?
Can you estimate without obligation how long this takes until its ready to use?

I think there shouldnt be any problems while filament loading and unloading etc. because (if i understand correctly) the filament monitoring is just checking printing moves (xy moves + extruding) and not move or extrude only commands.

oliof

@dc42 another option would be to implement Marlin's Host Action Commands as part of setting a Duet board to Marlin compatibility mode. Maybe that's more generally useful?