replacing shift registers with queues or notifiers?

[Fat Controller]

Hello World,

I'm using labView 7.1 with my first application, which is essentially a spectrum analyser and comparison to limits. now due to the parameters of the sampling 12000 samples/sec with 4096 point I have quite large chunks of data involved in rolling averages of 1 minute and rolling buffers that are an hour long. I'm pretty new to labview but I'm finding pretty easy to pick up except when it comes to optimisation and performance (I've been used to the microsoft approach until now) due to the fact that the instrument I'm building has to run in psuedo "real time".

I've been looking at replacing the shift registers with either queues or notifiers but I'm unsure if these techniques would result in improvements or not.

I'll attach a jpg of my main loop, I've only got the one but it is separated into three separate tasks but they are all governed by the data flow, DAQ then PROCESSING then REPORTING.

I've been told that by separating the loops and making them run in parallel LV will be able to compile it more efficeintly, but I'm unsure how to do that .

Cheers

Andrew

[rolfk]

---

@Fat Controller wrote:
Hello World,

I'm using labView 7.1 with my first application, which is essentially a spectrum analyser and comparison to limits. now due to the parameters of the sampling 12000 samples/sec with 4096 point I have quite large chunks of data involved in rolling averages of 1 minute and rolling buffers that are an hour long. I'm pretty new to labview but I'm finding pretty easy to pick up except when it comes to optimisation and performance (I've been used to the microsoft approach until now) due to the fact that the instrument I'm building has to run in psuedo "real time".

I've been looking at replacing the shift registers with either queues or notifiers but I'm unsure if these techniques would result in improvements or not.

I'll attach a jpg of my main loop, I've only got the one but it is separated into three separate tasks but they are all governed by the data flow, DAQ then PROCESSING then REPORTING.

I've been told that by separating the loops and making them run in parallel LV will be able to compile it more efficeintly, but I'm unsure how to do that .

Cheers

Andrew

---

Don't convert shift registers into queues or other things for performance reasons! LabVIEW has a lot of internal optimization logic when compiling your code which works best on shift registers. On a queue you will always copy the entire data of a message in or out even if you only need one byte of it.

Try to look at your architecture. You do want to do as much as possible in place. Try to completely avoid Append Array or Append String inside loops if possible. They are costly operations as they have to reallocate memory each time and often copy the entire data from the first array into the resized array. Better is to once preallocate an array of the necessary size, keep it in your shift register all the time and then use Replace Array Subset, Index Array and Array Subset nodes only on this. You will also have to maintian some index shich tells you up to where you have currently filled that array and that one is usualy best put into a shift register as well.

Rolf Kalbermatter

[Mark H]

Your use of shift registers looks absolutely fine - using exotic functions like queues or notifiers might be an unneccesary complication that could make you code less easy to read.

One thought though - depending on whether or not you need to access those shift registers' data within the loop, you could in some instances initialize and store some of the data structures entirely within the sub-VIs (in a sort of object oriented style).

Another observation - you have used large "build array" functions to create your "100% Fault Cluster" and "200% Fault Cluster" arrays. You don't have to do that, as the "Initialise Array" function will create arrays of clusters (regardless of complexity) just as happily as it does arrays of scalers.

Mark H.

[Fat Controller]

Thanks guys gor your respsonses

Rolf - Thanks for the tips on shift registers Vs Queues, as for the other note about dealing with arrays by not using append array I had recently found that and it did give a great increase in performance.

Mark - I didn't quite understand what you meant by initialising structures within the sub VI? as I have it at the moment I initialise large arrays outside the main while loop for use mainly in the individual subVIs, however I am dealing with rolling averages and require the data from the previous iteration of the subVI. Is it possible to internalise the feedback to within the subVIs.... If this is possible I beleive it would be a big advantage as I have found that just moving large arrays around consumes alot of time so to my thinking if I could internalise the feedback to the VI I could save alot.

What do you guys think?

And I'll change the build array as well...... I've got to appologise I didn't think that changing the build array to initialise would make mush difference other than to pretty it up. I thought that the problem with build array was when you put in it a loop so it basically creates a new array each time. so I didn't think it would make much difference as it was only run once. But hey I'm very happy to be wrong


Thanks again guys

[Waldemar]

Normally I create a library to include some strange functions into Labview and sometimes I use it even for counters. So whatever you think you can't do in Labview do it in your library. Slowly you'll find what can be done easier in C and what in LabView.

Peace
Waldemar

[Mark H]

Re initialising/storing data within sub VIs - I was thinking that sometimes, where data is not required to be passed back out of a sub VI (e.g. your report "...scribe.." VI) it is sometimes possible to have a single iteration while loop within the sub VI itself that has shift registers to store the data between sub VI calls. In order to initialise these shift registers though, you do need to have a call "method" case in the sub VI to initialse the shift registers. This level of complexity probably isn't really neccessary for your current relatively straightforward application though - it was just a thought.

Changing those "build arrays" to "initialize arrays" won't make any difference to performance, but there will be a lot less wiring required, the diagram will be more compact, more conventional and easier to read/interpret.

One more observation - I notice you used both "shift registers" and "feedback nodes" in your main loop. These features perform exactly the same function - my personal preference is not to use feedback nodes unless it is very difficult to wire shift registers across the loop (I sometimes find feedback nodes confusing to read - but maybe that's just because I'm a little "old-fashioned").

Mark.

[Fat Controller]

Hi again mark,

I didn't think that changing to initialise arrays would change anything either, I thought like you that it would only reduce the wiring but it does, essentially I've a got a possible 16 channels to be read and interpreted, with the system pervious to changing the function I could only get 13 channels without samples being missed now that number of channels has reached 16 with the same level of performance. I'm was surprised as you were, I just assumed that the two functions must reserve memory differently.

As with your comment on feedback loops and shift registers I realised that they were the same but I prefered the feedback nodes (must just be new-fashioned).

Lastly I am interested in your comments about internalising shift registers, I realise that my program is quite simple but I'm currently running pretty close to the limits of my system but still wish to get more information out of the signals that I'm processing and any performance increase would be very benificial.

Cheers

Andrew