Speed issue/ messy code

[tonh]

Good day everyone,
I have troubles with one Vi i'm designing. (In fact, I'm pretty new at LV and I had to learn it by myself for my job at school...anyway ) The problem is simply the speed of my VI. I dont know why it's slow and I'm trying to figure it out but I just cant. I know some parts of my code are pretty heavy stuff for LV (especially the sub-vis) but I'm sure there is something that could be optimized to improve the speed of my Vi. Could it be because I use a lot of local variables? Or is it only my huge mathscripts in the sub-vis?
If anyone could help me figure this thing out that would be very kind.
Thanks
tonh
I just realised that the files I was about to attached to this post were 13MB... any idea how to attached them?

[mishklyar]

--To attach the files, set the arrays you use to minimum possible size and make these

values as default,it would help

Regards,

Michael.

[smercurio_fc]

Well, you need to better isolate the problem. Is there a specific set of VIs that seem to be slow? Are you dealing with a lot of data? Are you dealing with a lot of file I/O? Certainly a lot of local variables indicate poor program architecture. Rather than trying to upload the whole 13 MB of code (which I won't download), you should try to narrow down the "slowness" and upload that code.

[tonh]

"Poor program architecture" is my middle name in fact AHAH! The point is I would gladly try to figure out where is the problem, but as I said, I'm new at labview and I designed the program as a "as long as it works" thing. I cut out a few of the subvis to download (which are 2.5MB each) as they are pretty much all the same with slightly different mathscript node in and put the main Vi in a seperate zip file...

thank you guys
tonh

[johnsold]

tonh,

Start by eliminating the use of stacked sequence structures. They make the code hard to read and hard to modify. A state machine architecture is probably a good candidate to replace them. See the examples that come with LV.

Next eliminate the local variables. Use shift registers on the state machine while loop.

The mathscript node is not supported on my platform so I cannot see all the code in it. What I can see through line 46 looks like it could easily be coded with LV primitives and functions, probably encapsulated in one or more subVIs. From the help file it is likely that the subVI approach would be considerably faster.

Lynn

[tonh]

Thank you Lynn
I'm starting right away to modify my vis considering your advices.
The sub-vis have a lot of input. Is that an issue?

tonh

[smercurio_fc]

I would agree with the given comments. It seems you come from a text-based programming background. I really couldn't find a good reason for having the Mathscript nodes. I did not look at every single line, but I couldn find anything that was using a Mathscript-specific function.

There's something quite peculiar about the "aZone" VI that you posted. Loading it in 8.2 took forever. It seemed to keep loading the same subVI in the Mathscript library over and over again. The subVI count got up to over 1700!. I suspect it's because of the long Mathscript node, and may be a bug? I don't really know.

In terms of the number of inputs to a VI, usually when you have a lot of inputs it's better to "clusterize" them rather than trying to use a huge connector pane.

[johnsold]

tonh,

Yes. There is a limit to the number of connector pane terminals you can use. The recommended pattern is 4-2-2-4 with inputs on the left and outputs on the right. You can either use several subVIs with fewer connectors or create a cluster of elements.

For your Zone VIs I would probably create one or two typedefed clusters of the data and pass the cluster to the subVI. Use Bundle by Name and Unbundle by Name to access the individual elements within the subVIs.

Lynn

[mishklyar]

Just interesting observation - while loading Zone1.vi  , Labview shows that it loads above 350 ! vi's.However this VI contains

almost nothing but MathScript.It looks like LV interpretes the MathScript code to VI's.

 So may be here is the reason for the big size and slow speed.

P.S

 Sorry for double answering, it was updated while I was typing..

Message Edited by mishklyar on 07-15-2008 10:55 AM

[tonh]

Thank you everyone!!
What I'm going to try is to do the zones vis without the mathscript.
I never thought about this cluster idea for all my variables, this is a great idea too.
Once again thank you.
tonh