Set Limits with "Don't Cares" or Partial HEX Words?

[GSinMN]

Hello All,

  Creating a multiple numeric limit test in TestStand, and the expected values for 2 tests are stored in a single 5 byte HEX word local variable (imported from a file).  For example, if the expected value word is "12345678AB", AB (the last byte) is the expected value for one test, while the 12345678 (the first bytes) applies to a second test.

  In the past, I have used a seperate code module to split the word and inject the limits automatically into TestStand.  However, in the case of a multiple limit test, I think it may be easier to just set the limit directly from the variable (if it can be done), as the path to get to the limit is much more complex.

  So here is my question:  What would the syntax be for the low limit expression field if I read in a 5 byte local variable, ignore 1 byte, and use the remaining bytes for the comparison?  Please advise.  Thanks.

GSinMN     

[hnesmith]

GSinMN, 

One potential option could be to use a bitwise AND. For example,  0x00000AB AND 0x12345AB should return 0x00000AB, setting 0x00000AB as your lower limit. 

[dug9000]

---

@hnesmith wrote:

GSinMN, 

One potential option could be to use a bitwise AND. For example,  0x00000AB AND 0x12345AB should return 0x00000AB, setting 0x00000AB as your lower limit. 

---

Don't biwise AND with 0x000000AB, that will give you incorrect results since that will even give you 0x000000AB if the original value was 0xFFFFFFFF.

To mask out everything except for the last byte and compare you should do something more like this:

(Locals.MyValue & 0x000000FF) == 0x000000AB

To do something like this from a multinumeric or numeric limit test you could do this by customizing the data source as follows:

1) If using multi-numeric limit, check the checkbox to specify a data source for each measurement.

2) Here's an example of what to change it to: (Step.NumericArray[0] & 0x000000FF)

Hope this helps,

-Doug

[dug9000]

I just realized you said 5 bytes. I want to make sure you are aware that you can't store a 5 byte integer value in a teststand number variable (at least not with the default representation). How exactly are you getting a 5 byte number into teststand? How are you storing it in teststand? What I said in my previous post likely does not apply if you have a 5-byte value. That is a more unusual case and would require more details about exactly how you are storing that in teststand variables.

-Doug

[GSinMN]

Hello Doug,

  Good catch.  I've been dealing with "odd sized" numbers through most of the development for this application.  Generally I convert everything to U64 (in Labview), do and processing or manipulation I need, then convert back as needed.  As far as how things are stored in TestStand, most variables are imported and stored as character strings, then converted as needed.  For this particular post, I was just wondering if there was a way to do some of that conversion directly in TestStand.  Doesn't sound like it would work. 

GSinMN 

[dug9000]

---

@GSinMN wrote:

Hello Doug,

  Good catch.  I've been dealing with "odd sized" numbers through most of the development for this application.  Generally I convert everything to U64 (in Labview), do and processing or manipulation I need, then convert back as needed.  As far as how things are stored in TestStand, most variables are imported and stored as character strings, then converted as needed.  For this particular post, I was just wondering if there was a way to do some of that conversion directly in TestStand.  Doesn't sound like it would work. 

GSinMN 

---

What I was referring to with the 5 byte issue was when using the default (double-precision foating point) representation of a number in TestStand. When using that representation, integers are treated as 32-bit.

There are also 64-bit integer representations in TestStand. If you change a TestStand number's representation to "Unsigned 64-bit Integer", then you can use bitwise arithmetic on the 8 byte integer values (using the ui64 suffix for constants such as 0x00000000000000FFui64), however, the numeric limit step types do not currently support 64-bit integers, so you would not be able to use those.

-Doug