VXI Register-based versus Message-based Device Communications

[CTE]

DAQ application using LabView 8.6 communicating with VXI chassis with multiple cards (both register and message based devices).  Register-based devices randomly stop communicating (after many hours at 200 scans/sec) while message-based devices continue to communicate.  Currently searching for the cause and a resolution to the problem.

[Roohcifer]

Hi CTE,

Could you give us some more info?

1.  By "stop communicating", what exactly do you mean?  Do you get errors?  Do you read in zeroes?

2.  Are you able to reconnect?  If so, how?  Restarting the program?  Waiting a certain amount of time?

3.  Does this behavior happen more slowly or quickly if you change your scan rate?

Regards,

[CTE]

David,

Thanks so much for your response.

Our application (after initial setup and configuration of data communication cards in  the 2 VXI chassis) enters an overall loop which contains many separate individual loops which carry out the data communication with the various individual cards.  Some of these individual loops contain counters which increment each time through the loop.  This overall loop continues until the operator interrupts it.  We have been running the executable of the code so when we encounter the problem it is difficult to get much in the way of details of what's exactly happening.  We are now planning on running the source code so if the problem occurs we could possibly get more information about what is happening.

1.  By stop communicating I mean that the some of the counters that I mention above go to zero which indicates that particular loop is somehow "hung-up" and not incrementing the counter. 

2.  When we encounter the problem we have to exit the program, reboot the computer and start the program again.  We have to reboot the computer because after the problem occurs we try to run Resman and we get the error "Unable to initialize ni-vxi driver".  I researched this error and found information in the Resman Troubleshooting Guide which mentioned the possibility of a conflict between the NI-VXI device driver and some other memory resident program or device driver.  The guide recommended adding lines to the config.sys and system.ini files to exclude the VXI device driver region of memory (0xD000 - 0xEFFF) from other device drivers (MS-OS).  We did this but we still had the problem.

3.  We have not tried changing the scan rate (currently 200 scans/second) for the cards but the problem occurs at very random times (anywhere from a few hours to 24+ hours).

V/R,

Craig

[Roohcifer]

Hi CTE,

1.  Has this always been the case with this VXI chassis, or is it just with this specific application?  Has the application worked for extended periods previously?

2.  Does this replicate with other VXI applications?  Could you make a simple application that performs only one of the reads in a loop to see if the issue replicates?

Regards, 

[CTE]

We have run this application with several VXI chassis at several different locations and have seen the problem with all of them.  The application has worked for extended times in the past but it seems to be occurring more frequently recently at one of our sites  Not sure if it is related to hooking up external equipment which we are monitoring/controlling or certain cards or VXI chassis.

We have other earlier VXI applications that this is similar to that do not appear to be having the same problem.  The application is fairly complex (2 VXI chassis with multiple cards in each chassis) monitoring and controlling external equipment.  It may be possible to somehow simplify or eliminate some of the communication to see if the problem still occurs.

Just another note - the communications that are stopping are using the calls: Move Block Data from RB Card and VISA Move In 16.  One of the communications that does not stop uses the calls VISA Write and VISA Read.  Could there be some issue with the A16/A24/A32/A64 address spaces?

Thanks,

Craig

[Roohcifer]

Hi Craig,

I'm not sure about your final questions regarding the address space, but if this replicates on multiple chassis, I don't know that a particular memory space being at fault would explain the behavior.  It looks like you have definitely isolated the issue to the program and not a particular VXI chassis.  As such, I would echo your suggestion to eliminate portions of the code to try and narrow down the parts that replicate the behavior.  I would also be curious to see if changing the loop rates in any way affected the time to failure.

Regards,