CIN (Code interface node) LabVIEW runtime engine dependency

[GE_Osmonics]

Hello:

Am I correct that the old style CIN (code interface node) is not dependent on what version of LabVIEW runtime engine is being used?

However if I create a dll  from say LabVIEW 8.2 I must then alway have LabVIEW runtime 8.2 installed on any newer machine with newer version of LabVIEW?

Thank You!

[smercurio_fc]

Once you create the DLL, that DLL is tied to the specific version of LabVIEW used to create the DLL. So, yes, you will need to have the LabVIEW 8.2 Runtime Engine to use it.

[rolfk]

You seem to confuse two things here. A CIN is an external code resource created with a C compiler. The same applies for a C compiled DLL included in a LabVIEW program though the Call Library Node. For both if they call into LabVIEW manager functions at all, they will use whatever runtime engine is used to execute the VIs that include the CIN or DLL call.

If you create a DLL from LabVIEW VIs, it's an different beast. That DLL will be starting up a runtime engine to execute the VIs inside the DLL, but if the DLL is called by a LabVIEW VI, that DLL will detect this and instead link to the runtime engine that executes the VI. At least that is the intention but there have been in the past some flakes in some versions, that usually got fixed with a bug fix release.

Aside from the aforementioned problems with some versions of LabVIEW, it's a bad idea to call LabVIEW DLLs from LabVIEW. It involves each time converting from LabVIEW parameters into stack based parameters and back into LabVIEW parameters both for input and output parameters, which can get easily a performance issue.

[GE_Osmonics]

Hello:

What I have are old CIN (no source) that work in LabVIEW7.1 but will not work in LabVIEW 2010 (link error, object code not loaded). 

What I thought I could do is generate dll from the vi's that contain the CIN using LabVIEW 7.1 with application builder.

 I could use the Call Library Function from LabVIEW 2010 to load the 7.1 generated dll  to effectively do what the old CIN accomplished

provided I installed the LabVIEW 7.1 runtime engine on my LabVIEW 2010 machine

Thanks for the input

[rolfk]

---

@ge Osmonics wrote:

Hello:

What I have are old CIN (no source) that work in LabVIEW7.1 but will not work in LabVIEW 2010 (link error, object code not loaded). 

What I thought I could do is generate dll from the vi's that contain the CIN using LabVIEW 7.1 with application builder.

 I could use the Call Library Function from LabVIEW 2010 to load the 7.1 generated dll  to effectively do what the old CIN accomplished

provided I installed the LabVIEW 7.1 runtime engine on my LabVIEW 2010 machine

Thanks for the input

---

If the CIN resource doesn't load you most likely changed the LabVIEW platform. LabVIEW for Windows 32 Bit and LabVIEW for Windows 64 Bit are different platforms. Just as LabVIEW for Windows and LabVIEW for Macintosh or Linux. A 32 Bit DLL, which a CIN is internally can't be executed in a 64 Bit environment at all.

Your solution fails for more than one reason here. LabVIEW will try to load and link a LabVIEW DLL into its actual runtime environment to avoid interprocess communication latency which would be inavoidable if the DLL is started in a seperate runtime engine, which is in fact a new process. If your issue is 32 bit to 64 Bit you won't be able to link the 7.1 32 Bit DLL into your LabVIEW 64 Bit application through the Call Library Node at all.