Plugin Serial Port Dev Ttys1 Was Used

[Jamie Swearengin]

Whatis the problem?

When connecting to my Anet running Marlin 1.1.9, I have always left the port set to AUTO. I have never had any issues. Now, with 1.4.0, I can see it trying to connect, as it reboots the controller board as always, but on the terminal, it shows:

Changing monitoring state from "Offline" to "Detecting serial port"

Serial port list: ['/dev/ttyUSB0', u'/dev/ttyS0']

Trying /dev/ttyUSB0

Could not connect to or enter programming mode on /dev/ttyUSB0, might not be a printer or just not allow programming mode

Trying /dev/ttyS0

Could not connect to or enter programming mode on /dev/ttyS0, might not be a printer or just not allow programming mode

Changing monitoring state from "Detecting serial port" to "Error: Failed to autodetect serial port, please set it manually."

Failed to autodetect serial port, please set it manually.

I assume that if you select AUTO for the device, OctoPrint wants to make sure that this is something that can respond correctly if an attempt is made to put it into programming mode. Note what happens on line 2613; a list of one doesn't go through the stk500v2 handshake.

The same problem here. I even doesn't find that the manual connection settings fixes the problem If I try to use AUTO mode, it fails imediately and Octoprint has no response - only fix complete restart or "service octorint restart".

I do this for a living. All these cards are different, no matter what they say. The Duet doesn't like M999 and will drop the connection, the Smoothieboard won't continue past a panic if you don't M999, etc. You just get to the point where it's like "fuggit, ship me the damned board and I'll test it here".

So the issue seems to stem from the actual autodetect never working to begin with with your printers, and things just working since the only detected serial port was your printer (which would bypass port autodetect). 1.4.0 added a new port pattern to accommodate some setups out there, and that matches something on your system for whatever reason which doesn't present on my machines or that of most of the testers it seems.

Long term solution: I'll throw out the garbage port detection that never really worked for most people anyhow and adapt what I'm doing for baud rate detection to port detection as well, as already mentioned.

If anyone plugs another smart USB device into their Pi (other than their printer), then I highly recommend creating a udev rule to match their printer board and manually set this alias up in OctoPrint.

Short version: sometimes your printer board and another device fight over /dev/ttyACM0 (or similar) status and OctoPrint could be confused. Setting it manually makes it connect much faster and without so much testing.

You can't set it manually. When the printer gets powered off it reverts to AUTO when the device isn't detected anymore. When you turn the printer on you have to refresh the connection list and select the port manually ever time.

In my case, I have one and I'll need to edit it. It's also possible that it doesn't exist and could be created. If it doesn't exist then sudo touch /etc/udev/rules.d/99-usb-serial.rules to create an empty one. Next, sudo chmod 644 /etc/udev/rules.d/99-usb-serial.rules so that the rights are correct.

Note how I've plugged in the idVendor and idProduct which we learned earlier. Also note that I'm creating an alias of /dev/smoothieboard for my board. Yours will likely be different so make the necessary adjustments for your setup. Be careful not to use anything as an alias which might already be used so feel free to call it chewbacca or something unique.

It works now however. I can finally walk up to the printer, turn it on, and print something with OctoScreen without fussing with my phone or WebUI. Huge thanks for the guide. I am sure it will come in handy for others that have this issue until it is fixed.

On a fresh reboot I can sometimes get it to connect but most times I get an "[Errno 11] Could not exclusively lock port". This is with the PiCam disconnected. Also tested a different USB cable on the other bank of USB ports. Disabled all plugins except PSU Control (I would have to disassemble the printer and re-wire).

There was a template that you should have used to describe your problem. You may consider this a waste of time to fill in that template, but actually we need the information provided in this template to be able to help you out. I suggest you open a new thread to copy the template and take the time needed to fill in the information.

According to your logs, your printer is connected to /dev/ttyUSB0 so you shouldn't bother trying with other serial ports (i.e. /dev/ttySnn, which are serial ports from your computer, and not connected to anything in particular).

It seems that OctoPrint is able to send the M110 N0 command, but your printer isn't responding in time. Could you try to enable serial logging (Settings, Serial, General, Serial logging at the bottom of the menu), try to reconnect to the printer and then upload the serial.log file.

Not expecting any kind of answer in particular, but this info tells us which kind of user runs the processes and if we should look for permission issues. I assume not, as you said the printer worked fine with OctoPrint 1.6.0, and I assume the same user ran the OctoPrint instance then.

Only that the printer doesn't answer in the 2s after the M110 N0 command is sent by OctoPrint, which OctoPrints assumes as a timeout... You could try to increase the timeout windows to see if something changes. These settings are located in Settings, Serial, Intervals and Timeouts, and then Timeouts.

OK that's definitely strange, but according to the serial.log file you provided and the screenshot you took, the serial port should be /dev/ttyUSB0 and the Baudrate should be 2500000. Could you try specifying those settings to the 1.7.0 instance ? You would perhaps need several attempts before it works. Though anything beyond 20 attempts is certainly pointless. You should wait a few seconds between each attempts, just to be sure. Before doing so, you would have to deactivate the 1.6.0 instance obviously...

EDIT: looking at your 1.6.0 systeminfo bundle, for this instance, you're using Python 2.7 and no virtual environment, how did you install it ? Because we're looking at two things that behave differently with different underlying software, so there's too much variables to take into account for what could go wrong. Besides, Python 2.7 is deprecated since 2020, so you shouldn't really use it anymore, but that's a totally different debate...

Not saying that at all, just trying to figure out what's happening. That's very strange, because in the code I provided, I specifically asked for the Python 3 binary by providing the python3 command...

it's because there's a setting in the config.yaml file that tells it to. Those settings are one time settings, since the instance started, the next start should be in regular mode, with plugins activated. So all you need to do is restart octoprint.

The public domain software package called NTP(Network Time Protocol) is an implementation of the same namedTCP/IP network protocol. NTP has been initiated in the 1980's byDave L. Millswho was trying to achieve a high accuracy time synchronizationfor computers across the network. The protocol and relatedalgorithms have been specified in severalRFCs.Since then NTP has continuously been optimitzed and is atpresent time widely used around the world.The protocol supports an accuracy of time down to nanoseconds.However, the maximun achievable accuracy also depends on theoperating system and the network performance.

Currently there are two versions of NTP which can be used intermixed:NTP v3 is the latest released version which runs very stableon many operating systems.NTP v4 has some improvements over NTP v3and has better support for some operating systems.Additionally, there's also a simplified version of the protocolcalled SNTP (Simple Network Time Protocol). SNTP uses thesame TCP/IP packet structure like NTP but due to the simpleralgorithms, it provides only very reduced precision.The NTP package contains a background program (daemon or service)which synchronizes the computer's system time to one or more externalreference time sources which can be either other devices on the network,or a radio clock which is connected to the computer.

The standard NTP distribution can not be run with Windows 9x/MEbecause there are some kernel features missing which are required for precision time keeping.For Windows 9x/ME and other platforms which are not supported directlyby the NTP package there are some NTP or SNTP programs available onthe internet.An overview of available programs can be found on theNTP support home page.

Nowadays many workstations are shipped with a pre-installed NTPclient, so Meinberg also offers various plug-and-play NTP time serverscalled LANTIME NTP time server with differentreference clock options, e.g. built-inGPS or DCF77 PZF receivers. The devices also have a network interface and power supplyincluded and are assembled in a standalone case and ready to operate.

Beginning with NTP version 4, the naming conventions were changedto be more straightforward, so now the name of the NTP distributionitself and the names of all the programs included start withntp (e.g. ntpd, ntpq).

Some Unix-like operating systems use a script to start the NTPdaemon at system start-up.Sometimes the script still has aname starting with xntp even though the real name of the daemon is ntpd.This is the case, for example, forSuSE Linux.

These features can be used to set up a hierarchical timesynchronization structure.The hierarchical levels of the time synchronization structureare called stratum levels. A smaller stratumnumber means a higher level in the hierarchy structure.On top of the hierarchy there is the daemon which has the mostaccurate time and therefore the smallest stratum number.

3a8082e126