Automatically start printing after turning on via PSU Controll after API Upload

Get Help
1

What is the problem?

I wanna start printing from within Prusa Slicer without taking care of octoprint at all if possible.

If I turn on my printer and connect it within octoprint beforehand I can use the "upload and start printing" button (I assume thats what the button says in Englisch cos I am using German) in PrusaSlicer so after the gcode is uploaded the print starts immediately.
Thats kinda neat and I'd like to take this one step further. Cos you know, after idling over night or for a few hours I like to turn everything off through PSU Controlls - Power Off Options - Idle Timeout.

If the printer is off or even if the printer is on but not connected it just wont work.
The upload just works fine but the print wont start until I clicked the button within octoprint.

There is this "Turn on prior to printing after API upload" option in the PSU Controll Plugin settings. It turns the printer on immediately after an upload and the printer also gets connected automatically ("Connect when powered on." is checked too.) but it wont just start my print.

So I guess there is no "wait for connection" feature within Octoprint if it gets a "start print" command via API?!? Or is there some hidden option?

I mean like some kind of delay or something would be fine here. The printer will be connected within a few seconds and than the print would just start.

What did you already try to solve it?

checked and unchecked a few checkboxes.

Have you tried running in safe mode?

nope

Did running in safe mode solve the problem?

nope

Systeminfo Bundle

do you need it? Sounds like a more basic question to me ...

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

OctoPrint 1.7.3, Python 3.7.3, Prusa i3 MK3s, printer firmware latest, browser Firefox,

Addition:
I am using PSU Control - Home Assistant for Switching and Sensing.
Switching:
"Enable switching with G-Code commands" not checked.
"Turn off when an unrec.. firmware or comm error occurs." not checked.
Sensing:
Polling Interval: 1sec

Addition 2:
I switched from Home Assistant to PSU Controll - Shelly Integration. Same Problem.
I also tried to use lower "Power On Delay" Settings like 0; 0.1; 0.5 and 1; 1.1 and 1.5 sec. No difference. Actually the printer seams to be connected just fine after about 1.5 secs after hitting the Power Button in OctoPrint or after Uploading it via PrusaSlicer.

2

You likely need to increase the post on delay.

3

Already tried that. What that does is, its waiting (the set delay) after powering on until connecting. This allows the printer to be fully on/botted before the connect is being triggered.

At least this is what I guess from observing. Tried with a stop watch ... hitting start on the stopwatch and the "upload and start printing" button in PrusaSlicer at the same time and stopped the stopwach when printer shows as connected in Octoprint I always get like "Post On Delay" + 2secs.

Doesnt matter if the delay is set to 3 or 8 or 20 secs. Prints dont start.

Also the little flash indicator stays grey for the given delay. Its like PSU Control assumes its powered off for the given delay. Without testing it any earlier.

4

Gotta add: I am using Home Assistant as the switching and sensing method. Polling interval 1 sec for Sensing.

5

Will need debug and serial logs.

Follow Troubleshooting · kantlivelong/OctoPrint-PSUControl Wiki · GitHub

6

Just realized that you are the developer of PSU Control Plugin. :smile: Thanks for the plugin!!

Here is what I did:

  • disabled PSU Control sub plugin for home assistant to take it out of the chain.

  • using shelly sub plugin, tested it. its working.

  • turned the power off

  • followed the instructions to set up debug / serial logging.

  • deleted old files octoprint.log and serial.log to give us a clean start.

  • [21:36] restarted Ocotoprint

  • wrote this message

  • [21:40] hit upload and print in PrusaSlicer

  • given situation, printer on, connected but print didnt start

  • moved the bed to see the display on camera ... (just to let you know cos it will be in the log files...)

  • [21:41] used PSU control to turn the printer off. Just to give us a kind of "clean start" without the "start from PrusaSlicer" ...

  • [21:42] turned the printer on via PSU control

  • hit "upload and print" Button in PrusaSlicer -> print does start

  • aborted the print right away

  • went to settings / logging and downloaded the files, here is the zip file:

octoprint-logs.zip (240.3 KB)

7

And to add, the post on delay is set to 0.5 secs for now. Let me know if you wanna se any other value there. (and a new set of files or whatever)

What I have seen from the terminal-window in octoprints UI was that a functioning "upload and start" looks like this in the gcodes:

