05-23-2020 11:24 AM
Well, I recently found that I can't open VIs with Inline C Node on the diagram in LabVIEW 2020 (both 32- and 64-bit). When I try to do that, I receive the following error:
LabVIEW: (Hex 0x2) Memory is full.
An error occurred loading VI 'sample.vi'. LabVIEW load error code 43: An error happened while converting the VI to the current version.
You may try to open this example to check it out. Moreover I can't create Inline C Node with VI Scripting. When I run Adding Objects.vi from \[LabVIEW]\examples\Application Control\VI Scripting\Creating Objects directory, I receive this error message:
Error 1061 occurred at New VI Object in Adding Objects.vi
Possible reason(s):
LabVIEW: (Hex 0x425) Unable to create new object.
Did the similar test on LabVIEW 2019 and there I can create Inline C Node with Scripting, but can't reopen the file that I created - LabVIEW quits silently or crashes. I'm unable to open another VIs with Inline C Node as well.
But I successfully open the forementioned example in LabVIEW 2014 or LabVIEW 2009.
Is it some sort of a bug or Inline C Node is considered obsolete and removed from LabVIEW codebase as of 2019 and higher versions?
05-24-2020 12:16 PM - edited 05-24-2020 12:18 PM
Hi da,
with LV2019 (32bit) I get this:
And I found this help article: while the article might be outdated, but do you fulfill the listed requirements?
05-24-2020 01:22 PM
As I see none of those modules has been updated for LV 2019 or 2020. According to the info on ni.com the recent versions are:
Embedded Module for ARM Microcontrollers - 2012 (What Is The Current Version Of The LabVIEW Embedded Module For ARM Microcontrollers?)
C Generator - 2017
Mobile Module - 2011
Touch Panel Module - 2013
Wireless Sensor Network Module - 2015
Anyway I tried to install C Generator 2017 onto LabVIEW 2020 32-bit. Even though it's got installed into "LabVIEW 2017" directory, I moved all the related files to "LabVIEW 2020". There's InLineCNode.vi in C Generator palette:
When I click it, the following error message appears:
LabVIEW: (Hex 0x2) Memory is full.
An error occurred loading VI 'InLineCNode.vi'. LabVIEW load error code 43: An error happened while converting the VI to the current version.
I could assume, nobody cared to fully test those modules onto modern LabVIEWs, because the modules became out of support and their further development is stopped. But it's just a guess and I hope to be corrected.
I will try to do a fresh install of LabVIEW 2019 on another machine to see if I messed with something.
05-25-2020 03:04 AM
I verified that LabVIEW 2019 is able to open VIs with Inline C Node on BD (both 32- and 64-bit versions), but it's true only on Windows platform. On Linux and Mac it doesn't work as I wrote above. But it doesn't really matter, because I use LV on Windows mostly. What is bad, that LabVIEW 2020 is unable to open that sample VI 😭 That's the second computer, where I see such a behaviour.
I would be happy to see, if it's a bug (and a CAR # being filed for it 😉), because I planned to use LabVIEW 2020 everywhere instead of 2019.
05-25-2020 02:31 PM - edited 05-25-2020 02:34 PM
The ARM Module has been obsoleted a long time ago. It's maintenance and support for various ARM targets was way to cumbersome, expensive and complicated to be useful for normal users. A lot of its underlaying infrastructure is used for the ARM target on the Zync FPGA based RIO targets from NI as well as the Raspberry Pi and Beaglebone Black support in the Lynx Toolkit but NI has given up on trying to provide a generic ARM Toolkit for other targets. Way to complicated and worrysome for anyone but the most dedicated hardware freaks. There was also a similar Toolkit for the Analog Device Blackfin CPU. Same reason for discontinuing that, with the additional reason that the Blackfin CPU has since been diminishing into the world of insignificance.
The Mobile Module was last released in 2011 and is since then obsoleted. It is based on Windows CE which has long ago been sent into the void by Microsoft. The same applies in many ways for the Touch Panel Module which is based on Windows Embedded which isn't supported by Microsoft anymore.
The C Generator has not been maintained. It is basically the Generic C compiler to port LabVIEW VIs to other targets. It requires an extremely expensive license to work and the resulting code is basically so complicated to get to compile on other targets that it is pretty useless. So NI stopped actively developing and supporting that too.
05-28-2020 02:25 AM
Thanks, Rolf! Good explanation. I was just a little surprised, that Inline C Node simply stopped working in LV 2020 unlike another legacy nodes, which still do their job (more or less), when needed. Maybe some change in LV codebase broke that node. Or it might be that NI intentionally removed support for those deprecated targets from LabVIEW, but for me it's doubtful, because still there are some pieces of ICN as:
C:\Program Files\National Instruments\LabVIEW 2020\resource\dialog\InlineCNode
C:\Program Files\National Instruments\LabVIEW 2020\resource\dialog\PreferencesDialog\PreferencePages\prefPage_InlineCNode.vi
If ICN is obsolete, then it would be good to mention it in Context Help at least, so nobody would ever try to use it.
Meanwhile I played with ICN a little and found, that it has likely never been tested on 64-bit LabVIEW, because it's bugged a lot. For example, I found these two issues:
1. Open and run Adding Objects - ICN.vi (attached) - a new VI with ICN will be opened;
2. Place the mouse cursor into the text field of ICN;
3. Press Backspace or Delete button;
4. Get LabVIEW hanging up or crashing 😊
1. Open and run Adding Objects - ICN.vi (attached) - a new VI with ICN will be opened;
2. Place Formula Node near Inline C Node;
3. Save the VI somewhere and close it;
4. Now open the VI again;
5. Get LabVIEW hanging up or crashing 😊
Tested these on LV2018 and 2019. The latter bug is reproduced sometimes even without Formula Node. Maybe the VI gets corrupted during the save. I couldn't reproduce these issues on a 32-bit versions of LabVIEW.
Also I had a chance to play with C Generator on LabVIEW 2017 32-bit. It's interesting, that it could be used for generic Win32 platform as well:
I suppose, nobody used it that way (except for PDA targets on Windows), but I tried. It took some time to put all the pieces together, but I got a common Windows DLL compiled and fully functional. It doesn't depend on LabVIEW Run-Time Engine libraries. It's funny, that even my Inline C Node sample was compiled also, although it was contained inside Conditional Disable Structure with TARGET_TYPE==Embedded case. I understand that it's an overkill to type C code on LabVIEW diagram to get it converted into C code again to get a DLL finally, but it works too. Of course, it won't work for more or less complicated code, because C Gen API has a limited set of functions and many LabVIEW instruments aren't supported. It also relies on outdated version of GNU make utility (3.81 was fine for me) and modern versions (including 64-bit one) don't work properly.
05-28-2020 07:22 AM
That was some kind of super-sleuthing! I'm a little unsure if you solved you original problem, though. It was difficult for me to follow along.
05-28-2020 07:42 AM
I was asking, why LabVIEW 2020 is unable to open VIs with Inline C Node. This is still unanswered. So I wait until someone of NI devs replies about this and optionally assigns CAR # or states that it is a normal situation for now.
05-29-2020 06:36 AM
Today I found that exe of LabVIEW 2020 no longer exposes several internal functions, which C Gen and its API relies on. These are on the list:
AddCGenSyntaxChkSubSys
DelCGenSyntaxSyntaxChkSubSys
GetCGenSyntaxChkErrors
InitFunclistVIs
IsFunclistVI
UninitFunclistVIs
But there may be another ones. So it's most likely now, that NI started to remove C Gen support from LabVIEW and that is the reason, why its components fail to work. I still don't mark any post in this thread as the solution, because that info is not confirmed by the developers.
As a little off-topic, I have succeeded in building 64-bit Windows DLL from the sources, made by C Generator. Here is 64-bit build of GNU Make 3.82.90, which was used. Also I altered LINKFLAGS in my Makefile to have /machine:X64 option instead of /machine:I386. Besides of that I recompiled lv_analysis.lib from the sources in [LabVIEW]\CCodeGen\analysis and activated 64-bit toolchain in MSVS. I met no errors during the compilation and the final library runs okay too.