Enclosure Temperature / Fan / Light Control / Filament - Octoprint Plugin

I should have caught that one :unamused: - it was the cache needing clearing.

It is not working for me.

I am getting this message in my debug

2017-03-04 02:29:19,709 - octoprint.plugins.enclosure - INFO - Detected end of filament.
2017-03-04 02:29:19,711 - octoprint.cli.server - ERROR - Uncaught exception
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_enclosure/__init__.py", line 170, in handleFilamentDetection
    for line in filamentSensorGcode.split(';'):
NameError: global name 'filamentSensorGcode' is not defined

Yeap… almost impossible to code something without test and be perfect at the first time… and now I’m a little bit buzzed to test, way to much wine, but made the changes without testing again, the bug was obvious… :mrgreen:

I’ll test tomorrow, I swear!

Ha! I’m nursing a slight hangover myself. Keep me posted - I’m eager to get it going :slight_smile:

Done, tested on my lulzbot taz 6 without problems, keep in mind that you should pug gcode with “;” at the end of the line, like real gcode commands.

I pushed the changes to the master branch, no need to use the development anymore.

I have a print going for the next 9 hours, but will test it the second it is done. Thanks Vitor!

Absolutely AWESOME. I love that the printer doesn’t strop abruptly and it finishes its current command before initiating the filament change. Better yet, after the filament is changed, it goes right back to printing. Nice job Vitor.

I’ll keep testing it and let you know if I come across any bugs.

Prior to my last post, to test I quickly triggered my filament sensor off and on; and it worked great. Since that post, I’ve learned that as long as the filament sensor is triggered (out of filament), it continually sends all the filament out gcode (M600 command). On my TAZ 6, it will respond to every single M600. I have to turn the machine off and on to break the cycle (at least that’s the only way I know how). Can we make it only send the gcode one time while the filament sensor is triggered? Then after filament is back in the tube start sensing again? Maybe even add a time delay to avoid false triggers while changing the filament?

Here is the debug code:

2017-03-05 18:39:42,652 - octoprint.plugins.enclosure - INFO - Detected end of filament.
2017-03-05 18:39:42,654 - octoprint.plugins.enclosure - INFO - Sending GCODE command: M600
2017-03-05 18:39:44,538 - octoprint.plugins.enclosure - INFO - DEBUG -> Filament detection active low: True gpio status: 0
2017-03-05 18:39:44,540 - octoprint.plugins.enclosure - INFO - Detected end of filament.
2017-03-05 18:39:44,542 - octoprint.plugins.enclosure - INFO - Sending GCODE command: M600
2017-03-05 18:39:45,412 - octoprint.plugins.enclosure - INFO - DEBUG -> Filament detection active low: True gpio status: 0
2017-03-05 18:39:45,413 - octoprint.plugins.enclosure - INFO - Detected end of filament.
2017-03-05 18:39:45,415 - octoprint.plugins.enclosure - INFO - Sending GCODE command: M600
2017-03-05 18:39:45,534 - octoprint.plugins.enclosure - INFO - DEBUG -> Reading temperature stdout: <open file '<fdopen>', mode 'rb' at 0x72184f40>
2017-03-05 18:39:46,272 - octoprint.plugins.enclosure - INFO - DEBUG -> Reading humidity stdout: <open file '<fdopen>', mode 'rb' at 0x6dcc97b0>
2017-03-05 18:39:46,803 - octoprint.plugins.enclosure - INFO - DEBUG -> Filament detection active low: True gpio status: 0
2017-03-05 18:39:46,804 - octoprint.plugins.enclosure - INFO - Detected end of filament.
2017-03-05 18:39:46,809 - octoprint.plugins.enclosure - INFO - Sending GCODE command: M600
2017-03-05 18:39:48,599 - octoprint.plugins.enclosure - INFO - DEBUG -> Filament detection active low: True gpio status: 0
2017-03-05 18:39:48,600 - octoprint.plugins.enclosure - INFO - Detected end of filament.
2017-03-05 18:39:48,602 - octoprint.plugins.enclosure - INFO - Sending GCODE command: M600
2017-03-05 18:39:51,916 - octoprint.plugins.enclosure - INFO - DEBUG -> Filament detection active low: True gpio status: 0
2017-03-05 18:39:51,923 - octoprint.plugins.enclosure - INFO - Detected end of filament.
2017-03-05 18:39:51,926 - octoprint.plugins.enclosure - INFO - Sending GCODE command: M600
2017-03-05 18:39:54,915 - octoprint.plugins.enclosure - INFO - DEBUG -> Filament detection active low: True gpio status: 0
2017-03-05 18:39:54,917 - octoprint.plugins.enclosure - INFO - Detected end of filament.
2017-03-05 18:39:54,919 - octoprint.plugins.enclosure - INFO - Sending GCODE command: M600

Hello,

