crash with nested cluster strict type def

[Freeky Frank]

Hello

I am having some tricky problems with nested clusters and strict type defs on MS Vista and LabView 8.6.
I have a large data structure, strict type def – cluster, which is built from smaller clusters also defined in strict type defs. This structure can be up to three layers deep containing say around sixty smaller clusters all with between 3 and 150 individual pieces of data. Each type def is generally used only once but a few are repeated. The structure is generally passed through my program which is also quite big and is static in value.

I have a number of problems with this structure:

1    If I update one of the type defs it will generally update all the instances of the structure. However, not always...

How do I force the new strict def to be propagated throughout my program?

2    To minimise the space taken up by the top level cluster I tend to collapse the lower level structures. This works reasonably apart from making the data impossible to check directly. However, occasionally the change propagates through but the size of the collapsed window is not propagated and my clusters completely destroy the panel layouts. Simply opening the type def resizing the window and then making it small again and saving can cause this to happen.

Is there anything else I can try to stop this happening?

3    I use a reference to iterate over parts of the structure loading the data fields with data that is dependent upon the clusters structure. If I simply allow LabView to decide the order with 16 such sub-structures it crashes!
I have debugged the code by single stepped through the code and it clearly works perfectly. I can run it on one or two structures perfectly well but not large numbers.

If I force the order by the use of error messages it works perfectly but simply takes takes longer. So I have a workaround!

This must be a LabView bug?  (I would not like to guess how!!!!  🙂

4    A little more development and the crash is back. This time if I stop a particular part of the structure (sub-cluster) being traversed the problem does not happen. But I can traverse that part independently without problem even by simply running the vi is situ. Further, if I single step through the code it works and lo and behold it sometimes works anyway. The sub-cluster is unique and not repeated elsewhere in the structure.

So to recount the same code and structure works in isolation, in situ in single step mode and sometimes at full speed with no changes of any type. Just restart LabView and it will work or not at will!

What do I do now?

I am trying to isolate a small piece of the code that exhibits the problem but so far to no avail.

HELP!

~~~~~

PS: Visa and LabView in combination hang for anything for up to 60 seconds on large programs before continuing without any other sign of problem.  This seems to happen when exiting from a VI tree that has been edited.

~~~~

Suggestions for LabView Development that might help this sort of work:

1    Provide the option to display an Icon instead of cluster. This would work very well for those with strict type defs as they cannot be changed and would become more like a c *.h file which can be inspected by opening the def. Yes! I know live data could not be inspected unless the Icon was made to open a sub-panel or a probe was used to display all the data but the Icon style could be optional.

2    Provide a way to make such a structure static/constant and therefore it could be precompiled into the VIs speeding up execution.

3    Fix the known bug that means that clusters and type defs in combination do not obey the default data rules that all other LabView variables observe.

[Ben]

I wrote a Nugget on Type def that can be found here. Near the end I suggest using a VI to hold the constant.

I have not heard of crashes with type defs so could you please porvide an example (with step-by-step instructions to reproduce) and we will se what else we can do to help.

Ben

[Freeky Frank]

Ben

I am sorry I am trying to distil this down to a manageable size but it seems that something I touch causes LabView to fix the problem. The simple act of adding a Case Statement around one of the VIs caused the problem to be fixed and removing it left it fixed. A very strange problem indeed!

Frank

[Freeky Frank]

Ben

I now have a smallish version that exhibits the problem; sorry about the delay but the problem occasionally fixes itself.

Unzip a copy of the files and run “_IDs.vi” if I have got it right and your machine is also running 8.6 LabView should crash.

A couple of alternative now:

1)    Restart LabView and go into “Set IDs.vi” and then “IDs MCS.vi” now set this VI to “Highlight Execution” and run “_IDs.vi” again. Everything should be OK.

2)    Restart LabView and go into “Set IDs.vi” and place a “Diagram Disable Structure” around the “IDs MCS.vi” and run “_IDs.vi” again. Everything should be OK.

Most anything else and LabView crashes.

I have not applied error reporting throughout because it does not stop the problem or add anything.

Thanks for the help

Frank

[Ben]

Thank you,

I submitted a request to have an NI App Engineer investigate your code. Let's see what they have to say.

Ben

[falkpl]

I had a similar issue ablut 2 years ago, I had changed a typdef cluster and one instance nested deep down in the structure was did not get updated for some wierd reason.  When the code got to the point of accessing the cluster, the code/labview immediatly crashed (quit out of labview).  I was able to use suspend when called and probes to chase down the offending cluster, relink it and this fixed the problem.  You might start by doing a find on the trpdef and see if there is a un-updated typedef.

Paul

[Freeky Frank]

Ben / Paul

Thank you both for your input I got it to update the sub-vi and eliminate the problem for the time being but I think “type defs” and “strict type defs” in association with “clusters” have some issues that make the code less stable then the rest of LabView. What I don’t understand is I am sure I had checked the type def from that particular VI at an earlier stage of my investigations and yet I did nothing specific to cause the update!!!!!!

I hope the notes at the bottom of my first post get read by someone in a position to do something about it!

Thanks

Frank

[Ben]

---

Freeky Frank wrote:
...

I hope the notes at the bottom of my first post get read by someone in a position to do something about it!

Thanks

Frank

---

My Nugget addressed part of those.

Ben

[James_McN]

Hi Frank,

I am an applications engineer at NIUK who has been asked to look at this issue for you.  I have been able to replicate the issue that you have seen but have seen more messages than you have mentioned so far.  I recieve a Windows No Disk error and also a LabVIEW internal error log.  These would suggest this is a memory issue, from what I can understand of it possibly to do with using references for the controls but LabVIEW has been unable to allocate memory for.

I shall pass your code and the error logs I have to the team in the States where they should be able to get in touch with someone who should be able to explain them further and will let you know when I hear anything back from them on that.

Regards,

[Freeky Frank]

James

I have today for the first time seen an out of memory message from Vista.

The relationship between processes performed with references and conventional data driven flows is not transparent. If it was I might be able to find a different way to fulfil the requirement.

LabView is traditionally flow driven and the reference breaks that, I wonder if the problems I had as described in item 3 of my original posting point to a weakness in the controlling algorithms which were resolved by adding the error cluster chain thus deferring the problem.

Thanks for the help

Frank