Serious Serial Questions

[j.masse]

I am experiencing a CPU utilization of 100% after many hours of RS232 serial polling. This happens inconsistantly and only when I "build" the application. (I have never seen it happen in the development stage.)

I am running Labview 8.5 with VISA 4.4.1.

My current technique is to build an array of all the serial ports to be monitored (setup is async) - usually 16 with various settings but can be anywhere from 3 - 16. (Data flow is fast so most have a TO setting of 100ms) I then send the array of comports to a For Loop and read from each comport consecutively and each port periodically is flushed (The data just streams out of of the comport devices .) There is not a buffer overrun situation since I have monitored this situation religiously.

I also have other RS232 devices that only transmit data after a query. Each of these have their own processes.

After many hours, though not all the time, the CPU goes to 100% and the executable is useless. (Acts like it is spinning in a while loop.) Typically the CPU utilization is about 10% - 12% and there is no memory leak. The executable size is fairly unaltered.

Is it possible that my method of reading (using the For Loop) is unorthodox? Is there a better way?

Also, I noticed an excessive amount of timeouts when I write on the comport. Is there a way to reduce this? Is it just an artifact of the 'async' that i have to work with? (I am going to try to add a NISPY result for observation.)

[muks]

Is it due to the processing that you do after you acquire the port data? Have you tried optimizing that. (Just a guess)

[j.masse]

There is no "while loop" processing that occurs on the data in the serial read/write loops. Once I have the data, simple arithmatic is applied to analyze the data. When I experience the 100% CPU, I notice that one set of front panel indicators (one comport's data) is not being updated. I painfully get NISPY up and running and observe that the specific comport is not operational. Every comport should be reporting data at least every second (or 100mS) and the front panel indicators show all the data being acquired.

I noticed other posts similar to mine especially the new one http://forums.ni.com/ni/board/message?board.id=140&thread.id=37714. I too have expereinced the "resetting" issue as described in this post but my hanging usually takes hours not minutes.

I am attaching a picture of a read/write process that has its own thread. This has been one of the threads I suspect hangs and causes CPU 100% as observed by its data not being updated on the front panel and its comport is not seen by NISPY after 100% is expereinced.

Message Edited by j.masse on 08-18-2009 03:47 AM

[Justin_E]

What hardware do you have connected? Since you said you normally have 16 ports active, does this still occur when you have only 3 ports active?

[j.masse]

Justin - the units requiring 1 - 16 ports are our own product that has been running for years. (It depends how many of the product needs testing but each unit requires 1 RS232 port.) They continuously output typically 84 - 100 ascii chars at 38400 at a 20hz rate. I read using a reading termination char or timeout. These comports are grouped together as an array of comports and I will read from them in a ForLoop. The fewest amount of ports used I can recall is 6 that has resulted in 100% cpu usage. (I don't believe fewer units were tested since the testing takes up to 3 days.) Bottom line is that timeouts should occur if there are any issues.

There is always a RTD simulator attached and it uses its own com port and a seperate thread. (Another in house product)

There is always a Watlow 942 chamber controller attached and it uses its own com port and a seperate thread.

Finally, there is a pressure controller attached and it uses its own com port and a seperate thread. (Another in house product)

[j.masse]

I have reduced the problem to an NI issue.

I have one parallel process that reads 16 (or fewer) comports continuously - to update the front panel. I have another process that reads from the same ports, averages the data and check the results. I use semaphore control between the two processes (individual while loops).

After many hours of switching between the two processes, the program eventually locks up resulting in 100% CPU usage. This pertains only to the executable not the development version. When I disable the process that reads the comports and averages the data, the program runs completely. When the two are enabled, LabView (the built executable version) hangs.