How can i get rid of the zeroes after sub-division of arrays?

[madgreek]

Hi

i have sub-divided a long 1-D array (50000 samples) into a number of smaller sub-arrays with different lengths build in a 2-D array. What happened is, where the sub-arrays end, Labview adds zeroes to them to match the length of the biggest array (558 length). How do i get rid of the zeroes?I just need to have the actual length of each sub-array with now zeroes to it. I have attached my vi

Thank you

[James_R]

try to using queues they will not add the extra 0's

after subdividing the array pass the result into a queue

you could also try using clusters

Message Edited by James R on 04-11-2007 02:27 PM

[Ben]

A 2-d array must be rectangular.

Bundle the sub-array into a cluster and build a 1-d array of these cluster on the edge of the loop.

Ben

Message Edited by Ben on 04-11-2007 02:35 PM

[madgreek]

Thank you guys

James, what do you mean by queue?

[James_R]

the queue is good if you want to process the data in a parallel loop but attached is an example of just putting the data into a queue and flushing it at the end.  same result as Ben's this way

[madgreek]

Can you post a pic of the vi you built. I only have labview 7 and i cant access it

[James_R]

here is pic and vi backsaved to 7.1

For whatever reason when i saved this vi for 7.1 i left the scroll bars in and since 7.1 doesn't have scroll bars on the indicators it messed up the remaining elements indicator so just delete it and then add another indicator.

Message Edited by James R on 04-11-2007 03:37 PM

[altenbach]

Hey guys,

when posting examples, don't retain bad programming, even if it only occurs as a side issue. New LabVIEW users will copy everything posted here as gospel!

Ben's workaround is sound, but please refrain form keeping a "cruncher loop". An empty loop without wait will consume all CPU and possible starve all other running processes for no good reason. That polling loop needs a small wait statement!

An empty loop without any wait statement will:

• Will spin millions of times per second using 100% of the CPU.
• run many iterations before allowing a thread switch.
• Add 10 such loops in any program and the program will be unusable (thread gobbling!).
• Even a 1ms wait will reduce the CPU consumptions by many orders of magnitude.
• Even a 100ms delay will not noticeably delay any user actions.
• Waiting for a button press is not something that needs to be handled within nanoseconds.

Cruncher loop!

Easy correction: place a smal wait inside that loop!

Message Edited by altenbach on 04-11-2007 05:12 PM

[madgreek]

By putting the wait inside the while loop, will that introduce any delay to the rest of the vi?i have two parallel vis that work together.

will i have to put the wait in every while loop?Shall i do this in the future for better performance or is it just for this case?

[altenbach]

Any loop that polls for user input needs a wait statement. Period!

---

@madgreek wrote:

By putting the wait inside the while loop, will that introduce any delay to the rest of the vi?

---

On the contrary, it will free up more CPU for all other parallel tasks and will give them a chance to run after each iteration of the small loop. Without a wait, the loops will spin successively at a very fast rate for many milliseconds, during which time nothing else can run. You are actually causing delays in the rest of the code because you don't have wait statements.

RULES:

Any loop that depends on user input needs a wait statement. Else it would just recalculate the same old calculations over and over again without producing anything new. Often, an event structure is a better choice. Why repeat a calculation with the same input values if we already calculated it before?

The only loops that should not have a wait are loops that do pure finite computations, e.g. an iterative calculation, indexed operations on arrays, etc.