LabVIEW
Pt By Pt VI's memory
Hi Alain,
as you (correctly) noticed those PtByPt-VIs use their internal memory (usually a shift register) to hold previous values. When calling such a VI in a (FOR) loop with data of several sensors your results get messed up...
To avoid this:
- Separate the signals as you did in the upper part of your VI block diagram. This is not the best way when it comes to scalability and flexibility (as you already noted)...
- Make your own version of that function to handle "vectors" (aka 1D arrays) of data correctly. That way you have the same functionality as the PtByPt-VI and still the flexibility of using an array of sensors!
Most of your memory problems are not due to the ptbypt VIs, but your use of shift registers. Since they are uninitialized, they retain all old data between runs, and they will grow without any upper limit until you run out of memory. You can remove all these shift registers and simply use a chart for display. Set the history lenght to a useful size.
As for the ptbypt VIs, I agree with Gerd to write a version that handles 2D data directly (The code of the ptbypt VIs is visible, so it is easy to make your own sratting with the existing code). Alternatively, you could use a parallel FOR loop with N instances.
Hi Alain,
using a reentrant VI in a loop doesn't create a new memory space for each call of that VI per iteration! It's still the very same instance of that VI!
Hi Alain,
while NI is the LV expert they still can't provide each and every function for any task someone might ask for...
They already have introduced PtByPt functions, where you can look at the BD to examine their programming schemes.
When you need the same function for a 1D array of values instead of a scalar value you can copy their BD and adapt it in any way you need.
That task is called "programming"! 🙂
Alain,
Recently I found a niffty way of making these things more scalable that I think will work for you.
In LabVIEW 2009, NI introduced the ability to parallelize For Loops. This was intended to be a performance boost, but it also allows us to scale parallel operations easily. For example, I was recently testing this feature out and using it to open 20 dialog boxes (or however many I chose) at the same time with just one subVI and a parallelized For Loop. Because all of the loop iterations ran in parallel, all 20 were opened at the same time and the loop did not exit until all 20 were closed.
For your code, I believe this behavior will cause different instances to be created in memory, just as if you'd laid out multiple subVIs on the BD.
To use this feature you need to do 2 things. 1) right-click on the For Loop and select Configure Iteration Parallelism... In that window, make sure to enable up to 64 (the max) parallel iterations to give you the maximum scalability.
The get the size of your waveform array and wire the output to the P terminal of your for loop.
LabVIEW will use the minimum of the number in the configuration window and the number wired to the P terminal.
I'm not certain this will work for you, but it should be easy to try!
@PackersFan wrote:
Recently I found a niffty way of making these things more scalable that I think will work for you.
That's why I wrote "Alternatively, you could use a parallel FOR loop with N instances" above. 🙂
@PackersFan wrote:
... In that window, make sure to enable up to 64 (the max) parallel iterations to give you the maximum scalability.
The max can actually be raised with an INI enty if needed.
That's what I get for skimming posts! 
Nice tidbit about the INI token. That was the one limitation of this technique that worried me. Whoo! 
