NI TestStand Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
RaviShrigiri

Adding checksum feature to the TestStand sequence

Status: New

This method ensures that the correct test sequence and its corresponding DLL/VI/custom files are run.

 

This feature needs to be optional as during development phase this feature is not desired.

 

Configuration :

User selects the test sequence.

User (optional) selects related files like dll/vi/etc

The checksum of the package is determined and tagged with the sequence.

 

Execution:

User enables the checksum option.

User selects the above sequence to run.

Teststand automatically checks for the sequence checksum and also the checksum of the related files.

 

The sequence will run only if the checksum matches.

1 Comment
warren_scott
Active Participant

A few things: 

This is a desirable feature -- we have already built a very similar thing into our customization of teststand/LV/etc and are currently using it. 

This can NOT be limited to a "check once at the beginning" because there is the possibility of things changing halfway through the testing of an instrument (think "self modifying code" or people copying files over the network, etc). 

Sometimes these checks can take quite a while, and we don't want to necessarily bother the user with waiting around while it happens before he can start the next instrument.  If it gets implemented as a "go start validation" step and then we can go do other testing, have user enter model/serial/configuration/etc stuff while scanning checksums, and then we have a "get state of checksum validation" step that would return "off/pass/fail/still running", we can implement this as blocking at the beginning of the test, or blocking for ending the test, or implement multiple times throughout the test of the UUT. 

We implemented this as a [when checksum fails, prompt user to either terminate immediately, or keep going and generate a critical error that will prevent the UUT from shipping to the customer].  This way if a technician did some funky stuff to try to troubleshoot a problematic UUT, he can still get his job done, but it prevents a possibly compromised UUT from getting to the customer.

 

Also, it is important to be able to know what caused any failure of the checksum validation -- which file(s) are missing/changed/etc