Added flag to send M600 only once for each detection

[Adirael]

Hello:

I added functionallity to be able to flag when the filament sensor is triggered so it only triggers once. I did this by adding a configurable option to do so and define the ammount of seconds the sensor triggers should be ignored.

Other solutions just stop detecting new triggers once the first one is detected, but that will cause the sensor to work just once per printing session.

Without this code mine was entering a pause loop since it was triggering while doing the filament swap. This addition fixed that.

Ángel

[Red-M]

Excuse me for maybe not quite understanding what you're wanting to do here but this kind of feature might be dangerous in the terms that, during a print you do want the sensor to pause the print as much as possible when there is no filament.

The intention here is to make sure that the printer is not printing air whenever possible but only make sure that we're doing that when we can confirm it rather than it be a faulty pi or switch.

The printer should be in a pause loop when you do the filament swap to stop you from trying to start the print again without any filament loaded.

I also need to setup a merge request template as well, so thank you for that.

[Adirael]

I agree with detecting as much as possible when there's no filament on the extruder. My problem is that while putting the new spool in sometimes the sensor gets pushed, so another M600 is sent by the plugin.

I have not tried the pause function, maybe that only happens if the printer is not paused (ie: you can't pause a paused print!) but when sending gcode it does get sent a few times other while fiddling around with the filament.

The two referenced plugins in the README have a couple pull requests to fix this, but they just stop listening for new filament changes, and that's an issue if you're finishing a lot of spools or doing a multiple color print with various strands. To mitigate this I save the timestamp of the last detection and only disable new detections for the determined amount of seconds.

Thanks for replying, and I understand if you don't want to merge this, I'm not sure if it's a problem for a lot of people or something specific to my setup :)

[Red-M]

Octoprint doesn't seem to care if code tries to pause a paused print. Personally I don't think this is really an issue unless you have a really bad sensor for filament out but you can fix that with bumping the number of detections up.

This might be an issue if I had put in auto resume on filament in.

I'm still happy to hear your thoughts however as I'm trying to understand what is going on here.

[Adirael]

I'm my case I have the pause checkbox disabled, since I want the printer to just run the filament change sequence. I guess that for people using pause this is a non issue, but when sending gcode it just keeps sending it until the filament is detected again.

My sensor is a basic switch on the filament guide, not sure if I can hook it up in a different way.

I tried upping the number of detections, but if I have it too high it detects too late that it's out of filament and it has no way to grab onto it to eject.

[Red-M]

Ok now I understand, you're using the gcode and not the pause print option.
Let me see what I can do here.

[Red-M]

Sorry to do this to you but do you mind doing this merge on the dev branch please?

I'd prefer to keep your name in the commits rather than me adding your code in with my name attached.

Actually, I have a different idea.
I'm going to add an option to only trigger once and not re-trigger when a confirmed pause occurs.
When the filament is loaded and the confirmations is reset, then allow for re-sending of a pause.

[Red-M]

Download the latest dev branch as a zip, install it and let me know if that fixes your problem.
You'll want to uninstall the plugin and reinstall it from the plugin repo in ocotopi once the feature goes to the master branch.

This might take a while as I don't currently have a functioning printer to test this (and other changes) with.

[Adirael]

I'll try it out later today and report back. Thanks a lot for making this changes!

[Adirael]

I tested it out and the same happens. It keeps receiving confirmations after sending the first GCODE string.

I took a look into the modifications made on 4d1eefe but it looks like the "send once" is only accounted for in the pause_print part.

I see there's a GPIO.remove_event_detect(self.pin)statement on the pause_print part, that should stop the sensor for triggering more than once for each pause and since there's a GPIO.add_event_detect() on the PRINT_RESUMED event will make the event trigger again on successive pauses.

This is a very clean way to make this work for paused prints, but I think it won't work if the user is only sending GCODE and not pausing, since technically the print is not paused, thus also removing the event will work the first time, but I don't see a clear way to re-add the event any other than a timer or something similar.

What are your thoughs on this? I'm up to coding anything any way you prefer to make things easier :)

I'm going to configure my printer to just pause and swap the filament manually for now and let you know if anything doesn't work as expected.

[Red-M]

Just an FYI, you'll need to uninstall the plugin then install from the dev zip.

[Adirael]

I installed it on a clean OctoPi instance, going from a zip downloaded directly from the dev branch.

[Red-M]

Did you also enable the send once option in the settings?

[Adirael]

Yes. My configuration looks like this:

[Red-M]

Odd, I'll see if I can make a test suite this weekend to try and get rid of bugs like this without a printer but in saying that the if statement for the send once is for both methods of pausing.

I see what I have done, I've not changed the tracking variable up when the pause is triggered, so it is always zero. Let me fix that and get another push.

[Red-M]

Give the latest dev a go now, sorry about that.

[Adirael]

No problem, thanks!

It will probably take a few days for me to test it out, looks like my sensor is not working properly. Checking the logs I can see the "Pin: 0" scroll, but if I release the switch nothing happens. If I push it and release manually a bunch of times I can see it detects the release sometimes, depending on timming.

Odd, a stand alone script works properly. Maybe something's wrong in my wiring or installation. I'll do a few test and get it working soon :)

[Charly333]

Hi, within two aspects I´ve got similar problems with that plugin.

First:
As far as I understood as soon as "Pin: 0 scroll" ist stopped, because sensor state has changed, the plugin should start it´s pausing action as defined.

This sometimes, specially shortly after starting a print does work fine. Many other times it takes up to five Minutes from stopping the "Pin:0" scroll until starting the pausing action. Putty shows even too a delay in showing new lines. This Putty delay only takes up to 15 sec but the pause action is delayed further on up to those five minutes.

Printing with 0,6 nozzle I can´t have the sensor far enough away from the extruder not to give it a chance to runnout of material within 5 Min.

It takes place on a Pi 3b+ with the newest octoprint release candidat (same with the lates stable on my second machine)

Second:
I can´t use M600 for this will pause my printer for ever without having a chance to bring it back to work. So I do use gcode snipped:

M207 S80 F5000; retract Settings
G10 S1 ; retract long
G91; relative Position
G0 Z10 ; 10 up
M104 S0 ; Extruder Temp 0

Every now and then this code even too is doubled, what results in two Z10 ups.

In my case I´ve swapped out all those tiny miro switches and did setup a new, bigger & more precise one that changes state with that much tension, any mice trap would be proud of.

Any results about thos two issues meanwhile?

[Red-M]

@Charly333
Before I even think of answering your issue I need to know if you are on the stable branch or the dev one.
I have further additions in the dev branch to stop a segfault on resume of a print that I'm getting with the original plugin and that I'm sometimes getting on mine.

I highly suggest using the plugin in the plugin repo if you want a stable printer.