LabVIEW 8.6 => LabVIEW 2010 Reload Prototype

[GeoffF]

We are developing an application in LabVIEW and TestStand for a group of clients.  Our Japanese clients insist on using LabVIEW 8.6.  Since they're also the parent company, we have to do it.  Our European clients are using LabVIEW 2010.  Both clients are using TestStand 4.2.

I added a Boolean flag to a LabVIEW typedef, as the second of about 7 items in the cluster, and then propagated the change to all affected types and sequences in TestStand.  Now, whenever the European try to run the updated code, they receive an error requiring them to reload the prototypes for those steps and step types that use that typedef.  If I update the code using LV2010, then try to load it on a system running LV8.6, I get exactly the same problem on the LV8.6 code.

The Europeans report that a computer restart also requires them to reload prototypes, even if they have saved their versions of the files.

Has there been some sort of change in the way LV (or TestStand) packs Booleans between the two versions?  Would I be better off moving the extra Boolean flag to the end of the cluster?

Thanks in advance for any possible help.

Geoff

[GeoffF]

Further information:

The typedef (a CAN message information cluster) has the following structure

String (Combo box)

Boolean (New variable)

Array of 8 U8s (unsigned byte)

S32 (signed 32-bit number)

There are other similar typedefs where I've added the boolean flag just after the first string, but they don't seem to cause the same problem.

I also discoved in TS that I had forgotten to give a name to the matching item in the "Cluster Passing" tab of the TS type.  However, that did not seem to affect the problem at all.

Also, the only prototype it asked me to update was a direct VI call from our master sequence.  There is a step type defined that also uses the same VI, but it does not seem to be affected.  Other VI invocations using the suspect typedef don't seem to be affected.  However, there are other typedefs in the suspect VI definition that are starting to look like candidates for further examination.

[GeoffF]

Changing the direct call to "Skip" and using the step type instead (but with the same inputs) seemed to fix the issue on our local LV2010 machine.  I've yet to confirm with the Europeans, though.

[Shawn_S.]

Hello GeoffF,

Would you mind posting a screen shot of the exact error?

[GeoffF]

Here's the screenshot.  I've obscured items that might identify companies or products (of course).

It appears whenever we try to run any sequence.  Basically, "xxTestSystem.seq" contains all the entry point code.  "State0" is a subsequence that is inserted at the start of most test sequences to set defaults, restore equipment to known values, etc.  However, this error message pops up before the code even gets to the "PreUUT" entry point.

I've also attached a screenshot of the code with the workaround.  In that screen shot, the highlighted step shows the need for a prototype update.  However, since it's a Skipped step, it doesn't produce the error message.  The preceding "Disable Periodic CAN Messages" step from our types palette does exactly the same job and seems to excute correctly.

[GeoffF]

When I said the "Disable Periodic Messages" step "seems to execute correctly", that was because it was skipped due to the precondition.  Changing the parameters for the precondition resulted in a run-time error from the step:

Error, code = -17600

Error executing substep 'Pre'

The prototype of VI 'C:\<directory path elided>\820_CAN_StopPeriodicCanMessages(Cluster).vi' changed.

The prototype needs to be updated before executing the VI.

To update the prototype, open the Specify Module dialog.

Interestingly, when I run it on the LV8.6 system, I get a different error relating to one of the input variables for the Post step - specifically FileGlobals.Can, which exists for the calling sequence file, but not for the main Test System sequence file.  In other words, I can't really use the step in the State 0 subsequence without major changes.   Of course, on the LV 8.6 system, the bare VI call step works without a problem if I remove the "Skip" condition.

Regards,

Geoff

[GeoffF]

I tried moving the flag to the end of the typedef, but there was no apparent change to the behaviour.  Since it's a user interface item, I'd rather not move it about too much.

[Shawn_S.]

Hello GeoffF,

I have found a KnowledgeBase article that speaks of a similar issue, however they are with different versions of TestStand and LabVIEW than those you are using. The article addresses this issue arising due to the version of TestStand that is being used was released prior to the version of LabVIEW that is being used. Perhaps it is something similar to this that is causing this issue. I have attached a link below for you to take a look at.  You will want to start by finding the particular step that is causing the error and reloading the VI.

Error Code -17600, Failed to Load a Required Step's Associated Module When Using LabVIEW 8.2 with TestStand 3.5

http://digital.ni.com/public.nsf/allkb/CA0423F591A14B28862572D00077AF4A?OpenDocument

How Can I Update All The VI Calls In A TestStand Sequence?

http://digital.ni.com/public.nsf/allkb/D7CB87B8EE52E7978625758400762D2D