Laptops and lack of 9-pin serial

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.

Mike

The USB/Serial converters from FTDI seem to be about the best around. I've had trouble with the Prolific ones but the FTDI ones have been the mutt's.

Chris

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

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...

Cameron:-)

On Sun, 24 Sep 2006 07:35:56 GMT, "Mike Lamond" proclaimed to the world:

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 box.

On Mon, 25 Sep 2006 13:37:43 +1000, "Cameron Dorrough" proclaimed to the world:

I had not thought of these alternatives. I will have to look at the CF stuff. I see using a PDA more in the future.

Thanks for the ideas.

On Wed, 27 Sep 2006 23:27:09 -0700, "Bruce Varley" proclaimed to the world:

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 right directions.

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 and retries.

Cameron:-)

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.

Howard.

Paul M wrote:

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.

I have some experiences with three usb-serial devices with the Prolific chipset.

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.

1. 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.

2. 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.

cheers, Tallak

For the time being, Ebay can be your friend, just full of older laptops. That won't work forever, but we have rat-holed some old machines because some of our customers will not upgrade their stuff.