Register Event Callback problem with Linkam ActiveX controls

[Davide De Focatiis]

Hello,

I have a problem in configuring a VI Reference to interface with a Linkam ActiveX control through a Register Event Callback function. I have created a strictly typed VI with reentrant execution, with all of the correct connectors, as shown in the image below, but LabView complains of a broken wire. The only difference between the input and output seems to be that the output shows up as an asynchronous function, and the input wants a normal function (synchronous?). I cannot find any option to make my VI reference become synchronous. Does anybody have any suggestions as to what to try next? Many thanks,

Davide

[wilburwu · Accepted solution]

Hi,

right click on the terminal "VI Ref" choose "Create Callback VI".

Don't try to build it yourself, it never works. 🙂

[JackDunaway]

Would someone be able to explain why this is broken? I have a situation exactly like the original poster; the strictly-typed VI refs match exactly, yet there's still a Wire Class Conflict. The workaround is to recreate the VI using "Create Callback VI", but it's laborious to transfer code, VI icon, documentation... What gives?

Here's the exact error in LabVIEW 2012: "Wire: Class Conflict - You have connected a refnum of one type to a refnum of another type and both types are members of some class hierarchy, but there is neither a simple up cast nor type cast between the two classes."

[Pete.Dunc]

Hi Jack,

I'm struggling to replicate this one in LabVIEW 2012f1.  Whether I create the callback function manually or automatically I do not see the broken wire.

The only things which jump to mind when talking about synchronous and asynchronous functions are the execution options in VI properties.  For instance, the VI priority or whether it is reentrant.  If you could provide some simple steps to replicate (as recreating the above example did not show me the behaviour) then I'll be happy to dig a little deeper.

[JackDunaway]

Hi Pete! Thanks for responding. A simple way to recreate this is to:

1. Create Callback VI
2. Create a new, blank VI with the exact same conpane as the Callback VI that was just created (you can do this even by copying all 4 controls from the created VI into the new VI)
3. Ensure those four new controls are wired into the conpane like the VI that was created
4. Wire this new VI that you "recreated from scratch" into the "VI Ref" of the Reg Event Callback node.

After completing step #4, you'll have a broken wire between the VI that you created and the Rev Event Callback node. Even if you Context Help and hover over the wires of both VI static refs of the created VI and the VI you recreated, their Data Types will be identical (as shown in the original post).

Does this help recreate the issue? Thanks!

[Pete.Dunc]

Hi Jack,

Thanks for the steps - this is identical to what I had done on my machine here.  I did toy with the execution settings afterwards (not the most structured testing, I must admit..) and it now does not occur.

I will set up a clean install tomorrow morning for testing.

[JackDunaway]

Oh, it's also worth mentioning... (I'm like the worst support customer ever, slowly revealing more and more details, you think I'd know better :b)

This problem is happening on VIs that were created exclusively using the "Create Callback VI", so no VI execution settings have been changed from what was created. The only thing that I'm changing is the datatype of the final "User Parameter" input. As I redefine the datatype of that control is when the VI breaks.

[Pete.Dunc]

Hi Jack,

Sorry for the delay in getting back on this one.  Using the Adobe Reader ActiveX control (the first in my list..) I cannot replicate the behaviour.  Well, I can, but if I change the datatype of the Callback VI then the wire goes back to being solid.

1 - Add ActiveX container and set object

2 - Create Callback VI automatically

3 - Wire something to the user parameter input (wire will break)

#

4 - Change Callback function to reflect this change (wire is okay again)

[JackDunaway]

OK, I've uploaded three VIs: a caller, a callback that works, and a callback that is broken. Note that the two callbacks have identical conpanes.

Below the Register Event Callback Node, I have placed an "Equal?" prim to show that the strictly-typed VI references are not of the same type, even though they have the same conpane. Here's a screenshot showing the two VI refs having VI Interface Type 4 and VI Interface Type 5, yet my understanding would be that these should be the same type.

So, I think we're not dealing with any problems with .NET callbacks; it's a problem with my understanding of strictly-typed VI references and the concept of "VI Interface Types". Why are these VI Interface Types different for two seemingly identical VIs?

[nathand]

---

JackDunaway wrote:

This problem is happening on VIs that were created exclusively using the "Create Callback VI", so no VI execution settings have been changed from what was created. The only thing that I'm changing is the datatype of the final "User Parameter" input. As I redefine the datatype of that control is when the VI breaks.

---

It's been a while but I think I've seen this problem before.  Can you fix it by right-clicking the VI reference, Browse for Path..., and reselecting the callback VI?  Also make sure the callback VI reference is strictly typed.