search

colinrgodsey / step-daemon

stepd - External planner and stepper for 3d printing
GNU General Public License v3.0
98 stars 8 forks source link

panic: Failed to load device settings #11

Open lav8org opened 3 years ago

lav8org commented 3 years ago

Setup: attempting to run from linux command line. Printer control board is a BTT skr 1.3 with Marlin 2.0.7.2 (latest), direct stepping and advanced ok enabled, buffer size increased to fit advanced ok, and page format verified to match config. The board communicates fine with Repetier, Pronterface, and a direct serial connection (user is a member of the dialout group).

Problem:

info:generating bed level function...
info:config processed
info:bed level z-func loaded
panic: Failed to load device settings
(stack trace w/o surprises)
exit status 2

Gut suspicion: the timeout may be because the response isn't as expected? Scanning config_handler.go I saw mentions of M501, but I don't have EEPROM enabled--it hasn't proven necessary, but more importantly the board becomes unresponsive when flashed with the option enabled.

FWIW: my application is a plotter/engraver that only uses X Y Z axes, no E or heaters. But despite that reduced complexity, it makes many tiny moves and has feedrate/accel sufficient to overwhelm the planner.

Unrelated: users installing go for the first time might also want to know that after installing the language they should point a shell at the step-daemon dir and issue "go install". I can attest that to the golang naive the error messages without that step look like a private build was published with static resource paths and unprovided dependencies. Took me a bit to work that out. If the go syntax didn't look so foreign I'd probably be slightly more useful above...

(edit: read the readme again and caught that bed leveling is explicitly denoted optional, so that probably isn't the issue. Unless there's a config flag that needs to be set?)

lav8org commented 3 years ago

I've got the board operating with EEPROM enabled (idk which intermediate change mattered, but the occasional self solving problem is alright). 19:51:30.745 : N13 M504*16 19:51:30.748 : DIGIPOTS Loading 19:51:30.748 : DIGIPOTS Loaded 19:51:30.750 : echo:EEPROM OK I noticed the hard coded confEnd= "echo:; PID settings:" and tried changing that to something that would appear in M503 as well as re-flashing with n extruders = 1 and a dummy thermistor so that "PID settings:" would show (aside: in Marlin PIDTEMP enabled in conf is not sufficient for M301 and etc). Neither resulted in progress/successful device setting load. Might have to try harder to get a handle on the flow of the go code, running out of dark places to stab...

lav8org commented 3 years ago

maybe I just haven't grokked the design patterns yet, but the concurrency and channels of go really don't make it easy to trace the logic of a program a priori! What I can say is that func (h *cfHandler) tailRead(msg io.Any) just gets some of the status messages above, and then nothing. Seems like whatever routine responsible for getting gcode lines to checkConfig isn't.

colinrgodsey commented 3 years ago

the section of code that consumes the config settings here is pretty brittle and needs to be changed. what you be able to get me the full response from the M503 on your device? definitely curious to see where the output differs with your settings

lav8org commented 3 years ago

doable! M503:

[18:36:14:958] echo:  G21    ; Units in mm (mm)␊
[18:36:14:979] ␊
[18:36:14:979] echo:; Steps per unit:␊
[18:36:14:979] echo: M92 X94.1020 Y63.2240 Z14.9260 E1.0000␊
[18:36:14:979] echo:; Maximum feedrates (units/s):␊
[18:36:14:979] echo:  M203 X833.0000 Y833.0000 Z833.0000 E10000.0000␊
[18:36:14:979] echo:; Maximum Acceleration (units/s2):␊
[18:36:14:979] echo:  M201 X10000.0000 Y10000.0000 Z10000.0000 E10000.0000␊
[18:36:14:979] echo:; Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>␊
[18:36:14:979] echo:  M204 P10000.0000 R10000.0000 T10000.0000␊
[18:36:14:979] echo:; Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> J<junc_dev>␊
[18:36:14:979] echo:  M205 B0.0000 S1.0000 T1.0000 J0.0010␊
[18:36:14:979] echo:; Home offset:␊
[18:36:14:979] echo:  M206 X0.0000 Y0.0000 Z0.0000␊
[18:36:14:979] echo:; Stepper driver current:␊
[18:36:14:979] echo:  M906 X900 Y900 Z300␊
[18:36:14:979] ␊
[18:36:14:979] echo:; Hybrid Threshold:␊
[18:36:14:979] echo:  M913 X30 Y30 Z20␊
[18:36:14:979] ␊
[18:36:14:979] echo:; StallGuard threshold:␊
[18:36:14:979] echo:  M914 Y2␊
[18:36:14:979] echo:; Driver stepping mode:␊
[18:36:14:979] echo:  M569 S1 X Y Z␊
[18:36:14:979] ok P15 B3␊