Been away for some time. Now I see that this plugin is the most important plugin in my Octopi :slight_smile:
I love all the new features.
Really happy to have auto start and stop function.
Maybe a suggestion it would be nice if we could delay start and stop separately.
For example I have now auto power on and would like to be the first thing when print starts and then LED lights inside enclosure, then greeen lights outside enclosure and finally airpump for cooling prints.
But after print finishes I would like firstly to turn red LED outside enclosure, then turn off airpump, then turn off LED inside enclosure and finally turn off power.

And I would love to have more pins for relays(just for fun), I have 8 relay board :wink:

THANKS for the GREAT work

Sorry for the delay guys! I was on a snowboard trip without internet access, but now I’m back and ready to code…

Thanks for the feedback and testing!

Yeap… I’ll add that, it would not be problem using the pause gcode but for the M600 it is definitely a problem.

I thought about that but got lazy when initially coding, I’ll add that.

I pushed changes to the dev branch. I added a bunch of minor improvements, much better documentation on the setting screen, turn on delay and turn off delay are now separated, cleaned up some of the code. Added filament detection delay after detection is handled to avoid sending the gcode over and over again.

The only problem that I see is that, at least for me, I leave my printer unattended for long period of times, so few minutes of delay would not help. I personally prefer using GCODE pause command and resume the print from octoprint interface, because sending multiple times pause command is not an issue, but sending M600 is…

Unless we change the firmware, and disregard M600 commands until the previous command is “handled”. I’ll take a look and see how difficult it would be to fix this on the firmware.

I did not test my changes yet, I have long prints going on, so maybe tomorrow?

Hopefully you had fun and recharged on your trip!

What are your thoughts on adding something after your plugin’s gcode runs, that hangs (while loop?) until their is filament again?

Yesterday I had the chance to test IO/s and the Heater. I still need to test the filament sensor and I’ll push another revision of the plugin.

That does not work, If I hang the plugin octoprint will stop responding. And the root issue is that your filament sensor is probably being triggered multiple times, we would need to put an oscilloscope and see the wave forms to understand it better, maybe when you are changing the filament? Could you send me a link for the filament sensor that you are using?

I use a mechanical one, so it is very reliable and it does not trigger multiple times.

The best way to fix this would be start the filament sensor again only when the printer resumes printing, but when using the m600 command that is handled by the printer, not octoprint, so I can not, from the plugin, know when the printer is resuming a print state. Few possible fix are:

  • Only trigger the filament sensor once per print, realistically how many times your filament will run out on the same print?
  • Use pause gcode command, because octoprint will handle the resume, activating filament sensor again
  • Fix the marlin firmware to stop handling m600 commands until the previous is finished, I took a look on the current development branch and it looks like m600 has new code, and probably handle it already.

If the issue is on your sensor signal, I would need to see the wave form, maybe adding a stronger pull up and a capacitor would clean the signal enough to avoid the issue.

The filament sensor is my own design and not likely triggering more than once. It uses an Omron SK472 photo sensor that the filament runs through. When filament is out, there is really nothing to give it false readings or make it bounce around. It is possible I have a bad sensor,
I can put my o-scope on it when I get home and confirm 100%. Here is my sensor: https://www.thingiverse.com/thing:2105007

I agree 100% - If I am trying to use up a bunch of almost empty spools - I can sit by the machine and babysit it. What is the max delay?

I will give your current version a try tonight or tomorrow.

The new update looks great. I like how you hide the I/O settings until enabled.

The repeated M600 command doesn’t seem to be an issue with the Omron sensor (see attached pics of the o-scope in both states). Because I don’t understand the communication between octoprint and my printer, it baffles me that octoprint keeps sending M600 commands even though the filament sensor is tripped and in the middle of a filament change. Weird.

I don’t want you to keep spinning your wheels on my behalf. The pause/resume irritant of mine is a small one that I can live with. I mean how often am I going to run out of filament and have to deal with it? More importantly, the pause works.

I’ll be checking for bugs over the weekend, I’ll let you know if I come up with any.


Could you do me a favor? put you scope on single capture mode, triggering on the rising edge, and feed the filament into your sensor, that is the wave form that I want to take a look. :slight_smile:

Make sure that you capture enough time to have all bouncing that might occur…

I got pics of it both ways in case it was helpful. I have it set to 1/2 a second (my scopes max) - Hopefully this is what you are looking for.


yeap, that is what I wanted to see, I have no fricking idea why octoprint is sending multiple M600…

I’m hooking up the event and it should only be called when the GPIO from the sensor is falling

I’ll try to figure it out… Does it only happen when you are loading the filament?

If I quickly remove the filament and put it back in (less than a second), it works perfectly. However, under normal filament change circumstances, it sends a ton of M600 commands. After I get the filament changed and the sensor is reset, there are way too many M600 commands in the queue. I’ve never been patient enough to cycle through all of them and see what it does at the end. My assumption is it would be fine.

Sorry I’ve been MIA - we brought home a new puppy last weekend and between work and him I’ve had zero time.

I saw a new update come down - anything exciting?

Hello,

Maybe it is not the right place to ask, but anyway.
Does someone know how to swap this two buttons.
buttons.jpg
This plugin is more important for me than timelaps.

Thanks for any help.