Raspberry Pi gone Bad?

What is the problem?
I’ve had my pi for about 3 years, hooked up to my makerbot. Installed octoprint and basically have had zero issues. On Saturday things started acting wonky, first I had a sudden loss of communications between octoprint and the printer, the fix I found was to change the Gcode flavor in GPX from Makerbot to RepRap, I had never changed that setting since originally installing OctoPrint. I made the change and suddenly things started working again.
It printed fine until Sunday morning or so where i again lost complete access to the printer remotely. I found that most of my Version of OctoPrint, Octopi and pip all required updates. I updated them and the problem continued
I bypassed the pi completely and plugged my laptop directly into the printer and had full comms (verifying usb on the printer is good). I stepped back and swapped to all 4 ports on the pi, no coms. My webcam is working through my Pi and I am receiving temperature readings from my printer, so some kind of communication is happening however when I click Print I get a serial error.

TL:TR So I can talk with the pi enough to interface with octoprint, I can receive webcam and temp updates like normal, however once I click Print I get a serial error and everything shuts down.

What did you already try to solve it?
Upgraded Versions of All Programs to there latest version, No Change
Hardwired Laptop to Printer, Bypassing Pi and OctoPrint and have communication (This verified USB on Prtinter is working)
Changed Cable from Printer to Raspberry Pi, no Change
Changed Ports on Raspberry Pi, No Change
Installed Fresh copy of OctoPrint, Didn't Restore from backup, set up parameters manually, no change

Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!)


Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)
OctoPrint Version - Version 1.4.0
OCtoPi Version - Version 0.17.0
GPX Plugin: 2.6.3
pip: 20.1
Raspberry Pi - Raspberry Pi 3 Model B Rev 1.2
Printer Version - MakerBot Replicator 2

I hope I have provided enough information, thank you for all of your help

I don't know what it means but this is your problem.
It could be a corrupted uuid :woman_shrugging:

2020-04-28 20:03:55,935 - Changing monitoring state from "Starting" to "Printing"
2020-04-28 20:03:55,949 - Send: ?b9f5e559-4716-4a92-8fcf-1??R???0????p?@??????4??8???f????>?4??C?
2020-04-28 20:03:55,964 - Unexpected error while writing to serial port: TypeError: 'argument 1 must be string without null bytes, not str' @ comm.py:_do_send_without_checksum:3490
2020-04-28 20:03:55,979 - Changing monitoring state from "Printing" to "Offline (Error: TypeError: 'argument 1 must be string without null bytes, not str' @ comm.py:_do_send_without_checksum:3490)"
2020-04-28 20:03:57,935 - Connection closed, closing down monitor

Maybe somebody else with MakerBot experience got an idea.

Yea thats the error message I get, I have no idea what it means. Obviously I think the root cause was something to do with the GPX and needing to change the Gcode Flavor but how that applies to the error and what I can do to fix it are 2 different things.

  • Verify that the printer controller board is plugged in and powered on
  • Verify that the power at the wall outlet is what you think it should be (consider plugging all this into a UPS)
  • Verify that your power adapter is 5V @ 2.5A and is an adapter not a charger, make sure that the ends fit snugly
  • Check to see if that error message happens every single time or if it's almost anything that could be corrupted
  • Review your gcode and your startup scripts
  • The serial cable needs to have metallic shielding or ferrite core, be as short as possible, fit snugly at both ends

The printer itself is working fine, no issues
I have everything plugged into a UPS already
The Power Adaptor to the Pi is 5V @ 2.5A, and is the adaptor that came with the Pi when I bought it
The message happens every time since last Saturday, previous to then everything worked perfectly for 3 years.
I have no Startup Scripts besides whatever defaults in Octoprint
The serial cable is less then 2 ft long and goes in basically a straight line from the pi to the printer

But does the serial cable have internal metallic shielding or a ferrite core?

I honestly have no way of knowing that, it was the cable that came with the printer so I have to assume so, I did replace the cable with an albeit longer cable and it did the same thing. If the cable was was the issue then replacing it should have fixed it. also when I take the same cable and plug it into my laptop I can talk to the printer and print directly from my laptop using that same cable.

A ferrite core is easy to spot. It's a blocky thing surrounding the cable. Do a web search for the term "ferrite core". You either have it or you don't.

Next, if neither cable has a ferrite core and neither have internal metallic shielding then replacing your cable back and forth between these proves nothing much. Only replacing it with the proper type would be the actual litmus test.

Hold the cable in your fingers. Bend and flex it in the middle. Does it seem to be giving you a fair amount of opposition? The standard metallic shielding I'm talking about includes a braided wire cage.

Screen Shot 2020-04-29 at 1.39.12 PM

Yes it has the blocky thing on it, I didn't realize that meant ferrite core. Yes both cables (the one I had been using, and the albeit longer one) are ferrite core and both are fairly flexible in the middle of the cable.

Alright, it sounds like both have ferrite cores and neither have internal metallic shielding (good enough).

The final question then would be if it always chokes on that same line or if it's more random. If it's the same place then it sounds like it's something to do with the gcode or as suggested the Marlin UUID. If it's random then I think I would troubleshoot this as the Pi is sinking 5V power over to the controller board.

So it fails and that serial error comes up immediately when I click print. Once I click print it spits out that line of BS and then changes its state to disconnected and basically I need to refresh octoprint to be able to connect back to it again.

I know very little on the ways of how this all really works, where does the Marlin UUID live? Right now I'm back to saving to SD cards but the Makerbot is functioning just like it has before.

If it fires off immediately when you print then it sounds like it's not the connection event ("HELLO") that's returning the Marlin firmware description ("M105" perhaps). You might try printing a small cube gcode file instead to see if the problem follows this job you're trying.

Do you have the same baudrate in your printer's firmware and Octoprint serial settings?

Yes been set for 115200 for as long as ive had it set up. Also if I change it to Default it changes too 115200

As soon as I hit print I get this back

Changing monitoring state from "Operational" to "Starting"
Send: N0 M110 N0*125
Recv: ok
Send: (@build "Cube")
Recv: ok
Send: N1 M136 (Cube)52
Recv: ok
Send: N3 G92 X0 Y0 Z0 A0 B0
Recv: ok
Changing monitoring state from "Starting" to "Printing"
Right after this it fails to the BS string and gives the Serial failure

I don't see any mention of a M105 in that whole string above it though

I'm a bit curious about the A and B parameter. These are specific for CNC and not 3d printing: https://reprap.org/wiki/G-code#G92:_Set_Position

1 Like

I have no idea , it’s not part of any script since I don’t have any loaded, as far as I know that’s always done that. We are dealing with a fairly old 3D printer so possibly they needed this line of code i there for some reason.

Just posted this in an answer to another question ... but your problem may be the same..
Lots of people have problems with the printer mainboard sucking the power out of the USB port - powering the mainboard from the Pi seems to cause lots of issues even when the printer is powered up... - disconnecting the USB+5V, which is what the tape does, often helps, I use a custom adapter or cable to isolate the +5V. Don't isolate the GND pin, you need a shared ground. Opening the wire sheathing and cutting the RED cable is what somepeople do, but its ugly!.

1 Like