I need a new laptop and all the new ones lack the old nine pin serial
I/O that many of the PLC interfaces I have need. I bought a USB to
serial adapter from Radio Shack a year or so ago and had trouble with
it locking up the laptop. Radio Shack was no help with support so I
wasted $50 bucks.
I know others here must have faced this problem. What solutions have
you guys found?
I have an IOGear USB to RS232 converter that's never caused any
trouble with my laptops. CompUSA charged a lot less than $50 for
it, too! We've got a couple of Belkin converters that are also trouble-
free. Mine's worked fine with both Allen-Bradley DF1 and GE Fanuc
SNP cable, but not Modbus RTU. That's not surprising given Modbus
RTU ends a message with lack of characters instead of sending real
end-of-message characters. Modbus ASCII should work, but I haven't
had a chance to test it yet. The best solution may be a Modbus TCP
to Modbus serial bridge, either Schneider's or a third party model.
The PC world may be going "legacy free," but the automation world
will be dealing with RS-232 for a long time. I expect some of my
municipal water and wastewater systems to run at least 20 to 30 years
before the next major capital project replaces them. As always, a
lack of spares will be the ultimate cause for replacement.
That has been the case in the past and even with limited use of
microprocessors, it has been hard to keep them running. I have had
lots of discussion with designers about building in points in the
system that lend to easy replacement of segments in a control system.
The hardest part of good design is to make it not only possible but
easy to maintain and upgrade. Time will tell.
Thanks for the info. Everyone's replies will make it much easier to go
shopping this time and maybe even get something that works out of the
If you're using older software that doesn't like USB (flow control issues)
or you don't want to use USB (not enough ports or ports in the wrong place),
your other option is a PCMCIA or CF serial card.
Quatech (www.quatech.com) sell both single and dual-port versions in either
straight RS232 or RS422/485 that work right out of the box - no special
config required. We've been using a dual-port RS232 one for years...
Another possibility is a USB Mobile Expansion Hub. They are also
called Universal Docking Stations. You run one USB cable from your
laptop to the Hub. Earlier models used USB 1.1. Recent models use
USB 2.0. Then the Hub typically has the following output ports.
2 USB Ports.
1 DB25 parallel printer port.
1 DB9 serial port.
2 PS/2 mouse and keyboard ports.
Estimated cost $50.00.
Paul M wrote:
I have some experiences with three usb-serial devices with the Prolific
So far the devices have been unstable installation wise. I have found
some workarounds to these issues:
1. Always use the same usb plug on the laptop. By using different
plugs/ports, new serial port numbers are assigned every time. You can
reconfigure the comm port number in windows in the device manager, but
it's only fixed as long as you only use one plug.
2. Sometimes I have to insert the usb plug a few times in order to get
all the functionality of the serial ports to work. The problem I mostly
see is that one of the ports are missing or that the traffic Rx or Tx
is not working.
3. Instead of using two separate usb-rs232 devices in two separate
plugs, I bought a dual serial port to usb device (sadly also with the
prolific chipset ;-) This works a lot better, as with the two separate
plugs I had trouble knowing which serial port the plugs were mapped to.
It's a major headpain and I often end up using more time debugging the
serial ports than the device connected to it. By using the usb-serial
port in the exact same manner every time (same usb port, plug in twice)
I am able at least to cope.
I'm in the process of porting my own industrial serial comms utilities to
WXP/USB. It's been a bit of a struggle, but I've learnt a few things in the
process. IME, if there's a problem, it may not be caused by USB port
emulation, rather by changes in the MS OS over the years. Later versions of
Windows, probably NT and after, schedule tasks differently to earlier ones.
My software was originally developed, and ran fine, under W98, but had
problems under XP, the data rates were very low (peak serial transfer rate
about 10 chars / sec) and huge hogging of CPU usage. The problem turned out
to be program constructs that are not recommended with the newer W32 systems
but were common previously, such as wait loops. I loaded my software on an
XP machine with a real COM port, and it performed equally badly. A fairly
substantial rewrite, with assistance from a good API reference, has restored
the original functionality completely, there's no discernible difference
btween the new and old platform, or between native COM port / USB.
One other thing that may cause problems with really old, DOS-based software
may be use of direct I/O instructions rather than Windows API calls. In the
DOS days it was common to include direct hardware I/O access instructions in
code (the BIOS and DOS APIs for serial comms were atrocious), the modern OS
probably won't support these (can someone confirm this?). USB may be a
contributor here, because the port emulation drivers may interface with the
File I/O API calls that Windows uses for serial port access.
So before you blame the USB, it would be worth checking your software out on
a machine running the same OS and a native COM port. And when you run it,
check the CPU usage, you may get a surprise.
On Wed, 27 Sep 2006 23:27:09 -0700, "Bruce Varley"
This is very interesting and useful to me. I tested out the serial to
USB converter on a Garmin GPS connected to a laptop running XP.
Although I am not looking forward to the task, I will have to do my
homework on the evolution of the USB standards. I am also going to
have to buy or build some type of tester for serial porting.
BTW, I have perhaps posted in the past as A. Paul Montgomery over the
last year or so. I changed newsreaders and just set this group back up
again. My nickname and signature might change again as I just did a
quick setup. Sorry for the lack of continuity.
And thanks for the help. This group is a great asset for me. Being
away from the industry for a few years really leaves you behind in
technical aspects. You guys have really helped by pointing me in the
AFAIK, Windows API calls are still supported (at least up to Windows XP -
not sure about the future!) but ever since W9x, the OS has buffered both
interrupts and I/O calls so that some of the old DOS software will work and
some won't - and some will work over USB and some won't.. depending upon
whether or not the system you are using needs hardware flow control, how
high your baud rate is and how long (or short) your character timeouts are.
The issue I have with USB port emulation (same as external Serial Device
Servers both Ethernet and USB neat as they are) is (a) the additional
software device drivers you need to load to access the ports and the
associated bugs they might introduce, and (b) the additional character
delays caused by the translation.
Both of these can make it really hard for a rookie to get a reliable, fast
link going with a minimum of fuss, because the first one will mean they get
no help from Support and the second means intermittent packet loss, errors
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.