Laser Filament Monitor - activate for USB streamed prints?

  • 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:

    1. 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?

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

  • administrators

    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!

Log in to reply