Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

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

by hennesse (Sexton)
on Nov 08, 2011 at 03:30 UTC ( #936647=note: print w/replies, xml ) Need Help??

in reply to Re^5: Win32::SerialPort v. New computers
in thread Win32::SerialPort v. New computers


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

  • Comment on Re^6: Win32::SerialPort v. New computers

Replies are listed 'Best First'.
Re^7: Win32::SerialPort v. New computers
by afoken (Abbot) on Nov 08, 2011 at 13:35 UTC
    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.


    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.


    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)


      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.


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

        A friendly tip, make sure to vocalize these moments, it helps your blood pressure :)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://936647]
[choroba]: bare SQL seems to work differently. Failing a prepared statement doesn't abort the transaction. So it's a behaviour of the DBD driver
[choroba]: and smells like a bug
[choroba]: oh wait
[choroba]: it doesn't abort, but it blocks any other operations than aborting
[choroba]: so it kind of makes sense

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (8)
As of 2017-09-19 14:08 GMT
Find Nodes?
    Voting Booth?
    During the recent solar eclipse, I:

    Results (222 votes). Check out past polls.