Jervin, I have a customer with this same use case.
In the setup that they are using, they have strings coming back from an instrument. In most cases, those strings are pre-defined characters (like the instrument identification, ACK, etc.) that they can directly compare to make sure they got the right response. So their instrument query function is wrapped into a custom step type that is merged with the String Value Test step type.
However, in some cases the number of characters is not known ahead of time, and depends on where in the TPS the function is called. In this case, the customer wanted the ability to call their usual instrument custom step type, but to have a 'no comparison' case. That way they could use a subsequent step to evaluate the instrument's response.
Josh W. Certified TestStand Architect Formerly blue
While this use case could be accomplished by performing the 'dummy' test step (that gets the unknown response) as an action step (instead of a string limit test), they'd rather not have to create another custom step to do this.
This custom step type library is for re-use across an organization of 10-20 people, and it is going to be used by developers without any training on the step types, and who probably don't know TestStand that well. So adding a very similar step that has only slightly different behavior is considered undesirable because of training and maintenance concerns
Josh W. Certified TestStand Architect Formerly blue
For tracabillity, logging MAC addresses from ethernet- wireless- and bluetooth- adapters or storing the serial number of power supply modules are becoming more important and require such a solution. Meaning more fexible (or no) comparsion on string based values.
As a workaround for those who need this functionality now; you can set the 'Expected String Value:' on the Limits tab to 'Step.Result.String' (or whatever your 'Data Source Expression:' is defined as. This ensures that the test will never fail by comparing the string value to itself and the data will be collected as desired.
Thanks for the hint, that's the well known workaround, which everybody uses.
But then it looks, as if this test step had been executed with different limits. Validated test systems used in medical or defense environment has to be validated, meaning the limits have to be certified and released by the customers quality regulations.
Many measuring data collecting/processing system check, if limits were changed within production lots, which is not allowed. So you have two choices, to explain the customer that his requirements do not make sense or that we can not meet his requirements with NI software framework.
I think I accomplished this goal by using an Additional Result to log the string value. Need to double-check when I get into the office next week.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
