LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

how to "mix" arrays?

Ben,

What you propose to do sound extremely promising, however i do not see how to attack the task. please guide me trough this Smiley Happy.

the thing is that its what i was trying to do before getting into this mess. i will give you an idea of the process:

i have several timed waveforms, from which i create a data point using an action engine (thanks to you). the waveform is stored in the AE, while i get a new point every time i ask it, if the step size of the waveform is adequate.

meanwhile, some other AE creates other data points at specific request times.

if at time t no waveform is supposed to release info, then i create a 'wait' array, where every point represent a time step.

all those  datasets are then picked up together to be sent elswhere. BUT, every one of the AEs are sending out actually not only 1 element, but sometimes up to several hundreds (for example the waveform AE can send info related to several waveforms that give a certain data point out, or some other AE sends up a lot of data for the specific time t).

It would not be too bad just to add the arrays one after the other, as long as they all are very short. but as they get lengthy, some elements that should occur at time t, are actually accessed for at time t+delta t, which becomes non- negligible.

a very simple solution would have be "interleave", to allow same priority for all datapoints of a specific time t.

A related problem is of course memory management: since all the arrays created in the AE are variable in size, and change every time i call them, i get 2 problems:

1) - assembling all the arrays together i need to allocate in advance an array size, that i resize once i know the output array length

2) same inside of the AE, where i create on the fly my data arrays. i need to initialize an array size, and to resize it outside.

the whole thing takes almost as much computation time as not allocating any memory for the arrays, and let LV take care of that. not to say, it is still about 20 times too slow...

on a side note however: the AE solution is one of the greatest i ever had in labview. you reinvented my way of thinking. i am now using it to the limit, with AE inside AE inside AE...Smiley Very Happy

-----------------------------------------------------------------------------------------------------
... And here's where I keep assorted lengths of wires...
0 Kudos
Message 11 of 15
(1,016 Views)
Interleaving your data doesn't seem to ensure that all your data has the same priority. If you process your array for time t in order, then the last element will always have the lowest priority in your scheme. I'm guessing you just don't want one module to always have its data at the end.

I would encourage you to use one of the following approaches and stick with fixed-size arrays:

  • Have one array that's large enough to store all possible AE data for one time step t. Keep track of the number of elements actually in this array and ignore everything past that point in the array. One solution I've done for this is to have the first element in the array be the relevant array size. So your array might look like [4 1 4 2 5 7 23 5 ... 5]. Here the 4 indicates that only the first 4 elements are valid, and everything from 7 on is garbage and should be ignored. The downside here is that this one array might be very large, since it needs to be able to handle the worst possible situation. The good thing is that you it's a very consistent approach.
  • Instead of having one really big fixed-size array, use a number of smaller fixed-size arrays as packets. The AE would fill up each packet until it was full, then move onto the next packet. It's easier for LV to allocate multiple smaller arrays, than one big array, so there's some advantage here. This also allows you to use your packets as a buffer. For instance, if you have 100 total packets, then the first 12 might correspond to time 0.1, the next 23 packets might correspond to the time, 0.2, etc. With the fixed size array, you're stuck with one time step at a time unless you want to keep track of where in the array one timestep ends and the next begins. If you decide to use packets, then it might be helpful to have two pieces of information in them: the number of relevant elements in the packet, and the timestep it corresponds to. The receiver end will then know exactly how to use them.
Jarrod S.
National Instruments
Message 12 of 15
(1,011 Views)
I'm not sure if it's going to be helpful now, but I wrote an interleave function a while ago (it was a little fancier). So here's a cut down version that should work (I may have introduced a bug when I cut it down, and I haven't tested it too thoroughly).

Matt

Message Edited by Matt W on 05-24-2007 03:42 PM

Download All
Message 13 of 15
(1,002 Views)

Sorry for not having reponded before, i was totally ill.

thanks Matt for the interleave. however i have decided not to use it, as it takes too much computation.

i am trying now to pick up the data "on the fly", without creating any array in advance. will see where it goes.

-----------------------------------------------------------------------------------------------------
... And here's where I keep assorted lengths of wires...
0 Kudos
Message 14 of 15
(965 Views)

Jarrod,

thanks for your advices. i am not yet sure it will work for me, as the result of my operations actually lead to tranfering all the time data between different arrays, and i fear that it actually induce enormous computation.

if i would just have pointers...

-----------------------------------------------------------------------------------------------------
... And here's where I keep assorted lengths of wires...
0 Kudos
Message 15 of 15
(962 Views)