No-Programming Sequence Bug with Test Executive Version 4.0.Primary Software: LabVIEW Toolkits>>Test ExecutivePrimary Software Version: 4.0 Primary Software Fixed Version: N/A Secondary Software: LabVIEW Development Systems
Problem: On page 5-50 of the LabVIEW Test Executive Reference Manual, there is an example on No-Programming Sequences. When I work through this example the first time, all is well. However, if I try to go back and edit anything in the example, it appears to hang when I run the VI again. This problem was generated in Test Executive version 4.0 with both LabVIEW 3.1.1 and LabVIEW 4.0 under Windows 95. Solution: The situation relates to the manner in which the Call Instrument VI functions. Consider the following scenario: A VI is loaded into memory with the Call Instrument VI. The VI is later run with the Call Instrument VI with a value provided for one of the VI's inputs (controls). Later again the VI is run, but this time no value is provided for that same input. Because of the way the Call Instrument VI operates, the VI actually gets called with the previous input value, *not* the default value for the input. This operation is somewhat counter-intuitive to the way one normally calls a LabVIEW VI on the block diagram: if an input is left unwired, the default value of the control is used regardless of any previous call to that VI. The problem is that the Test Executive code assumes that a VI called by the Call Instrument VI will use the default value of an input if no input value is provided to Call Instrument. The problem is seen here when using a test VI shell. When the test VI shell is called in the Sequence Editor, its "mode" input is provided with an input telling it to operate in "config mode." When the VI is later called in the test sequence, no value can be provided to the "mode" input since that is not an input parameter for a normal test VI, only for test VI shells. When the test VI shell is called with no "mode" parameter given, it uses the input from the previous running of the VI, which tells the VI to run in "config" mode. This is what causes the problem. The reason that this problem occurs only when the user presses "Edit Test VI" after running the sequence is that when the test VI shell is defined as a test VI the very first time and is edited via "Edit Test VI," the VI is loaded into memory, run, and then *unloaded*. Since it is unloaded, the problem doesn't occur when the sequence is now run. Now, when the sequence runs, the test VI shell is brought into memory and not unloaded. If you now go and "Edit Test VI", it doesn't need to be loaded since it is already in memory, and therefore is not unloaded afterwards. So the VI is called and uses the old input parameter. Now, how do we work around this problem? The answer is to set the Load Specification of all Test VI Shell VIs to Dynamic load. This setting will cause the test VI shell to be loaded and unloaded at every execution, so old values for inputs are never used. The new VI server functionality in LabVIEW 5.0 fixes this problem. This is included in version 5.1 of the Test Executive which will work with LabVIEW 5.0. Related Links: Attachments:
Report Date: 05/09/1996 Last Updated: 12/02/2004 Document ID: 0L8H7LJW |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