M906-M569 are specific to Trinimic drivers. Extruders has been set back to 0. EEPROM is still enabled, M501 and M504:

[18:44:35:452] ok P15 B3␊
[18:46:19:922] echo:EEPROM OK␊
[18:46:19:923] ok P15 B3␊

edit: more specifically I'm pretty sure EEPROM is still enabled, but I do not know with the level of certainty that comes with recently rebuilding and flashing the firmware

TilBlechschmidt commented 3 years ago

I'd like to join the discussion! Running into the same issue.

Hardware

M503 output

echo:  G21    ; Units in mm (mm)
echo:  M149 C ; Units in Celsius

echo:; Filament settings: Disabled
echo:  M200 S0 D1.75
echo:; Steps per unit:
echo: M92 X80.00 Y80.00 Z400.00 E93.00
echo:; Maximum feedrates (units/s):
echo:  M203 X500.00 Y500.00 Z5.00 E25.00
echo:; Maximum Acceleration (units/s2):
echo:  M201 X1000.00 Y1000.00 Z1000.00 E5000.00
echo:; Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo:  M204 P500.00 R500.00 T500.00
echo:; Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> J<junc_dev>
echo:  M205 B20000.00 S0.00 T0.00 J0.08
echo:; Home offset:
echo:  M206 X0.00 Y0.00 Z0.00
echo:; Auto Bed Leveling:
echo:  M420 S0 Z0.00
echo:  G29 W I0 J0 Z-0.00000
echo:  G29 W I1 J0 Z-0.00000
echo:  G29 W I2 J0 Z-0.00000
echo:  G29 W I0 J1 Z-0.00000
echo:  G29 W I1 J1 Z0.00000
echo:  G29 W I2 J1 Z-0.00000
echo:  G29 W I0 J2 Z-0.00000
echo:  G29 W I1 J2 Z-0.00000
echo:  G29 W I2 J2 Z-0.00000
echo:; Material heatup parameters:
echo:  M145 S0 H215 B60 F255
echo:  M145 S1 H250 B70 F255
echo:; PID settings:
echo:  M301 P21.73 I1.54 D76.55
echo:; Filament load/unload lengths:
echo:  M603 L0.00 U0.00
ok P7 B3

What happens?

When I start the program it prints the same output as the original post and then just exits with a panic. Stdout and error, GCode and Marlin configs are appended. Command line is shown below. Let me know if there is anything I can test or there is some more information I can provide 🙂 

cat FilamentClip.gcode | go run main.go trace device=/dev/cu.usbserial-141240 baud=500000 config=./config.hjson 2> stderr.txt 1> stdout.txt

CLI Output without trace option

info:generating bed level function...
info:config processed
info:bed level z-func loaded
// Some seconds of delay
panic: Failed to load device settings

goroutine 8 [running]:
github.com/colinrgodsey/step-daemon/pipeline.ConfigHandler.func1(0xc00007a480, 0xc00007a420, 0xc00007a4e0, 0xc00007a540)
    /Users/themegatb/Downloads/step-daemon/pipeline/config_handler.go:155 +0x527
created by main.handler
    /Users/themegatb/Downloads/step-daemon/main.go:38 +0xa5
exit status 2

FilamentClip.gcode.txt

stderr.txt stdout.txt

Config files.zip

colinrgodsey commented 3 years ago

Should have an update for this shortly, thanks for the patience!

colinrgodsey commented 3 years ago

Just posted a new commit that changes what it looks for as the 'terminator' of the config response. This still needs to be reworked further to perhaps just wait until it gets the core configuration it needs, but for now this looks for the "Advanced: ..." line from the config response which should be universal. But for now, this should allow all marlin devices to pass the config sync section.

lav8org commented 3 years ago

nw, at this price point I can be very patient :grin: I just tried it and still get the panic. Running main.go from shell. Double checked things on the top of my head: not using old source, M503 does contain trigger string. IDK if it's noteworthy since the serial lib might be autocorrecting, but fwiw the first time I used the wrong baud rate and still made it to the settings panic. Minor quibble: the default path for default config.hjson is no longer correct

