LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unknown process sending serial data to my instruments

Solved!
Go to solution

I have a couple of test stations that I am developing test software for at the moment.  When I am actually running them, there's no problem with the serial communications.

 

However, if I leave either of the test stations on without the software running for an extended period of time, I will often come back to find that one of my serial devices (a Keithley 2510-AT) has locked up.  For a while I thought it was  defective devices (strange that two had the same issue), until I found that if I left the serial cable unplugged it would stop locking up.

 

I borrowed a data tap from a co-worker (the 9-pin verison of this) and attached a laptop to the link over the weekend, using Putty to monitor the communications.  I had it save a log of what it found, and I have attached it below.  The first 3 lines were me sending *IDN? queries to verify that the data tap and such were working.  I have edited out the serial number just in case but the rest is the raw data.  Does anyone have any idea what might be sending the rest of the data?  It doesn't appear to be making much sense, but there's a lot of repeated strings in there so it's probably not just random line noise or something.  Both stations have it using the built-in COM1 port of the PC.

 

On one of the test stations I have an Agilent E3646A power supply connected to the station using a USB-to-serial adapter and a null modem cable.  Occasionally it will beep and throw up a ton of errors, all of which are "error 511", which the manual says is a RS232 framing error.  I put the data tap on that line and sent a few *IDN?  commands along with reset and remote-enable commands to verify it worked, and then found that some other process was sending *IDN? queries as well, they just weren't formatted correctly (they appear to not be terminated properly plus have some trailing ASCII gibberish) for the device so it threw the errors.  I've also attached the log from that Putty session.

 

I have tried using the technique in this article to find which process accessed the port, but it seems that whatever process is using it doesn't leave it open long enough for me to find it. 

 

I'm using Windows 7 64-bit on both of these PCs, so that means that Portmon doesn't work, and I can't find another utility that works in the same way.  Does anyone know of one?

 

Does anyone know if there's a NI process that could be sending these signals?  There's a few of them running in the background.  I have 4 other devices on the first station and 6 on the second station that have their own drivers as well, so I can't rule out other people's software.

 

I really really dont's want to have to write the equipment manuals for these stations and include phrases such as "Power cycle the device each morning to reset it" or "Unplug the serial cable when done for the night" or "Ignore any errors from the Agilent power supply".

Download All
0 Kudos
Message 1 of 12
(3,283 Views)

When using USB-serial adapters check that Windows is not "power saving" and turning off the USB port.

 

 

0 Kudos
Message 2 of 12
(3,280 Views)

What I would like to see is the timing. Can the serial tap you are using timestamp the data that is going across the link?

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 3 of 12
(3,270 Views)

I would first check the USB power settings in Windows 7 to make sure it doesn't have the power saving feature of randomly turning off your USB hub enabled.

 

Are you in a noisy environment?  I have seen some weird noise cause some fun interference on serial ports.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 12
(3,258 Views)

First, to clarify in case this wasn't clear:  Only the second device (the E3646.log file, with the malformed IDN queries) is from a device with a USB to serial adapter.  The 2510-AT is plugged into COM1, which is a serial port on the main PC output panel, and has nothing to do with USB.  I don't see an option in device manager to disable power saving on it.  I will disable the power management on the one that does use a USB to serial adapter but I doubt it'll do anything.

 

The device I am using is just in hardware, and the software I was using to monitor it (Putty) didn't have a time stamp option for the lines in the file that I could find.  Possibly there's some other software out there I can find...

 

When you ask if I am in a noisy environment, do you mean like audible sound?  It's not in a very loud place, but it is in a clean room manufacturing facility so there is a fair amount of background white noise (fans and such). 

0 Kudos
Message 5 of 12
(3,245 Views)
Electrical noise.
0 Kudos
Message 6 of 12
(3,240 Views)

The problem has occured on two different electrical circuits (one outside the clean room for initial development, one inside the room during integration).  The equipment is in a server rack with a common power strip powering up about 10 devices on one station and 15 on the other.

 

Is there a good way to check for electrical noise?

 

I do have my doubts that it would be something like that though, since there are a fair amount of repeated patterns in the log...

 

 

0 Kudos
Message 7 of 12
(3,234 Views)
Solution
Accepted by topic author Kyle97330

I can guess what is happening. at least with the Agilient.

 

you neglected to use an external hub with its own power supply and you neglected to put a serious surge arrestor on the PC primary power.  Enough junk from pri power is getting through to actually make windows think the USB - Serial adapter is getting pluged back in and some device manager (Agilient IO Libraries?) does a scan for USB TMC devices when the connection is "Restored"

 

Simillarly the PC power supply is affecting the COM port.  Kiethleys are notorious for reporting a Device Clear "DCL" when they recieve malformed commands from noise.

 

NI Trace will eliminate any VISA calls and confirm electrical noise

 

Recommendations:

  • Get a surge arrestor/ UPS on that machine to guard against junk on the line from air-handlers and other large cleanroom loads.
  • Get cable assemblies with ferrites on them for the serial data lines.

Alternately:

  • Get a membership to a hair club----you are going to pull out a lot of hair

 

 


"Should be" isn't "Is" -Jay
Message 8 of 12
(3,225 Views)

@Kyle97330 wrote:

The problem has occured on two different electrical circuits (one outside the clean room for initial development, one inside the room during integration).  The equipment is in a server rack with a common power strip powering up about 10 devices on one station and 15 on the other.

 

Is there a good way to check for electrical noise?

 

I do have my doubts that it would be something like that though, since there are a fair amount of repeated patterns in the log...

 

 


I would also have my doubts about electrical noise, on a hardware level the signalling voltages in the standard were chosen to eliminate problems caused by noise, and even though RS232 links aren't running +- 12V anymore I would have a hard time believing noise would cause the problems you are seeing -- assuming of course that you don't have the cable wrapped around an arc welder a couple times...

 

How 'bout if you create a small program that simply opens the port and does nothing to it but hold it open and check the byte count every couple minutes. Do you still see the spurious data appearing? Are there any errors? That would clinch the case for or against noise, and the reconnection scenario that Sy Sperling Jeff mentioned.

 

Mike...

 

PS: Jeff, he's not just a Proven Zealot -- he's also a client...  (If you don't get the reference, don't worry. It's an 80`s thing... You had to be there...)


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 9 of 12
(3,224 Views)

The Agilent thing makes sense - I generally notice the error beeps start while I'm doing something with the machine (starting/stopping LabView, running MAX, rebooting, etc) so if something triggered a power-up, that could do it.

 

I did have a look round and I don't see anywhere that sells 9-pin RS232 cables with ferrites.  Are you sure they exist?

 

I am really hoping not to have to order a UPS or any other device, as I'm already over budget on this project, and new cables are a much easier sell.

 

I do see a lot of DCL strings in the log now that you mention it.  I'll probably try to create a quick program that holds open the serial port all weekend long and monitors it to see if I can prove it's noise or not, since it would theoretically stop all other programs from accessing the port.

0 Kudos
Message 10 of 12
(3,206 Views)