Digiboard config on SCO 3.2v4.2

[SoTexPal]

We are limping along on a system that runs an application under SCO 3.2v4.2. It has a Digi C/CON 16 attached. We ran into several problems that we thought would be solved by reinstalling the software for the concentrator via Digi's MPI software. Having very limited knowledge of UNIX, we ended up with more problems than when we started. After many reconfigurations, we finally have all the ports configured properly and most of the peripherals operating as before. One of them, an Accumark 2000 barcode tag printer on ttya13, still doesn't work.

We have a cloned disk drive that we used for backup before we started the reconfiguration. When we boot with that drive, the barcode printer works fine. When we boot with the "live data" disk, the printer just sits there.

We checked the inittab file and its parameters were the same except for hupcl and cread which we changed via ditty. The port is set up as a terminal with login disabled.

I did notice that the permissions on /dev/ttya13 were different - I changed them to give everyone read and write permissions as they were prior to the reconfiguration. The other difference that shows up when I list /dev/tty* is that the fourth column used to show "other" and now shows "terminal".

Ed Fair suggested putting a terminal on the line to see what, if anything, was being transmitted. I'll do that if no one has any other suggestions, as I don't have any parts or tools to do that now.

I would greatly appreciate any help from anyone who has any ideas as to what I should do. Thanks!

 

[PHV]

Some stty setting in the printer interface ?

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244

 

[stanhubble]

besides permissions take a look at ALL the ditty settings of the port on both disks. some of these are the stty settings that PHV suggests, but ditty can control them all.

ditty -a /dev/ttya13

my guess, if the permissions are ok, is that you have a flow control problem. rtspace ctspace ctsflow rtsflow are the ones to look at.

alternately, are the /usr/spool/lp/admins/lp/interface files the same for the barcode printer?

 

[SoTexPal]

Thanks for your quick responses!

I forgot to mention that the peripheral is not configured as a printer port. It was set up as a terminal in the MPI port configuration in both the pre and post configuration disks so it isn't using the interface, model or printer files (as far as I know).

 

[SoTexPal]

Thanks for your replies. "ditty -a ttya13" shows all settings the same. I agree that it seems the problem is flow control related, but haven't a clue about where to check other than ditty. Any suggestions?

 

[edfair]

If not a printer, and not a terminal, then it is doing a raw dump to the port and except for possible setup stuff that could be done in /etc/conf/rc.d/8/userdef (i think it is) it seems a failure to match speeds or some differences in how the handshaking is bypassed.

Any diagnostic tools? A RS232 light kit, perhaps? Would show data flowing. And you could use another serial port running CU to tie into the one not working, dump to the failing port and see what shows on the port using CU.

And rather than using the software, during diagnostics do something like cat /etc/default/lpd > /dev/ttya13.

Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[stanhubble]

if the ditty command doesn't show the printer parameter then the port will not stay open and parameters like baud rate and flow control will reset to their default settings.

here are examples of:

xon/xoff control

ditty printer 9600 cs8 ixon ixoff -ixany /dev/ttya13

hardware control

ditty printer 9600 rtspace ctspace /dev/ttya13

 

[piperent]

That particular printer is waaayyyy old. As I recall, it has an interface connection that only recognizes and responds to pins 2 (rcv), 5 (cts), and 6 (dsr) so you first need to be sure you have the port configured for hardware protocol (this means the port being used must be ttyA13, not ttya13). Next, be sure your cable is correct. Using a cable with only two (2) wires (as in xmt and rcv) will doom any attempts at success. Check the spool interface to assure the proper stty settings are in place. If you have a copy of the 'old' interface used prior to the install, either use it or match the current to it. That's about all I can lend to what has been offered previously.

Hope this helps. At least it gives you something else to look for.

jpiper

 

[apeasecpc]

Since this printer is connected to your digiboard, it is a local printer with an interface file. Sometimes re-installing can cause interface files to be overwritten with a default copy, which most likely would not be compatible with your specialized printer. You should restore the original printer interface file from your backup.

 

[PHV]

it isn't using the interface, model or printer files (as far as I know)
Check the output of the following command:
lpstat -v

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244