Open oerkel47 opened 3 years ago
I really hate to be repetitive but the logs you linked are not complete. Check out the instructions in the wiki under troubleshooting.
Do you miss the serial.log? I created another logfile. Logging was set to debug already.
Serial.log https://pastebin.com/3w1kUKdR Octoprint.log: https://pastebin.com/bLNULLqY
Interesting part should start at around 19:56
Thanks. The previous log wasn't from startup. :). Will look in a bit.
Can you try without Arc Welder and if that doesn't work try with all other 3rd party plugins disabled?
Disabling arc welder doesn't change it. Will try more tomorrow. Thx for looking into it.
Just tried with a fresh install with only psucontrol as 3rd party plugin. Same behaviour. The behaviour is the same as if the printer was off. It uploads and selects the file. I am quite sure the reason is the printer not being connected when the api command comes in.
Hello,
I have started to use this plugin and have this issue as well. I have monitored the issue and I believe the issue lies with the "Connect to Octoprint automatically". When I have this selected it works functionally but appears to send the connect command right away but this is too early for Octoprint to detect the printer as octoprint will fail to connect after trying all the baud rates on /dev/ttyUSB0 when it should be delayed until /dev/ttyUSB1 becomes available otherwise octoprint fails to connect and stays there.
I can work around by waiting for the usbserial to show in octoprint then connecting manually but maybe a customizable delay to the connection back to the printer could assist here?
Thanks for this plugin though it's really awesome stuff - super impressive!
I can work around by waiting for the usbserial to show in octoprint then connecting manually but maybe a customizable delay to the connection back to the printer could assist here?
Found the setting... Post On Delay becomes 'Connect Delay' when Connect to printer automatically is set. try that that may help
I am using that option already and connecting works, just the print doesn't start.
Does it start printing for you? Or only connect?
Will see if I can narrow it down. Might just have to add a connection wait.
I set the post delay to 10 and this was perfect for my ender 5 Pro. I can have thr printer now idle and power and print automatically via cura
Oh Wow. It works with 10 seconds delay! With 8 seconds apparently the timing is off but good enough for connecting.
Possibly just an environmental difference. I had a few people test prior to releaae with delays of 5s and below. Will see if can improve the handling though.
Yes I am using an esp8266 running wled on the pi so if the connect is run too early octopi fails as it cannot connect to that and deems nothing is suitable. It needs to have the second usb avalible before working 💪
On Sat, 1 May 2021, 13:59 Shawn Bruce, @.***> wrote:
Possibly just an environmental difference. I had a few people test prior to releaae with delays of 5s and below. Will see if can improve the handling though.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kantlivelong/OctoPrint-PSUControl/issues/206#issuecomment-830628702, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANWVMCDBGZIUC5EGV7E5UNDTLP3LFANCNFSM432RREVQ .
So I've made a test build to see if adding a simple wait during the upload helps. Since I don't have a printer with this type of configuration I'm unable to test. If someone wants to try it out the link is below. Install via Plugin Manager.
https://github.com/kantlivelong/OctoPrint-PSUControl/archive/refs/heads/enhance_api_print.zip
When testing please set the "Post On Delay" value to 0. Attach debug logs even if it works.
Thanks 🙂
Hi.
It doesn't do the trick unfortunately. Additionally the slicer will throw an error now:
HTTP 500: {"error":"The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application."}
Delay too low: error (this is new) Delay 10s (which worked before): works
Log with 0s delay: https://pastebin.com/35r0Gf5x
NameError: name 'c' is not defined
whoops. Just pushed a change. Reinstall with the same URL.
Ah. This works! Nice. https://pastebin.com/DDpPpy8b
Ah. This works! Nice. https://pastebin.com/DDpPpy8b
Odd, I don't see anything in the log for it. Make sure power is off and the printer is disconnected. Having the logs is really important since I can't test it myself. Thanks 👍
Sorry, you are right. Didn't reset the post on delay to zero.
..doesn't work. https://pastebin.com/wMWGT0Rk
serial.serialutil.SerialException: [Errno 6] could not open port /dev/ttyACM0: [Errno 6] No such device or address: '/dev/ttyACM0'
Alright now we've got confirmation that it attempted to connect and failed because of the lack of delay. Previously early in the ticket you had a delay of 8s and it was connecting but not in a ready state so it wouldn't print. So let's try a value like 5s for the delay and see what happens.
5 seconds runs into timeout. 6 seconds works.
Both cases are in the log.
On another note: I noticed that the symbol lags when using this feature now. PSUcontrol has determined the PSU to be on but the symbol doesn't change to green before the timeout or succes. This is not really important, since normally you wouldn't monitor the GUI anyway while using this feature. But I guess you might want to know anyway.
So that kind of fits in with the original timings where 8s was not long enough. With your 6s plus the plugin waiting an additional 3s sounds like the change is working.
The UI not updating is expected with how this is implemented as the API call is stuck waiting for the printer to connect.
I'm not 100% committed to this implementation so will see if I can come up with something better.
Afterall an entry in the FAQ/Wiki to adjust the delay timing until it works is probably a good enough solution. I just hit an edge case with the timing..
I am hitting this issue too. Even after setting the delay to 30 seconds, I still see the issue. Printer is turned on, connected, print job exists, but doesn't start.
I tried the change in the enhance_api_print branch and it worked great. Please merge. :smiley:
I just tried that change as well. Worked as expected.
I created a new issues about this problem, someone have found some fix ?
I created a new issues about this problem, someone have found some fix ?
Can you increase the delay?
The info should be above
I tried with a delay of 90 second and nothing change.
See #244 for more info
@BeppeTemp you can try if my fork works for you as it works differently in that regard: https://github.com/oerkel47/OctoPrint-PSUControl
@oerkel47 I plan to get back on this project at some point in the future. Likely near the end of the year.
@BeppeTemp you can try if my fork works for you as it works differently in that regard: https://github.com/oerkel47/OctoPrint-PSUControl
Works perfectly thanks a lot, why it's not merged in this repo ?
What were you doing?
Octoprint running already (not controlled by psu control)
Printer is OFF (controlled by psu control)
in psucontrol "turning the printer on prior to printing when uploading file from API" is activated
send a file from slicer via API with activated start print command
What did you expect to happen?
File uploads & printer gets turned on via psucontrol. File starts printing.
What happened instead?
File uploads & printer gets turned on via psucontrol. File is selected but print does not start.
Version of OctoPrint-PSUControl
1.05
Link to octoprint.log with octoprnt.plugins.psucontrol set to DEBUG
https://pastebin.com/KaXuvYi3 The log might not be super helpful since its more the lack of stuff happening that is interesting.
my take on this problem
To make it work as expected it is necessary to make sure the printer is connected and then retrigger a print command. This is because the "original" print command gets lost if the printer is not 100% ready when the api file upload comes in.
What I tried:
https://github.com/kantlivelong/OctoPrint-PSUControl/pull/205
Works in my case, but might not work in every case.