Preserve Run-Time class - why?

[CoastalMaineBird]

LV2013.

This code works, but I'm trying to figure out why I need the PRESERVE operation.

If i don't include that, I get a compile error, at the right-side ShiftReg:

"One or more of the inputs to this terminal or shift register does not originate at the dynamic input front panel terminal."

The VI used, looks like this:

I have a root class called "Addon", and a child class called "Addon for Emissions TC".

Another root class is called "Emissions Bench" - not a child of either one.

The "Addon for Emissions TC" class contains an array of "Emissions Bench"es

The purple VIs are methods of the ADDON (root) class.

So I pick out each bench, do some work on it, and put it back into the array.

Some of that work involves a root method.

But I don't understand the error.  There is no way for the output terminal to be some class OTHER than the class that came in.

If I put the PRESERVE operation inside the VI itself - it still has the error.

I can't make that second input terminal DYNAMIC (LV won't let me) - is that the issue?

Can someone walk me thru what the compiler is thinking?

[Intaris]

Did you try putting the "Preserve" outside the case structure, just before the terminal output in your sub-VI?  IIRC this should allow the IDE to auto-detect the fact that the class does not change.

[CoastalMaineBird]

I just did that.  No change.  If the preserve is not in the loop, outside the VI, then it complains.

If I have to put in a "preserve" op, it's not "auto-detected", is it ?

[Intaris]

If you pass an object through a Dynamic dispatch VI (Where the object terminals in question are themselves not Dynamic dispatch) then LV cannot possibly know whether the same object type is passed back or not due to the ability to load classes at run-time.  As such these will always default to the base class.

If, however, you have a static VI and the static VI does not call any other VIs which may cause a change in object type then the object type should still be maintained.

It's enough if a single element in the chain does not guarantee to return the same object type.  Then the output datatype will again default back to a base class.  IIRC, placing a "Preserve" node immediately before the terminal returning the object (with the type wire coming from the input terminal) should restore this functionality.  YMMV.

The attached code has an example.  Static VIs in themselves can retain the type.  But if a static VI contains VIs which do not guarantee the same object type (formally) then the type gets lost UNLESS you put a "Preserve" item directly before the returning terminal.  Of the 4 sub-VIs in the example, 2 are DD and lose the object type (This cannot be changed as the scope of code for DD VIs is not known at compile time) but of the two static VIs (Which call Dd VIs), one uses the "Preserve" and one does not.  The one which preserves type returns the same type on the terminal whereas the other coerces to a parent type.

[CoastalMaineBird]

I can't see your code, as I'm stuck on LV2013.

I did learn that it's the TERMINALS of the subVI that cause the issue.

Notice in this pic that I have the PRESERVE op just before the output terminal, but that fails to help.

That means that, because that input is NOT dynamic (and I can't make it so - LV does not permit it), then the wire has lost the true data type.

Preserving it INSIDE the VI does no good, because it's lost AT THE INPUT TERMINAL.

Even wiring the output directly to the input terminal does not solve it.

But preserving it BEFORE calling the subVI, and restoring it afterwards, is OK.

Since the input terminal is STATIC, and of type ADDON for EMISSIONS, the output terminal must be the same type.

The purple VIs can accept an object of type ADDON for EMISSIONS, because that's a child of type ADDON.

But I can't REPLACE the shift reg object with an ADDON for EMISSIONS, because the shift reg is of type ADDON - it might have been some other type.

The PRESERVE operation, is a promise from me to the compiler that I know this is OK, even if it can't tell.

At least, that's what I get out of it.

Anything wrong with my thinking?

[Intaris]

The code you show, "MoSAIC Emissions Bench.lvclass:Bench Menu Items.vi", is it a Dynamic member of the owning class? (Are the top connectors Dynamic Dispatch?)

If so, then due to the fact that the ACTUAL method which will be executed at run-time may be different than you show here (You might want to load a child class which doesn't contain the "PRESERVE" node, then LV CANNOT guarantee that the output will be identical to the input.  If, however, the VI is a static member of the owning class, then it really should work.

This would explain why you need to follow the Dynamic VI with the PRESERVE node.  You could cheat and create a STATIC caller of the Dynamic VI and simply put the PRESERVE in there.  This way you have simply encapsulated the "PRESERVE" method into a sub-VI.  It will then behave as you require.

[CoastalMaineBird]

---

Intaris wrote:

The code you show, "MoSAIC Emissions Bench.lvclass:Bench Menu Items.vi", is it a Dynamic member of the owning class? (Are the top connectors Dynamic Dispatch?)

---

Yes.

You could cheat and create a STATIC caller of the Dynamic VI and simply put the PRESERVE in there.

I don't care WHERE the preserve is done.  I'm just trying to figure out WHY it's needed.

The answer seems to be that the terminal on a subVI is NOT dynamic brings up the need.

Not sure why a dynamic terminal is not allowed there - I guess it would then be a dispatching nightmare.  Although only one terminal should be the "dispatching" terminal, which determines the instance to run.

In any case,I think we're done.  Thank, Intaris

[Intaris · Accepted solution]

The problem is not due to the dynamic or static nature of the Addons terminal, it related to the dynamic state of the Emissions Bench input.  Because THESE inputs are dynamic, LV CANNOT guarantee that the code you currently see is even the code which will be executed at run-time.  It therefore cannot guarantee that the type will be preserved.

If you wrap the "Emissions Bench: Bench Menu Items" VI in a static VI (Which calls the Dynamic VI) you can then put the Preserve in this sub-VI.  This will then give the appearance of double dispatch.

[CoastalMaineBird]

OIC! 

This particular VI does guarantee that the output is the same as the input (on that lower set of terminals).

But because it is dynamic, some OTHER override might come along and do something different.

Then you would be trying to set the shift reg to this other type, which would possibly be harmful or impossible.

The main terminals are dynamic, so LV can be sure that the output type is the same as the input type (it will complain if you break that).  But it can't guarantee that in all cases, for this non-dynamic terminal.

The help says "either originates at a different source, or the wire passes thru some function that doesn't guarantee runtime type preservation".

I traced it through and didn't find such a case, but what I failed to consider was the possibility of some other override failing that guarantee.

So the PRESERVE operation is my promise that they ARE the same type.

I don't need to hide that operation, I just need to explain it.

Thanks again !