M600 triggered part-way through first layer

[Cylindric]

Hi there. I've just started using this plugin with a BIGTREETECH Smart Filament Sensor, and there's an odd issue that only happens near the start of a print. The job starts, and about 30 seconds into the first layer, the plugin triggers an M600 event. If I continue, the rest of the job will be fine.

Running some GPIO scans on the Pi itself shows a constant stream of pings coming in from the sensor.

This is my start GCODE:

M80 172.29.14.101 1 ; light on
G90 ; use absolute coordinates
M83 ; extruder relative mode
M204 S[machine_max_acceleration_extruding] T[machine_max_acceleration_retracting]
M104 S[first_layer_temperature] ; set extruder temp
M140 S[first_layer_bed_temperature] ; set bed temp
G28 ; home all
M420 S ; enable mesh levelling data
G1 Y0 Z1 F100 ; move print head up
M190 S[first_layer_bed_temperature] ; wait for bed temp
M109 S[first_layer_temperature] ; wait for extruder temp
G92 E0
G1 E38 F1000; deretract filament
G92 E0
G1 X60 Z0 E9 ; intro line
G1 X100 E12.5 ; intro line
G92 E0

[Cylindric]

Forgot to add, my settings are:

Board Pin Mode: Board Mode Detection Method: Distance detection Motion Sensor GPIO Pin: 5 Detection time: 45sec Detection distance: 15mm

But it seems to do the same in timeout mode.

[maocypher]

Hi, did you run the test connection python script to verify that the sonsor is connected properly? In the Wiki you can find the instructions how to do it.

Did you check that your filament is not slipping in the extruder? Sometimes it might be necessary to set distance higher than 15mm. I had to set it to 20mm once, because it was to sensitive for the print.

I am continously trying to improve the detection algorithm.

For timeout detection the starting point is the first G1 or G0 command. After your first command you heat up again which costs some time and can cause this behaviour.

[Cylindric]

The test script doesn't seem particularly useful in this instance, it's using a very different calculation than the actual plugin. Like I said, I know the sensor is being detected, as after that one (consistent) failure it always continues to work.

I have attached a debug log output of an actual run instead, that seems more useful. It's interesting that two prints of the same gcode fail in exactly the same place. It's part-way through the first layer, so it's nothing to do with the wipe or warmup.

On both prints, I watched the extruder until the failure, and there were no skips. It's during a pretty steady part of the print, so there is constant extrusion.

I have attached: The logs of the first print The logs of the second print The first layer of the gcode that goes with the logs

Just for fun I ran some of the numbers from the logs, here is a plot of the reported Remaining Distance, Delta Distance and E values, with an accumulated total "E" seen.

smartfilamentsensor-first_layer_failure.log smartfilamentsensor-first_layer_failure-2.log

[3DVERSEjn]

How do you run the test script? I am having trouble understanding the directions

[maocypher]

I looked into the log, it could be something after restarting the print. Can you send me your gcode, so that I can run it on my printer?

Did you try a higher distance value, maybe 30?

That the test connection script uses timwout detection is fine, because it is only to verify that sensor is connected properly and any movements are detected. I.e. no error with the sensor itself or wiring

[Cylindric]

I can confirm the sensor is correctly connected, because the rest of the print is fine, and it detects breakages and stuff. It failed both times in the exact same point of the gcode. The test script shows activity as expected, as do my own scripts I've created to do raw monitoring of the GPIO pins.

I linked the gcode in my earlier reply. It's only the first layer, but it's enough to consistently cause a trigger event for me.

[maocypher]

I tested your Gcode on my printer. With your configuration of the plugin I ran into the exactly same issue.

I changed detection distance from 15 to 30. And it didn't stop. Everything was fine. Probably 20 would already be sufficient.

[Cylindric]

Cool, I'll try that. I guess it's getting caught by a particularly long straight line. Curious that it only ever happens on the first layer for me. Thanks for the help :)

[maocypher]

You are welcome. Please try different configurations, what is best for your print. Sometimes it has to do with the sensor that it is reacting later than expected. I know about this inaccurcy from time to time, but I have no other solution than changing the configuration, right now. You can change the parameters also when the print paused.

As there seems to be no problem with the plugin itself, I am going to close this issue.

If there are more question that are not related to an issue, you could also join my support discord channel https://github.com/maocypher/Octoprint-Smart-Filament-Sensor/projects/1#column-11443492 Or ask in the discord or forum of OctoPrint.