Call by Reference with Enum Types -- 1031 Errors

[jfron]

I am attempting to perform a Call By Reference on a set of VI's with an input type of enum.

I have successfully executed Call By Reference on VI's with input types that are Boolean, Double, and String.  I need to do this also with VI's that have an input type of INT, where the input control is an enum.  All the VI's have the same pattern with a UINT16 data type, but Enum controls are used, and the values of the Enum items are different depending on which VI is to be called.  I would have thought that since the input to each is a single UNIT16 type, that Call By Reference would allow it.  Unfortunately, at runtime, I get a 1031 error when loading any VI other than the one used as a Reference.  The calling function will be passing a plain UINT16 value, and does not care what the Enum items are, just the int value.

Is there any way to use Call By Reference with VI's all having the same input type, but with different Enum values?

I can't change the input type to plain UINT16, the enum values must be retained in the VI.  However, perhaps there is a way to access the VI's properties at runtime so that it matches the Reference VI exactly (or dynamically modify the Reference so that it matches the VI to be loaded)?

[Dynamik]

Hi Jfron,

     Try this.

(Cheers)

[mikeporter]

I use enums and call by reference a lot and haven't had any significant problems.

If you are talking about enums that have different items in the enumeration, that won't work any more than connecting a string to a number input. Enums with different values in them are different kinds of controls, different datatypes. What is it exactly that you are trying to do? Now there are ways of dynamically linking to VI's with different connector panes--but passing data then becomes the connection pain.

Mike...

[jfron]

> Try this.

That's it!  I ran a simple test, and it seems to work.  The enum even coerces out-of-range values.  Thanks!

[jfron]

> If you are talking about enums that have different items in the enumeration, that won't work any more than connecting
> a string to a number input. Enums with different values in them are different kinds of controls, different datatypes.

Yeah, I pretty much figured that was the case when they refused to load.

> What is it exactly that you are trying to do?

We have a (large) set of low-level VI's that handle hardware calls.  These are in turn generall called by TestStand -- hence the enums: it's much easier for someone to sit down and insert a VI call to "setState.vi" with a value of "Open" "Closed" "Short-to-Battery" "Short-to-Ground" when they can select the value from a drop-down menu in TestStand.

We also have existing tests that are executed on a second machine using non-NI hardware.  Those routines are extensive, and far too much effort to re-implement in LabVIEW.  Also, for various reasons, we can't run the Non-NI software/hardware on our PXI (i.e. concerns about processor load, and the PXI chassis we have has no empty slots).

Essentially, what I'm doing now is this: I'm writing a small TCP server so that the non-NI machine (any machine, even machines without LabVIEW installed) can connect to the PXI box and execute arbitrary code.

> Now there are ways of dynamically linking to VI's with different connector panes--
> but passing data then becomes the connection pain.

Dynamik's example code gives me exactly what I need to extend the current capabilities to include VI's with differently-enumerated UINT16 inputs.  Of course, I had to insert an "Invoke Node" to actually RUN the VI after writing the data to the descriptor.

[Dynamik]

Hi Jfron,

Kudos humbly appreciated.  Your welcome!

[mikeporter]

Yes, that will work. One point to be aware of is that running a VI using an invoke node does not link that VI to your program. Hence, if you query it's state it will say it's running top-level. Likewise, the call chain in the subvi will not include the Code that's "calling" it.

This is a fine point that probibly won't make any difference, but it's something you should be aware of...

Mike...