After taking my printer out of storage, I made the mistake of upgrading to 1.6.1 from 1.3.10. I discovered I could no longer connect to the printer. This is not a hardware issue - because if I restore the SD backup image, the printer works. If I upgrade, or replace it with the latest OctoPi, I can no longer connect to the printer.
I won't bother uploading logs at the moment. It is clearly a software issue rather than hardware, so I thought I'd ask some general questions before getting more in depth.
I'm running a Raspberry Pi 3 plus. The printer runs an Arduino 2560, with Marlin V1.0.0.
Do the latest versions of Octoprint play nicely with Marlin V1?
You aren't trying all that hard to get people to help you here, in fact doing pretty much the opposite.
As far as we know, there's no reason that OctoPrint shouldn't work with really old Marlin firmware. But 'not connecting' is a number of different things, without a log I don't know what it is.
OK, I'll bite. Which logs would help? The serial log before upgrading shows the serial connection being opened on the first try. The logs after upgrading and the logs after resinstalling using the latest OctoPi show the serial connection being tried on the same port and every baudrate, and timing out each time. It's the same hardware/firmware combination so it's not hardware related. Or maybe it is? I'm running the Pi B Plus, not the Model 3 B. Have the later versions developed a greater appetite for power?
I wasn't holding off on uploading the logs to be obstructionist - rather I was hoping for some direction to lead my investigation in before uploading relevant logs. Otherwise, it's just noise, is it not? My first thought was that at some point, a change in Octoprint introduced an incompatibility with the earliest Marlin. Your response has scarpered that theory, so back to the drawing board.
This is from V1.6.1:
octoprint-systeminfo-20210529225111.zip (24.1 KB)
And this is the serial log from 1.3.10:
serial.log (12.0 KB)
It looks like it never hears anything back from the printer in time to successfully complete auto detection. What happens if you skip auto detection and try to explicitly connect to port /dev/ttyACM0' and baudrate 115200`?
I tried that, I'm afraid. The only difference is it tries only the single combination. Actually, not the only difference - when you specify the baud rate, it seems to use a longer timeout. I also tried ttyAMA0 in addition to ttyACM0.
The only difference I can think of at the moment may be the underlying PySerial library updates. It's the same port, same baud rate, the rest of the settings seem the same as well. It just doesn't respond to the newer version's connection attempts 
More thinking needed on this one. Usually these are issues with the printer being detected by the Pi, but the port is there.
That's good thinking - and it means we need more information. I'm going to check if there's any difference between the serial hardware on the B+ and the 3B+. And I also wonder if the problem is elsewhere - like maybe a the PySerial library has internal timeouts that are have changed, or a plugin delaying processing just enough to push it over the edge. I'll try running in safe mode - it will disable plugins and improve processing speed since it will be doing less.
Only just realized - we are also forgetting another big one. The version that works runs under Python 2. The latest version runs under Python 3. Is there a way to get older versions of OctoPi so that I can install the first version that runs Python 3?
Never mind. I just checked. The latest OctoPi is the first version that uses Python 3. I'll install the previous version - OctoPi 17 - and see if that version works. Then I'll progressively upgrade OctoPrint from there and see at which point it breaks.
Solved it. Problem turned out to be Python. The problem exists from V1.4.0 onwards. From that version, Python 2 doesn't work.
The problem also was between the chair and the keyboard. Sometimes, when you're debugging an issue that becomes frustrating, you start to overlook things while convincing yourself you are still being logical and methodical. I had upgraded to V1.6.1, but had left Python alone. However, the python version should have been one of the variables to be eliminated, and I never did, until I found a line among the release notes saying 1.4.0 was the first version compatible with Python 3.
It may be worth checking the changes to the serial code made while making the code compatible with V3. Even though V2 compatibility is no longer important, it may be that the relevant change is a problem waiting to bite. No need to spend time on it, just look at it to see if anything jumps out. The problem, as Charlie thought, may turn out be in the PySerial libraries.
Thanks for everyone's help on this. In the end, what helped the most was Charlie's and your comments indicating I should look at a lower level than the configuration settings.
In addition, be aware that OctoPi 18, while being compatible with Python 3, actually installs Python 2. Since Python 2 is now EOL, this is a non-intuitive problem for many people.
1 Like
This helps me a lot. I was having the same issue over the weekend. I even loaded prontoface to validate the serial port was still working. I’ll try and update python and see how it goes.
Just be aware of one gotcha I had. After updating python, the problem still seemed to exist one more time. The key was update python, attempt a connection (which fails), then shut down both the Pi and the printer (since the Arduino is powered from the printer). After that I was OK. I don't know why, but it was the same behaviour multiple times.
Appreciate the heads up. I did validate that with 1.3x my printer connected to my pi, but not with the current update.