LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Casting a DVR to more specific within an IPE

So I have following use case:  I have a UI and a state machine which I want to be able to share the same object DVRs.  This is to easily allow me to alter the parameters of the state machine object while the state machine is running.

 

I also want to have a modular UI so I have a UI for each object running asynchronously in a sub-panel.  So far so good, all works.

 

Now I wanted to actually store DVRs instead of objects themselves and I ran into an interesting behaviour.

 

If I define a parent static method with a DVR input which contains an IPE which then calls a Dynamic dispatch version of the "Launch UI" while branching the DVR before the IPE and inputting it as a parameter to the "Launch UI" (so that they will share the same DVR but still allow Dynamic dispatch) then I am forbidden to even perform a "Cast to more specific" within the "Launch UI" VI.  I have to pack it into the init portion of the actual asynchronous UI.

 

DVR Async UI launch.png

The VI shown here (purple banner) launches an async VI which accepts a DVR as a parameter.  I wanted to pass a strict DVR (the purple VI is dynamic dispatch) but this has caused problems.  In this image, if I try to perform a "Cast to more speficic" in the VI shown with the purple banner, I have a deadlock.  If I pass it as a base class but do the cast in a VI started asynchronously, the IPE will exit and the cast can continue.

 

Is this expected?  Is the IPE preventing me from accessing the required information from within the DVR needed to do a cast?  I can't do the cast outside of the DVR because only within the DVR (in the Dynamic dispatch VI) do I know what I want to cast it to.

 

It surprised me a little, thus the question.

0 Kudos
Message 1 of 6
(3,187 Views)

What if you split the IPE in two? Just extract the Object from the first, use the function and then use a 2nd IPE to write it back?

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 2 of 6
(3,173 Views)

Because the DVR could already be in use elsewhere at the same time.  I don't want to create a NEW DVR, it must remain the same pointer.

0 Kudos
Message 3 of 6
(3,162 Views)

I was thinking along these lines.

DVR.png

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 4 of 6
(3,134 Views)

This unfortunately doesn't work because the IPE is in the Parent VI, not the same VI where the function on the non-DVR object is to be used.....  If they were in the same VI, things would most likely work better, but that would require a Dynamic Dispatch call on a DVR to achieve the same functionality which would essentially make the whole concept irrelevant in the first place as that is what I'm trying to simulate.

 

I have since solved the problem, I simply cast the DVR in the UI.  Since I control when this operation is done, I know that it will essentially always be the correct type, as I have managed to couple the DVR with the correct Dynamic Dispatch function.  I was just being a bit pedantic and wanted my Async VI to have the connector pane with the correct specific class on it.  This would prevent me from connecting the wrong UI Async VI reference to the wrong object as it would give a wiring error.

0 Kudos
Message 5 of 6
(3,130 Views)

I'm out of my depth on the discussion as a whole, but just in case this helps anyway...

 

My only experience with DVR's was a joint development project architected by a LV Architect.  I seem to recall that there were places it was *very important* to use the 'Preserve Runtime Class' primitive rather than any kind of 'Cast to More Specific/Generic'.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 6 of 6
(3,109 Views)