added feature for sending GCODE only once. #29
Conversation
|
Omg this it's really needed. I actually stopped using this pluggin because of this behavior. This bug forced me to learn how to find and configure a free pin in Marlin. Modify and upload firmware and then wire a endstop as a filament sensor. Harder but at least I know how now. |
|
If you are interested, I can make the changes available to you (two files to replace in your octoprint deployment) so you can test it out. Let me know and I can make that happen. |
|
@DrWatson Yes please. I still have one printer(Taz6) that I haven't hard wired a filament sensor to. I'd love to try it this weekend. |
|
Please read this whole message. If anything in here is not at your comfort level, then I suggest you not proceed. If you do choose to proceed, you do this at your own risk, of course. I will help if I can...just post here. You will need two files. The first is the _ _ init _ _.py which you can find here: The second file is the filamentreload_settings.jinja2 which you can find here: Making some assumptions about your octoprint deployment, here, but you should back up both of these files. I will assume that you know how to ssh and get to the folders where these files are. Mine are located here: After you have backed up the original files and replaced them with the two above, you should restart octoprint by running: sudo service octoprint restart For me, I am using the reload filament command of M600 to help in the reloading process when I get a filament run out. To do this, I have set mine up using these steps:
Remember that you need to have M600 enabled in your firmware. It's not on by default in Marlin 1.1.* Here is a video for how to do it: The process will now be that when the filament is out, the M600 command is called once and Octoprint pauses the print. The M600 command will lift the head, park it, and allow for refilling of filament. You control these steps from the LCD on the printer. (Yes M600 in marlin is only operational using the LCD panel.) Once the filament is loaded and you've finished the steps on the LCD, you go over to OctoPrint and resume the print. The head will go back to the position it left off at when the filament ran out and resume the print. Let me know if you have any questions. |
|
Thanks for the detailed instructions. I haven't touched my Taz6 for months. But I'll dust her off to try this, this weekend. |
|
Leaving the pause print unchecked won't be a solution for you, I fear. Let me explain. The way the plugin works is that it registers for an event from the Pi GPIO interface. It gets a steady flow of events from this interface regardless of pin change. This is why in the logs you get a message a few times each second that reports "Filament detected!". This is the root cause of the looping behaviour in sending GCODE. To fix this problem, when the new "Send GCODE only once when out of filament." configuration item is checked, I unregister the callback so the plugin doesn't get any events from the GPIO interface. When you resume the print, it reregisters the callback and the GPIO events begin to flow again. So if you don't use the pause functionality of the plugin, you won't need to resume the print in Octoprint, however, you will no longer get the GPIO events. In this way, you will only get the out of filament handling once. If you run out of filament again subsequently in the same print, you will not get the event because it hasn't reregistered for the event because resume was never called. Hope that makes sense. I don't know if I can get an event into the plugin when the M600 is complete. If I do, then code could be added there to reregister for the GPIO event, but I didn't think of that at the time or writing. Perhaps that's something else for me to look at this weekend or next week. |
|
Ok I'll test for the loop behavior fix anyway. And then report back either tonight or tomorrow. As for hitting resume in Octoprint and continue in lcd, I understand your explanation. |
|
@DrWatson I dont see option to "Place a check in "Send GCODE only once when out of filament." in the plggin window Your versions size init.py is 84,368 compared to old @ 5,292 Couldnt test as I cant get it to install properly?? suggestions? |
|
Those file sizes do not look close at all to what is in my repo. I have downloaded the files from the repo and included them here. Please use these files instead and see if you get different results. |
|
Ok i used the files from the download above. When I do so, the Filament Sensor Reloaded (1.0.1) doesn't show up in the pluggins section on the right where all pluggins are listed and you can alter their parameters. It does show up in the main plug in manager as being installed, however. Reverting to stock and rebooting fixes the issues of it not showing up on the left under pluggins, but then im stock cant test. |
|
That's strange. Those are the exact files I am running. If the plug in fails to load, there will be an error in /home/pi/.octoprint/logs/octoprint.log . If you could put the files from the zip file back in place and restart octoprint again, then paste here what the log says after the restart. I changed very little for this fix, so I'm surprised it's being difficult. |
|
ok my logging level is set to debug: |
|
Deleted the pluggin. Reinstalled. Now I get pluggin showing up in master pluggin list and on left where I can edit parameters. |
|
type: then type: post the results here. |
|
pi@octopi:~/oprint/lib/python2.7/site-packages $ grep -r -i "send gcode" * |
|
Something still isn't right. There should be more files that contain that pattern. At least two:
Let's try this from scratch again...this time a little more thorough. (Sorry about this.) Unzip the zip file in this message and place the filamentreload_settings.jinja2 file that it in the templates folder (octoprint_filamentreload/templates/filamentreload_settings.jinja2) Place the _ _ init _ _.py in the folder one up from the templates folder (octoprint_filamentreload/). In the octoprint_filamentreload/ folder, please delete the _ _ init _ _.pyc file. This is a compiled version of the file and will be rebuilt when needed. Perhaps something is being cached. Reboot the Pi. When you go to your web browser and navigate to the settings page for the filament reload configuration, press Shift+Reload (I will assume chrome, don't know what force reload would be in whatever browser you're using) to make sure you are not being served a cached copy of the page. |
|
Ah oh ok. I never deleted the .pyc |
|
I haven't had to delete the pyc before, but I'm thinking it's more likely a browser cache thing. The new files in the zip are the actual files I am running on my Pi (which are slightly different than the ones in the repo.) Just curious. Were you replacing the files in the two different directories? ie octoprint_filamentreload/templates/ and octoprint_filamentreload/_ _ init _ _.py? What is the whole path for the files you are replacing? Mine is in: /home/pi/oprint/lib/python2.7/site-packages/octoprint_filamentreload. |
|
Yes my path was the same as yours. I renamed originals as ......old, in both folders. Then uploaded your versions. |
|
Success - I can see the new "Send GCODE only once when out of filament" in the pluggin window. I can now test filament changes for loop behavior, :) |
|
Awesome! Let me know how the testing goes. |
|
Did a little testing last night. At first I thought it didnt work. When I cut filament, printer kept on printing. Thought it was something on my end. So I double checked the pin assignment and the state of sensor, normally open, normally closed. Then I decided to tail the output of log in real time...... From turning printer on and reboot of Octoprint. Did test again monitoring the log output. Cut filament. No trigger filament change, even in log. So from scratch again. Printer powered off. Octoprint restarted. No trigger 1st out of filament. 2nd out of filament detected. No loop. |
|
Great, so this solution works for you? Call it a success? |
|
No loop behavior for filament changes - success. For me 1st filament outage undetected. |
|
Just re-read your messages again and realized I missed the part about it not working the first time. I don't know why that would be. Would be interesting to see if that happens with the plugin without my modifications. If so, then we can rule out the changes I made as being the culprit and tackle it differently. If you find that it misses the first out of filament trigger again and you determine it's not some kind of problem with the printer or detector somehow, then let me know and we can try and troubleshoot together. |
|
@DrWatson Without your new code, stock filament reload pluggin - I change filament - printer gets stuck in a loop if you happen to trigger the runout sensor during a filament change - creating a loop. However stock pluggin is always able to trigger/catch a filament runout condition. |
|
I followed suggestions here and deleted the .pyc and replaced everything. It worked once. Now anytime the sensor is triggered, I receive the following in a webpage and have to completely restart the Octoprint. The OctoPrint server is currently not running If the issue persists, please log into your Raspberry Pi via SSH and check the following: Verify that the process is running: ps -ef | grep -i octoprint | grep -i python should show a python process: The gcode I am using is as follows: Also I have the "pause Print" and "Send GCode only once" checked. |
|
Looks like octoprint is crashing. Can you remove the gcode you have entered in the text box and try again ? We need to narrow down what is causing the issue. Did any of this work prior to substituting the new files? |
|
@mylife4aiurr |
|
It did work stock. I believe it works with just the pause print checked and no gcode but I will have to test it further and get back to you. |
|
Just to be specific, if you could try having pause checked and send gcode once checked, but don't include any gcode. If octoprint still crashes, then we can rule out the gcode and the gcode messaging pipeline and we can look elsewhere. |
|
The error appears to occur when gcode is input into the box with both items checked. With no gcode, the printer pauses as expected and wants for the unpause to be hit. |
|
@3DEnthusiast For me, I could get the pause to happen on the first time during a print. Then I continue the print with no issues. Then I go to remove the filament again, and it crashed Octoprint. I have to restart everything and once I'm back up again, I remove the filament. This time, the GCODE doesn't get executed and Octoprint crashes. Is this the same behaviour you see? |
|
Speaking of updates. I upgraded my Octoprint version to newest maintenance release (1.3.9rc1). |
|
I'm running 1.3.8, myself. That sounds like what is happening to my octoprint when any gcode is used after it's paused. |
|
I think I have found the problem with Octoprint crashing. I think it is because I unregister for the filament out callbacks while I am inside the callback itself. Kind of like sawing off the branch you're standing in. I have changed how it works now so it doesn't do that. I am doing some testing right now and will report back after I am satsfied with the results. So far, it's looking good though. |
|
Awesome! Hopefully it is an easy solution! |
|
Bad news. Just made it crash again. I decided to remove the plugin all together and reinstall. Then I left it stock and only enabled the pause checkbox. Then went into the Octoprint configuration into the section GCODE Scripts -> After print job is paused and entered this GCODE: M600 X40 Y40 Z10 E2 L10 I then started a print job and caused a out of filament trigger. Octoprint paused and then immediately crashed. I assume it crashed when it tried to run the GCODE. Ugh. So this is with the stock plugin and no GCODE executed. I decided to try again. I started another print job and caused a out of filament trigger. Octoprint paused and the GCODE executed as expected. Weird! Then when I refilled the filament and clicked resume, Octoprint crashed again. There is definitely something going on here and I have confirmed it doesn't have anything to do with my changes. I am going to have to post something on the Octoprint Google+ group and see if anyone else is seeing issues somewhere around this area. Sorry guys. Looks like a solution is not in the cards in the short term. |
|
I actually, just thought of something else to try. I am going to remove the plugin again and remove the run out sensor also. I am going to leave the GCODE in the pause script area of Octoprint. Then I am going to manually click pause in the UI and see if it crashes. If it does, then we can rule out the plugin altogether and point directly at Octoprint with an easier set of reproduction steps. I'll let you know what I find. |
|
I just put the move gcode in the "after pause" section of octoprint. It worked about 4 times but now it's crashed octoprint. Pause print and send once we're checked but no gcode in the plug-in itself. |
|
Further testing shows that Octoprint seems to crash if it's paused and restarted multiple times. I believe my optical endstop is triggering multiple times and causing it to crash. |
|
What about if you manually pause and restart? |
|
Manual pause and restart doesn't appear to cause issues. Only when it's
told to do something more than just pausing the print automatically and,
apparently, only at random does the issue arise.
…On Sat, Jun 23, 2018, 11:31 PM Steve Van Dokkumburg < ***@***.***> wrote:
What about if you manually pause and restart?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#29 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AhibTqgwL4D95eIpHL6cY4a4vjra9bxOks5t_xYEgaJpZM4Ub9KP>
.
|
|
Added different fix for this issue at #35 |
|
Hi i have a question. I have also the Filament Sensor reloaded Plugin with the orginal Anycubic Sensor. It is connected to the PI3 directly and it works. I tried it make pause etc and it works but in some cases it dont works. I got the Message in the octoprintlog: And the Octoprint does not stop. I checked the Switch with "gpio read 7" and it works fine from PI side. Does anybody now a fix for this Problem? I use Octoprint 1.3.10 with Filament Plugin Version: 1.1.0 Regards. |
Made some changes to address an issue that has been reported a few times here. I picked one of the issues (issue 22) as the name of the branch. This has been referred to as a "looping" problem in other posts. It basically allows the user to configure witch a checkbox if they want to old classic behaviour of resending the GCODE or if they want to send it only once. The way this is accomplished is by simply unhooking the callback when the filament is out and then rehooking it again when they resume.