We have over a dozen portservers in use which vary from 2 to 16 ports. These are used strictly for printing. O/S is linux. We are exploring use of telnet/raw connect 20xx and 21xx tcp/ip ports. When performing ‘pr myfile | telnet ip port’, it appears there is no flow control. i.e. printing a long file just stops after a couple of pages. This does not happen if we ‘pr myfile > realport-device’.
Is this the correct behavior? i.e. is there no flow-control to prevent overruns when using the ports directly? We are using x-on/x-off.
I think you’ve hit the nail on the head as well. The Realport driver is designed to emulate a standard serial port, so the driver/hardware combo will support hardware and software flow control, and relay control information between printer and host computer where the print job is coming from.
The problem with the native configuration is that although you can set the flow control on the Portserver serial port to match your printer, there is no mechanism to relay this back to your Linux server like there is in the Realport driver. So your print job gets dumped to the telnet connection and begins printing. Once the printer’s buffer becomes full it goes into a flow control state, and the Portserver’s serial port begins buffering the data. If the Portserver’s buffer then becomes full as well, information may be lost because there’s no way to tell telnet to stop sending that data, i.e. no way to relay the “stop sending” message back to the host computer that sent the print job.
I’m looking in these forums to see if someone else is having my problem. This seems to be the same problem that I am having.
We set the application’s flow control to software, the server sending the data to the DIGI PortServer TS 16 to software, the DIGI itself to software, and then finally the printer (Tally T6215) to software.
All is fine when printing, but as soon as we print 2 consecutive jobs to the same port, the first job stops and then second job starts.
The flow control settings are applied on the unit directly and should show ixon=on and ixoff=on, the rest should be off. To set this from the root prompt of the unit:
#> set flow ixon=on ixoff=on range=(port#)
Are you using a print spooler?
Print jobs should be spooled in order to queue jobs until the port is available.
As previously mentioned, when printing directly via TCP, etc… the host sends the data and closes the socket connection. There is no ability for the host to track or have knowledge whether the first job is finished, so a second print job can interrupt the first.
For more reliable printing, I recommend installing the RealPort driver and configure the printer using CUPS. This will not only offer reliable flow control communication, but also ensure the print jobs are spooled. LPD is another option, as well.