PtByPt filter for multiple channels

[Shuggy1]

I am working on a project requiring point by point processing of a variable number of channels. The code is running in a timed loop on a RT PXI LV 2020SP1.

I require a inline filter and was planning on using a "Butterworth Filter PtBbyPt.vi" however cannot find a multi-channel version of it or polymorphic instance. I assume as a re-entrant VI i cannot put this in an indexed for loop as the filter history will be populated from the previous channels' samples. I can create multiple instances of the vi but this hardcodes the number of channels.

I am surprised i cant find any body else how has wanted to do this and assume i must be missing something, is there a simple way to do this i can write code to do this from scratch but assumed there may be something some one has used to do this that may be more efficient. (is it available in another tool kit?)

Any advice would be gratefully received.

[ZYOng]

There are a few old threads discussing this, all pointing to either Asynchronously Calling Multiple Instances of a VI for Parallel Execution or Configuring Parallel For Loop Iterations to Tweak Performance

Reference:

Programmatic way to parallel clone vi for large array?

Solved: Re: Preallocated Reentrant VI within Parallelized For Loop

[Shuggy1]

Thank you ZYOng really usefull links. and put me on the right track, i hadnt considered calling the vi that way. I had no need to asycronously call the vi as it is a very small process and believe that it would not add value so used the call by referene and embedded this in a FGV to handel the references.

I compaired this to running a number the Pt by pt Butterworth filter vi's in parrellel with one another and found that it was significanly slower at least 3 times and that excluded time to initialise. I have included shots of the code below. (apologies the ‘filter’ state got corrupted when transferring and required editing so is not a snippet any more.)

 

 

I am going to be running this in a timed loop dedicated and resurved on one core so do not think that i can parallel process the loop (please let me know if im wrong)(although i just thought that is not how i benchmarked it). And that is why i didn’t asynchronously call the vi is this a mistake? 

I subsequently looked into the NI PtbyPt filters and butchered them to take an additional array into the shift register for the previous state information for each channel this appears to run and approximately the same speed as utilising a number of filters in parallel but with the added convenience of being able to alter the channel count with out changing the code. I have include shots of this below the code is of the edited NI_IRR cascade filter  sub VI with in the PtByPt butterworth vi. 

Do you think that asynchronous calling would have any benefit timing within a timed loop with a reserved core? Although the above solution works for this case i have another function that i would like to scale with array size that is not as easy to manage its internal state information.

 

[ZYOng]

There are a few benchmarking examples in Asynchronously Calling Multiple Instances of a VI for Parallel Execution. Among them, \Benchmarking Asynchronous Calls.vi shows that you can pre-allocate multiple async pools using option 0x100 via only a single VI reference.

The execution time seems pretty good to me. Your snipper VI is broken so I can't compare it.

[Shuggy1]

Thanks for your reply im sorry for the delay.

That example is really useful and I have been investigating the options, I have not managed to get the Asynchronous calling working for my example and interestingly am also getting the same outcomes as the example with regards timings.

I appreciate your vi attached to replicate a Pt-By Pt processing I transposed the array so that the reentrant VI was processing a multiplexed signal rather than one channel then the next. This subsequently did not output the correct filtered data I believed this was due to the non-sequential completion of the called VI’s and added index labels to re order the data on receipt on my version. The Asynchronous calling still does not output the expected values and takes x5 longer than the other methods. If this is the case that is fine however I am not confident that I am doing it correctly.

I have included the project that I have been using to compare these included is the multi-channel Pt-By-Pt Butterworth filter (using a shift regester) that works well and may be useful to others.

As I said previously the reason I was continuing to look at this was to find a solution for other Pt-By-Pt vi that have state information, that I am using to find a more generic solution that I may be able to use in time critical loops.

Any help looking at the asynchronous calling within this project to show why this is giving incorrect results and potentially increasing the processing time would be appreciated. The timing may be realistic for my task but in comparison to the NI - Benchmarking example outlined in the previous post I was expecting something more comparable or better than a call by ref rather than worse.