LabVIEW
[Mass Compile] What is an Insane Object?
I just ran a mass-compile on my project which involves a number of CompactRIO targets. Using LabVIEW 2013 SP1.
The mass compile log contained the following messages:
Insane object at FPHP+31B0421C, UID 129, in "nirvimemoryEmulationManagerCache_Clear.vi": {tdname } (0x4000): Cluster (DDO )
Insane object at FPHP+31B01BEC, UID 129, in "nirvimemoryEmulationManagerCache_SetValue.vi": {tdname } (0x4000): Cluster (DDO )
Insane object at FPHP+31B0636C, UID 59, in "nirvimemoryEmulation.vi": {tdname } (0x4000): Cluster (DDO )
Insane object at FPHP+31B06A54, UID 59, in "nirvimemoryFastEmulation.vi": {tdname } (0x4000): Cluster (DDO )
Insane object at FPHP+31B0C9CC, UID 59, in "nirvimemoryEmulation_8684067B12CA43EB8922676B06954D59_000.vi": {tdname } (0x4000): Cluster (DDO )
Insane object at FPHP+31B09494, UID 59, in "nirvimemoryFastEmulation_84A92DAB8EB749BFB5C327E89D6ED6B1_000.vi": {tdname } (0x4000): Cluster (DDO )
Insane object at BDHP+1F011F80, UID 1635, in "FPGA-Pod_Main.vi:Instance:3": {tdname } (0x4000): Numeric Constant (DDO )
insanities in BDHP of C:\Jobs\ProjectX\src\RT-Pod\Source\FPGA-Pod_Main.vi\3
Insane object at FPHP+31B01BEC, UID 129, in "nirvimemoryEmulationManagerCache_SetValue.vi": {tdname } (0x4000): Cluster (DDO )
Insane object at FPHP+31B06A54, UID 59, in "nirvimemoryFastEmulation.vi": {tdname } (0x4000): Cluster (DDO )
Insane object at FPHP+31B0421C, UID 129, in "nirvimemoryEmulationManagerCache_Clear.vi": {tdname } (0x4000): Cluster (DDO )
Insane object at FPHP+31B0636C, UID 59, in "nirvimemoryEmulation.vi": {tdname } (0x4000): Cluster (DDO )
I found piece of NI documentation (http://digital.ni.com/public.nsf/allkb/654877E62A97B72986256C95006F9B24 ) which simply says, in a nondescript fashion:
-
You should look for the following string in the mass compile reports to identify insane objects that exist in your application. “Insane Object”, and
- The log also indicates if these insane objects were fixed by the mass-compile routine.
Questions:
- Could someone please explain what "insane" means, and why it needs to be fixed? (Note that my VIs that are flagged as "insane" seem to work fine when built and deployed)
- It looks like most of the items marked "insane" are VIs from LabVIEW itself, not my project (e.g. nivimemoryEmulation.vi). Should I be worried?
Thanks for the link, Derick.
In my post above, most of the insane objects are found in NI VIs (e.g. nirvimemoryEmulation.vi) that I have no control over.
How do I fix those?
Intaris wrote:
I really wish we could do something similar to a mass compile from WITHIN the project so that the context of the VI is maintained.
The closest I can think of at the top of my head is open the top level VI for each target and save. That should also update the VIs that are directly called. Doesn't work so well for the dynamically called VIs though.
@DerickMathew wrote:
When did you encounter this issue ?
How do i reproduce your find. Which VI caused this ?
Like I said before, I encountered this when mass compiling my project, and the VIs that caused this are listed in my original post.
The nirvi*.vi errors seem to have disappeared by themselves, but I still get an Insane Object message with FPGA-Pod_Main.vi (see attachment -- pardon the messy front panel). I copied its block diagram and pasted the contents into a fresh new VI, but I still get the same message from the new VI.
@Norbert_B wrote:
It seems to me, that those VIs refer to the simulated mode of FPGA. Is that impression correct?
I'm not sure -- I've never used the simulated mode of FPGA before. I've never seen those nirvimemory* VIs before, and Googling "nirvimemoryEmulation.vi" returned nothing except this post.
So they're simulation VIs? What could cause them to become insane?
@Norbert_B wrote:
If so, why do you mass compile that components from the FPGA module?
I simply wanted to mass compile my project, which contains 2 FPGA VIs.
Should I remove FPGA VIs from folders prior to mass compiling? The compiler doesn't seem to mind. From what I understand, mass compiling is used to refrresh the VIs in a folder, possibly updating stale code if the VI hasn't been touched for a while when the rest of the project has morphed. Am I mistaken? Does this not apply to FPGA VIs?
Norbert_B wrote:I hope you didn't just copy the FPGA components from an older LV installation to a new one....
All my development on this machine has been done in LabVIEW 2013 SP1. No copying across versions. 🙂
@Intaris wrote:
This is a regular occurrence with my code also.
Mass compiling doesn't link any given VI with a specific context (FPGA card, RT system) so a lot of the time the information saved within the VI when checked int he "normal" context returns insane objects because the context has not been applied.
I also see the same insane errors in nearly all of my FPGA vis which involve FIFOs and such.
Thanks, I didn't know that the mass compiler ignores context.
This FPGA VI of mine does have a FIFO. Maybe that's why. The follow-up question then, is: Why is this considered "insane"? AQ's comment in http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Help-dealing-with-insane-objects/idi-p/1140158 suggests to me that insanities are related to invalid pointers in the LabVIEW kernel, which are related to memory management. Yet, having something like an FPGA FIFO in a non-FPGA context seems to me like a code-correctness issue, not a memory management issue.
@Norbert_B wrote:
If you are up to implementing a small tool, you can automatize this approach. The LV Project API provides functionality to differ between targets, so the main issue might be in identifying the top-level VI.
For this, i recommend a strict rule for naming conventions. If done properly, the tool could search for VI names on targets (e.g. WinMAIN.vi, RTMAIN.vi, ..., the common ground would be the component MAIN in each vi name), open it and save it.
Identifying the top-level is imho the reason why there is not tool like this already available.....
Norbert
An alternative is to extract the top-level VIs from the Build Specifications.