colinrgodsey commented 3 years ago

oh right, i did change the format of the arguments now: if you do stepd --help it should show you, they're the same but you have to append with '-'. also, could you get me a copy of the new output?

lav8org commented 3 years ago 
cat ~/workspace/plot\ optimizer/lnwidth.gcode | ../bin/stepd -device /dev/ttyACM0 -baud 115200 | grep -v "ok"
info:generating bed level function...
info:config processed
info:bed level z-func loaded
panic: Failed to load device settings

goroutine 21 [running]:
github.com/colinrgodsey/step-daemon/lib/pipeline.ConfigHandler.func1(0xc0000b4480, 0xc0000b4420, 0xc0000b44e0, 0xc0000b4540)
        /home/cole/workspace/goprojects/step-daemon-master/lib/pipeline/config_handler.go:158 +0x527
created by main.handler
        /home/cole/workspace/goprojects/step-daemon-master/cmd/stepd/main.go:41 +0xa5

(switched from running main.go to stepd)

colinrgodsey commented 3 years ago

hmm... it looks like it's not getting any data from the printer at all. there should usually be some announce from marlin on startup, something like:

info:generating bed level function...
info:config processed
info:bed level z-func loaded
echo:start
Marlin 2.0.7.2
echo: Last Updated: 2020-10-15 | Author: 
echo:Compiled: Jan 18 2021
echo: Free Memory: 684  PlannerBufferBytes: 1232
echo:EEPROM version mismatch (EEPROM=V79 Marlin=V82)
echo:Hardcoded Default Settings Loaded
info:gathering device settings
info:stepd initialized
pages_ready

The gathering device settings line is when it actually requests the config, and it doesnt look like its getting that far. Stepd generally waits until it sees pages_ready from the device before it starts doing much. Are you using any other configs that may suppress some of the output from Marlin?

lav8org commented 3 years ago

Nothing special that I'm aware of. When I do a direct serial connection there's no announce and Repetier-Host always logs "No start signal detected - forcing start" I tried looking into it in the past but didn't find anything. Maybe a quirk of using a HAL to port to ARM (blind guess)?

colinrgodsey commented 3 years ago

Oh interesting- I bet its something with the restart signal. Does the marlin device restart when stepd connects?

lav8org commented 3 years ago

I don't think so? Not sure how best to check, I just turned on a fan and then disconnected and ran stepd and the fan didn't stop.

colinrgodsey commented 3 years ago

Ah, yea sounds like its not respecting the restart. I think I can probably add something similar, where if it doesnt hear from the device for a second or so, it'll just continue.

lav8org commented 3 years ago

Repetier follows that with an M115 fwiw

colinrgodsey commented 3 years ago

Just pushed a new commit- stepd should start anyways if it doesnt see the pages_ready message after a few seconds.

lav8org commented 3 years ago

looked like it didn't work but apparently bash silently updated paths when modified in the UI... wouldn't have had any idea unless the stack trace had "trash" in it.

Unfortunately not the end of the problems!

