I'm out of town until next week but I will plug it into the pi again and see what the logs say. I'll also open it up and inspect that it's not a wiring issue. I did a small print off an ssd before I left and it seemed fine.
Ran into the same issue. Brand new Workhorse, plug in Octoprint, click connect. Workhorse (Marlin) resets, and hotend temp is set to a random high temp.
Shut everything down. Started the Pi, when it finished booting and tried to automatically connect to the printer (presumably), the printer reset and came up with a hotend temp over 300 degrees.
Luckily I was watching it because a friend just got the exact same setup and ran into the exact same issue.
I don't notice anything interesting in the logs, except that the Pi is undervolted. I'll find a larger PSU and try again, although this same setup has been working fine on a Lulzbot Mini for months. If there are any loglevels I should change, any information would be appreciated.
Not sure if the issue is with Octoprint or on the Marlin side, but there should be no reason this thing should try and immolate itself.
I got distracted a couple months back and did not follow up with the log files (and I had to replace some of the melted parts). There's a guy on the LulzBot forum using octoprint with his workhorse and I just asked if he could share his settings.
On an unrelated note, I've had a really tough time getting results out of the workhorse and I don't seem alone in my experience. Had I known the issues in advance I wouldn't have bought it and if I had the option to return it I would do it in a second.
If I get some information on the settings I will return here. Thanks!
Regardless, whatever is happening here, it's something that's happening (or not happening) on the serial communication with the printer. So in order to figure out what exactly is making the firmware think it's supposed to heat up, we'll need to see what's going on between the two. Hence my request for a serial.log of the whole communication because that will contain the whole story of what goes on between OctoPrint and the printer. Mind you, it might also reveal that nothing out of the ordinary is going on, in which case the problem lies somewhere in how the firmware on your printer handles serial input.
Looks like that page on the forum got taken down, probably because people were being honest about how poorly made the Workhorses are. It was still open on a browser so I took a snapshot and removed the user for privacy.
That being said, I appreciate that you are able to help. I will find time today to plug a new octopi into the workhorse and get you a serial log. Thank you!
I've also had this issue (being the friend that @mhenstell was mentioning earlier), however, it was after I started using a supply over 2A (whatever two lightning bolts on a power strip means to amazon) so it's probably not related to the undervoltage.
I have the octoprint.log but unfortunately didn't have serial.log enabled. My issue happened on the 14th at the end of the day. After the black smoke, I reverted to using octoprint as just a webcam. You will likely not see any new info in my log but here it is.
I have enable serial logs and will try to replicate today, as well.
@mbaio - what melted parts did you have to replace? can you provide info on that?
One more question for the community as this is the first time I've attempted to use OctoPrint.. Is it normal for 3D printers to reset once connection is established?
Okay, I demoed the issue again and the same thing occurred. I made a 2 minute video of the issue, as well. Serial.log, octoprint.log and video attached.
Thanks for what you've created @foosel. Very much looking forward to using Octoprint when we work through this issue.
4/20 @12:43pm EST:
Thanks @foosel - I'll test today without the card and reply with logs and results. New forum users can only reply three times on a single thread, so I had to edit this comment to say so. It's like a reverse Knights of Ni situation
4/20 @ 2:30pm EST:
Yep, it was the card. After the card was removed the issue no longer occurred. Thanks for your help!
Does the same thing happen when you remove the SD card from the printer? I see it does a file list there but that never ends correctly, so it could be something being wrong with that SD that trips up the firmware, and the issue only manifests when connecting with OctoPrint because it will query the contents of the SD card if it is reported as present on connect.
Wouldn't be the first time a broken SD card causes issues on connect that are attributed to OctoPrint at first.
There we go - I'm no longer a "new user" and allowed to reply more than three times on a single post. Here were my updates (placed as an edit to an older comment):
4/20 @12:43pm EST:
Thanks @foosel - I'll test today without the card and reply with logs and results. New forum users can only reply three times on a single thread, so I had to edit this comment to say so. It's like a reverse Knights of Ni situation
4/20 @ 2:30pm EST:
Yep, it was the card. After the card was removed the issue no longer occurred. Thanks for your help!
Good to know... I suggest to propagate that info also on the lulzbot forums then and tell people to remove their cards. I can't remember which printer it was, but a year or so ago we had another case of a particular model's firmware crashing hard on weird stuff on the SD and causing all kinds of issues.
@mbaio, @mhenstell please also check if removing the SD card from the printer moves the issue.
Thanks for doing the footwork and getting this sorted with foosel. I may have missed this on the thread. What files did you need to change to fix the pausing issue?