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?"
Fortunately RS232 is still well supported via PCI-e cards and USB, so you can just run the old system in a virtual machine on modern hardware to avoid many of the problems associated with maintaining old gear.
My only other advice is to never underestimate the costs, especially when talking to your boss. He/she will want guarantees that everything runs smoothly all the time, which realistically you can't provide without plenty of redundancy and extensive testing. Be clear that old hardware is hard to maintain and repair, and not trivial to replace.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
They are a god send. For software I use RSlinx Gateway which is for Allen-Bradley PLC's, but has many different driver solutions. Also it will allow you to bridge network connections if your running DH 485/RS 232/DF1/ DH/DH+/Ethernet. Gateway is expensive though there might be a more cost effective solution.
At work we use Industrial PCs for work with PLCs. You can still buy PC with an ISA slot, and most of industrial PCs have good old serial port. Just contact any competent supplied of industrial automation equipment.
One of manufacturers is Advantech. Have a look at their UNO line of "brick" computers. Plenty of industrial RS232 and RS485 ports even in the most basic models. Computers are fanless and built to last. Unfortunatelly, those machines are bloody expensive.
If you look really hard, you can even find new 486 machines. Those are even more expensive than Advantech bricks I wrote about, but there are still people that need those computers, so there are companies able to provide them at a cost.
Hi Timothy,
Unfortunately, you didn't provide a lot of information in your post as to what the problems are.
As people have pointed out, there are a ton of USB to Serial solutions out there so having the modern hardware with the ability to communicate over RS-232 is generally not a problem (although, depending on the connections used, you might want to invest in a RS-232 breakout box and read up on RS-232 handshaking as many of the older devices do use hardware handshaking). I have a few hand wired 9 pin to 25 pin connectors with the CTS-RTS and DSR-DTR pins shorted together as they can simplify your life immeasurably.
In my experience, the biggest problem is retaining floppies & CDs with the original software on them (assuming that the developers are no longer supporting the product/are out of business). If the company is still in business, usually they're pretty good at providing updated software for their products. If they're not in business, then look to see if they were bought out by anybody. Chances are you'll find that the purchaser is still supporting the product, although it may be under another name.
Personally, the biggest issue that I see when I have encountered this type of situation is that the original programs are on floppies. If this is the case, you will need to find somebody with a Windows/95 machine that they're keeping together with spit, bailing wire, gaffer's tape and good intentions - you should be able to copy the program onto a USB key and then burn it on a CD/DVD for more permanent storage.
Once you have the program in a media that you can work with, you may have problems with the installation. You will probably have to create a virtual machine on your PC AND there may be 16 bit programs that you have to convert to 32 bit - here's a great resource that's saved me a couple of times: http://www.reactos.org/forum/viewtopic.php?f=22&t=10988
Finally, Google is your friend. Chances are the answers are out there for your particular equipment.
Good luck!
myke
Mimetics Inc. Twitter
But dos and older windows 9X apps / os may not like USB to RS232 and or pci / pci-e based RS232 ports. Also VM pass though may not work 100%.
You can try running free dos / MS-DOS 7.x or 8 on newer hardware but usb may not work as well.
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.
When you buy a rack mounted unit that does this, it's sometimes called a terminal server. You can provide network to serial access, enable unique passwords on each device and create access lists. When I managed customer equipment, I used to require a DECserver and modem/phone line for last ditch access. In this case, I had firewall, switch, router and console access. Much of this kit is can be found used or see Vnetek. I understand Cisco also makes comparable product. You can pair this with virtual comm port driver, letting you drive these units from a central location.
Answer number 2, you need to put a business risk into supporting antique systems. Cost of replacement, downtime to find part vs lost business. Consider stocking in house pre staged replacement systems.
RS232 to Ethernet devices have a big security problem - they can expose your RS-232 device directly to the Internet. Many RS232 to Ethernet devices will talk to anything that tries to talk to them. Some have built-in minimal web servers for configuration, and those make it easy for attackers to find the device.
Industrial automation people try to have isolated Ethernets for these devices. But then something comes along that needs to be on the isolated net and also needs to talk to something in the outside world. Then someone reconfigures the isolated net to connect to the outside world. Everything still works fine, until somebody breaks in.
This used to be more of a theoretical attack, but there are now search systems out there finding and cataloging control devices reachable on the Internet.
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.
That is an awesome idea. Let us know when you commit that!
I am very small, utmostly microscopic.
Ah, of course. Makes perfect sense - the one thing no game needs but every business user needs...
I can't blame them, I would also avoid touching anything printer-related with a 3,048m pole if possible. I guess it comes down to emulating HP LaserJet and whatever else was commonly supported at the time, similar to what's currently done with sound cards...
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.
You're forgetting that in DOS, every application needs its own drivers for anything beyond text mode output (MDA?) and keyboard input, so there's not a single printer interface to emulate - ideally, you emulate the more popular ones.
DOSBox can't handle Control-Break, which was used an awful lot (for good reasons and bad) in the DOS era.
See my post from further up in this thread where I've linked to the SVN Daum build of DosBox. Among other things, it contains a very good "Ctrl+Break" patch that adds that particularly little oddity with almost 100% accuracy.
Nowadays, the SVN builds of DosBox can do so much more than the Vanilla DosBox, it's no wonder the maintainers can't decide which of those patches to add to the mainline first.
I had to support a manufacturing company 15 years ago that was using (at the time) 15-20 year old gear. I did it by scavenging and making it myself. Robot needs a new SSDD floppy drive? Flea market Commodore. RAM in the Soviet S100 clone going bad? Take apart a broken synth. Winchester drive controller going tits up? Drive around and look at all the junk bins of every computer shop in the county. Need to move a bit of kit but now the non-standard 45-pin cable is too short? Clip the ends off and Radio Shack them to RS-232. I also swapped a lot of gear around; The DOS machine that was used to program one robot was gradually upgraded from an 8088 machine to a 486 as I stole parts from it to keep the CP/M-86 one running.
The other thing I did a lot of was preventative maintenance. Blow out the dust, check the power supply, clean the disc drive, make sure everything is well seated. Switches got lubed, cables checked for faults, and media replaced.
.sig: Now legally binding!
One of the few marketing catalogues I actually use. Sometimes flipping through a book can show you products you didn't know existed. http://www.iebmedia.com/
I have two Windows98 virtual machines to support equipment requiring crusty old modems. They have been running trouble free for several years now.
Power off before disconnecting connecting connector. Seen on a cash register
Am I the only one laughing at the thought something from the early 90s is now considered antique?
Ha, darn kids probably can't fathom the idea that there were real computers in use by companies and organizations before those flashy single chip microprocessor based PCs were all the rage.
No mention of minis like PDP, VAX/VMS (RIP DEC), CDC Cyber (12-bit bytes), Data General, or IBM & Unisys mainframes.
Thankfully there was at least mention of Zilog's Z80, terminal servers, RS-422/485, and green screens.
Bunch of whiny kids. Next they'll complain their first automobile or hand-me-down cathode ray tube colour television doesn't have WiFi and a web browser. Get old my lawn.
Heck, I develop, maintain, and extend software that's over 20 years old. I've worked on software written before I was born. Software approaching 50 years old is more like what I would consider ancient. Like much of the insurance and banking industry in Europe and North America.
So. my serious bit: Learn about industrial computer market, products, and vendors. Use industrial USB to RS-232C converter in most cases (where timing or bit banging isn't used), not the $5 USB-to-serial adapter from the big box electronics store. Take a class from your local community college if PLC or ladder logic is relevant to your environment.
Windows maintains the best backwards compatibility in the industry. Apple, the worst. Why you'd lump these two together is beyond me...
I don't respond to AC's.
Heck, I develop, maintain, and extend software that's over 20 years old. I've worked on software written before I was born.
The software JPL uses to navigate all of its space probes was written by Dan Alderson, who died in 1986. Why haven't they replaced it? Better yet, ask why should they replace it when it works so well. So far, the only failure it's had was when somebody screwed up a measurement conversion, and you can't blame the software for that!
Good, inexpensive web hosting
The beauty of OSS is that if it doesn't work you can add support yourself. And if you lack the technical expertise, pay someone to add the support for you.
A few years ago I was asked to organise a new PC to replace a failing vintage laptop that connected via rs232 to a cnc machine. The problem was that the program didn't seem to work on anything else. DOSBox didn't work initially because the program used api calls that were considered obsolete when DOS2.0 came out. DOSBox had support for those calls but it was broken, but fortunately easy enough for me to fix and it now works great. Or did work until the machine it was running on broke and they replaced it with a laptop that didn't have an rs232 port. For some reason DOSBox + USB RS232 works very slowly and I haven't had a chance to figure out why yet. Or try the SVN builds.
OSS FTW!
Unrelated, I was doing much the same thing somewhere else with a drill, but with slightly more modern software that didn't require DOSBox, but no matter what machine we tried it wouldn't talk to the drill. We tried machine after machine with no success. I asked for a USB serial port but then didn't have internet connectivity to download the drivers so kept analysing the serial output and trying to figure out wtf was going on. Eventually I got internet connectivity, downloaded the drivers for the USB serial port and it worked first time and every time since. I guess the control board on the drill (a paper tape emulator) had slightly dodgy rs232 signalling and for some reason the onboard serial ports of all the computers we tried weren't quite able to talk.
It seems like if someone were to create a small 486 single board computer, similar to a Raspberry Pi, for under $60 or so, there would be an incredible market for it. For running everything from industrial equipment to a DOS/Windows retro gaming rig. Are there any cheap systems like this out there? I've seen lots of cheap ARM based boards but haven't come across any x86 ones.
The sending of this message pretty much inconveniences everyone involved.