I'm using TestStand 3.1 and LabWindows/CVI 7.1. I am trying to write a generic 1394 Read function using LabWindows/CVI callable from TestStand sequences.
The first attempt is in Attempt1.txt
This worked ok, except for the FW_Reset function took about 20 seconds to complete. Since this function could be called repeatedly, sometimes in a loop this made the total test sequence time unbearable, so I split the function into 3 functions IEEE1394_Initialize, IEEE1394_Read, and IEEE1394_Shutdown.
The first attempt is in Attempt2.txt
This worked better. I could put the IEEE1394_Initialize in the TestStand Setup section, the IEEE1394_Read in the TestStand Main section, and the IEEE1394_Shutdown in the TestStand Cleanup section. Doing this eliminated multiple calls to FW_Reset and it's 20 second delay. The Main sequence could loop on IEEE1394_Read.
All was well until someone unplugged the 1394 cable and powered down the unit under test. The IEEE1394_Read still came back with valid data. This was apparently from the last valid 1394 message. I believe that this data is retained in hardware buffers on the 1394 board. I have been trying to figure out a way to clear this hardware buffer without the FW_Reset 20 sec delay penalty. I have tried various combinations of FW_Disconnect, FW_Open, FW_Close, FW_Connect, FW_ASP_Setup, and FW_ASP_Update combinations without success. The docs are incredibly sparse in this area.
What function actually clears the buffers created by FW_ASP_Setup? Do I have to do an FW_Reset to clear these hardware buffers? Is there some way of recognizing the 1394 cable has been unplugged or the unit powered down?
Any ideas would be greatly appreciated.
Thanks
Terry
