Slashdot Mirror
Ask Slashdot: Supporting "Antique" Software?
First time accepted submitter wolfguru writes "As the IT Manager for a large printing firm, I often have to provide hardware to support older software which is used to configure and maintain existing systems, some of which are nearly 20 years old. Much of the software uses RS-232 serial communications to connect to the PLC devices and is often 16 bit versions. Newer systems from the PLC manufacturers supports some of the equipment, but many of the older PLC consoles are essentially unreachable without the serial communications. For any of you faced with similar challenges in keeping a manufacturing environment maintenance department working; what do you use to support them and where do you find equipment that will run the older systems that are sometimes the only means of supporting these types of devices?"
If USB to serial adapters cause communications problems, most motherboards still have RS-232 headers on them (residing at DOS friendly COM1), just need the bracket. Most of them can run DOS as well as long as they have a BIOS boot option as an alternate to EFI mode.
Here are some observations about why the problem isn't as difficult as you are making it out to be.
First and foremost, for older PLC hardware, the PLC hardware was considered to be the valuable part, and the software/drivers were considered to be overhead that they had to have to sell the hardware. So most of the serial protocols for these things were well documented in order to reduce support costs. In general there was either reluctant free support for their software/drivers, or you paid a fee per incident. If support contracts were an option ... you are unlikely to have kept the payments up this long. So you will likely be writing some code, but you will likely have documentation with which to do it.
Second, the FTDI drivers are crap. They leak kernel memory in Linux when you unplug them while the device associated with them is open. They also do this in the Windows Drivers, and because Mac OS X is religious about its encapsulation model in IOKit, unplugging them in Mac OS X while the device is open generally leads to a kernel panic. Almost all the USB-to-RS232C/RS422 adapters use chips sourced from FTDI, or use clones of the FTDI chips so they don't have to actually write their own drivers. Rampant code copying between vendors is my suspected reason that most of these vendors refuse to document their hardware well enough that an Open Source driver without the bugs could be written. You are unlikely to be happy with USB fobs.
Third, 9 pin RS232C is frequently not enough for a lot of older devices. The RS232C specification allows external clocking of the signal, but these pins are not present on the 9 pin connectors, only on the 25 pin. Additionally, there is out of band signaling that is sometimes used on other RS232C pins that aren't as frequently used that can be necessary. As you are with a printing firm, if what we are talking about here is an old Linotype or similar machine, you are likely to be SOL without full 25 pin RS232C. You should be happy that it isn't an 8 pin DIN cable from an old Mac, since at least you get the RI pin on the 9 pin connector.
Fourth, terminal servers often have these issues, in spades. There are a number of terminal servers where, if you have a blocking outstanding read on the serial port, outgoing writes are blocked until the read completes or times out. They basically expect that you will poll, or that all your communications over the serial port will be synchronous (i.e. you will not end up with output to your Wyse-50 until after you have input something). I can name a number of vendors with 8-port serial cards that have this issue. On the plus side, it's a driver design bug, so if you are swilling to use your own driver, or are willing to go Open Source OS, this is typically not a problem, but you will end up screwed by Windows and Mac OS X -- but a Mac OS X subclass of the broken driver is easier than an entirely new driver written in windows. Computone 8 port cards used to have this problem a lot.
Fifth, and finally, with USB dongles, it's frequent that the modem control signals are borked up. What I mean by this is that until the pseudo tty USB driver on the host side of things is opened, then the pins on the RS232C side of the adapter are floating in an indeterminate state which depends on the USB fob firmware, and is frequently not where you would want e.g. DTR or CTS/RTS or other signals hanging out for an idle serial port. This can make older equipment Do Things(tm), and the oly real remedy is to get the port open, set the signals right, and THEN plug in the serial cable. Generally, this means that you get to have two sets of signal state for setup, in addition, since the line buffers in some of the older devices are not optoisolated, and on those which are, the optoisolation can blow if you immediately apply voltage before ground, etc.. If you think talking to an old PLC is hard, try replacing an ancient Zilog UART on the damn thing.
It is a case of the 'right tool for the right job.' In some cases ladder logic is still the best choice. Running interlocking or normal controls like PID and so forth in ladder makes a lot of sense. Sequential function chart can be useful too, but tends to be overused by IT types who get cornered into control and have no clue what they're doing, as does script. Basically, what I'm saying is if we ever throw out ladder, it means we're being pretty thick. Ladder has a place and makes a lot of sense from the process POV, throw too much of it out and you're being stupid.
Naturally, put the 'hardware' ladder system into a suitable PLC that can do SFC as well as ladder and the scripting language of your choice, but don't throw out the logic. That is often still the most logical solution and IT types who think ladder is obsolete should honestly be shot at dawn for the bastards who create un-maintainable messes of spaghetti code that they are. Siemens programmers are the worst culprits here.
I have determined that my sig is indeterminate.
Actually, newer SVN + patches builds for DosBox go much further than that:
http://www.dosbox.com/wiki/SVN_Builds
The best one, if you ask me, is the SVN Daum build (alas, their website is down at the moment). To quote its set of difference to Vanilla DosBox:
Description: The Windows build incorporates Direct3D with pixelshaders, OpenglHQ, Innovation, Glide, zip/7z mount, Beep, NE2000 Ethernet, Graphis user interface (menu), Save/Load states, Vertical sync, CPU flags optimization, Various DOS commands (PROMPT, VOL, LABEL, MOUSE, etc) and CONFIG.SYS commands (DEVICE, BUFFERS, FILES, etc), Continuous turbo key, Core-switch key, Show details (from menu bar), Nice DOSBox icon, Font patch (cp437), MAKEIMG command, INTRO, Ctrl-break patch, DBCS support patch, Automatic mount, Printer output, MT-32 emulation (MUNT), MP3CUE, Overscan border, Stereo-swap, SDL_Resize, MemSize128, Internal 3dfx voodoo chip emulation, etc.
I emphasized the important bit. What these two little words mean is the this DosBox build can not only emulate a DOS printer to dump stuff into various output formats (PNG, PDF, etc.), but it can also pass along the output to a Windows printer driver (which allows you to print to any USB printer) as well as use a real parallel port on your computer to let the DOS talk directly to the printer.
I know at least one company that is using this DosBox build to support printing out of a 20+ year old billing software.
I'm surprised nobody has simply named the obvious, which is just pick up an older laptop on ebay. Plenty of old Toughbooks still out there, built like tanks,, with RS232 already on them. Sure it isn't as fancy as setting up VMs and trying to get them to talk to the old gear but sometimes the simplest answer is the best IMHO.
ACs don't waste your time replying, your posts are never seen by me.