11-18-2005 04:48 PM - edited 11-18-2005 04:48 PM
Message Edité par Jean-Pierre Drolet le 11-18-2005 05:53 PM
LabVIEW, C'est LabVIEW
11-18-2005 04:51 PM
Thanks JPD!
The world again makes sense.
Ben
11-18-2005 07:36 PM
You are correct, that is a known issue with LabVIEW 7.0 and 7.1. As you pointed out this problem was corrected for LabVIEW 8.0.
They didn't exactly confirm the 32768 number (I've asked for clarification, but heard nothing back yet), but basically said I was out of luck. So I have sidestepped the problem by replacing the ENUM with a string indicator. For display purposes, it's a bit slower, but it avoids all this. I tested adding some more stuff to the ENUM and there is no problem. Which confirms the idea that it's not a problem with the ENUM itself but the things that use it (and contain 60 copies of it). Anyway thanks for your idea.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
11-18-2005 07:46 PM
Well, I know that my byte length was 30500+ (having flattened the TD to string and counted string length). So what you're saying means I was barking up the wrong tree again. Nevertheless, the fix I applied (see above) removes the problem.
do not forget that the Front Panel itself is kind of a cluster and have its type descriptor including all the controls of the panel.
Well, I have a front panel which had a tab control with ten (10) pages of this cluster, one in each page. That's 1800 controls on one panel, and 600 of those were of this enum, having ~500 bytes each. 600 * 500 = 300000 bytes just for the TDs, assuming no compression, or duplicate removal. Of course if there was duplicate removal, the single cluster wouldn't have a problem. So I don't see how I got away with that, if what you say is true.
Blog for (mostly LabVIEW) programmers: Tips And Tricks