Octoprint / Lulzbot Workhorse... smoke!

What is the problem?

Hello, I set up octopi / print on a pi3B. It seemed happy. I connected to the Lulzbot workhorse @ 115200. I saw some text go back and forth. It looked connected and happy. I got called to the front of the office to deal with something. When I came back the shop was filled with smoke. The printer seems to be working but the extruder / body have a nice ash coating from the smoke that I need to clean. I realize getting Lulzbot support is difficult nowadays and I may be one of the few with a workhorse printer... What did I do wrong and how do I keep this from happening again?

Thanks!

So you did nothing but connecting the printer?
No preheat, no homing, no nothing?

The thing is without logs we can't tell you what happened.

This and many more fun things are found on their forum.

Thanks PrintedWeezl and OutsourceGuru!

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.

Thanks for the help!

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.

octoprint.log (52.6 KB)

Create a serial.log with reproduction and share it here.

Hey M,

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!

Check out this link for some octopi settings, looks like the issue may have been specific to 1.3

I can't access that page as it seems.

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.

Thanks Foosel!

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?

octoprint.log.2020-04-15.log (190.1 KB)

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.

serial.log (21.6 KB) octoprint.log (174.5 KB)

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.

1 Like

Does the upvote mean this was it? :thinking:

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!

serial.log (166.0 KB)

Card included with the Workhorse is a Verbatim 8GB Class 10, sent with other files. Firmware, etc?

I will test with another card and provide that info.

I now have a new issue with the Workhorse where prints started from Octoprint are constantly pausing, but that's for another thread, I suppose.

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.

Will do! Once I get some testing in with another card I'll have the info needed to post on the Lulzbot site.

Thanks.

This doesn't seem to be an issue with other cards, only with the card that comes with the machine. I'll upload to the Lulzbot forum.

Thanks for helping us work through this @foosel. FWIW, I also stopped having pausing issues after changing files. :slight_smile: