discover ttySX port of a printer

[lucasomoura]

A question, I have a thermal printer that is serial (not usb)

I know it's installed somewhere in /dev/ttyS...

what I have done is send it to print, I do:

echo "test" > /dev/ttySX

where I test one by one until I find the right port

Are there any commands I can do to return me what the ttyS of the printer is instead of having to print until I get it right?

I tried several commands and none of them give me the correct information on which port the printer is.

[Aki]

Hello,

Are there any commands I can do to return me what the ttyS of the printer is instead of having to print until I get it right? I tried several commands and none of them give me the correct information on which port the printer is.

As far I know, serial printers do not return as ID code to the computer to which they are connected.
What is you printer and what command protocol does it use ?

[steve_v]

Serial long predates plug-n-pray, so there's no standard way to tell what is connected to a port, and no event emitted when a device is connected. If a device has some kind of query function, it's up to the manufacturer to implement.
Your printer likely does have some kind of "status" query it will respond to, but you'll probably need to hunt in the manual or reverse-engineer a windows/DOS driver to find it.

For a more agricultural solution, if this is the only serial device connected (and it uses hardware handshaking) you should at least be able to determine which port has something connected - IIRC the contents of /proc/tty/driver/serial (AKA serinfo) should show the status of the flow control lines... I don't know if this still works mind, it's been a long time.

[kent_dorfman766]

Serial printer? Wow! How does that work in the 21st centure when today's generation knows nothing about DTE/DCE or RTS/DTR, etc?

To answer OP question...No...some legacy serial printers could be inquired for status, but RS232 is a layer one spec. If knows nothing about, nor does it care about above network layers.

[steve_v]

How does that work in the 21st centure when today's generation knows nothing about DTE/DCE or RTS/DTR, etc?

TBH the main reason I'm rusty on querying those lines from (linux) software is because I use a serial breakout adapter with physical LEDs for that (and sticky labels with settings on the ports)
It still surprises me how many (even "old timers") just go straight for xon/xoff because they can't be arsed working out the wiring... Then drop the baud rate to 4800 because of buffer overruns and complain that it's slow.

As for "today's generation", try explaining how to configure serial comms to a '80s industrial controller to one of those... You can watch the eyes defocus the moment you mention something like "find the appropriate table in the manual then set parameter 9023 in (little endian) binary". Even a simple "step one: read the manual" is met with "ugh, why this so complicated?" half the time.
Personally I find old-school serial refreshingly simple, no "cross your fingers and hope some autoconfiguration BS does magic" nonsense, if you set it up properly it just works (and over a wet noodle if you keep it short). If something is really broken you can debug it with a bog-standard meter and / or scope.
Reports of RS232's death have been greatly exaggerated anyway, my fairly modern (2021 IIRC) desktop motherboard still has a real serial port header, you just don't get the cable and backplate in the box any more. In the industrial scene RS(232/422/485) is everywhere.

[NorthEast]

minicom, kermit or setserial may be able to provide the info you want on the serial port. Also maybe:

Code: Select all

cat /proc/tty/driver/serial

(as above in post #3 by steve_v)

[kent_dorfman766]

It still surprises me how many (even "old timers") just go straight for xon/xoff because they can't be arsed working out the wiring

Oh, my experience has been more entertaining (or is that frustrating) than that. I seem to end up working with the know-it-all kids who don't even consider software flow control, but just think those three magic wires will make it all happen, reliably.

God, thank you for USB!... so long as vendors use the defined driver classes!