viWrite halts thread

[ndo]

Hello,

I have an ETS real time CVI application in which I have many threads performing RS-422 communication.  Many of the threads simply poll one single port for data.  In others, one thread reads data from a particular port and another thread sends data out that same port.  All serial IO read threads have the same priority and one time critical thread has the highest priority.   I am having a problem where the time critical thread is intermitently stuck on a viWrite().  I have verified that only this one thread is frozen.  All other threads are running, including the thread that reads data from the same port to which the time critical thread is trying to write. 

I have always assumed that it is perfectly fine to perform VISA read and write simultaneously to a full duplex serial port from two different threads, and I have written a test program to do just that, which worked fine.  Is this a wrong assumption?  Can anyone suggest other causes for this error?

I am using an 8-port RS-422 PCI card from NI.

Regards,

NDo

[Ted_H]

Hello NDo,

My first suggestion is to run NI-Spy.  NI-Spy is a utility included with the VISA drivers and allows you to view all commands sent to your com port.  Run NI-Spy and then run your program, NI-Spy will show all the serial calls you are making and any errors or timeouts you may be experiencing as well.

About your code, it sounds like you are opening two different VISA sessions on the same port, is this correct?  Typically it is recommended to open one VISA session for a given port and perform your VISA read and write using the single session.  Have you tried combining these two time critical threads into one (do the write and read with the same VISA session) and see if the thread has the same behavior?

Lastly, is there anything unique about this thread, aside from the fact that it is time critical?  Can you describe the behavior you are seeing in a little more detail? 

Ted

[ndo]

Hello NDo,

My first suggestion is to run NI-Spy.  NI-Spy is a utility included with the VISA drivers and allows you to view all commands sent to your com port.  Run NI-Spy and then run your program, NI-Spy will show all the serial calls you are making and any errors or timeouts you may be experiencing as well.

About your code, it sounds like you are opening two different VISA sessions on the same port, is this correct?  Typically it is recommended to open one VISA session for a given port and perform your VISA read and write using the single session.  Have you tried combining these two time critical threads into one (do the write and read with the same VISA session) and see if the thread has the same behavior?

Lastly, is there anything unique about this thread, aside from the fact that it is time critical?  Can you describe the behavior you are seeing in a little more detail? 

Ted

=====================

Ted,

Thank you for your suggestion about NI-Spy.  I will definitely try that.  I am only opening one VISA session for each port.  The session identifiers are globals to the entire program.  In addition, they are not protected by mutexes as one thread initialize them and no other threads modify them.  I only have one time critical thread. 

The task of most of the serial IO threads is to simply wait for data to come in on their respective port, parse the data and puts the result into a thread safe variable.  These thread safe variables are essentially the states of the system.   The time critical thread reads and operates on these states, and then sends commands to some of the ports. 

What I'm seeing is, randomly (usually within an hour or so), the time critical thread would stop on a viWrite().  All other threads continue running. 

--NDo

[Ted_H]

Hi NDo,

What devices are you communicating with over RS-422, specifically what is the thread in question communicating with? It does sound like it may be a device issue.  The device you are communicating with probably isn't responding to the command, and is causing the thread to stop. Do you have timeouts declared in your code?  Timeouts would allow the thread to continue after the device becomes non-responsive and would also return a timeout error to notify you that the device did not respond.

Ted

[ndo]

Hi NDo,

What devices are you communicating with over RS-422, specifically what is the thread in question communicating with? It does sound like it may be a device issue.  The device you are communicating with probably isn't responding to the command, and is causing the thread to stop. Do you have timeouts declared in your code?  Timeouts would allow the thread to continue after the device becomes non-responsive and would also return a timeout error to notify you that the device did not respond.

================================

Hi Ted,

The thread is communicating with custom hardware via the RS-422 port.  I initialized the port using VISA drivers and set the timeout to 1 second, however, viWrite does not return.  No hardware/software flow control and no handshaking are used.  The RS-422 card we are using is from NI so I'm sure it's compatible with the VISA drivers.  The computer that we're communicating with is unaffected when this error occurs.  Any insight is appreciated.

Regards,

NDo

[ndo]

By the way,  I have not been able figure out how to use NI-Spy to watch VISA calls on the Real Time system.  Is there any other utility that will allow me to monitor VISA operations on real time systems?

[Ted_H]

Hi NDo,

I apologize for taking so long to post back.  Unfortunately NI-Spy is not a Real-Time supported utility, and I have not been able to find any real time utilities designed to monitor a serial bus for VISA calls.  You can always try to run the code on a Windows machine, use NI-Spy, and see if you replicate the behavior on a non real time system.

About your code, have you tried running the same code in a non time critical loop?  The problem is serial communication is not deterministic, and the time critical loop will execute in the time you specify regardless of whether the VISA calls you are using have executed.  What kind of time constraints are you specifying for the time critical loop?  The loop may finish executing before the write VI returns a time out. 

Ted