Re^5: Win32::SerialPort v. New computers

[afoken]

The device becomes a different COM ports on different computers (e.g. COM6, COM11).

Well-known behaviour of most USB-to-RS232 adapters with Windows. It depends on the available internal COM ports (based on 8250 / 16450 / 16550 and clones), the virtual COM ports that once were used (e.g. by other USB-to-RS232 adapters or Bluetooth devices), and sometimes even on the actual USB port into which you plug the adapter. Someone at Microsoft must have decided that it is a good idea to reserve COM ports for devices that had been plugged in ages ago.

This particular imported no-name USB->RS-232 device was based on the Prolific (a Taiwanese company) PL-2303 chips, as I suspect many commercially available models are. Use the install software that comes with the device - NOT a generic driver from Prolific. Make sure the device says it supports Windows 7 if that's what you're going to use it on. I installed it successfully on one XP computer using the device manufacurer's software. When I tried in on another XP computer using Prolific's generic sofware from their website - it failed miserably. Reboot after installing -even if it doesn't tell you to do so.

There seem to be two different kinds of such adapters. Some identify as a generic RS232 adapter and are supported out-of-the-box by the drivers that came with Windows. And the other ones need vendor- or chipset-specific drivers. I would try to avoid the second type, because no vendor spends much money on testing the driver software for a device that costs less than 6 €. Most vendor drivers seem to be rebranded chipset drivers from the chipset manufacturer.

Note that Linux handles USB-to-RS232-adapters a little bit different: The first free device name is assigned, typically /dev/ttyUSB0 for the first adapter, /dev/ttyUSB1 for the second one, and so on. No reserved devices. Unless you configure udev to identify a certain adapter by its vendor and device ID and its serial number and to assign it a constant device name. Other adapters will still get the first free device name.

Alexander

[hennesse]

Alexander,

The device works OK, with one little problem. When I initialize the COM port with the USB->RS232 converter, one of my pumps spins for a fraction of a second. This does not happen with the native RS-232 serial port. I fear the win32 device may have been infected with a certain virus.

The RS-232 does go to RS-485 to an industrial process control system with (not Siemens) PLCs, and might, at a real stretch, be considered a SCADA system. But the USB->RS-232 conveter does seem to issue a #030SB09 command immediately followed by a #030CB09 command - which would make the pump start and immediately stop.

Dear National Security Agency - this is a beer brewery, not a calutron or gas centrifuge. Please remove "Stuxnet".

Thanks - Dave

[afoken]

one of my pumps spins for a fraction of a second. This does not happen with the native RS-232 serial port. I fear the win32 device may have been infected with a certain virus.

Virus: Unlikely.

I think the adapter chip emits some noise on power-up. The RS-232 to RS-458 converter converts that noise to properly formated signal. And finally, the process control system misinterprets that as pump start / pump stop commands. The on-board RS232 COM port probably generates less noise, or has some extra hardware to keep the output lines on a sane level until the chip has reached stable conditions.

Note that USB ports can be powered off by software. This is not implemented in all USB ports, but in some of them. If you connect to an on-board port, try a different port. If you connect to an add-on card, try an on-board port. If you connect to a hub, try connecting directly to the computer. If not, try going through a hub. Look at the Windows device property pages. Some Windows versions can automatically shut down unused ports to save energy. Disable that feature, if enabled.

Other ideas:

• Try a different USB-to-RS232 adapter from a different vendor, preferably based on a different chip. The idea is to find an adapter that emits less or no noise, or at least different noise that is ignored by the RS-485 device.
• Try a different bit rate on the RS-485 device so that the noise is interpreted differently (i.e. as junk that is to be ignored).
• Try a different communication protocol that is less prone to line noise.
• Try adding a little load to the RS-232 lines, so that low-voltage noise is attenuated to a level that is ignored by the RS232 to RS485 converter. A typical "blink box" with dual-colored LEDs and resistors between the various signal lines and GND may be sufficient. Else, try adding a resistor between each used RS232 signal line and GND, about 1kΩ to 10kΩ (0.25 W) should be sufficient. Ceramic capacitors of about 100 nF / 35 V may also help, but they may disturb communication at high bitrates.
• Do you have a ground loop, injecting unwanted noise into the RS232 connection? PC case, PC GND, USB GND and thus RS232 GND are all connected to PE, and you should not change that, for your own safety. The RS485 device is probably also connected to PE, and so is its GND line, and you should not change that, too. Try disconnecting the GND line between RS485 device and RS232-to-RS485 converter to break the loop; RS485 does not need GND. If available, replace the RS232-to-RS485 converter with a galvanically isolated one.

UPDATE:

There is a standard for detecting devices connected to the COM ports. It toggles the handshake lines several times and waits for the device to identify itself by toggling other handshake lines and / or sending some characters at 1200-7N1. Windows seems to use this standard. The RS232-to-RS485 converter does not convert the handshake lines, simply because RS485 does not have handshake lines. How it responds to Windows toggling the handshake lines is not defined. If Windows is convinced that it has found a device because of the handshake lines response, it may send some identification commands to the RS485 device, something like ATI or AT+FCLASS for a modem. That bytes may switch on and off your pump, reliably and every time Windows decides it is time to test for a new PnP serial device.

Alexander

[hennesse]

Alexander,

Brilliant work on the PnP - but the cause was actually a virulant agent: ME

I originally set this system up under FreeBSD, and had no such problem. When I converted it to run on a Win32 platform (with tremendous help from BrowserUK and many others) I did most of the work in the office, only occasionally checking it out in the lab/production environment. I did hear some unusual noise, but couldn't identify it, and dismissed it as something unrelated. It was only when I started fooling with the USB->RS-232 converter that I positively identified the noise as the "hot liquor pump" starting up and then immediately turning off.

While there was no ill effect, this condition just shouldn't happen, and I was (wrongly) convinced that it had something to do with the USB. I went back to the straight serial port and it still happened. I did have a ground-loop, and as you suggested, untied the RS-485 ground from the RS-232 ground. Still happened. After working through the PnP document, I started thinking - there is no way that Windows, or any kind of noise, could send an ASCII sequence of #9SB08 with the correct 2-character checksum appended.

I finally realized that the culprit could only be ME, and after some searching, my face turned red with embarrassment.

It turns out I had left an artifact in one of my threads while testing Thread::Queue communications - and it was turning the pump on. While my digital input/output PLC is configured to start or reset with all outputs off, my software initialization sequence explicitly turns each output off - just to make sure. So I was turning it on in one thread, and my init sequence in another thread was immediately turning it off - just long enough for it to make a brief noise.

Thank you for all your help.

Dave