Filament monitoring while printing via USB

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?

timoschuett

@oliof is this still needed if the host reads the outputs of the board?
The board just needs to output a certain message in the console and the host needs to react to this event as for example repetier-server can.

I would be totally happy with an S2 option for M591. This should resolve many problems.
If there is a quick and dirty workaround for this, please tell me

oliof

@timoschuett The host reading output from the board is exactly what happens with host action prompts, just in a documented, known, and supported way that is already done by other firmware. Hence I suggested using that instead of inventing another scheme which would require adoption by other systems.

benecito

Any update on when it will / might be available?

chrishamm

@benecito See https://github.com/Duet3D/RepRapFirmware/issues/862

jaysuk created this issue in Duet3D/RepRapFirmware

closed [FeatureRequest]: M591 filament monitoring option for USB control #862

benecito

@chrishamm @jay_s_uk thanks for the suggestion! Just wanted to try it out, but did not even get that far as it's status stays at "ok" even if there is no more filament in the sensor and the print is paused on a sd print.
Also is there a limitation not documented if the filament monitor is connected to a CAN board (duet 3 mini slave)
I get information back when sending M591 but no calibration values and the print does not pause. It works when it's connected to the mainboard.

jay_s_uk

@benecito the filament monitor has to be on the same board as the extruder driver.
there are some temporary limitations in place https://docs.duet3d.com/en/User_manual/RepRapFirmware/CAN_limitations

benecito

@jay_s_uk I know about those and the extruder driver was always on the same board as the filament monitor

jay_s_uk

@benecito looks like there are a few things that aren't reported in the OM for filament sensors, especially when over CAN-FD. https://github.com/Duet3D/RepRapFirmware/issues?q=is%3Aissue+is%3Aopen+filament

benecito

@jay_s_uk @chrishamm To be honest I don't care so much if it's reported in the OM or not. The proposed "workaround" at https://github.com/Duet3D/RepRapFirmware/issues/862 does not work if the status is always "ok". Rearranging the extruders and the filament monitors to the mainboard could be done, but is not the preferred option.

Is there another parameter than sensors.filamentMonitors[0].status that might help to achieve the idea of using deamon.g

jaysuk created this issue in Duet3D/RepRapFirmware

closed [FeatureRequest]: M591 filament monitoring option for USB control #862

jay_s_uk

@benecito no, thats the point of my response, sensors.filamentMonitors[0].status is from the object model...
there isn't another way to query something

benecito

@jay_s_uk all right - so the conclusion is, that we can't use any filament monitor as of now?

jay_s_uk

@benecito you can use them on the mainboard but it looks as though the reporting over CAN-FD needs work. but hopefully someone like @dc42 can chime in

benecito

@jay_s_uk But that's my point - even when connected to the mainboard sensors.filamentMonitors[0].status will stay at "ok" when I run out of filament