2022-03-18 21:42:44,894 - Changing monitoring state from "Operational" to "Starting"
2022-03-18 21:42:44,954 - Send: N0 M110 N0*125
2022-03-18 21:42:44,967 - Recv: ok
2022-03-18 21:42:44,970 - Changing monitoring state from "Starting" to "Printing"
2022-03-18 21:42:44,978 - Send: N1 M73 P0 R2*22
2022-03-18 21:42:44,998 - Recv: NORMAL MODE: Percent done: 0; print time remaining in mins: 2; Change in mins: -1
2022-03-18 21:42:45,014 - Recv: SILENT MODE: Percent done: -1; print time remaining in mins: -1; Change in mins: -1
...
...

And the case where octoprint turns on the printer via PSU control but does not start the print afterwards looks like this:

2022-03-18 21:40:13,858 - Changing monitoring state from "Offline" to "Detecting serial connection"
2022-03-18 21:40:13,883 - Performing autodetection with 7 port/baudrate candidates: /dev/ttyACM0@115200, /dev/ttyACM0@250000, /dev/ttyACM0@230400, /dev/ttyACM0@57600, /dev/ttyACM0@38400, /dev/ttyACM0@19200, /dev/ttyACM0@9600
2022-03-18 21:40:13,884 - Trying port /dev/ttyACM0, baudrate 115200
2022-03-18 21:40:13,885 - Connecting to port /dev/ttyACM0, baudrate 115200
2022-03-18 21:40:13,899 - Handshake attempt #1 with timeout 2.0s
2022-03-18 21:40:13,902 - Connected to: Serial<id=0xa9ed3bd0, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2022-03-18 21:40:13,904 - Send: N0 M110 N0*125
2022-03-18 21:40:14,948 - Recv: start
2022-03-18 21:40:14,953 - Changing monitoring state from "Detecting serial connection" to "Operational"
2022-03-18 21:40:14,998 - Send: N0 M110 N0*125
2022-03-18 21:40:15,018 - Recv: echo: 3.10.1-4697
...
...

Looks the same in serial.log.

What I can see from octoprint.log is when its not working its like this:

