LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial communication crashes with blue screen

Solved!
Go to solution

Hello,

 

I have been troubleshooting an application that consistently kept crashing/hanging after ~1 to 5 minutes. I am communicating with a syringe pump NE1000 from New Era (http://www.syringepump.com). If have finally isolated the problem to a VISA write function.

 

Configuration:

 

  • ·         DELL INSPIRON running Win7 64 Bit
  • ·         LabVIEW 2011SP1
  • USB to Serial RS-232 Adapter [ GUC232A ] http://www.iogear.com/product/GUC232A/
  • ·         The driver for the GUC232A has just been updated to the latest version, but the same behavior was observed with the older driver dating back to 2009.
  • ·         RS232 to “telephone cable” adapter:

     

  • ·         Telephone cable to RS232 port on syringe pump

 

 

I was running the NI Desktop Execution Trace Kit while running the attached Test NE100X – Query Volume.vi. The log is attached, Trace Test NE100X - Query Volume vi (1_4_2013 _ 17_06_11_423180).ttd.

 

When I run the vi at a loop rate of 10ms, it hangs after 15889 events. (Occasionally, Win7 crashes with the Blue Screen of Death.) I did not find anything unusual in the trace report.

After the vi hangs, it becomes unresponsive. When I attempt to exit LabVIEW, I get the Resetting VI: … message, and LabVIEW is hanging and does not exit:

 

If I decrease the loop rate to 50 ms and 75 ms, the vi seems to be running longer, but still crashes after about 52000 events, or 25000 events,respectively. At a loop rate of 100ms, it is was running for 51 min and then I had another Blue Screen Windows crash.

 

What confuses me is that the system just hangs without giving me any timeout or error message. This makes the troubleshooting very difficult. A query rate of 10 Hz seems to be rather low. I wonder whether this is a hardware issue or some bug in the software. I appreciate your help in troubleshooting this issue. Thank you.

0 Kudos
Message 1 of 13
(16,312 Views)

what is the baud rate for your RS232 port?

0 Kudos
Message 2 of 13
(16,306 Views)

19,200 baud (manufacturer default)

0 Kudos
Message 3 of 13
(16,292 Views)
Solution
Accepted by topic author pbuerki

Have you tried your VI on a non-Windows 7 PC?

 

I use those particular USB-RS-232 adapters all of the time and have never had a crash.  However, all my PC's are still XP.

 

Is the adapter plugged into an onboard USB port, or an external USB hub?  Is it a PC or a laptop?

Message 4 of 13
(16,289 Views)

I also used this particular USB-Serial adapter a lot on XP computers without any crashes. But I do no longer have access to an XP machine. The adapter is plugged into an on-board USB slot and does NOT go through a Hub. It is a laptop. I checked the manufacturer's webpage for updated drivers and installed the most recent driver compatible with Win7 64bit. But the observed behavior is the same as with the older driver.

0 Kudos
Message 5 of 13
(16,283 Views)

Does it repeatably hange at exactly 15889 events?  Every time?

 

Try running Perfmon while your VI is running to monitor CPU and memory.  Maybe there is a memory leak somewhere.

http://www.medicollector.com
0 Kudos
Message 6 of 13
(16,252 Views)

Also, your code has no error handling.  Probably not the cause of this issue, but you might be getting an intermittent error that is ouccring quickly and intermittently that it goes unnoticed.

 

You should check the state of your error cluster in your while loop (every iteration).  If an error occurs, you should probably stop execution (or at least reinitialize the serial connection).

http://www.medicollector.com
0 Kudos
Message 7 of 13
(16,251 Views)
Hi I can see several potential problems with this code. It looks as though what you are trying to do is to send a "DIS" command to the syringe pump and are then trying to read the data that the syringe pump sends back in response to this command. 1. How many bytes are you expecting to get back in response to the DIS command? You're attempting to read 1024 bytes. If you really are expecting 1024 bytes then you need to calculate how long that would take to arrive. If we assume that you're using a data word consisting of 8 data bits, 1 stop bit and no parity then the number of bytes you will receive per second = 19200 / (8 + 1) = 2133. Therefore 1024 bytes will take 1024/2133 seconds = 0.48 sec. Therefore there is no point having a loop rate of 10msec. 0.5 seconds would be better. 2. You haven't included the vi that initialises the serial comms so I can't see what timeout value you've assigned. You need to check that it is greater than the time it's going to take for your data to arrive. 3. If you're not expecting exactly 1024 bytes then you need a different strategy for reading back the data. Possible options are i) counting exactly how many bytes you actually do get and using that number in the byte count input, ii)reading data continuously in a small loop until a terminating character is seen. eg if a CRLF is returned at the end of the data, read continuously until you see this. I've attached a modified version of your vi that shows how to implement this last method. regards Mike
0 Kudos
Message 8 of 13
(16,224 Views)
whoops , my attachment hasn't appeared. It's the first time I've tried to do that so obviously my mistake. It's late now but I'll try again in the morning. Mike
0 Kudos
Message 9 of 13
(16,219 Views)

It looks like the code is already in a constant loop that is reading until the termination character is detected. It's all automatic with configuring the serial port and enabling the term char. The setting of a high byte count is normal and the recomended method.

Message 10 of 13
(16,216 Views)