Inconsistent connection to Snapmaker Original

What is the problem?

I can only connect to my Snapmaker Original about 1 in 10 times that I attempt to.

What did you already try to solve it?

I have increased the timeout from 10 to 20 seconds. I have restarted and rebooted the OctoPi server (I’m running OctoPrint on a Raspberry Pi 3B+). I’ve turned the Snapmaker on and off multiple times. I’ve ordered a new USB-A to USB-B cable which I should have tomorrow.

Have you tried running in safe mode?

Yes, I’ve run in safe mode and that has not solved the problem

Did running in safe mode solve the problem?

No

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)

octoprint-systeminfo-20240406110251.zip (151.6 KB)

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

OctoPrint Version 1.9.3
Snapmaker Original 3-in-1

In terms of connecting to OctoPi, I'm doing that primarily from my iPhone using Safari, though I have also managed to get the connection working with Home Assistant and OctoPod or from an iMac running Safari

What I typically see in Terminal is:-
Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyUSB0, baudrate 115200
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0x6e921898, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=20.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
There was a timeout while trying to connect to the printer
Changing monitoring state from "Connecting" to "Offline"
Connection closed, closing down monitor

And the strange thing is that it will occasionally connect and I can see the temperatures, control the axes movement and even start printing a file - but then the connection drops and I just can't seem to get it to reconnect.

I'm really interested in being able to use OctoPrint because of it's ability to adjust settings on the fly during a print.

Many thanks for any suggestions and ideas.

Unreliable USB communications are usually caused by poor quality cables and/or EMI interference. The cable should be shielded, as short as possible, and have ferrite beads which can help minimize EMI.

If you enable the serial.log in OctoPrint and upload another systeminfo bundle, we may be able to determine the difference between successful and failed communications (assuming that you manage to capture both in the log).

1 Like

So I have the serial.log enabled - I just haven't been able to get it to connect at all since I turned that on.

It seems like the serial.log only keeps the data since the last restart of OctoPrint - is there a setting that I can toggle for it to keep a longer history?

I'll keep trying and will capture the log if I manage to get it to connect, but here are the most current.

serial 2.log (2.1 KB)
octoprint-systeminfo-20240406160811.zip (210.4 KB)

OK, so I was able to get it to connect a couple of times. I have switched the USB cable - it doesn't have ferrite cores, but it seems like a little better quality.
serial 3.log (18.7 KB)
Looks like the connection dropped within a couple of minutes each time.

I was actually running prints directly from the USB drive attached to the printer at the time that I was able to connect.

There is nothing in the serial.log that would indicate EMI or a faulty cable. It looks like the printer just stops communicating.

I was going to suggest contacting Snapmaker support but while searching the internet I found lots of complaints about them so that probably won't help.

Yeah, especially with it being a Snapmaker Original it seems like that was their ‘mass market prototype’ and that their current generation of printers have improvements based on the lessons learned and that they’d rather forget about the Original. What seems a shame is that they’re not prepared to open source the software/firmware so that the community can make improvements.

Thanks for looking at it though.

This is in violation of the Marlin license agreement. Not sure if there is a "Marlin legal department" or if there is any other recourse other than letting people know about their violation. I will never consider buying a product from them because of this.

Ah, so once they’d chosen to base themselves on the Marlin platform their hands were tied.

OK, so success of sorts. I got a hold of some clip on ferrite cores for the USB cable and as soon as they were on the connection has become stable, with terminal showing me some send and receive packets along with the temperatures being reported.

It doesn’t seem to want to print based on a file sent from Octoprint at the moment, but I suspect that there’s an issue with the printer set up that I have in Octoprint.

Doing some urgent printing direct from USB stick tonight so I do some more troubleshooting as I get a chance later in the week.

Here’s the serial log that showed the failed attempts over the weekend and then the successful connection this evening along with the failed attempts at printing from OctoPrint, before communication stopped after I set a print running directly from the inserted USB drive in the printer.

strong textserial 4.log (128.4 KB)

Already tried this?

No, I haven’t - I’ll give that a try at the weekend (before if I can)

1 Like