How to troubleshoot print freeze?

Given that it's a 3B+ it could also be the firmware on the Raspi: sudo apt-get update && sudo apt-get -y upgrade.

Thank you. Does that means I need to look on how to update the PI's firmware? Any reliable place for it?

I just gave you the command in my last post.

Maybe, but I have no idea where to "type" that. I guess it is youtube time for a 101 in that thing. Thanks. I will try it tonight.

1 Like

Ok, got PuTTY, fired the command you sent. Looks like it is doing its thing updating something. Also got a new cable and the power supply is good. This looks very interesting...

1 Like

octoprint.log (136.1 KB)
Updates done. New cable, 2.5A power supply. Still failed.

serial.log (3.5 MB)

Looks like you figured that out and got the correct version of that second command. (The "&&" is how you'd run more than one command at a time.)

From your serial.log, this is about the only thing that raises my eyebrows:

2018-12-21 03:02:32,666 - Send: M20
2018-12-21 03:02:32,682 - Recv: Begin file list
2018-12-21 03:02:32,698 - Recv: /OLDER/SHORTD~1.GCO
2018-12-21 03:02:32,713 - Recv: /OLDER/CR-10E~1/HUBA3H~1.GCO
2018-12-21 03:02:32,761 - Recv: /OLDER/CR-10E~1/47ACB~1.MOD/1/HUBA3H~1.GCO
2018-12-21 03:02:32,790 - Recv: /OLDER/CR-10E~1/47ACB~1.MOD/2/EAST_D~1.GCO
2018-12-21 03:02:32,791 - Recv: /OLDER/CR-10E~1/47ACB~1.MOD/3/BAIZEH~1.GCO
2018-12-21 03:02:32,806 - Recv: /OLDER/CR-10E~1/47ACB~1.MOD/YAXISW~1/CR-10~1.GCO
2018-12-21 03:02:32,866 - Recv: /OLDER/CR-10~1/HUBA3H~1.GCO
2018-12-21 03:02:32,868 - Recv: echo:Cannot open subdir
2018-12-21 03:02:32,869 - Recv: 1380A~1.��
2018-12-21 03:02:32,870 - Recv: echo:Cannot open subdir
2018-12-21 03:02:32,872 - Recv: 25282~1.��
2018-12-21 03:02:32,873 - Recv: echo:Cannot open subdir
2018-12-21 03:02:32,874 - Recv: 30C02~1.��
2018-12-21 03:02:32,876 - Recv: echo:Cannot open subdir
2018-12-21 03:02:32,877 - Recv: 451AC~1.��
2018-12-21 03:02:32,879 - Recv: echo:Cannot open subdir
2018-12-21 03:02:32,880 - Recv: 5927D~1.��
2018-12-21 03:02:32,882 - Recv: echo:Cannot open subdir
2018-12-21 03:02:32,883 - Recv: 62CC5~1.��
2018-12-21 03:02:32,884 - Recv: /OLDER/C_FRON~1.GCO

I'm sure others would know more but strange characters in a file list from your printer controller's SD card could suggest either card corruption, wonky firmware or a problem in the serial line. I've suggested before that Marlin may not be happy with Microsoft-style long filenames but others think that it's okay with that.

If this were a classic early-Raspi-firmware-on-a-3B+ situation, then the Pi itself would freeze up and not be responsive to anything, forcing a power boot to return to service. I think you've ruled that out if you've now updated the firmware with that apt-get upgrade.

You "new" cable hopefully has internal metallic shielding or one or two ferrite cores.

Your serial log looks nearly pristine to me. I don't love the temperature responses coming back from your firmware with the question mark at the end; that looks odd to me.

I'm noting that although you're not in Safe Mode, you don't seem to have any additional plugins other than those bundled.

Looks like a problem running one of the bundled plugins:

2018-12-21 03:03:19,169 - octoprint.plugin - ERROR - Error while calling plugin tracking
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/plugin/__init__.py", line 230, in call_plugin
    result = getattr(plugin, method)(*args, **kwargs)
  File "/home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/tracking/__init__.py", line 119, in on_event
    self._track_printjob_event(event, payload)
  File "/home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/tracking/__init__.py", line 237, in _track_printjob_event
    sha.update(self._settings.get([b"unique_id"]))
TypeError: update() argument 1 must be string or buffer, not None

It did this right after you kicked off the print job. It's the tracking plugin. This has to be the Anonymous Usage Tracking plugin, new with this major version. Here's the bit of code that's throwing the error:

	def _track_printjob_event(self, event, payload):
		if not self._settings.get_boolean(["events", "printjob"]):
			return

		sha = hashlib.sha1()
		sha.update(payload.get("path"))
		sha.update(self._settings.get([b"unique_id"]))

Do me a favor. Run this cat ~/.octoprint/config.yaml | grep unique (copy/paste that into your putty session). You should see a value there.

Thank you so much for the attention. I run "cat ~/.octoprint/config.yaml | grep unique" and got nothing.
If I remove grep unique, I get the attached text

accessControl:
  salt: REDACTED
api:
  key: REDACTED
plugins:
  announcements:
    _config_version: 1
    channels:
      _blog:
        read_until: 1545132000
      _important:
        read_until: 1521111600
      _octopi:
        read_until: 1527588900
      _plugins:
        read_until: 1544486400
      _releases:
        read_until: 1544449800
  cura:
    cura_engine: /usr/local/bin/cura_engine
  discovery:
    publicPort: 80
    upnpUuid: 78eac33e-a734-4d26-b964-319b4b7c5902
  softwareupdate:
    _config_version: 6
  tracking:
    enabled: false
printerProfiles:
  default: _default
serial:
  autoconnect: true
  log: true
server:
  commands:
    serverRestartCommand: sudo service octoprint restart
    systemRestartCommand: sudo shutdown -r now
    systemShutdownCommand: sudo shutdown -h now
  firstRun: false
  onlineCheck:
    enabled: true
  pluginBlacklist:
    enabled: true
  secretKey: q27Hy9jWV2tc2NfuYqk5k3dE32bkveKD
  seenWizards:
    corewizard: 3
    cura: null
    tracking: null
webcam:
  ffmpeg: /usr/bin/avconv
  snapshot: http://127.0.0.1:8080/?action=snapshot
  stream: /webcam/?action=stream

By the way, I am using a 128GB card. I assume it is ok, but while installing octoprint I did get a message complaining abt it.

My CR10S still have merlin 1.1.0
Should I plan to update that?

The error above indicated that it couldn't find "unique_id" in your config.yaml and you've just confirmed it.

Did you upgrade to v1.3.10 as suggested above? In theory, you wouldn't have that plugin unless you did. But the absence of the config.yaml section makes me wonder.

Visit the Settings -> Anonymous Usage Tracking page. There should be something written next to the Instance ID. If the first checkbox is off, toggle it on. If it's on (and the Instance ID is empty) try toggling it off, save and then return to turn it back on. You're trying to get it to issue an ID.

If all that fails:

sudo nano ~/.octoprint/config.yaml

Under the plugins section, add this just before the next printerProfiles section of the file:

  tracking:
    enabled: true
    unique_id: bbb18e1b-5105-4275-a020-644412786abc

I did the update, and in putty shows Octoprint Version 1.3.10, and octopi 0.15.1
I will try what you suggested now.

Got an ID there
unique_id: 8215753c-a8fb-4c9d-8fef-4f73dab0031d

Okay... restart OctoPrint and see if it's now happy. The octoprint.log (for the timestamps after the restart) should not throw an error for that plugin especially after starting a job.

Restarted it all. Did not print yet, but it does not stay connected. I get a printer reset detected warning. I got those before, just did not mind them. I connect to my printer and in few minutes I get disconnected again.

disconnect

Either the printer reset because it lost power or it's possible that the serial connection got bumped or otherwise lost its connectivity somehow. It feels like it's not the Raspi in this case, for what it's worth.

I'd say, review the connection again and make sure that it's firmly attached for the serial cable. Then review the power for the printer controller board and make sure that it's also firmly attached. It would be nice if everything was plugged into a UPS so that there are no brown-outs on the incoming power (a possibility as well).

Thank you . The printer and raspi are on the same UPS. I also do not think it is the raspi.
I an due to replace the fans in the printer control box this week, and will review all wiring on that board, then update firmware.
Funny thing: The printer itself is printing fine from SD (sans octoprint). Just finished a 6 hour job and not a glitch.

For what is worth, I also tried to use a USB powered hub in between raspi and the printer. Got the same issue, randomly stopping communications and print.

That's starting to suggest a serial problem then.

The problem was solved by replacing the PI. I got a PI 3 B this time and worked fine.
So,or I got a defective 3B+, or there is a bug using it.
Just to know, I re-purposed the 3B+ into my home automation and it is working 24/7 for 2 weeks now. Go figure.

2 Likes