LabVIEW
Getting error of code interface node.
Solved!
I am getting this below error of code interface node, object not loaded, Please help me for finding solution of this error.
Hi Poojaa,
@Poojaavi123 wrote:
I am getting this below error of code interface node, object not loaded, Please help me for finding solution of this error.
This seems to be rather old code, CINs are supported very well since LabVIEW7 (or even earlier, RolfK surely knows more about this topic)!
There is are Clipboard methods for the "Application" class: can't you use them?
Code interface Nodes are NOT supported in 64-bit versions of LabVIEW!
Code interface Nodes were replaced with Call Library Nodes very early on, and declared legacy technology around LabVIEW 7.1. Any LabVIEW platform released after that does not have support to create CIN object files needed to be loaded into the CIN. This includes all 64-bit platforms as well as NI Linux RT. For 64-bit a different CIN would need to be compiled as it is binary object code and the 32-bit object code can’t be loaded. But there are no tools to do that and you would also need the C source code, which I’m sure you don’t have.
Solutions;
1) Use 32-bit LabVIEW. But be prepared that that is not a solution for very long. LabVIEW for Windows is the only version which is still available for 32-bit (aside of LabVIEW for NI Linux RT for ARM) but for how long? My guess is that LabVIEW 2025 or 2026 for Windows will not be available as 32-bit anymore.
2) Replace that CIN through the VI Server methods as mentioned by Gerd.
3) If you happen to have the source code for the CIN you could rewrite it to create a DLL and call that through the Call Library Node.
If you want to read-more details about the history of CINs and their timeline, you can look in my blog through old entries.
@Poojaavi123 wrote:
Sir, I am using 32 bit version of LabVIEW but error is not resolved.
Then it was probably created with one of the Visual Studio C compilers between 2003 and 2016. These all had their own specific C runtime version that needs to be installed on the computer.
Still, you can either try to get this resolved until you need to get it to run on an different computer or in a different LabVIEW version again, or you can replace this ancient LabVIEW relict with a more modern function that is better supported on nowadays computers. As mentioned there are VI Server methods to access the Clipboard, definitely if it is for text or an image. This would be my preferred solution if it is compatible with what you need. There are many other solutions including .Net that can be used too.
If you feel adventurous, you could for instance also look into this library: https://forums.ni.com/t5/LabVIEW/LV-slows-down-extremely-when-having-large-contents-in-clipboard/m-p...
I really know very little about Sun systems. I used to work on Sun Sparc stations back in the 80ies of last century, when the OS was still called SunOS, later renamed to Sun Solaris 1. That was even before LabVIEW was a fact.
LabVIEW for Sun was released for Sun Solaris 2 running on Sparc stations (those famous pizza boxes). I'm not sure if LabVIEW was ever released for Solaris running on x86 hardware. Technically it would not have been impossible, but sales for LabVIEW for Sun were only underrun by sales for LabVIEW for HP Unix. So it would seem very possible that NI never made that investment but I did not follow the development of that. Mac, Windows and Linux was already more than enough to keep track off.
Since LabVIEW is a compiled language, and CINs are in fact compiled binary object resources, even going from Sparc 32bit to Sparc 64bit (UltraSparc) would render the CIN unusable. Changing from Sparc to x86 or x86_64 even more. I don't think NI ever released LabVIEW for Sun Solaris other than the original 32-bit Sparc Mode. Sun Solaris only seems to have started supporting 64-bit Sparc with version 7 (1998) and 64 bit x86 with version 10 (2005). But the LabVIEW compiler back then was an inhouse proprietary piece of software that had to be completely redeveloped from scratch for every new CPU architecture. So it was not something NI would do on a quick hunch, and the Sun version of LabVIEW, while popular in certain research places, was anything but a money maker.
LabVIEW version 7.1 was the last that supported Sun systems, and that was released in 2004. But the only Unix ambitions NI had from around 2000 and later was Linux, as any other Unix variant had shown more and more declining sales numbers.
The CIN lsb file created in the C compiler for the desired platform was embedded inside the VI as a code resource with the according platform identifier (a unique four letter identifier that was based on a combination of CPU and OS). If LabVIEW loaded a VI with a CIN, it verified this four letter identifier with its own, and if they did not match, the lsb code resource got removed and LabVIEW prompted the user for the correct one (which of course had to be compiled for the right platform with the recommended compiler (you couldn't generally just take any compiler you liked but LabVIEW had pretty strict requirements about which compiler was suitable for a specific platform and what command line options you needed to use to make the resulting object code exactly as LabVIEW wanted it. My guess is that something in the OS changed compared to the original setup where your LabVIEW 6 version was running. However how LabVIEW 6.0 could even run on a "modern" Solaris 10 system is pretty strange to me even if the system you run this on has an old Sparc CPU. Sun Solaris was always a bit tricky to get older applications running on a newer OS, just as most other Unixes too. Strict ABI compatibility across major OS versions seemed never the main focus there.
LabVIEW only gained 64-bit CPU capabilities with LabVIEW 2009 and only for Windows. Linux and Mac got 64-bit support with version 2014. All of this was long after LabVIEW versions for any of the other platforms such as Sun, HP Unix and PowerMax had been already discontinued. It did start supporting 64-bit integers in 8.0 though.
