I guess I worded that wrong, you're right - yes it could do, but OctoPrint's code does not try to. It could be a dependency of a dependency like you say, that creates this issue. Without digging into the dependency tree hell, I couldn't tell you!
I'm probably also partially blinded by the number of people who end up with 'my OctoPrint's broken' after they update because the install was corrupted. So many after the 1.4.1/2 update with corrupted installs, which the command above fixed it.
at least for me
~/oprint/bin/pip install --force-reinstall --no-cache-dir octoprint
fixed it!
i did also run ~/oprint/bin/pip --upgrade pip or what ever the pip upgrade command was because it was an old verison
edit never mind.. it started printing and then the print process was stopped because lost connection or something
I was experiencing the same issue after upgrading to 1.4.2
Connection just magically started working after changing USB port on RaspberryPi and resetting the Serial Port and Baudrate to AUTO.
I'm running a test print now.
Edit
Test print worked, but lost ability to connect to OctoPrint server via a web browser shortly after the print began. Test print finished successfully.
I had to restart the server in order to connect to OctoPrint server via a web browser, but was again experiencing connectivity issues with the 3D printer.
I reset the serial and baudrate to auto, shutoff the RaspberryPi, changed the USB port, and started server again. This again allowed OctoPrint server to successfully connect to 3D printer.
Second print running now.
Throwing in my two cents, I'm also having the same problem.
I've had a part in my printer (Ender 3) broken for a while, so I haven't tried using octoprint for a couple of months. Now that I've fixed it, I'm getting the
Offline (Error: No more candidates to test, and no working port/baudrate combination detected.)
error.
I've tried: connecting to a different printer mainboard, using a different usb cable, using a different usb port, rolling back to an earlier version of octoprint, manually re flashing octoprint, using the force-reinstall command via ssh. Attached are my logs (main, and serial communication).
Any help would be super appreciated. I want so desperately to finally have my 3D printer back.
Thanks for your time!
serial.log (1.2 KB) octoprint.log (101.0 KB)
Is there a serial port listed that would allow you to manually set the port and baudrate?
Hi Jneilliii,
I can manually set the buad rate (although no baud rate succeeded when I tried setting them manually) but only "auto" appears under Serial Port.
Thanks for your help!
So that means octoprint is not aware of the serial port that your printer is connected on. This may mean it needs to be manually added in the additional serial ports option in order to be recognized. If you SSH to your pi and run the command dmesg | grep tty what is returned?
This thread may also be helpful, and the connection may also be listed with dmesg | grep usb.
Here's what I get with dmesg | grep tty.
Not sure how to interpret those results.
And once again, thanks for your help, it's very much appreciated!
ok ttyAMA0 is the bluetooth chip if I'm not mistaken, so the pi doesn't see the printer at all. this could be a bad USB cable, bad power supply, or possible linux corruption. I'd try the manual reinstall just to see if that makes any difference.
Edit: there's been reports of electrical interference from motors and power cables too.
So I've tried manually reflashing a clean octopi to my raspberry pi's SD card, as well as doing the force-reinstall command. Is there another thing I should try reinstalling/another way to do it? Likewise, I run a small business that includes a mini usb cable with every order, so I've got tons of them lying around, and none seem to work, so that's the one thing I'm pretty confident it shouldn't be. For the power supply issue, the printer powers up and can be used via its monitor, and on the pi end I can connect to the webinterface, just not the printer. Could it still be the powersupply? Genuine question.
I'll try moving it seperate from everything else, but at the moment it's in its own area for from my computer, which is why octoprint is pretty important to me.
Also here's the dmesg | grep usb result.
Worth pointing out that it's connected to wifi via a usb adapter, and I've tried switching the usb cable to the port that the wifi adapter was on, and it still didn't work.
I meant the power supply to the pi, not the printer. If you're not using a true power supply and are using a phone charger wallwart, or ipad charger plug, etc. can cause weird issues.
Yeah, I don't think any of those USB options are relevant.
Sorry, I don't know why I assumed the details of my personal setup would be known to others. Both my printer and pi are powered by my printers PSU, in the case of the pi stepped down to 5vs via a buck converter. Maybe I accidentally hit the buck converters dial and it's not getting the proper voltage now? Could that be it? I can break out the multimeter tomorrow and find out.
I wouldn't naturally think that to be the issue assuming you weren't getting under voltage warnings prior to upgrade. The issue is definitely the pi not seeing the printer though for whatever reason.
Ah this is frustrating. I've literally replaced the usb cables and the printer mainboard itself, and it's still not working, and like I said, the usb wifi dongle works, so the usb ports should work.
I'm truly at a loss.
Thanks for all your help though. My next step might be trying to replace the pi. It wouldn't be my favorite option, since all my other pis are in use with other projects, but if I can't think of something else...
Hello,
I have two ideas for testing:
try to disable bluetooth on your raspi - for example follow this instruction: https://scribles.net/disabling-bluetooth-on-raspberry-pi/
does your printers USB-Port is working? Can you connect your printer directly to a computer and does it there appear as a Com-Port and works for example with cura or something else?
Best regards,
Sebastian
Ok so I have the good fortune of having a number of setups I can test at once (I have my orignal ender 3, the replacement skr mini board I got for that ender 3, and a broken (no-hot end) ender 3 I recently got on craigslist.) I tried connecting each of them to my computer and got different results for each. My original ender 3 board didn't show up at all in device manager, the SKR mini showed up as an unknown device, and the craigslist ender 3 showed up as its usb controller (CH340). None of them however, showed up in cura (I think? It's been a while since I tried printing directly via cura so maybe I messed something up there).
I disabled bluetooth as well and didn't see any change in behavior.
Thanks for your help+time
Just adding my 2 cents to this thread as I was also having the same issue, but may have just solved it.
Here's my experience.
Everything was working flawlessly before the update and now nothing. At one point I was having an issue but it resolved when I used a modified cable without the power feed. I only had 2 plugins installed and wasn't even using them yet. Enclosure plugin and The spaghetti detective.
I disabled plugins, rebooted in safe mode and tried plenty of different things and tests but to no avail. Still got the same no more candidates to test error. I even forced a reinstall of octoprint and everything else mentioned in this thread but to no avail
So I put it away for a couple days and decided to try a fresh start tonight and log my steps.YMMV
I'm using a pi model B revision 2. I have a usb webcam plugged in.
Here's my method:
Downloaded latest octopi image and wrote it to a fresh card using rufus.
The version is 0.17.0
Plugged in printer, rebuilt my serial cable to reconnect the power feed wire. I fired everything up immediately ssh into the pi and ran a dmesg and lsusb. Here is the output
pi@octopi:~ $ dmesg | grep tty
[ 0.000000] Kernel command line: coherent_pool=1M bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 console=ttyAMA0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[ 0.001262] console [tty1] enabled
[ 1.041583] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
[ 1.936643] console [ttyAMA0] enabled
[ 17.906948] usb 1-1.2: ch341-uart converter now attached to ttyUSB0
pi@octopi:~ $ lsusb
Bus 001 Device 005: ID 0ac8:303b Z-Star Microelectronics Corp. ZC0303 Webcam
Bus 001 Device 004: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. SMC9512/9514 USB Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubI loaded octoprint and ran through the startup wizard. After setup it immediately connected to my printer, I was able to control the motors and view the camera. I did not touch any settings or change anything except to enable serial logging. I did not attempt to print anything. .I did not physically touch or go near the printer at all.
I then proceeded to click to update from 1.3.12 to 1.4.2. It upgraded fine, I reloaded the page and the connect button remained greyed out, could not click it to even attempt a connection. I opened up my ssh window and rebooted the pi.
Upon reboot I again ran dmesg and lsusb with identical results. I compared them word for word
Opened a new browser and loaded octoprint. Would not connect.
I get the same error.
Here's the serial log
2020-09-06 07:15:14,219 - Changing monitoring state from "Offline" to "Detecting serial connection"
2020-09-06 07:15:14,673 - Performing autodetection with 7 port/baudrate candidates: /dev/ttyUSB0@115200, /dev/ttyUSB0@250000, /dev/ttyUSB0@230400, /dev/ttyUSB0@57600, /dev/ttyUSB0@38400, /dev/ttyUSB0@19200, /dev/ttyUSB0@9600
2020-09-06 07:15:14,700 - Trying port /dev/ttyUSB0, baudrate 115200
2020-09-06 07:15:14,767 - Connecting to port /dev/ttyUSB0, baudrate 115200
2020-09-06 07:15:14,827 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:14,891 - Connected to: Serial<id=0xaf7a3250, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2020-09-06 07:15:14,946 - Send: N0 M110 N0*125
2020-09-06 07:15:16,975 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:17,112 - Send: N0 M110 N0*125
2020-09-06 07:15:19,091 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:19,177 - Send: N0 M110 N0*125
2020-09-06 07:15:21,163 - Trying port /dev/ttyUSB0, baudrate 250000
2020-09-06 07:15:21,212 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:21,283 - Send: N0 M110 N0*125
2020-09-06 07:15:23,281 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:23,355 - Send: N0 M110 N0*125
2020-09-06 07:15:25,359 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:25,446 - Send: N0 M110 N0*125
2020-09-06 07:15:27,425 - Trying port /dev/ttyUSB0, baudrate 230400
2020-09-06 07:15:27,458 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:27,544 - Send: N0 M110 N0*125
2020-09-06 07:15:29,530 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:29,592 - Send: N0 M110 N0*125
2020-09-06 07:15:31,590 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:31,683 - Send: N0 M110 N0*125
2020-09-06 07:15:33,664 - Trying port /dev/ttyUSB0, baudrate 57600
2020-09-06 07:15:33,707 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:33,779 - Send: N0 M110 N0*125
2020-09-06 07:15:35,781 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:35,870 - Send: N0 M110 N0*125
2020-09-06 07:15:37,860 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:37,925 - Send: N0 M110 N0*125
2020-09-06 07:15:39,921 - Trying port /dev/ttyUSB0, baudrate 38400
2020-09-06 07:15:39,962 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:40,037 - Send: N0 M110 N0*125
2020-09-06 07:15:42,040 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:42,112 - Send: N0 M110 N0*125
2020-09-06 07:15:44,110 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:44,197 - Send: N0 M110 N0*125
2020-09-06 07:15:46,193 - Trying port /dev/ttyUSB0, baudrate 19200
2020-09-06 07:15:46,248 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:46,337 - Send: N0 M110 N0*125
2020-09-06 07:15:48,336 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:48,424 - Send: N0 M110 N0*125
2020-09-06 07:15:50,415 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:50,506 - Send: N0 M110 N0*125
2020-09-06 07:15:52,498 - Trying port /dev/ttyUSB0, baudrate 9600
2020-09-06 07:15:52,540 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:52,605 - Send: N0 M110 N0*125
2020-09-06 07:15:54,611 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:54,677 - Send: N0 M110 N0*125
2020-09-06 07:15:56,711 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:56,854 - Send: N0 M110 N0*125
2020-09-06 07:15:58,872 - Changing monitoring state from "Detecting serial connection" to "Error: No more candidates to test, and no working port/baudrate combination detected."
2020-09-06 07:15:58,967 - Changing monitoring state from "Error: No more candidates to test, and no working port/baudrate combination detected." to "Offline (Error: No more candidates to test, and no working port/baudrate combination detected.)"
2020-09-06 07:15:59,033 - Connection closed, closing down monitorI went into settings and moved the connection timeout and autodetection timeout to 45s. Also moved consecutive handshake attempts up to 30s
Tried again and it connected to the printer within maybe 10 seconds.
It appears to respond to commands now and I've just sent it a succesfull print.
So for what its worth I appear to have fixed me issue. Hope this helps somebody