no page_ready seen, sending anyways
info:gathering device settings
info:stepd initialized
pages_ready
echo:  G21    ; Units in mm (mm)
echo:; Steps per unit:
echo: M92 X94.1020 Y63.2240 Z119.4080 E1.0000
info:max vel (step limit) is [1958.7256381373404 2915.348601796786 1543.6151681629372 184320]
echo:; Maximum feedrates (units/s):
echo:  M203 X833.0000 Y833.0000 Z833.0000 E10000.0000
echo:; Maximum Acceleration (units/s2):
echo:  M201 X10000.0000 Y10000.0000 Z10000.0000 E10000.0000
echo:; Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo:  M204 P10000.0000 R10000.0000 T10000.0000
info:finished gathering device settings
echo:; Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> J<junc_dev>
info:syncing with device position
echo:  M205 B0.0000 S1.0000 T1.0000 J0.0010
echo:; Home offset:
echo:  M206 X0.0000 Y0.0000 Z0.0000
echo:; Stepper driver current:
echo:  M906 X600 Y600 Z300
echo:; Hybrid Threshold:
echo:  M913 X30 Y30 Z2
echo:; StallGuard threshold:
echo:  M914 Y2
echo:; Driver stepping mode:
info:syncd with device position
info:setting to absolute coords
info:skipped move with 0 feedrate
debug:failed block: Trapezoid(head: Trapezoid(head: Pulse(dy: 856036.0415587845, area: 14014.74935295355), tail: Pulse(dy: -856036.0415587845, area: -14014.74935295355), area: 1.4855280471424592, c: 0), tail: Trapezoid(head: Pulse(dy: -856036.0415587845, area: -14014.74935295355), tail: Pulse(dy: 856036.0415587845, area: 14014.74935295355), area: -1.4855280471424592, c: 0), area: 0.3300094695611023, c: 0)
warn:failed to apply s-curve easing
debug:failed block: Trapezoid(head: Trapezoid(head: Pulse(dy: 162183.5440034681, area: 10604.308646380678), tail: Pulse(dy: -162183.5440034681, area: -10604.308646380678), area: 0.9507379501711739, c: 0), tail: Trapezoid(head: Pulse(dy: -162183.5440034681, area: -10604.308646380678), tail: Pulse(dy: 162183.5440034681, area: 10604.308646380678), area: -0.9507379501711739, c: 0), area: 0.2003902442735174, c: 0)
warn:failed to apply s-curve easing
debug:failed block: Trapezoid(head: Trapezoid(head: Pulse(dy: 223262.5222605769, area: 11163.126113028777), tail: Pulse(dy: -223262.5222605769, area: -11163.126113028777), area: 0.9507379501711739, c: 0), tail: Trapezoid(head: Pulse(dy: -223262.5222605769, area: -11163.126113028777), tail: Pulse(dy: 223262.5222605769, area: 11163.126113028777), area: -0.9507379501711739, c: 0), area: 0.20155644370746384, c: 0)
warn:failed to apply s-curve easing
debug:failed block: Trapezoid(head: Trapezoid(head: Pulse(dy: 162183.5440034703, area: 10604.3086463807), tail: Pulse(dy: -162183.5440034703, area: -10604.3086463807), area: 0.9507379501711739, c: 0), tail: Trapezoid(head: Pulse(dy: -162183.5440034703, area: -10604.3086463807), tail: Pulse(dy: 162183.5440034703, area: 10604.3086463807), area: -0.9507379501711739, c: 0), area: 0.20039024427351743, c: 0)
warn:failed to apply s-curve easing
debug:failed block: Trapezoid(head: Trapezoid(head: Pulse(dy: 679999.9999999988, area: 13999.999999999996), tail: Pulse(dy: -679999.9999999988, area: -13999.999999999996), area: 1.1884224377139674, c: 0), tail: Trapezoid(head: Pulse(dy: -679999.9999999988, area: -13999.999999999996), tail: Pulse(dy: 679999.9999999988, area: 13999.999999999996), area: -1.1884224377139674, c: 0), area: 0.24999999999999964, c: 0)
warn:failed to apply s-curve easing
debug:failed block: Trapezoid(head: Trapezoid(head: Pulse(dy: 680000.0000000008, area: 14000.000000000004), tail: Pulse(dy: -680000.0000000008, area: -14000.000000000004), area: 1.1884224377139674, c: 0), tail: Trapezoid(head: Pulse(dy: -680000.0000000008, area: -14000.000000000004), tail: Pulse(dy: 680000.0000000008, area: 14000.000000000004), area: -1.1884224377139674, c: 0), area: 0.25000000000000017, c: 0)
warn:failed to apply s-curve easing
debug:failed block: Trapezoid(head: Trapezoid(head: Pulse(dy: 223262.52226057468, area: 11163.126113028757), tail: Pulse(dy: -223262.52226057468, area: -11163.126113028757), area: 0.9507379501711739, c: 0), tail: Trapezoid(head: Pulse(dy: -223262.52226057468, area: -11163.126113028757), tail: Pulse(dy: 223262.52226057468, area: 11163.126113028757), area: -0.9507379501711739, c: 0), area: 0.2015564437074639, c: 0)
warn:failed to apply s-curve easing
debug:failed block: Trapezoid(head: Trapezoid(head: Pulse(dy: 393722.9909394496, area: 12527.549711709764), tail: Pulse(dy: -393722.9909394496, area: -12527.549711709764), area: 1.1884224377139674, c: 0), tail: Trapezoid(head: Pulse(dy: -393722.9909394496, area: -12527.549711709764), tail: Pulse(dy: 393722.9909394496, area: 12527.549711709764), area: -1.1884224377139674, c: 0), area: 0.20953818267800278, c: 0)
warn:failed to apply s-curve easing
debug:failed block: Trapezoid(head: Trapezoid(head: Pulse(dy: 282575.7537436161, area: 11671.60721984506), tail: Pulse(dy: -282575.7537436161, area: -11671.60721984506), area: 0.9507379501711739, c: 0), tail: Trapezoid(head: Pulse(dy: -282575.7537436161, area: -11671.60721984506), tail: Pulse(dy: 282575.7537436161, area: 11671.60721984506), area: -0.9507379501711739, c: 0), area: 0.20348525745124602, c: 0)
warn:failed to apply s-curve easing
echo:Unknown command: "!"
warn:pending OK count dropped below 0
echo:Unknown command: "!"
warn:pending OK count dropped below 0
echo:Unknown command: "!"
warn:pending OK count dropped below 0
echo:Unknown command: ""
warn:pending OK count dropped below 0
warn:pending OK count dropped below 0
echo:Unknown command: "!

                        "
