Why can't my VI (called as a .dll from VB) get at the controls of another VI running in memory?

[Ben]

I am not sure why this will not work.

I have a VI that talks to a widget. This VI, call it CP.VI (for Control panel) will allow a user to punch some keys key on the front panel that show up in one of the indicators. When the user punches the "enter" button the string that was built up in the indicator is sent to the widget. THe widget responds and the results show on the screen.

The CP.VI works fine. No problems there.

The customer then wanted to get the user out of the loop so I wipped a VI that does the button punching. It does the button punching by using control references to punch the right keys and look for the response.

This worked great as well. Give the "button Puncher.VI" a list of commands and it can breeze through all of the commands and tell you what you got back from each command.

All of this was great until...
We tried to port this functionality to VB.

We crated a dll from the "button puncher" so we can pass the dll a command and check the response coming back.

I simplified the button puncher and set it for "show front panel when called". When the button puncher VI is called I can see the data that was passed in from VB. I can see a "dummy" response returned to VB from the dll. I can also view an error cluster on the FP that shows me that there where no errors in any of my refnum operations.

The problem is that when I write the "value" property of any control, it nver shows up in the front panel of the CP.VI.

No errors!

Same applies to reading the "value" property.

It seems the dll when called in VB is running in a completely different memory space or something.

It reminds me of posts by others that it is possible to run multiple copies of a VI by creating a dll and running that.

I believe I will end up having to do active-X from VB to punch the buttons but I am not sure.

Anyone understand what is happening to me and would care to teach me something?

Admiting his ignorance,

Ben

(last time I touched basic it was BasicA)

P.S. In all cases the CP.vi is up and running.

[JeanPierre]

Ben,

how do you read/write the "value" property? I'm not familiar with DLLs created with VIs but I'm quite sure they have their own memory space separate from LabVIEW/Application. Probably button puncher runs in the dll space and acts on an instance of CP.vi in that application space. If you look at an instance of CP,vi running in LabVIEW/Application, it won't be updated.

Please be more specific about how references are opened and where CP.vi is running so we can figure out what happens.

[BJD1613]

Ben asked me to post this vi. This is the button pusher vi that is compiled into the dll.

[Ben]

Please see BJD's comment to see the code that runs but does not seem to work as a dll.

Ben

[Jeremy Braden]

Jean-Pierre is on the right track. Dlls created in LabVIEW behave like executables in the sence that when they call other VIs, they call copies of the VIs. I imagine this helps make the dlls/executables more resistant to crashing but it can be aggravating to code. The only workaround I have found is to have your code call LabVIEW via activeX which in turn calls the VI.

[JeanPierre]

Ben,

If I understand correctly,you make the button puncher as an interface DLL between VB and another LV app running NEWCLIENT.vi. Indeed, when the VI inside the DLL opens a VI reference to NEWCLIENT.vi, the VI is instanciated in the DLL memory space, not in the other LV app.

To accomplish what you need the VI in the DLL should open an application reference to the LV application. To do this, wire "localhost" to "Open Application Reference" and activate the TCP VI Server in the LV app.

Another way is to enable ActiveX VI Server in the LV app and let the VB application make an ActiveX Call/Run to the button puncher VI.

[Ben]

Hi Jean-Pierre and Jeremy!

Thanks for the follow-up.

I thought wiring the IP of the machine I was running on was the same as using "localhost". I will have bjd try that out.

There are two options under VI Server configuration that allow me to enable disable TCP/IP and active-X protocols. I am fuzzy on exactly when one or the other is used.

I believe that when I connect to another machine and do a call by reference, I am using TCP/IP.

When I open a reference to a VI in LV from LV, I think I am using Active-X. Not sure on this one though.

It seems that if I disable the "Active-X" protocol and use the "localhost" I should be forcing LV to use TCP/IP protocol. Like I said I will have bjd try that one out.

Re: transfering th
e "Button Puncher" functionality into the VB app. I think I will re-write the interface to the widget before trying that. The "Button Puncher" was a fast way to demonstrate that we can do the same thing an operator can do and let people watch while it was happening.

I will post summarizing how we solved this in the end.

Ben

[JeanPierre]

> I thought wiring the IP of the machine I was running on was the same as using "localhost". I will have bjd try that out.

Yes it is the same except when the IP is hardwired in the VI diagram, the code is not portable if the IP changes. Anyway the address is not wired in the posted VI so it opens a ref to local (dll) application.

> There are two options under VI Server configuration that allow me to enable disable TCP/IP and active-X protocols. I am fuzzy on exactly when one or the other is used.

If you use VI server within the same application, neither TCP or ActiveX is used because they can be both disabled. It remains internal to the application.

When one LV app/dll is client to another LV app VI Server, it
is the TCP VI Server that is used. The protocol over TCP is private to LabVIEW. Just the TCP server needs to be enabled.

You activate the ActiveX VI Server when a third party application (like VB) is to be the client using ActiveX. The ActiveX VI Server is rather limited, not having properies/methods below VI (no panel or control refnum access). So if you want to write control value property, you have to write a VI that wraps the function and call it from VB

[Ben]

We tried every variation of TCP/IP addresses and enabling/disabling VI server protocols. None of these helped. We even tried the complete node\\file_Spec (as if trying to run a VI on another machine) with negative results.

But...
Our suspicion that we have to different memory spaces was the key we needed.

Inset key and turn. Door opens!

I think we managed to crack this nut.

All of my observasions indicate that when VP and LV are running on the same machine, they are using completly different memory spaces (as we suspected). These observations are based the returned values we where getting from "all VI's in memory". The VI that was called as a dll, only saw itself and its sub-VI's.

What we had to do was get t
he VI we want to act on to show up in the listing from the VB called dll.

How we did it:
1)We included the target VI (the one we wanted to operate on) as an "exported" VIT in the build of the dll.
2) Used the "First Call?" (from advanced>>>syncronization) to control a case that used an invoke node run method on the VIT the first time it was called. The returned refnum was then saved in a shift register for subsequent use.
3) On subsequent calls, the previously cached refnum was used do perform the tasks required.

Summarizing:
Problem
LV dll called from VB run in a different memory space than LV.

Solution
Include the target as part of the build and start it from within the dll to get it into the same memory space that VB is running in.

Jean-Pierre and Jeremy,

I would like to thank you very much for being willing to interact on this issue. I think it is Proverbs that says "There is wisdom in a multitude of counselors."

I count both of you as wise counselors (actua
lly you guys have been more like mentors).

Thanks again!

Ben

[BJD1613]

I second what Ben said. We appreciate the help on this topic and now the project can go on. Thanks again.