With options on Serial Port and Baud Rate set to Auto. I tried to connect to Octopi, but got the following terminal comments;
Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: []
Changing monitoring state from "Detecting serial port" to "Error: Failed to autodetect serial port, please set it manually."
What did you already try to solve it?
I looked in the drop-down menus for Serial Port, but "Auto" was the only option.
I then went to settings/serial connections and looked in the options there, but again there was only "Auto". However, there was a window in which I could enter other ports, and I entered "COM6" and "COM4", which I know to be serial ports through which I can connect my computer with my printer (both of which appeared to be working).
I tried again with these new ports entered, but I got the same error messages.
I saw some advice on how to enter additional ports, but I didn't understand the advice at all.
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
I had not used Octoprint since late last year, and I found that I should update, since there were Messages telling me so.
I upgraded first from 1.3.6 to 1.3.8 (I think!) , even though I know now I need not have bothered. Could something have gone wrong here? It was only after the update that I attempted to connect.
That means your printer isn't even seen as a serial device by the operating system underneath OctoPrint. You can enter ports all you want in OctoPrint, if your OS isn't seeing your printer that won't make it magically show up (and Windows "COM" ports are already part of the default set looked for anyhow).
"COM" sounds like you are running OctoPrint under Windows. Is this really the case? If this was an OctoPi installation under Linux I'd say to check dmesg before and after connecting your printer, to see whether the OS even sees the connect and how it reacts to it.
Thanks. It looks as though I must try and re-install 1.3.8 (or go back to 1.3.6, which I had before this problem occurred and could serially connect with OK).
I use windows, not linux.
I have a test rig which involves a RAMPS board and a Raspberry Pi 3 and they're connected with a (spare) long USB cable. Since that cable doesn't have one of those cool ferrite cores on it I sometimes have problems with the auto setting and have to manually set the speed. I just bought a short USB cable so that should work better (the longer the cable, the better of an antenna that it is).
Did it connect recently, before you updated octoprint? Windows has gone through a few updates since last year and if you haven't used your printer since then, it's entirely possible windows itself has lost your printer.
Press the windows key then type device manager and open device manager, see if there are any unknown devices, or devices with yellow exclamation marks.
Hmm, where to begin?
You see, the fundamental problem is that I am not a developer; and therefore I have only a sketchy knowledge of the innards of computers beyond the common User interface. Moreover the knowledge I do have I am unable to use with any great facility. It's an age thing ...So:
I studied the three responses, and fairly quickly worked out that the Responders all agreed with me; that there was no connection between the raspberry pi and my printer. Very helpfully, OutsourceGuru suggested that I could use a spare long USB cable to make the connection.
Now, I thought," why should I use another USB cable to make the connection, when I already have a cabl ....". At this point I realised that there I didn't have a cable already. I had inadvertently forgotten to attach it!
My apologies all round, and thank you for your responses. Now, where is the little square box I have to tick for problem solved ? .....
Hi...i am a new user here. As per my knowledge recompiling the kernel should work. But if exagear has managed to do this without modifying the kernel, i would like to see if I can get something similar working and Wine is still compiling in my Docker container.
I am experiencing a similar problem, I believe it's related to the USB port on my MPSM main board. I had been running the printer by direct USB connection from my Windows 10 computer for over 2 years without issues. Then started having "connection" problems with prints stopping mid-print, while the machine UI still functioned. Tried different USB cables, different USB ports on the PC, and finally decided to try OctoPi (because everyone raves about it).
My implementation also only lists "Auto" under the port drop-down. My dmesg dump looks like this, with most of this output in red ("Danger, Will Robinson"):
[149709.256469] usb 1-1.1.2: new full-speed USB device number 5 using dwc_otg
[149709.356476] usb 1-1.1.2: device descriptor read/64, error -32
[149709.576489] usb 1-1.1.2: device descriptor read/64, error -32
[149709.796509] usb 1-1.1.2: new full-speed USB device number 6 using dwc_otg
[149709.896511] usb 1-1.1.2: device descriptor read/64, error -32
[149710.116520] usb 1-1.1.2: device descriptor read/64, error -32
[149710.236609] usb 1-1.1-port2: attempt power cycle
[149710.896579] usb 1-1.1.2: new full-speed USB device number 7 using dwc_otg
[149711.336608] usb 1-1.1.2: device not accepting address 7, error -32
[149711.436621] usb 1-1.1.2: new full-speed USB device number 8 using dwc_otg
[149711.876652] usb 1-1.1.2: device not accepting address 8, error -32
[149711.876766] usb 1-1.1-port2: unable to enumerate USB device
pi@octopi:~ $
So I'm assuming that this confirms my suspicion of a bad USB port on the main controller board (and yes, the USB cable IS PLUGGED IN).
First off, is this a Raspberry Pi Zero (W)? I'm seeing OTG there in the log which is "on-the-go" and something the Raspberry Pi 3 doesn't have, to the best of my knowledge. In my own opinion, the Raspberry Pi Zero's single core is probably not enough processing power for this job; I always suggest the Raspberry Pi 3B (four cores) which are ample enough for the many things you'll want it to do.
It sounds like you've experienced a trend of serial problems before changing where OctoPrint lives. It's possible that your printer controller board or your serial cable itself is to blame for your earlier problems. Make sure that this cable has internal metallic shielding or minimally, ferrite cores to block electrical noise from the stepper circuits and relays.
There are times when you actually need to set the OctoPrint connection information manually for this to work. You'd need to include your octoprint.log for us to advise here on this one.
Back to the Rasperry Pi, it includes two UARTs: a good one and a cheap one. Read this and understand what it's trying to tell you. It's possible that the Pi is using the cheap UART for your printer communications and that this is why it's failing. If you troubleshoot things to this level, you might consider toggling off Bluetooth and console-over-serial.
No, it's a Raspberry Pi 3B+, so processing power shouldn't be an issue. I have to plead ignorance of UARTs.
I'm pretty sure the issue is the USB port on the main controller board, as I've tried 3 different cables, as I noted in my original post. I'm just hoping that someone will point out something that I've missed before I get to the point of replacing the controller.
But the issue is that it worked with no problems with the same USB cable for over 2 years, and then started not working; that is, started losing connection to the printer mid-print, and then not connecting at all -- over a period of a couple of weeks. Which is leading me toward the motherboard... either the USB port or something failing on the board itself.
Unless of course you (or your neighbors) purchased some electrically-noisy device and it's now in service.
Cut a thin rectangle of aluminum foil, wrap your serial cable and add tape around that to insulate it. Watch the Terminal or turn on Serial logging and look for serial-related hiccups before/after doing this. If it seems to help them get a good cable that's made for this.
And then of course, it doesn't sound like you're connecting with OctoPrint. Drop the baud rate down, manually set things and see if it connects.
