NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

On the Fly report fills UUT_RESULT informations at the end of the test

Running on the fly report with a database, the table UUT_RESULT is first updated with all informations at the end of the test. During the Test only the ID is inserted. This makes it hard to query for the results. How can i add the informations at the beginning of the test?

 

Kind regards

 

Lars

0 Kudos
Message 1 of 13
(4,796 Views)

Lars -

This is a limitation of the database logging on-the-fly feature and I am not aware of any workaround to get the feature to write this information out. Additionally the feature does not expose the key value of the initial record written to the database. There is an internal issue written on this limitation and the ID is 47056.

 

The only option that I can think of is if the table key value was a GUID and the Database Options schema that you use stores GUID values into the table, you might be able to change the column primary key type from Store GUID Value to Use Expression Value, and pass a GUID string value manually in the expression. You would have to generate the GUID value per UUT. If the UUT record can be created with your GUID value, you could then use that key value to query the database and possibly write temporary information to the UUT record.

Scott Richardson
0 Kudos
Message 2 of 13
(4,749 Views)

Hi Scott,

changed my configuration as you suggested. I changed the GUID to Use Expression Value and updated the callback ProcessModelPostResultListEntry so the UUT_Result table will be updated. This solution worked fine, but i found a problem under some certain circumstances:

 

In my seq file the first step is a "Sequence Call". This step has "Recode Result" disabled. In the SubSequence we have some steps where the "Recorde Result" is enabled. Under these circumstances my Vi which updates the UUT_Result failes, as record has not been written.

 

How can i fix this?

 

Kind regards

 

Lars

0 Kudos
Message 3 of 13
(4,707 Views)

Lars -

When logging with on the fly enabled, I believe the placeholder entry in the database for the UUT result is created when the first non-sequence step that records a result completes executing, which would be the step in your second-level sequence that you mentioned. At what point in the execution is the VI trying to query the database for the UUT result and failing?

Scott Richardson
0 Kudos
Message 4 of 13
(4,699 Views)

Scott,

 

the question is, how does the LogResult step in the Callback handle this. For the Subseqence Call the callback is not been called, but for the other steps it will.

 

As i know, this step inserts the step_result and inserts the placeholder in the uut_result.

As the GUID is known, i just try to update the uut_result table with my informationes. but this placeholder seems not to be created even that the logresult has been executed. In case of that my vi of cause failes.

 

Lars

 

 

0 Kudos
Message 5 of 13
(4,690 Views)

Lars -

I could also be that the connection that your VI makes with the database might not be able to initially see the changes made by the first step until the database truely commits the changes. This can be affected by the cursor type of the connections that logging uses and that the VI uses. If you delay your VI, is the UUT record eventually available?

 

Another solution would be to store your additional UUT information in a separate table that uses the same UUT key and you can join them when peforming a query, but you would not want to use a constraint between the two tables.

Scott Richardson
0 Kudos
Message 6 of 13
(4,683 Views)

Hi Scott,

the connection is not the problem. I single stepped the callback und before updating the uut_result i queried the database to see if the record set has been created by TestStand. But it did not.

 

Your second solution could be an option, and might also work. But this requeres a redo of some tables, and is hard to implement during runtime. So if you could think about a third solution, it would be great.

 

Kind regards

 

Lars

0 Kudos
Message 7 of 13
(4,671 Views)

Lars -

My misunderstanding. The issue is that the on-the-fly database logging feature does not log (skips) child steps if any parent sequence call up the call stack explicitly disables its result. This was done to allow on-the-fly to more closely mimic what the post-UUT database logging feature does. TestStand discards child results if when the parent sequence call does not collect a result. So basically the UUT result will not be created until the first step is run where its parents will also record results.

 

I see your only options as:

  • Require all MainSequence client files to include a first step that records a result
  • Build into your VI the ability to catch this case and try again without raising the error to the user
  • Store the GUID in a separate table with the additional information that your require.

 

Scott Richardson
0 Kudos
Message 8 of 13
(4,661 Views)

I tried now to change my flow that i first insert the uut_result with my vi.  But the result was that i get a violation error from the step LogResult, that it is not possible to insert the same GUID.

 

Ok, next i changed the Command Text in the Database options to execute an Update and not an Insert. But the result was the same.

 

How does the LogResult know that there is allready a line in the uut_result? Or can i tell LogResult that there allready is a line?

 

Kind regards

 

Lasr

0 Kudos
Message 9 of 13
(4,648 Views)

Lars  -

As it is designed today, the logger requires that the SQL statement contain an INSERT command. If it is not found, I do not believe that on-the-fly logging will work if the schema defines a foreign key to the UUT record.

 

Now, I have not tried this, but if the step result statements in the schema do not define their UUT_RESULT columns as foreign keys, the logger will just assume that they are data that you will provide, and it will not attempt to log a placeholder for the UUT record. So I believe you can then set the expression for the UUT_RESULT in the step results to assign the UUT key and the logger will just log it as a value. The database schema will likely have a constraint, but if you pre-create the record as you were suggesting, the constraint will be satisfied when you log the step result. Lastly when the UUT completes, the logger will just log the values using the UPDATE statement that you supplied.

 

Note that we already do have a internal suggestion/problem tracking issue (ID 47056), specifically to add support to log more than just the key for the UUT result and parent sequence call steps, but we have not determined how easy that would be and whether there are any backwards compatibility issues.

Scott Richardson
0 Kudos
Message 10 of 13
(4,626 Views)