warn:pending OK count dropped below 0
echo:Unknown command: "!"
warn:pending OK count dropped below 0
warn:pending OK count dropped below 0
warn:pending OK count dropped below 0
echo:Unknown command: ""
warn:pending OK count dropped below 0
echo:Unknown command: "!R"
warn:pending OK count dropped below 0
warn:pending OK count dropped below 0
warn:pending OK count dropped below 0
echo:Unknown command: "!"
warn:pending OK count dropped below 0
echo:Unknown command: "!O"
warn:pending OK count dropped below 0
echo:Unknown command: "!"
warn:pending OK count dropped below 0
echo:Unknown command: "!"
warn:pending OK count dropped below 0
echo:Unknown command: "!"
warn:pending OK count dropped below 0

At which point it just hung. Carriage did move a bit.

I'm going to guess that stepd doesn't have all the gcode parse features of Marlin like cnc move mode (remembers last command type, uses for next line if no cmd), remembers F/feed rate/"flow" for g1 and g0 (if enabled), and accepts lower case?

Edit: actually for the test file I ran the only feature used of the above is stored F Edit2: including F with every move didn't help. It seems to crash immediately after sensorless homing... maybe it needs to wait to start direct stepping? I'm not sure why but it runs Z up a bit before homing Y (or at least Y going to 0)... is this homing independent of Marlin? Gcode preface:

M106
G28 Y Z; home axes
;G92 X1 Y0 Z0; in case host has stored coords from manual positioning (works?)
G90 ; set coordinates to absolute
M569 S0 X Y Z ; disable stealthstep
;M906 X600 Y600 ;  set motor current, defaults in fw
;M83 ; set extruder coord to relative
G1 Y20 X0 Z0 90000; machine home offsets for pinch wheel margin, endstop switch clearance 
G92 X0 Y0 Z0; set these axes to 0 now to preserve as new basis
M121 ; disable endstops, reqd due to x axis hack (infinite axis)
M203 X750 Y750 ; max feed mm/s
;M204 S9000 ; start accel P+T
;M201 X9000 Y9000 ; max print accel
;G0 F90000 set move feed rate to max (mm/min) (default set in firmware)
G1 X0 Y0 Z0 F90000 ; 2*max axis feed so diagonal moves are at max
;G5 F2000 ;bezier, but g1+ sets speed for all? doc says this one takes mm/s but it doesn't smh
;print start here
G0 X0.000000 Y0.000000

(just noticed missing F on the first G1, investigating)

colinrgodsey commented 3 years ago

It should carry over the last used args for the G1/0 commands. I've tested mostly with g-code produced by slic3r, but I really should test with a few other slicers.

The commands starting with '!' are part of the multiplexed protocol for page access. Judging by the fact that this is an arm board... i think there's probably something missing in the HAL for the serial handling here. I've been meaning to get one of these boards for testing anyway, so... might need to get another patch in Marlin for ARM boards soon.

Just to confirm, DIRECT_STEPPING is enabled in the marlin config?

lav8org commented 3 years ago

DIRECT_STEPPING is enabled. Although I have discovered that since enabling EEPROM some settings in FW are not updated when flashed/overridden by previous settings until manually saved to EEPROM, but don't see how that would be an issue since there's no command to set DIRECT_STEPPING. I'll build w/o EEPROM and see.

