NI does not actively maintain this document.
This content provides support for older products and technology, so you may notice outdated links or obsolete information about operating systems or other relevant products.
LabVIEW
Code interface Node:call Interface Node No longer Supported
hi al i facing the issues ("Code interface Node:call Interface Node No longer Supported") i tried to open the block diagram but it password protected can any one help me in this
and i doesn't facing this issues in 2021 but in 2024 version I'm facing the issues
Is version 2021 32bit and 2024 64bit?
(also start reading here and also be aware of this)
Where is the VI from? Is this from a commercial driver? Can you contact the author for help?
Well well 😀
Why someone would password protect a VI with a Code Interface Node inside is really beyond me, as all the interesting work likely is done inside the external code.
But Code Interface Nodes are a thing of the ancient past! And yes I really mean ancient. It was the way to interface to external Code in LabVIEW 3 and 4 but LabVIEW 5 had already a Call Library Node that was for many cases already superior to the CIN. It got improvements in subsequent versions and as of LabVIEW 7 there were virtually no reasons at all to develop a CIN instead of interfacing to a shared library through the Call Library Node, as it had no real advantage anymore and only caused a more troublesome development phase and distribution of VIs using CINs for multiple platforms was simply outright a nightmare.
CINs still work in new versions BUT there is a huge BUT!
Support for the creation of CINs has been discontinued with version 8.0 or 8.2 on purpose. And support for running CINs has not been ported to any new LabVIEW platform since at least 8.0. This means that there was really no way to create CINs for any of the real-time targets (exception: LabVIEW for Pharlap targets could load old self contained Watcom C compiled CINs), Apples with x86 or ARM Silicon, and any 64-bit platform. Basically the only current platform that could still load CINs until recently is LabVIEW for Windows 32-bit.
I'm not really sure when and if NI removed CIN support completely and for good. If you were using LabVIEW 2021 32-bit, that CIN could run, but if you were installing LabVIEW 2024 64-bit there simply never was or is a way for a CIN to be loadable even if you went back to LabVIEW 2009 64-bit, which was the first 64-bit platform LabVIEW was supporting. Maybe LabVIEW 2024 32-bit still supports loading old CINs, but unless it is a very precious function that you absolutely can't live with, I don't think there is any merit in trying to install the 32-bit version of LabVIEW. CINs were on extended life support since about 20 years already and they will for sure go away for good soon if they haven't already. Whoever developed and maintained that application in the past, should have thought 15 years ago already about how to go forward and mitigate obsoletion of that little CIN critter in the code.
If you really want to know more about the history of CINs and external code development for LabVIEW you may want to take a look at my blog on kalbermatter.nl/blog. Be warned however, it for sure will contain more than you ever wanted to know and will be likely simply useless ballast unless you endeavor into external code development yourself. 😁
Hi
Yes, Rolf is the undisputed CIN master.
The newest CIN related manual ( also discussing DLL's ) is probably this from 2003 :
Whether CIN's were still run'able was already up for discussion in 2010.
https://lavag.org/topic/14928-convert-cin-to-call-library-function-labview-2010/
NI has this odd page mentioning HP-UX, Solaris and PowerMac, declaring the page updated in 2023 :
Archived:Using External CIN and DLL Code in LabVIEW
Updated Jun 12, 2023
Environment
Software
- LabVIEW Full
- LabWindows/CVI Full
I want to call external CIN and DLL code from LabVIEW, but I am not sure where to start. How can I do this?
In order to call external CIN and DLL code in LabVIEW, you should become familiar with:
-
CIN & DLL Starting Point
- Using CINs in LabVIEW Base Package
- Optimization and Performance Issues for External Code in LabVIEW 7.x
- How To Compile CINs and Shared Libraries with GCC on Solaris
- Compilers that support CINs in LabVIEW
- Create a CIN with LabWindows/CVI 4.x and Above
1. CIN & DLL Starting Point
If you are using Microsoft Visual Studio .NET 2003, a great reference would be the tutorial Creating a CIN Project in Visual Studio .NET 2003. It describes how to configure Microsoft Visual Studio .NET 2003 to create a Code Interface Node (CIN) project to write CIN code for use in LabVIEW 7.1.2. Using CINs in LabVIEW Base Package
Although CINs are used in the LabVIEW Base Package and show up in the functions palette, they are not supported for application development. The necessary files for creating CIN object files (.lsb) do not come with the base package.The Base Package does indeed allow you to use CINs, but it does not include the tools to build the code that is used by the CIN. You will need to purchased the Full Development System or higher if you want to do this. This is why the CIN is present in the palette but the Cintools directory under LabVIEW is absent. There are several steps involved in creating a CIN:
- Put the node on the diagram and wire up the inputs and outputs.
- Create the .c file from the CIN's pop-up menu
- Edit the .c file and insert your code.
- Create a code resource file (.lsb) from your .c file. To do this, you need the "CIN Tools"
- Load the code resource file (.lsb) from the CIN's pop-up menu.
3. Optimization and Performance Issues for External Code in LabVIEW 7.x
You should strongly consider using thread-safe CINs and DLLs. A CIN or DLL is thread-safe if it can reliably be called from two or more separate threads. Since CINs and DLLs that are thread-unsafe must be run in the user interface thread, any call to such a CIN or DLL causes LabVIEW to switch execution from the block diagram's thread to the user interface thread.There is overhead associated with this switch. The CIN or DLL will run to completion in the user interface thread before relinquishing control to the thread, so the user interface will appear unresponsive during this time. By default, LabVIEW considers all CINs and DLLs to be thread-unsafe. The reason for this is that the computer may crash or hang if LabVIEW assumes a CIN or DLL to be thread-safe when it is actually thread-unsafe.
To identify a CIN to LabVIEW as being thread-safe, you must include certain function calls in the CIN. You can also see Chapter 3 of the LabVIEW Code Interface Reference Manual»CIN Advanced Topics, for more information.
4. How To Compile CINs and Shared Libraries with GCC on Solaris
Please reference How Do I Compile CINs on Unix / Linux? which will covers the steps on how to compile.5. Compilers that support CINs in LabVIEW
For a list of compilers that support CINs for LabVIEW 5.x see the Code Interface Reference Manual.Here is a list of compilers for LabVIEW 4.x:
- Macintosh: Symantec’s THINK environment, Metrowerks’CodeWarrior environment, GCC, and Apple’s Macintosh Programmer’s Workshop (MPW) environment
- Microsoft Windows 3.x: Watcom C
- Windows 95/NT: Microsoft Visual C++ compiler and Symantec C compiler
- Solaris 1.x and 2.x: unbundled Sun C compiler
- HP-UX and Concurrent PowerMAX: HP-UX C/ANSI C compiler and Concurrent C Compiler
- PowerMac: Metrowerks CodeWarrior C/C++ and Symantec C++ Version 8
- Linux: GCC
6. Create a CIN with LabWindows/CVI 4.x and Above
The detailed instructions on how to create a Code Interface Node from LabWindows/CVI is given in the cvilvsb.h file which can be found in LabVIEW/cintools folder.
Regards
@Vishnu2098 wrote:
both are 32 bit
Then NI finally sacked CINs for good and well. Can’t blame them for this. It was an anachronism for over 20 years already although I had felt some attachment to them back in the days. But that was in the last century!
