insane object with a symptom

[RudyRed]

I looked at the messages regarding insane objects and didn't see anything quite like my situation:

I have a cluster of controls (bool, num, and string--but no waveform chart --see below error) that is wired (I've deleted and reconnected this wire numerous times) to a subVI.  Using breakpoints and probes, I've determined definitely that my runtime operation of these controls does NOT make it onto the wire between the cluster control and the subVI!!!  I gotta laugh to keep from crying, it's so ridiculous.  This is the perpetually reproducible symptom to which I refer in the subject line of this message.

Now, if I try to edit (I thought my attribute nodes that were converted to non-strict property nodes when the code went from v5 to v6.0.2 might be a problem, since the error outs are red--and newly-created property nodes have black error outs) I get the following three error boxes:

Insane object at FPHP + 10200 in "<my VI name>": {sub} (0x10): Scale (DDO)

Insane object at FPHP + FFC0 in "<my VI name>": {sub} (0x10): Waveform Chart (DDO)

Failure: "fpsane.cpp", line 269....etc

Looking through the LabVIEW_Failure_Log.txt, I see a number of citations of the same file AND line number, dating back 18 months, making me wonder if it might indicate a problem with my computer, especially since the previous version of my VI works fine.  I have made some changes, but they were unrelated to this control and its routing.  My VI is over 2 MB (you know that if I had it to do over again it wouldn't be that big) so localizing the issue to a small bit of code seems impossible.  I did copy the control to a new VI and it performed as expected.  I guess I'll try some more of that, and copying and pasting to a fresh VI, and maybe starting over again with the previous iteration of the VI/application.

I just wanted to get this on the record so that if someone else comes searching for this kind of info he doesn't get the same blank search results that I got at the NI website.  And if you are such a someone...well, you have my sympathy.

[RudyRed]

Update:  now I only have the symptom.  I took a cue from the insane object messages and deleted my only waveform chart--which had been in the code, unchanged, for years!  Now I can edit and save without error.  However, the control cluster still does not carry the cluster changes when connected to the subVI--but it DOES when connected to only the loop border!!!  So there's nothing wrong with the cluster itself.  The only thing I can think of to do is recreate the subVI the cluster connects to.

Does anyone have any other ideas or experience.  I've been programming in LabVIEW for over 15 years and I have never seen anything like this before!

[tst]

Can you post at least the subVI?

Other alternatives would be to disconnect the control from the connector pane and reconnect it or copy the entire code to a new subVI and so on.

BTW, red error terminals on property nodes normally indicate that the node has been set to ignore errors.

[RudyRed]

Thanks for the response, tst.  The subVI in question is about 290k, but I want to try copying the block diagram to a fresh VI before posting it.  However, I did recreate the cluster control in a fresh VI, and copied it to the VI and the subVI--in that process I did disconnect and reconnect to connector pane.

Yes, you are right about the red error terminals.  But, in my case, this happened as a result of automatic code conversion from an earlier LabVIEW version (by default, such conversion sets the node to ignore errors within the node).

I'll update this thread with the results of my attempted recreation of the subVI.  Thanks, again, tst.

[Ben]

Yes please post an example or summarize your solution.

I have seen issues with "circular references" like Property node >>> Value wired to bundle by name, wired to indicator getting confused.

That is the only thing that comes to mind.

Ben

[RudyRed]

Thanks for the response, Ben.  Your "circular references" comment is interesting...not sure why you say "circular", but at one time I did have a different input of the subVI wired to a bundle (not by name) of arrays read from property nodes associated with 4 of the boolean controls in the control cluster.  I was having trouble before I removed this input--but I may not have removed the terminal's control within the subVI.  Still, though, the corresponding indicator is being unbundled (not by name) outside the subVI, and the unbundled arrays being written to string[4] property nodes associated with the same 4 boolean controls within the control cluster.  So, what was the "confusion" you mentioned?

[Ben]

When I first heard an explanation of what an "Insane Object" error was, I understood it as an indication that LV was not able to propely account for something in the code. When I said "confused" I was thinkning of how I understand the "Insane Object" error.

Ben

[IEC]

I just had an insane object problem with LV for the first time ever yesterday.... so it's funny that this post is up now. 

I found that my specific 'Insane object' was some VI server stuff that wasn't properly linked.  That being, I had a couple instances where I had copied and pasted the invoke node and property node VI server objects from one location to another.  However, I found out that when I copied these, the links defaulted to no-link.  A simple fix, I just clicked on the nodes and re-linked them to the proper object and all insanity was averted.

So yeah, try checking to make sure all of your nodes are properly linked!

Though, it's probably not that simple... nothing ever is.

Jonathan

[RudyRed]

Ben, I did manage to get rid of the insane object errors, as near as I can figure, by deleting the waveform chart cited in the insane object error messages.  That chart has been in the code for years, and during that time the chart, which charts a scaler integer representing the number of milliseconds it takes for the main loop to iterate, would show a gradually increasing value.  When first started, it would show a flat line at about 50 ms (not bad, given a 25 ms wait in the main loop).  After a week of running I'd see spikes on the chart up to 200 ms; another week and we're up to 500 ms.  This level of delay begins to create problems.  I found that exiting and reentering this VI (this VI is itself a subVI of the larger app--about 420 VIs) would "reset" the chart!  Then I found that if I just skipped one "conversation" with the chamber controller (GPIB, at 3-sec intervals) the chart would reset, without my having to exit and reenter.  I still don't know what the problem was, but my "remedy" was to programmatically skip one conversation every 20 hrs.  I also revamped the chamber communication VI for efficiency sake and to eliminate the 488.2 GPIB functions (there are a number of reasons why we must decline to use VISA), which the chamber controller was too old for (somebody else had written the chamber comm VI).  The changes worked great--I thought I was golden.  Then this apparently unrelated (I'm not so sure that anything in LabVIEW is UNrelated to everything else) issue cropped up.

If there's anything in the above that jumps out at you as a possible problem, please let me know.  Thanks again, Ben.

[RudyRed]

Thanks for the response, Jonathan.  It's interesting that you mention VI server.  One of the latest additions that I made to this code was a little plug-in architecture thing, but I never copied and pasted any of that, and it all worked as expected and hasn't been touched since.

I haven't tried yet to reintroduce the offending waveform chart, the deletion of which seemed to restore sanity to my code.  When everything else is working, I will do that .  I just don't see how this chart could have become a problem...