Asynch call to dynamic dispatch VI - will it be available?

[PiDi]

Hello

I'm wondering if it will be possible to use asynchronous call VIs with dynamic dispatch VIs (classes methods) in next versions of LabVIEW. When I try to do it, I get broken arrow with error attached. It ends with "in this version of LabVIEW" (i.e. 2011). Should this give me hope, that NI is currently working on such feature, or is it just my over-interpretation?;)

[tst]

There is one obvious difference between a CBR node and a DD VI which would cause NI not to support combining them - with a DD VI, the decision which VI to call is made at run-time when you get to the VI call. With the CBRN, the decision can also be made at run-time, but it has to be made at the Open VI Reference node, not at the CBR node.

The two features probably could be combined (either by saying that the CBR node will behave differently from normal DD and only allow you to run the actual VI you referenced or by adding special code which will allow it to call the correct VIs), but I have no idea if such action has been taken for 2012. I would guess not, but you can probably find out in about a month.

[onnodb]

You realize you can work around this by creating a non-dynamic-dispatch "wrapper" VI? You call the wrapper VI asynchronously; the wrapper VI then contains nothing but a call to the dynamic dispatch VI.

Not ideal, but workable.

[bokorpet]

It may work syntactically but it seems to me that the VI inside the wrapper won't be dynamically dispatched. What happens instead is that LabVIEW executes the VI of the super class 😞

Any idea for a workaround, i.e., how to start dynamically dispatched VIs in parallel?

Thanks,

Peter

[kegghead]

I don't think the two could possibly ever be combined, they are entirely conflicting. Async calls are decisions made at compile/edit time about what to call, and dynamic dispatches are decisions made at run-time. No way to mix the two.

onnodb's suggestion does work though, I've done so many times in my own code and there are entire frameworks built around this (the Actor Framework being among them). During edit time it may appear you're calling a super class because that may be the VI that opens, but bear in mind at edit time there's no notion of what data is riding on that wire. At run-time there could be any child class on the wire and the type will be resolved to the correct dynamic-dispatch.

[tst]

---

@Bokor wrote:

It may work syntactically but it seems to me that the VI inside the wrapper won't be dynamically dispatched. What happens instead is that LabVIEW executes the VI of the super class 😞

---

I don't see why. The setup is that class B inherits from A. You create A:wrapper.vi which calls A: DDVI.vi (which B overrides). You then call A:wrapper.vi using the ACBR and pass it your B object. The VI will do an async run and then get to the DDVI.vi call. Because the actual object is of type B, it should dispatch to B: DDVI.vi.

[bokorpet]

Yup, the basic wrapper works as you describe it.

There is, however, a related case that I cannot comprehend:

1. The wrapper has got an input which is a reference to object C.

2. The wrapper contains a loop which calls inplace a dynamically dispatched VI of C in each iteration. (The loop is with shift register.) 

3. The wrapper is called asynchronously (ACBR) and it is passed an object D which overwrites C's VI.

Now the result is very strange: D's VI is called in the *first* iteration of the loop only, then the reference is changed to a C and C's VI is called in all further iterations. Why that??

I found that this strange behavior is due to ACBR as the wrapper works as expected (calling to D in each iteration) if it is directly called (instead of via ACBR). So iIt seems that the ACBR does something to the reference.

Can someone helps me out here?

Thanks in advance,

Peter

[tst]

---

@Bokor wrote:

Can someone helps me out here?

---

Not without actual code or at the very least some detailed images. I suggest you post the actual code (ideally saved to 2011).

If I had to guess, I would guess that the DVR becomes invalid and thus you get a default value out of it (which would be an object of class C) and you're not looking at the error, but that's just a guess.

[bokorpet]

You're right about the error. It complains about the ACBR proxy caller (error code 1556: ACBRProxyCaller.8AF00046).

Can you think of a workaround?

I attach the main and wrapper VIs in JPEG.

Thanks,

Peter

[tst]

---

@Bokor wrote:

Can you think of a workaround?

---

Make sure the top level VI doesn't stop. I think that what's happening is exactly what I guessed - the DVR is created in the get ref VI, which is in the hierarchy of the main VI. When the main VI stops, LV automatically destroys the reference, because the async VI is considered a separate hierarchy and so LV thinks* that no one is using the reference any more. As long as the main VI is still running (for instance, if it's waiting on the output of ACBR call or if it has another loop or subVI), the reference should still be valid.

If that doesn't help, post the actual code. There's no reason we should guess.

* At least that's the way LV currently works - when the original hierarchy goes idle, the references are destroyed.