case structure with more than 200 cases, slower lab view app

[altenbach]

As Norbert already hinted with the "size" question, one thing sticks out:

The BD objects are ~1.5MB, which looks way too big for the VI.

Message Edited by altenbach on 10-15-2008 09:28 AM

[cmdrb]

yes, its quite big...

is there a way i can increase some buffer size for LV to handle big block diagram.

i need those objects in the cluster..i dont have any option in mind.

[RavensFan]

Quick comment on the code.  For your PSMI specs and readout clusters, do you want to have a shift register on the boundary of the inner for loop as well?  Right now you only have shift registers on the outer for loop, so changes will take affect between iterations of the outer for loop.  But for the inner for loop, the changes you are making in the cluster will be lost as you go back to the same data on the tunnel in the next iteration of the for loop.

Message Edited by Ravens Fan on 10-15-2008 03:09 PM

[cmdrb]

loop iteration 5 is the last iteration for the for loop, it will get the data on iteration 5 then transfer it to the cluster. no more data will be pass after this iteration for the inner loop

but to be safe, i will add a shift register in the inner loop...thanks...

[F._Schubert]

You can much simplify the code by working with references. As far as I see, every case is doing the same (comparison, setting to default, creating a warning) with each element of the cluster. You can use the property Elements[] as input of the for loop, use a type cast (try the next type if an error occures) for all used types and use the lable.text property to match between PMSI item and Input data. You will need about 5 cases that way (one for each data type).

Felix

[cmdrb]

it sounds good, but i dont know how to do it...

can you give me a simple vi with property elements[] as input for the loop as you have stated.

[F._Schubert]

Ok,

here is a really quick draft. Hope it's clear enough

Felix

[Adam_H]

Hi All,

So I have taken a look at the VI and have done a little digging to why it is doing this.  It is not an issue with LabVIEW.  Every time you change something on the block diagram LabVIEW is changing the information used to run the program.  So when you delete a wire on the block diagram it is having to completely rework what is going on in the background.  It has to do this every time so that it is always ready to go when the run arrow is selected.   In this case it has to redo the entire case structure every time something is changed.  This is what is causing the slow down.    As far as how to fix the problem.  In addition to the suggestions already talked about use smaller clusters.  So use a handful of clusters instead of one large one.  Where possible break the code up with sub-VI’s.  In your sub-VI run many smaller case structures instead of the one huge one.   This should help to reduce the problem.

[cmdrb]

I am done in generating the vi, i tried it and it works based on what i expected.

the problem on generating the vi on large cases didnt affect the run time of the vi, meaning when i run the vi it runs normal (no sluggish)

i know theres a lot of ways to improve the vi by using element property, or by rearranging the cluster to eliminate the huge case structure.

thanks a lot for all the guys who have shared their wisdom.. i really appreciate it.

the bottom line, based on my understanding, is that the labview case structure have some limitation in handling enurmous cases.

[Jimmbo]

I would not say it as a limitation of large cases...as the Applications Engineer mentioned, the LabVIEW environment has background processing to determine when a programming change will create an error or be accepted by the compiler and when processing very large sets of data (large clusters) the PC is bogged down for processing power.  Therefore, I see this as a limitation of using large clusters of data rather than case structures with a large number of cases.