NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

TestStand not remapping cluster element when VI input cluster changes

Hi Folks,

 

I'm running into a major headache centered around using an updated VI prototype in a TestStand sequence, and the fact that no matter what I try, I cannot get TestStand to preserve input mappings, specifically a string array element that is an element of an input cluster for the VI.  Trying to explain this is a bit difficult, but here goes:

 

  1. One of the inputs to the VI is a cluster, and one of the elements in this cluster is a string array.
  2. The string array is populated by hardcoding the strings in the TestStand 'Module' tab for the step that calls this VI.
  3. I then changed the VI prototype by removing some elements of the cluster, and adding a couple others.  Specifically, two bool controls were removed, and removing the bools is the source of the problem.
  4. When I then go to reload the VI prototype in the step that calls this VI, TestStand is unable to re-map the string array, and thus it's put in the 'unmapped' inputs container, which means I have effectively lost all the hardcoded strings that make up the array.

The only 'fix' that works is to re-add the bools back into the input cluster -- when I do this, TestStand has no problem re-mapping the string array. But, this kinda defeats the purpose, since the two bools are of no use to me anymore (and, causes sequence writing headaches, since the cluster itself is marked as required, so I can't just default these to true or false).  I have tried everything I can think of to try and 'fool' TestStand, but nothing works.  Note that _adding_ elements to the cluster doesn't cause any problems with re-mapping (other than TestStand marks these as '<The expression cannot be empty>', which is perfectly understandable, since obviously TestStand has no clue how to re-map to a cluster element that didn't before the prototype changed).

 

I'm wondering if anybody else has had this same issue, and if there are any workarounds for it.  Unfortunately, I use this VI in many steps in the sequence file (sometimes passing _many_ strings), and hand-copying over the strings from the 'unmapped' inputs section back into the cluster's string array for each and every test step that calls this VI is not a realistic option.  I was hoping that there was some way to manually specify the mapping instead of having TestStand try and automatically do it, but I don't think there is a way to do this, at least I couldn't find any way.  Any suggestions from the crowd at large?

 

Thanks,

Steve

0 Kudos
Message 1 of 13
(5,650 Views)

Hi Smurray,

 

Is there any errors that TestStand throws, any screenshots you can send?

Why do you mean by this "string array is populated by hardcoding the strings in the TestStand 'Module' tab for the step that calls this VI"? don't you just change the container in LabVIEW, and reload it in TestStand?

Is this a behaviour you are seeing?

 

Also take a look at this page for more info.

 

Let me know how it goes.

National Instruments
Applications Engineer
0 Kudos
Message 2 of 13
(5,620 Views)

Hi Edna,

 

Yep, I can try and explain this via some screenshots from a very simple example (I've also attached the sequence file and the VIs that I'm using for this):

 

1.  I have two VIs -- one VI has an input cluster that has an array of strings and a bool, the other VI has an input cluster that just has an array of strings (the bool was removed):

 

Two VIs.png

 

2.  For the left VI (the one with the bool), I am calling this from a sequence file in a sequence step.  You can see below where I have populated the string array in the TestStand 'Module' tab:

 

TestStand step calling original VI.png

 

3.  I then copied the step to the next step, and changed the called VI to point to the 'other' VI (the one _without_ the bool in the input cluster).  As you can see, when TestStand re-mapped the cluster input, it threw all of my strings into the 'unmapped arguments' section. 

 

TestStand step calling VI with modified input cluster.png

 

 

You can see what the issue is here -- basically, TestStand was unable to deal with the fact that the input cluster changed (the only change was that the bool was removed), and therefore failed to re-map the hardcoded strings to the string array input in the 'modified' cluster.

 

The hard way to fix this is to copy and paste the individual strings by hand into the string array, but this isn't a realistic option for me, because I use a similar VI in many steps across many sequence files, and not only would manually copying and pasting the strings (sometimes up to ~50 per step) take forever, it would also be extremely error prone.  So, I was hoping (praying) that there was a workaround for this, or maybe there was some way to manually specify the mapping.

 

I've attached everything you need to see this for yourself in the attached zip -- it's extremely simple (seq file is TestStand 2012, LabVIEW VIs are LabVIEW 2012).  Note that you will have to repeat step 3, i.e. you will have to copy the first step then point it to call the 'other VI' (the one without the bool in the input cluster), since TestStand doesn't persist 'unmapped arguments' when you save the file.

 

Thanks for the help,

Steve

 

 

0 Kudos
Message 3 of 13
(5,612 Views)

Thank you for the screen shots. So when you change this custom step type that contains the arrays of string and bool, do you know if the changes are made, and the version of custom step type has been incremented. Also just curious this custom step type is global, and not specific to a sequence file?

 

http://www.ni.com/white-paper/3193/en/

 

Also this KB talks about a possible solution.

National Instruments
Applications Engineer
0 Kudos
Message 4 of 13
(5,584 Views)

@Edna-S wrote:

Thank you for the screen shots. So when you change this custom step type that contains the arrays of string and bool, do you know if the changes are made, and the version of custom step type has been incremented. Also just curious this custom step type is global, and not specific to a sequence file?

 

http://www.ni.com/white-paper/3193/en/

 

Also this KB talks about a possible solution.


Hi Edna,

I'm not sure I understand your questions -- this isn't a custom step type, it's a built-in 'Action' step.  So, I'm confused by the questions -- can you clarify a bit?

 

Thanks,

Steve

0 Kudos
Message 5 of 13
(5,581 Views)

@smurray wrote:

@Edna-S wrote:

Thank you for the screen shots. So when you change this custom step type that contains the arrays of string and bool, do you know if the changes are made, and the version of custom step type has been incremented. Also just curious this custom step type is global, and not specific to a sequence file?

 

http://www.ni.com/white-paper/3193/en/

 

Also this KB talks about a possible solution.


Hi Edna,

I'm not sure I understand your questions -- this isn't a custom step type, it's a built-in 'Action' step.  So, I'm confused by the questions -- can you clarify a bit?

 

Thanks,

Steve


Hi Edna,

I looked at the KB article you suggested, and I'm pretty sure it doesn't apply.

 

I thought my example was pretty clear, but maybe it isn't clear at all ;-).  Basically, there are two questions I have:

 

  1.  It appears that TestStand cannot re-map elements inside an input cluster when the cluster _itself_ has changed, particularly when elements are _removed_ from the cluster (TestStand appears to have no problem re-mapping inputs when elements are _added_ to the cluster).  Is this correct?
  2.  If 1) is correct, are there any workarounds to deal with this?  In the example I showed you, all of the strings that were hardcoded to the string array inside the cluster were put in the 'unmapped arguments' section once the cluster was updated to the 'new' version.  Just to make sure we are on the same page, the only difference between the old and new versions of the cluster was that the old cluster had both a string array control and a bool control, while the new cluster had only the string array control (i.e., the bool control was deleted). 

Regards,

Steve 

0 Kudos
Message 6 of 13
(5,577 Views)

Thank you for you reply. I was talking about the custom data type, which is a solution to the issue.

I went ahead and tried to reproduce the issue on my end from scratch. 

 

Then the way it was resolved on my end was to first create a custom data type from the cluster that you have (Input Cluster). It is always recommended to do this when you are dealing with cluster that are passed into LabVIEW code from TestStand. In the picture attached just click on the circle and you will be able to create a custom data type of your cluster.

 

Next, create a local variable of this custom data type in TestStand>>Insert Local>>Type>>Input Cluster (the cystom data type you created).

Then I added this local variable to the "Value" section of the Input Cluster parameter you have in the code modules (Locals.MyCluster).

Be sure to  initialize your cluster in the local area section before executing your sequence.

 

Hope this helps to resolve your issue. Let me know how it goes.

 

National Instruments
Applications Engineer
0 Kudos
Message 7 of 13
(5,545 Views)

Hey Steve,

We are considering making improvements to TestStand/LabVIEW integration that would allow TestStand cluster passing to to match changes in LabVIEW clusters (such as deletion of elements). Since you did such a good job explaining describing the issue (with screenshots) in this post, would you mind posting this request to the NI TestStand Idea Exchange here?: http://forums.ni.com/t5/NI-TestStand-Idea-Exchange/idb-p/teststandideas

 

I want to give you proper credit =]

 

Lars L

National Instruments - TestStand

 

 

0 Kudos
Message 8 of 13
(5,383 Views)

I tried the same thing using a local array of strings with hard-coded values and assigned the local to the input of the vi.  When I deleted the boolean I got the same results, TestStand doesn't even remember the local.  This is definitely a bug, and a very irritating one.

 

Kelly Bersch
Certified LabVIEW Developer
Kudos are always welcome
0 Kudos
Message 9 of 13
(5,375 Views)

Hi,

I found the solution for this issue. You just need to open the Types window, and go to the custome type you make. Then right click on each element of your cluster and select properties to open the property dialog. Next click on cluster passing tab. In the cluster item label, you want to make sure you have the correct value which is the same with the label of the item inside the LabVIEW cluster. After verifying all of the element of the cluster, you click on apply cluster passing change again and it should work. I hope I understand your question correctly.

0 Kudos
Message 10 of 13
(5,034 Views)