Laser Filament Monitor - activate for USB streamed prints?

MGJosh

Good afternoon all, more strange questions about filament monitor setup. I purchased one of the first production run from Filastruder, and have it setup - I created my own mounting system, with the laser sensor watching the rotation of the (etched) filament drive idler bearing; early testing is promising. I do have a couple questions though:

I was able to use the filament monitoring and pause-on-error features on a print running from the Duet's SD card, however I cannot get it to work on a print streaming over USB (in my case, from a Raspberry Pi 3 running OctoPrint). Is there a gcode that will switch the sensor into "calibration" or "print" mode, or would that require some firmware tweaking?

I did read on one forum post that to generate calibration data, the print needs to be running from the SD card - so I guess part of it is I'm wondering if that's a firm requirement (that section of the firmware wants more lookahead for instance), or just how it's setup at the moment?

My calibration data so far has been quite promising, though a bit strange - over 3627.9mm min/avg/max of 172/180/189 %; the rest of the print, between intentional jams, had a very similar average and range. I'm confused about the 180% value though - I would think that measuring the circumference of the idler, as it's driven by the filament squeezing between it and the extruder drive gear, would be extremely close to 1:1 with the filament motion. E steps/mm are correct, and prints (including those monitored) look fine, so I don't know where that error/offset is coming from.

I do have some angle and distance experiments to run here, so I may just find that the 180% is from my current specific mounting system, and tilting the sensor a bit gets closer to 100%...

Thank you as always for your time and thoughts.

dc42

The problem with using the filament monitor with prints streamed over USB is that when a problem occurs, the firmware needs to tell Octoprint:

"Hey, a problem has occurred so I've stopped processing moves. The reason is xxxxx. Stop sending me any more moves and go into manual mode. The first move you sent me that I didn't print is the one that you read at offset yyyyy in your print file, so when you resume the print, start sending me moves from that one."

If/when there is agreement on how to support this type of communication mechanism in GCode senders like Octoprint, we could implement the RepRapFirmware end of it.

I find the 180% surprising too!