NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

How to pass a numeric value without its format to a subsequence?

I have a sequence with a numeric parameter that is interpreted as a 16-bit bit mask. The numeric format of the parameter of that sequence is therefore "%#.16b".

I also have a Sequence Call step in a second sequence (in the same file) that calls this first sequence. That second sequence passes literal values for that bit mask in the Sequence Call. My specific problem at this point is that, while debugging, I don't see the parameters in the numeric format I explicitly specified for them, but rather in one of three possible formats:

- Literal values seem to come with a "system"-wide (maybe sequence-file-specific?) default format, which is decimal instead of binary.
- Variable values (e.g. from the Locals) have their specific (and also explicitly defined) numeric format, which can be anything instead of binary.
- If I don't pass a value but use the parameter default, this default is shown in the parameter's actual numeric format, binary. This is the only case that works as intended.

How do I get the parameters to *always* keep the numeric format I specified for that sequence?

The attached file tries to reproduce the problem and the intended result using only Sequence Calls and Message Popups. My version is TestStand 3.1f1.
0 Kudos
Message 1 of 7
(3,801 Views)
The attachment got lost...
0 Kudos
Message 2 of 7
(3,800 Views)
I ran your sequence. The first sequence call uses the first local variable which is expressed in binary. The message box shows a binary number (although the padded zeros to the left are not shown), contrary to your statement about not being able to use binary format. It works here. The second sequence sends the second local which is expressed in decimal. The message box shows a decimal 26. So far I don't see a problem. The third sequence sends a literal expressed in hex. The message box shows a decimal, probably because this is the default format for literals. So what is the problem? If you want to use a specific format, use a local variable defined for that format. In the case of a binary, if you want the extra zeros to the left, you can use a string function to pad the zeros until the desired length is reached.
- tbob

Inventor of the WORM Global
0 Kudos
Message 3 of 7
(3,790 Views)
I just want to debug my subsequence and see its parameter represented as "0b0000000000011010" when I supply a literal value of 26.

Ok, I try to be more explicit and show my problem using your suggestion: (The resulting sequence file is attached.)

- Create a new sequence file.
- Insert a new sequence "Sequence".
- In "Sequence", create a parameter "Parameter" of type "Number".
- Change the numeric format of "Parameter" to Binary with a minimum of 16 digits and *without radix*, ie. "%.16b". (In the other sequence file I used "%#.16b".)
-> Intention: I want to see the supplied parameter value in this numeric format when debugging or converting to a string using Str().
- Still in "Sequence", create a local "Local" of type "Number".
- Change the numeric format of "Local" to the same as above, "%.16b".
-> Intention: I want to demonstrate your way here, which actually works (I can use it as the "reference string" of the yet-to-be-defined message box), but does in an indirect way what I want to do directly using only sequence parameters.
- Insert a "Statement" step in "Sequence".
- Of "Statement", "Edit Expression" and use "Locals.Local = Parameters.Parameter" as the expression.
- Insert a "Message Popup" step in "Sequence".
- Of "Message Popup", do "Edit Message Settings", and use the following expression as the Message Expression:
"I have this: " + Str(Parameters.Parameter) + "\n" +
"I want this: " + Str(Locals.Local)
- Insert a "SequenceCall" step in MainSequence.
- Point "SequenceCall" to sequence "Sequence" of the current file and supply exactly the literal value 26 for the parameter.
- In "MainSequence", create a local "Local" of type "Number".
- Change the numeric format of this "Local" to something very dangerous, eg. "%9.16o".
- Assign the exact numeric value 4616 to this "Local" variable.
-> Intention: I want to demonstrate that there are cases where a propagation of numeric formats to subsequences can actually be more than a mere nuisance.
- In "MainSequence", insert a second Sequence Call step, "SequenceCall_2".
- Let "SequenceCall_2" call the same sequence "Sequence", but supply Locals.Local for the parameter.

- Now run the sequence file in "Single Pass" mode.
- In the first popup, you see that I get the (binary!) representation 0000000000011010 only for the local variable, but I also want it for the parameter value.
- In the second popup, you see that I get the (octal!) representation 0000000000011010 for the parameter value, which would be correct (for what I want) if I had supplied the decimal literal 26 again. You see that the binary representation is something entirely different here!

I hope you now get the point. Thanks for answering!
0 Kudos
Message 4 of 7
(3,784 Views)
Your example is quite clear. It seems that the format of the parameter as defined in the main sequence is passed along to the subsequence and not converted to the format defined in the subsequence. I have tried passing by value and by reference and it didn't make a difference. I have also tried turning on propgation to subsequence and allow propogation from caller, and it sent the format of the octal but not the literal. Still didn't convert to the format of the subsequence. I don't have an answer to this one, sorry. This is something you should take up with NI. Your workaround, to assign the value of the parameter to a local inside the subsequence, works fine. But you should not have to do this.
- tbob

Inventor of the WORM Global
0 Kudos
Message 5 of 7
(3,771 Views)
Thanks for your reply. Sadly, the trouble does not stop here. I now have a support request with NI regarding strangely behaving Numeric Limit Tests, which pass or fail in an unpredictable way. Maybe those two problems are related somehow... (I send a link to this thread to the supporter at NI.)
0 Kudos
Message 6 of 7
(3,759 Views)
Ok, the solution to that other problem of mine was: do not let TestStand do too many type casts between different numeric formats! And start thinking at the origin of your numeric value.

This is probably a good general advice for all problems related to numeric formats.
0 Kudos
Message 7 of 7
(3,748 Views)