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.
The strategy should include a short time support strategy for old hardware. You can run 20 year old software on today's PCs either directly or in a virtual machine. However, you might have problems, because they are too fast. This short term support must be supplemented by a migration strategy for the old PLCs. I know that is hard, have worked in a project using PLCs in railway control systems, which have to run for 20 or more years before they are replaced again. Therefore, you need also a strategy how to replace the replacement in the future.
One important tool to do this, is detailed documentation of protocols (including timings) and semantics of the software.
A few posts ago I wrote about Industrial PCs.
If you need just a serial port, and not complete PC running old software that needs to access serial port directly, there are boxes from Moxa that let you connect dozens of serial ports to one PC.
16 bit software. What OS? Windows 3.1? 2.11? OS/2? DOS? Xenix? Beside the RS-232 problem, finding new hardware for these OS can get difficult. As others stated, you can use VMs to run, but it would help us answer the question if you list the OS. Just finding old OSs can be quite difficult. (legally)
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
There is demand for a DOSBox like product that supports legacy productivity apps. I haven't had any problems running things like Wordperfect 5.1. If anything they are easier to get running compared to picky DOS games and demos!
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.
On a modern OS, such as Windows or Linux (preferable), you can use a virtual machine to run older DOS and such operating systems, passing the RS-232 ports of the host though to the virtual machine. Works great for me, and I use that for dealing with similar embedded systems all the time. FWIW, my preferred host OS is a clone of Red Hat Enterprise Linux (RHEL) 6, Scientific Linux (SL). CentOS is another such clone, and widely used in industry. I use SL because I personally know the maintainers of SL at Fermi National Laboratory in Illinois (my wife is a staff scientist/physicist there), so if I have an issue, I can contact them directly. My preferred virtual machine manager tool is currently VirtualBox (open source, from Oracle/Sun), but KVM will also work very well for this. That said, I prefer the GUI and configuration tools provided by VirtualBox.
Sometimes, real fast is almost as good as real-time.
All about risks, not just the fact the device is RS-232 only, but can the manufacturer support the equipment and if it fails whats the cost to the business while the machine is down.
Sure we can all get 486's with ISA cards if the device needs connectivity to the outside world, but the device of that is a business risk and needs Mgmt to be aware of the issue.
I've had a parts carousel system go down for weeks while we replace gearboxes, made worse by a switch from AC to DC by the manufacturer. Costs to the business were huge and all production was slowed down. Mgmt were informed of the risks but wouldnt spend any money till if broke.
Basically you're looking at a CYA situation, make sure mgmt are informed in writing (email etc) of the issues around the machines and what costs there are vs getting in new machines and added benefits of new machines
Ethernet and USB to RS-232 are great solutions, but sometimes software is written a little too specific to HW, like CPU clock speeds, system IO chips, etc., and it just won't run in newer OSes and virtualized environments. For that reason I've kept a few older motherboards and systems and I've had to run them from time to time- ISA slots, 5.25" floppies, even 3.25" floppies are rare for me these days but once in a while, needed. About a year ago a guy paid me around $200 to recover lots of files from some XT and AT class hard disks, and I was able to do it (fairly easily).
Everyone has "upgrade fever" but I don't necessarily recommend it. Often the 20 year old software is well written and works 100% in its correct environment.
A good friend of mine works at a company with just this problem. They have a very expensive CNC machine. The software is very hardware dependent- needs to see old AT architecture stuff, the original 5.25" floppy (software key), CPU clock dependent timing loops, etc. The whole machine was wearing out and needed so much overhaul, all new bearings, slides worn, etc., they finally scrapped it, but replacement cost hundreds of thousands. But during it's 25 year lifetime they kept some older PC hardware around for spares and kept it running.
It might be more cost-effective and time-efficient to find some older stuff on ebay. Maybe I should rent out my systems / services!
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.
What doesn't DOSBox have that games don't need but business stuff does? Usually games are those things that require very good compatibility, and DOSBox is perfect in my experience...
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.
Those often run into problems. Often when using those I have had to fiddle with settings. Some software has limitations as to which port the device needs to be plugged into. Yes you can reroute but thats part of the fiddling. Getting a stack of old laptops with rs232 ports has always been the most reliable way I have found. Sadly ensuring you have enough to last the life of the device your communicating with can be an issue.
Just make sure you get one supporting the flow control lines, which most cheapo adapters don't. Most industrial equipment i've worked with wont communicate without those.
Oh, God! That makes me feel sick. We had messes like that when I started working at this company. There are exactly two of them left, and one of them is being dismantled to be carted off to the junk yard. The remaining one is rapidly becoming so expensive to maintain, that no one can justify keeping it around.
We'll still have ladder logic for a long time to come, but no more of those freaking tangled spaghetti wire boards!
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
Am I the only one laughing at the thought something from the early 90s is now considered antique?
DOSBox is really, really good but does not include printing support. That can be a problem with productivity apps; you have to print to file then print the file (not even possible with every app).
There is a SVN build that includes Epson LQ (ESC/P) color printing support. It isn't perfect, but it works. With some changes, DOSBox could easily intercept data written to LPT1: and send the output to a file.
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.
why don't they have it print to postscript. many modern printers take postscript input so it would not be hard to have it pipe the input to the printer.
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
100% of RS232/RS485 to ethernet adaptors I have worked with have had at minimum IP level filtering. Trivial to defeat, I know, but most sit on networks with no direct connection to the internet. And honestly if you've got a hack on your subnet you have bigger problems than the fact that he can access your unknown (to him) PLC. Like the fact that he can own your SCADA and break things without having to understand ladder logic in the PLC.... Worry about your SCADA first, and your conversion devices second....
I have determined that my sig is indeterminate.
Is see if the PLC manufacturer supports newer hardware/software. I went through this in a few places. Ancient systems in place to do a specific function.
But where I could I replaced them with more modern hardware and software. Sometimes I'd have to write the software myself but it got done.
Maybe I phrased that poorly - my complaint isn't the logic, but the spaghetti wire boards. Yes, we'll have ladder programs for a long time to come, because it works wonderfully in the type of application that it was designed for. But, it's SO MUCH simpler to work with in an ActionLogic or comparable PLC!!!
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
Not even. Our data center had an irreplaceable piece oif software that was not Y2K so they just declared that 2000 = 1970. It was finally replaced last year (1982).
That is an awesome idea. Let us know when you commit that!
I am very small, utmostly microscopic.
What about using a terminal server for RS232 stuff? There are plenty of them out there that are designed to give you a console connection to network gear. Seems like you might be able to hack something like this to make it work. Essentially you would load a driver on a PC that makes it think the serial port on the terminal server is a local RS232 port.
I don't understand the question. Why is running hardware via serial ports a problem? Serial ports have been included on almost every PC made for the last 30 years. I have plenty of serial port based hardware. You plug it in. There are literally billions of computers on the planet with serial ports.
I don't respond to AC's.
I would really hate to have to deal with those boards, or even the massive relay logic banks that they used to use. You do have my sympathy....
I have worked with a lot of PLCs, but never action logic. Always curious, how do they compare to the Allen Bradleys and Omrons of the world? I am not tied to any particular setup, except I do have an abiding hate for the bloated mess that is Siemens.
I have determined that my sig is indeterminate.
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!
the way they supported old lines at (major environmental controls company you've all heard of) was to keep all the old 286 machines and line printers in a back room the size of an 80s living room, and repair, repair, repair. label printing for boxes on the production line was old Printronics machines, which was the big headache.
if this is supposed to be a new economy, how come they still want my old fashioned money?
My employer has only recently taken off sale a re-shelled 1980s Object Pascal application that needed direct serial and parallel access and we were able to provide machines that handle it and the various peripherals perfectly well. Intel Reference boards (which they're withdrawing for PCs sometime soon unfortunately) and Startech PCI-E cards for the ports. I think the boards even have a floppy controller although the need for them was finally removed by an upstream supplier buying some CD burners a few years back.
Something written to work on 1987 grade hardware can sometimes run faster than intended on a Core i7, though.
Trivial to defeat,
Only if its UDP, and only if you dont care about return traffic.
Spoofing an IP is really only useful when you are flooding a target and really dont care about bi-directional communication, or if youre punching a hole in a firewall with the help of an intermediary server.
You know, when i was new to the industry, I would have thought you were full of crap.
But now I find that sadly plausible.
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/
They are cheap, almost indestructible, small, low-power and ancient enough to comfortably run any legacy application out there, even under pure DOS. Should one break (which is, in itself, rather unlikely even for heavily used units), full service manuals are available and having lots of them means easy replacements. They have traditional, hardware RS232 and LPT ports, one of each. As long as you need a single machine for a single PLC, X40s should be one of the best tools for the job.
This is Slashdot. Common sense is futile. You will be modded down.
Vendors, such as Apple, Microsoft, etc, should be required to continue to support older software in their new hardware and OS releases.
There is no excuse, except greed, for them to drop support for Classic, Rosetta, PPC, etc. The new hardware, even a lowly iPodTouch, can easily emulate the old systems by orders of magnitude. There is a tremendous amount of not just mission critical software such as the above article discussed but also simply good software like what came out of the hay-day of educational software programming during the 1990's.
Apple and Microsoft have committed cultural and intellectual crimes by dropping compatibility such that older software can't run on the new OSs. They have HUNDREDS OF BILLIONS (yes, I'm shouting) of dollars and could not just afford but should be required to provide backward compatibility.
If they plan to stop providing backward compatibility then they should be required to give up all copyright, trademarks and patents related to the hardware, OS and software and provide full documentation five years before they sunset it so that others can pickup the software, OS or hardware.
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
I am actually working with such systems right now! I've been trying to remote into an HP 1000 unit over serial but can't get the hyper terminal settings right to send the break command over and get going, it call comes out as corrupted. What has your experience been with this? We have no documentation for the manroland folks/ HP so I've been digging around.. happy to get communication back over MUX 0 to even see nonsense coming back from the terminal... Perhaps I can't use hyperterminal or ADVLINK so... I was very frustrated and happen to see your post! What are the odds? I was hoping for some terminal settings such as flow control etc for these things but have had no luck! Mostly we have been trolling around online to find legacy vendors that have amassed the stuff, to respond to your question.
Networking.
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.
Better be careful about shorting hardware flow control pins. I've seen CNC mills where someone did that. (Google "CNC Drip Feed"). The feeding PC didn't know the CNC controller buffer was full and kept sending data. When the CNC controller began accepting data again, it had missed hundreds of lines of code. The move commands drove the cutting tool into a bad place and people almost got hurt.
Your advice to learn RS-232 was excellent. But one must understand the flow control issues before you can know how to cable it.
Place nail here >+
By the way, here's a working link for those who wish to download this version of DosBox, while the original website is down:
http://www.emucr.com/2013/02/ykhwongs-dosbox-svn-daum-build-20130205.html
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.
Stop mixing OSS with "source available" software...
Stop mixing OSS with "source available" software...
I'm not sure what you're getting at here... DOSBox is GPLv2, so is OSS by any definition of the TLA. A source available license doesn't necessarily allow you to make changes to the code so obviously I wasn't referring to that.
But DOSBox is itself an application and does not have to output the same stream as the applications it contains.
"I've got more toys than Teruhisa Kitahara."
This link leads to a maze of adware and shit. What the hell?
I finally got this link to work.
http://www.sendspace.com/file/gpof0m
Click the non-flashy download link labeled "Click here to start download from sendspace." There are a million other buttons trying to get you to click on crap.
I occasionally have to interface with Square-D SyMax PLCs from the early 80s. We still have equipment at customer sites that's using it. The software we have to do the programming uses software timing loops so I have to use a 386 or early 486 laptop to run it. I have this very old 386 laptop with an 80 Meg hard drive that still hangs on and boots. I've warned my boss that someday it won't boot and we'll be done.
"Do the Right Thing. It will gratify some people and astound the rest." - Mark Twain
A company went a step further and modified DOSBox to support their USB-to-ISA bridge adapter directly: http://arstech.com/install/cms-display/ste_uniformdos.html That CVS build list is interesting, what is the point of MP3CUE support?
An RS232-to-Ethernet device is should be essentially a hardened Raspberry Pi running a modern Linux, configured for security. The communications should be established using ssh configured for login only using known keys. This can be set up relatively easily to be pretty foolproof and can probably beat 99.99% of commercial products out there when it comes to security. It's really not that hard.
A successful API design takes a mixture of software design and pedagogy.
Someone's got to look after us in our old age.
The initial problem with these I have found is that you can end up with e.g. COM12 after plugging in the adapter. The fiddling you have mentioned then becomes necessary. The more insidious problem I have seen is when the COM port number mapping changes, since it's really not a "fixed" port. Now you foist the task of fiddling on to the guy in the field, who may in no way be qualified (rightly so) to do such a task.
As an example, the FTDI drivers by default key the port number on the USB device's serial number. Plug in a different adapter, you get COMn+1. As luck would have it, FTDI does provide a registry setting to adjust this behaviour but you need to know it's there first.
Even worse regarding fiddling is if your application does fancy things with Windows overtop of the COM port. For example, running a null model Internet dialler (ppp). God help the poor soul who needs to fiddle with that mess while the customer is breathing down your neck. What we did was add in to our application some C/Win32 code to allow "reconfiguration" of the ppp dialler in the event the COM port mapping changes. We found that to be a poorly documented black art API that would sometimes require a reboot, sometimes not.
Regarding paths forward to deal with the general problem of RS-232 obsolecense in consumer laptops I see no adequate alternatives. Ethernet/TCP? Lack of a standardized IP addressing configuration makes it too cumbersome to field personnel since all vendors will implement their interfaces differently. USB? See the preceeding paragraphs. Couple that with the fact that the complexity of the protocols and software required to implement communication via TCP and USB are ridiculous to that of RS-232, there is no reasonable solution that I have seen yet. In an embedded system, UART (RS-232/422/485) core I/O routines can be written in one or two dozen lines of code. Lines of code for TCP/IP and USB stacks easily number in the thousands, and may also require a multitasking OS for certain API requirements. Because of this, UART interfaces aren't going away any time soon.
If you are too dumb to know what type of PLC is implied by the context, the moron arrow is pointing at you here.
I would go with one of the Ethernet based terminal server solutions. They are reliable and well proven.
To be perfectly honest - I've not had time to get into that ActionLogic5 controller. It's been in the plant for about two years now, and it has "just worked" all this time. Setup was very much like an Allen Bradley - in fact, the housing looks very much like an Allen Bradley. I suspect that it's a rebranded AB.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
Good point... You would need two way comms to get into most PLCs...
I have determined that my sig is indeterminate.
Of course not, but it has to emulate the relevant printers. Only then can it receive what the printer would have received from the application and do with it whatever is convenient (dump to disk, pipe to printer, convert to PDF/XPS, call Windows' print stack - listed in what seems to be least to most convenient).
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.
I'm conceptually surprised by the title, the author complains about supporting antique software, then complains about hardware issues.
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
Before embedded web pages became de rigeur, configuring network equipment seemed so much more mysterious. And billable. I used to love the money received from tapping into customer's serial ports, but that's about all I miss.
-- Jimtown Kelly
Empress database? There's a local company that is still doing the same thing.
"Think about how stupid the average person is. Now, realise that half of them are dumber than that." - George Carlin
IT didn't choose this, or at least not in any case I'm directly familiar with. Industry as a whole has a huge number of PLCs which in general are programmed internally with ladder logic which interfaces with very old systems. These are the process controllers and flow controllers used in the chemical industry as well as industry in general.. As long as they work and are supported by the manufacturer or are simple enough to repair in-house, they will remain in service. I know of many systems still in service that were installed before I quit and went to college in 87. Those would be a minimum of 26 years old. If it works, don't fix it. Then you have Chromatographic integrators interfacing with data collection systems which can be another PITA
In the second instance: If it were a ground issue, it wouldn't be solved by using USB, as the ground is continuous throughout.
In the first instance: Who the fuck knows. There are too many dodgy API layers to immediately blame wiring. But grounding (and any loops) would stay the same, as long as the replacement laptop were plugged into the same outlet as the new (native RS-232-less) laptop: Switching things around should not create new ground issues.
Kid-proof tablet..
Interesting.
In your first case, have you tried getting a PCMCIA (preferred) or Cardbus (less-preferred) or ExpressCard (possibly useless) RS-232 interface?
In the first two instances, generally: Proper voltage levels. Real serial hardware with real hardware interrupts.
ExpressCard is iffy only because ExpressCard exposes both a PCI-Express bus and a USB interface, the latter of which might be used instead of the PCIe bus (depending on the particular serial adapter)....which means you might get a USB adapter in a different form factor.
And why not just run DOS on the machine, anyway? It's not like you need Linux and DOSBox to drive a serial port, even in 2013. Last I looked, new cardbus/PCMCIA RS-232 interfaces still came with DOS "drivers" (more like at-boot configurators, but whatever), and should work every bit as well now as they did back then: Assign it to COM1, run the industrial control program, and move on with life.
Kid-proof tablet..