Also contrary to above the Z run up this time was after Y home; not sure if my memory tricked me or etc.

lav8org commented 3 years ago

Just fyi I'm not using a slicer at all, my code generates gcode directly to be used by an engraver... definitely violates 3D printing related assumptions in other software out there, especially monotonic Z, everything E related, and arc/beziers, but fortunately most persevere without catastrophic results.

FW w/o EEPROM, same outcome. Ran without grep, there are some oks sprinkled between failed blocks. Same home behavior.

Happy to provide dev hardware if you're not picky, just PM your address.

colinrgodsey commented 3 years ago

Ah right, just reread your use case- engraver! So for G0/1 we carry over... feedrate and position between commands, and that should work for relative or absolute movements. So I think that should be good judging by the above gcode. Bezier curves still need to be implemented though.

I was looking to test out a smoothieboard anyways for my 3d printer setup, so this gives me a good excuse. I ordered the v1.4, should be here before the weekend. It really shouldn't be hard to get working i think- just need to dive into how the HAL differs at the serial level. We'll see if thats enough, hopefully wont need to ship anything special :)

colinrgodsey commented 3 years ago

@lav8org I got really close to getting this working, but ended up getting hit with a complicated housing situation. Had a bit more info here: https://github.com/colinrgodsey/step-daemon/issues/17#issuecomment-809751746

I should be coming back to this as soon as I can.

cetemadi commented 2 years ago

@colinrgodsey Hope everything is going okay with your housing situation! I'm happy to help out with testing if I can. I have a 32-bit Creality v4.2.7 board and seeing similar issue. Seems like it's hitting a serial error where it connects and disconnects with that UnicodeDecodeError, and then it eventually hits the same panic:

2021-12-27 02:53:34,286 - octoprint.plugins.stepd - INFO - Checking for stepd updates...
2021-12-27 02:53:34,291 - octoprint.plugins.themeify - INFO - Themeify initialized.
2021-12-27 02:53:34,293 - octoprint.plugins.stepd - INFO - Initializing new install
2021-12-27 02:53:34,316 - octoprint.plugins.stepd - INFO - Init stepd at /home/pi/.octoprint/data/stepd/repo
2021-12-27 02:53:35,254 - octoprint.plugins.pluginmanager - INFO - Loaded notice data from disk, was still valid
2021-12-27 02:53:35,260 - octoprint.server.preemptive_cache - INFO - Preemptively caching / (ui _default) for {'base_url': 'http://octopi.local/', 'path': '/', 'query_string': 'l10n=en'}
2021-12-27 02:53:38,872 - octoprint.plugins.stepd - INFO - Remote at e83868b1c9ab556c91b6f22f7de85e377d853b2a, local was at e83868b1c9ab556c91b6f22f7de85e377d853b2a
2021-12-27 02:53:38,873 - octoprint.plugins.stepd - INFO - Changes detected, triggering build...
2021-12-27 02:54:22,480 - octoprint.server.preemptive_cache - INFO - ... done in 35.96s
2021-12-27 02:54:27,320 - octoprint.plugins.stepd - INFO - GO: 
2021-12-27 02:54:27,320 - octoprint.plugins.stepd - INFO - GO: 
2021-12-27 02:54:27,322 - octoprint.plugins.stepd - INFO - Copying bin to /home/pi/.octoprint/data/stepd/stepd
2021-12-27 02:54:27,352 - octoprint.plugins.stepd - INFO - Update complete!
2021-12-27 02:54:27,458 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Opening serial connection"
2021-12-27 02:54:27,502 - octoprint.plugins.stepd - INFO - Starting service: ['/home/pi/.octoprint/data/stepd/stepd', '-device', '/dev/ttyUSB0', '-baud', '115200', '-config', 'config.json']
2021-12-27 02:54:27,521 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial connection" to "Connecting"
2021-12-27 02:54:27,533 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-12-27 02:54:27,540 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-12-27 02:54:29,047 - octoprint.util.comm - ERROR - Unexpected error while reading from serial port
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/util/comm.py", line 3940, in _readline
    ret = self._serial.readline()
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_stepd/StepdService.py", line 40, in readline
    data = self.process.stdout.readline()
  File "/home/pi/oprint/lib/python3.7/codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 33: invalid start byte