2022-03-18 21:40:13,990 - octoprint.filemanager.analysis - INFO - Starting analysis of local:filler_0.2mm_PLA_MK3S_2m.gcode
2022-03-18 21:40:14,005 - octoprint.printer.standard.job - INFO - Print job selected - origin: local, path: filler_0.2mm_PLA_MK3S_2m.gcode, owner: Andreas, user: Andreas
2022-03-18 21:40:14,651 - octoprint.filemanager.analysis - INFO - Analysis of entry local:filler_0.2mm_PLA_MK3S_2m.gcode finished, needed 0.66s
2022-03-18 21:40:14,849 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...
2022-03-18 21:40:14,884 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0, status_code=200, text={"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:40:14,885 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True
2022-03-18 21:40:14,953 - octoprint.util.comm - INFO - Changing monitoring state from "Detecting serial connection" to "Operational"
2022-03-18 21:40:14,997 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2022-03-18 21:40:15,004 - octoprint.plugins.firmwareupdater - INFO - Got CONNECTED event
2022-03-18 21:40:15,008 - octoprint.plugins.firmwareupdater - INFO - Run postflash flag is not set
2022-03-18 21:40:15,887 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...
2022-03-18 21:40:15,917 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0, status_code=200, text={"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:40:15,918 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True
2022-03-18 21:40:16,921 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...

With the file name of the job filler_0.2mm_PLA_MK3S_2m.gcode can be seen three times (Starting analysis, print job selected, Analysis finished)

Where in the working case (with PSU on beforehand) it looks like this:

2022-03-18 21:42:44,782 - octoprint.filemanager.analysis - INFO - Starting analysis of local:filler_0.2mm_PLA_MK3S_2m.gcode
2022-03-18 21:42:44,788 - octoprint.printer.standard.job - INFO - Print job selected - origin: local, path: filler_0.2mm_PLA_MK3S_2m.gcode, owner: Andreas, user: Andreas
2022-03-18 21:42:44,844 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0, status_code=200, text={"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:42:44,845 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True
2022-03-18 21:42:44,894 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Starting"
2022-03-18 21:42:44,907 - octoprint.printer.standard.job - INFO - Print job started - origin: local, path: filler_0.2mm_PLA_MK3S_2m.gcode, owner: Andreas, user: Andreas
2022-03-18 21:42:44,953 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2022-03-18 21:42:44,970 - octoprint.util.comm - INFO - Changing monitoring state from "Starting" to "Printing"
2022-03-18 21:42:45,260 - octoprint.plugins.tracking - INFO - Sent tracking event print_started, payload: {'origin': 'local', 'file': 'e48134b4454eb9504b8eacd02622ec58caf9456d'}
2022-03-18 21:42:45,450 - octoprint.filemanager.analysis - INFO - Analysis of entry local:filler_0.2mm_PLA_MK3S_2m.gcode finished, needed 0.67s
2022-03-18 21:42:45,846 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...
2022-03-18 21:42:45,876 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0, status_code=200, text={"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:42:45,878 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True
2022-03-18 21:42:46,881 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...

Where you can find the file name four times. And this essential line is missing in the not-working-case:
2022-03-18 21:42:44,907 - octoprint.printer.standard.job - INFO - Print job started - origin: local, path: filler_0.2mm_PLA_MK3S_2m.gcode, owner: Andreas, user: Andreas

I added octoprint.printer.standard.job to the debug logging and deleted the files and restarted Octoprint and redid all the steps.

octoprint-logs_2.zip (74.5 KB)

But I cant see anything here either?!

8

Next test. I fired up the PSU several times and stopped the time it was like 7.9 / 8.4 / 8.6 secs until the printer was fully ready. So I set the delay to 9 secs.

Uploading and "starting" print via PrusaSlicer still does not work.

Now after hitting the button I see the Shelly switching on (and lights on the webcam) and after ~9 secs I can see the connection being made and the desired file is popping up in the files panel. But the print just wont start.

Might it be a problem with the sub plugin?

9

So I see two instances where a job was selected in this log and for both instances the plugin is showing the power supply as on and if that's the case then the plugin wouldn't switch anything on. Perhaps the issue isn't captured in this log file?

2022-03-18 21:40:13,549 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True
2022-03-18 21:40:13,549 - octoprint.plugins.psucontrol - DEBUG - PSU state changed, firing psu_state_changed event.
2022-03-18 21:40:13,788 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...
2022-03-18 21:40:13,845 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0, status_code=200, text={"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:40:13,847 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True
2022-03-18 21:40:13,859 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Detecting serial connection"
2022-03-18 21:40:13,883 - octoprint.util.comm - INFO - Serial detection: Performing autodetection with 7 port/baudrate candidates: /dev/ttyACM0@115200, /dev/ttyACM0@250000, /dev/ttyACM0@230400, /dev/ttyACM0@57600, /dev/ttyACM0@38400, /dev/ttyACM0@19200, /dev/ttyACM0@9600
2022-03-18 21:40:13,884 - octoprint.util.comm - INFO - Serial detection: Trying port /dev/ttyACM0, baudrate 115200
2022-03-18 21:40:13,885 - octoprint.util.comm - INFO - Connecting to port /dev/ttyACM0, baudrate 115200
2022-03-18 21:40:13,899 - octoprint.util.comm - INFO - Serial detection: Handshake attempt #1 with timeout 2.0s
2022-03-18 21:40:13,903 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2022-03-18 21:40:13,990 - octoprint.filemanager.analysis - INFO - Starting analysis of local:filler_0.2mm_PLA_MK3S_2m.gcode
2022-03-18 21:40:14,005 - octoprint.printer.standard.job - INFO - Print job selected - origin: local, path: filler_0.2mm_PLA_MK3S_2m.gcode, owner: Andreas, user: Andreas
2022-03-18 21:40:14,651 - octoprint.filemanager.analysis - INFO - Analysis of entry local:filler_0.2mm_PLA_MK3S_2m.gcode finished, needed 0.66s
2022-03-18 21:40:14,849 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...
2022-03-18 21:40:14,884 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0, status_code=200, text={"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:40:14,885 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True
2022-03-18 21:40:14,953 - octoprint.util.comm - INFO - Changing monitoring state from "Detecting serial connection" to "Operational"
2022-03-18 21:40:14,997 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2022-03-18 21:40:15,004 - octoprint.plugins.firmwareupdater - INFO - Got CONNECTED event
2022-03-18 21:40:15,008 - octoprint.plugins.firmwareupdater - INFO - Run postflash flag is not set
2022-03-18 21:40:15,887 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...
2022-03-18 21:40:15,917 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0, status_code=200, text={"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:40:15,918 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True

2022-03-18 21:42:42,733 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True
2022-03-18 21:42:43,737 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...
2022-03-18 21:42:43,765 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0, status_code=200, text={"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:42:43,765 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True
2022-03-18 21:42:44,773 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...
2022-03-18 21:42:44,782 - octoprint.filemanager.analysis - INFO - Starting analysis of local:filler_0.2mm_PLA_MK3S_2m.gcode
2022-03-18 21:42:44,788 - octoprint.printer.standard.job - INFO - Print job selected - origin: local, path: filler_0.2mm_PLA_MK3S_2m.gcode, owner: Andreas, user: Andreas
2022-03-18 21:42:44,844 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0, status_code=200, text={"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:42:44,845 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True
2022-03-18 21:42:44,894 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Starting"
2022-03-18 21:42:44,907 - octoprint.printer.standard.job - INFO - Print job started - origin: local, path: filler_0.2mm_PLA_MK3S_2m.gcode, owner: Andreas, user: Andreas
2022-03-18 21:42:44,953 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2022-03-18 21:42:44,970 - octoprint.util.comm - INFO - Changing monitoring state from "Starting" to "Printing"
2022-03-18 21:42:45,260 - octoprint.plugins.tracking - INFO - Sent tracking event print_started, payload: {'origin': 'local', 'file': 'e48134b4454eb9504b8eacd02622ec58caf9456d'}
2022-03-18 21:42:45,450 - octoprint.filemanager.analysis - INFO - Analysis of entry local:filler_0.2mm_PLA_MK3S_2m.gcode finished, needed 0.67s
2022-03-18 21:42:45,846 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...
2022-03-18 21:42:45,876 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0, status_code=200, text={"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:42:45,878 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True
2022-03-18 21:42:46,881 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...
2022-03-18 21:42:46,913 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0, status_code=200, text={"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:42:46,914 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True
10

You are citing log file _2 but the timestamps seam to be from the first one?

Anyway, first time might be better anyways.

And you skipped something important. First section you cited 6-9 lines above you can see PSU Control switching the PSU on:

2022-03-18 21:40:11,480 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: False
2022-03-18 21:40:12,487 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...
2022-03-18 21:40:12,516 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0, status_code=200, text={"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:40:12,516 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: False
2022-03-18 21:40:13,150 - octoprint.plugins.psucontrol - INFO - Switching PSU On
2022-03-18 21:40:13,150 - octoprint.plugins.psucontrol - DEBUG - Switching PSU On Using PLUGIN: psucontrol_shelly
2022-03-18 21:40:13,151 - octoprint.plugins.psucontrol_shelly - DEBUG - Switching PSU On
2022-03-18 21:40:13,186 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0?turn=on, status_code=200, text={"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:40:13,519 - octoprint.plugins.psucontrol - DEBUG - Polling PSU state...
2022-03-18 21:40:13,548 - octoprint.plugins.psucontrol_shelly - DEBUG - url=http://192.168.1.128/relay/0, status_code=200, text={"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"http"}
2022-03-18 21:40:13,549 - octoprint.plugins.psucontrol - DEBUG - isPSUOn: True

So thats the difference.
First occurrence: Power Off, PSU Control kicks in, print job selected but not started.
Second time: Power On, PSU not doing anything, print job selected AND started (octoprint.printer.standard.job - INFO - Print job started)

And thats my problem...

11

Okay, I think I kinda fixed it. But I am just a diy hacker so I wont yet post a pull request for it on github.

in psu-controlls __init__.py on line 508ff it says:

            time.sleep(0.1 + self.config['postOnDelay'])

            self.check_psu_state()

            if self.config['connectOnPowerOn'] and self._printer.is_closed_or_error():
                self._printer.connect()
                time.sleep(0.1)

But for me I am able to work with 0 delay here. So after turning on I just dont need no delay for OctoPrint to try to connect. (I guess it will keep trying for another kind of timeout or the like?)

But looking at the second time.sleep ... Thats where I need a little bit of delay!

Connecting to my prusa is just not done with an instant / fast enough for it to be able to trigger the start of a print right away.

So I changed it to:

            time.sleep(0.1)

            self.check_psu_state()

            if self.config['connectOnPowerOn'] and self._printer.is_closed_or_error():
                self._printer.connect()
                time.sleep(0.1 + self.config['postOnDelay'])

Now I can go down to 0.9 (so 1sec in total given the +0.1 in the code) for my post on Delay and it will just start the print after powering on the printer. Using 1.1 secs in the settings, so 1.2secs in total, as a 0.2sec safety margin for now.

So the solution to my problem is: I need no (addition / 0.1 sec?) for post-on-delay but I need another 1 sec post connect delay.

I dont wanna suppose anything at this point cos I dont know other printers and what you folks had in mind. You could just move it like I did (and rename it in the settings) or you could introduce a second option called "Post connect delay" (and place it right below the "connect when powered on" checkbox (and make it only visible when its active))

I guess you would be like 100times faster than me implementing it, but if you'd like and you'd be okay with my second proposal (adding another optino), I'd just edit the code and leave a pull request for you on github?!

12

Just opened a PR on gh. Dont know if I got everything right (extra branch, PR agains devel) but I hope so.

If there is something wrong you guys have a point to start with.

13

Whoops wrong quote reference. :slight_smile:

The only thing I can think of that would make a delay after connect work is if your controller takes a while to get to a good state after connecting. Though I think I would have seen something by now since Prusa is pretty common.

To be honest the print on upload isn't the best implementation (relying on delays sucks) and I believe @oerkel47 might have something better in their fork. Would you be willing to see if that works for you?

https://github.com/oerkel47/OctoPrint-PSUControl/archive/refs/heads/master.zip

If so be sure to set postOnDelay back to zero.

14

Hey, thanks for the shoutout. The master branch was not up to date at this time, but I pulled the correct branch into master now. If anyone downloaded in the meantime, please update.

Yes I added some things and improved others (at least from my pov). Changelog should be as follows:

  • printer connection after turn on will be tried until it works or a timeout occurs

    • it will look a little funny in the ui as it will basically spam connect command
    • in a non blocking way (no system hang)
    • files should be printed in any succesful case

  • (if enabled in options) will react (connect) if externally turned on (manual control of relay)

  • It will start printing every time a file with print command comes in from the slicer

    • before this wasn't the case if printer was on but unconnected.

Not sure if the implementation is flawless, but I am using it and it appears to work as intended.

15

Especially the last point sounds good, cos printer on but not connected would be the last thing to fix for getting files to print right away in any case when coming in with print command from the slicer.

But with the connect when powered on externally the only way it would be on but not connected would be if I disconnected it myself. And one could argue that you would do this on purpose.

So it would not be that likely but anyway, sounds like its a kinda fool proof "fire and forget" thing to print things directly from the slicer. I like that!

I reviewed the code from oerkel and it looks good but I still got some points I didnt understand at first read and need to read through again. I guess I wont find time to do so within the next days / week.

I might also just give it a try. Gonna give feedback on that if I did. Meanwhile I am keeping the printer busy what makes fiddling around with octoprint a bit harder ... :wink:

16

Would it be possible to implement the delay in the "Post On GCode Script"? Or even run shell commands from "Post On GCode Script".

FIRMWARE_RESTART
DELAY 15s
G28
17

This is a Klipper specific script, which wouldn't work for the OP. The concept may be useful - the gcode for a delay like that is G4.

1 Like
18

The problem with sending a G4 is that the printer isn't ready yet. I'm not looking for a delay on the printer, I'm suggesting a local delay in the PSU Controller "Post On GCode Script"

You can see where the "Post on GCode Script" keeps sending G Codes even though the printer is not ready yet.

Send: RESPOND TYPE=command MSG=action:poweroff
Recv: // action:poweroff
Recv: ok
Connection closed, closing down monitor
Changing monitoring state from "Operational" to "Offline"
Changing monitoring state from "Offline" to "Detecting serial connection"
Performing autodetection with 7 port/baudrate candidates: /tmp/printer@115200, /tmp/printer@250000, /tmp/printer@230400, /tmp/printer@57600, /tmp/printer@38400, /tmp/printer@19200, /tmp/printer@9600
Trying port /tmp/printer, baudrate 115200
Connecting to port /tmp/printer, baudrate 115200
Handshake attempt #1 with timeout 2.0s
Connected to: Serial<id=0x695e0db0, open=True>(port='/tmp/printer', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Recv: // Lost communication with MCU 'mcu'
Recv: // Once the underlying issue is corrected, use the
Recv: // "FIRMWARE_RESTART" command to reset the firmware, reload the
Recv: // config, and restart the host software.
Send: N0 M110 N0*125
Changing monitoring state from "Detecting serial connection" to "Operational"
Send: N0 M110 N0*125
Recv: // Printer is shutdown
Recv: !! Lost communication with MCU 'mcu'
Recv: ok
Recv: ok
Recv: ok
Send: N1 M115*39
Recv: ok FIRMWARE_VERSION:v0.10.0-320-g7e654aed FIRMWARE_NAME:Klipper
Send: M21
Recv: ok
Send: FIRMWARE_RESTART
Recv: ok
Recv: // Klipper state: Disconnect
Send: G4 P1000
Recv: // Printer is not ready
Recv: // The klippy host software is attempting to connect.  Please
Recv: // retry in a few moments.
Recv: !! Printer is not ready
Recv: ok
Send: G28
Recv: // Printer is not ready
Recv: // The klippy host software is attempting to connect.  Please
Recv: // retry in a few moments.
Recv: !! Printer is not ready
Recv: ok
Recv: // Klipper state: Ready
19

Like Charlie said, wouldnt be a fix for me as the printer is not connected and gcodes cant be send at that point.

To me I didnt need a post on delay but a post connect delay. See my post above:

After moving the delay to after connecting everything worked just fine.

20

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.