2021-12-27 02:54:29,061 - octoprint.util.comm - INFO - Changing monitoring state from "Connecting" to "Offline after error"
2021-12-27 02:54:29,066 - octoprint.plugins.action_command_notification - INFO - Notifications cleared
2021-12-27 02:54:29,067 - octoprint.plugins.stepd - INFO - GO: 
2021-12-27 02:54:29,078 - octoprint.plugins.stepd - INFO - service terminated
2021-12-27 02:54:49,265 - octoprint.server.util.sockjs - INFO - New connection from client: 2601:641:4000:efc0:6468:8b9e:354a:f04f
2021-12-27 02:54:49,430 - octoprint.server.util.flask - INFO - Passively logging in user admin from 2601:641:4000:efc0:6468:8b9e:354a:f04f
2021-12-27 02:54:49,432 - octoprint.access.users - INFO - Logged in user: admin
2021-12-27 02:54:49,643 - octoprint.server.util.sockjs - INFO - User admin logged in on the socket from client 2601:641:4000:efc0:6468:8b9e:354a:f04f
2021-12-27 02:54:53,997 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Opening serial connection"
2021-12-27 02:54:54,060 - octoprint.plugins.stepd - INFO - Starting service: ['/home/pi/.octoprint/data/stepd/stepd', '-device', '/dev/ttyUSB0', '-baud', '115200', '-config', 'config.json']
2021-12-27 02:54:54,090 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial connection" to "Connecting"
2021-12-27 02:54:54,113 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-12-27 02:54:54,117 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-12-27 02:55:00,126 - octoprint.util.comm - INFO - Changing monitoring state from "Connecting" to "Operational"
2021-12-27 02:55:00,160 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-12-27 02:55:00,279 - octoprint.util.comm - ERROR - Unexpected error while reading from serial port
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/util/comm.py", line 3940, in _readline
    ret = self._serial.readline()
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_stepd/StepdService.py", line 40, in readline
    data = self.process.stdout.readline()
  File "/home/pi/oprint/lib/python3.7/codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 53: invalid start byte
2021-12-27 02:55:00,287 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Offline after error"
2021-12-27 02:55:00,291 - octoprint.plugins.stepd - INFO - GO: 
2021-12-27 02:55:00,297 - octoprint.plugins.action_command_notification - INFO - Notifications cleared
2021-12-27 02:55:00,305 - octoprint.plugins.stepd - INFO - service terminated
2021-12-27 02:55:32,016 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Opening serial connection"
2021-12-27 02:55:32,073 - octoprint.plugins.stepd - INFO - Starting service: ['/home/pi/.octoprint/data/stepd/stepd', '-device', '/dev/ttyUSB0', '-baud', '115200', '-config', 'config.json']
2021-12-27 02:55:32,111 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial connection" to "Connecting"
2021-12-27 02:55:32,128 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-12-27 02:55:32,137 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-12-27 02:55:38,120 - octoprint.util.comm - INFO - Changing monitoring state from "Connecting" to "Operational"
2021-12-27 02:55:38,138 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2021-12-27 02:55:47,107 - octoprint.plugins.stepd - INFO - GO: panic: Failed to load device settings
2021-12-27 02:55:47,108 - octoprint.plugins.stepd - INFO - GO: 
2021-12-27 02:55:47,305 - octoprint.plugins.stepd - INFO - ERR: goroutine 22 [running]:
2021-12-27 02:55:47,572 - octoprint.plugins.stepd - INFO - ERR: github.com/colinrgodsey/step-daemon/lib/pipeline.ConfigHandler.func1(0x207d780, 0x207d700, 0x207d800, 0x207d840)
2021-12-27 02:55:47,572 - octoprint.plugins.stepd - INFO - ERR: /home/pi/.octoprint/data/stepd/repo/lib/pipeline/config_handler.go:178 +0x358
2021-12-27 02:55:47,572 - octoprint.plugins.stepd - INFO - ERR: created by main.handler
2021-12-27 02:55:47,573 - octoprint.plugins.stepd - INFO - ERR: /home/pi/.octoprint/data/stepd/repo/cmd/stepd/main.go:41 +0x78
2021-12-27 02:55:47,581 - octoprint.util.comm - ERROR - Unexpected error while reading from serial port
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/util/comm.py", line 3940, in _readline
    ret = self._serial.readline()
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_stepd/StepdService.py", line 40, in readline
    data = self.process.stdout.readline()
ValueError: I/O operation on closed file