Best way to send backend data from a custom device to the UI?

[ChrisLudwig]

Greetings all!

I must say, I am new to Veristand.  I am building a custom device that performs FFTs on a PXI chassis within a Custom Device.  That CD does quite a lot of processing.  It downsamples all incoming channels to one desired sample rate that we need to run the FFTs on, it applies a window function, does the FFT, then does some pretty complex limit checking, and then has a fairly simple set up outputs to write back to the Veristand engine, mostly just if a limit is exceeded and some very basic info about the top peaks on the FFT.  We also supply the downsampled waveform to the Veristand engine in case any other operation needs that signal as well.

CPU load for the above work is not minor.  We are spec'ing the best controller to make all this happen.  Even at that, we may still have to use a coprocessor to handle the workload.

We will then have a custom UI that will plot the FFT, the multiple limit lines, the detected peaks, the limit status, etc.  We could have the custom UI reprocess all the FFT data from the downsampled waveform, but it doesn't make sense to have two CPUs each doing heavy FFT lifting when one could send all the back end data to the other so that the custom UI just formats and displays data the the CD computed.

So, I'm asking for ideas of how to send all this data out to the custom UI.  It is alot of data per channel and it would be a real mess if trying to pass all of it to the UI via Veristand since I can't just toss it all in a cluster or anything handy like that.  You'd never need to access this data from the UI itself as the UI wouldn't be able to do anything with it.  It would need to just go to the custom UI that we launch.

I'm open to all ideas as to how to make this painless.  My first thought was to bypass Veristand and just use a CD to pipe data out as UDP multicast onto the local net, but they really wanted to keep processing in the engine as it will drive emergency stop functionality.  I could still UDP out the backend data, but that will be somewhat messy given that I'll have 80 channels all piping the processed data out to the UI at once.

-Chris.

[joshe]

Hi Chris,

One thought would be to get an FPGA card and offload the processing to it.  You could then probably eliminate your CD and use some tools like the VS FPGA XML Builder and NI VeriStand FPGA Interface Tools to easily pull the FPGA calculation into VeriStand.  We have done similar things at my company.

Regards,

Josh

[ChrisLudwig]

That is on the list of options if the controller CPU can't manage the heavy lift.  My main question now is what would the best way be to package up all the data that we are calculating within the engine and passing it all to the custom UI so the UI doesn't have to re-compute all the results from the FFT.  

The UI would need the computed FFT (XY plot so two arrays of singles), a couple computed limit lines (two more arrays of singles), detected peaks from the FFT (currently an array of clusters, but could be sent as three more variable length arrays), the limit check results (an enum, but could be sent as a double), etc.  I don't really want to send everything through the Veristand engine as named channels as I'd have something like 8 arrays per measurement, which adds up to 640 arrays.  A bit of a mess to have all that background data visible in Veristand given that none of it is useful to the standard UI.  We'd need a custom UI to organize and display all that data.  

I can recalculate all the results on the PC, but I'd rather share all that between the Veristand engine (PXI) and the PC to save from having two CPUs running flat out making the same calculations.  Looking if there are some best practices for working around the limitations for data types imposed by Veristand (and not making a mess of things by creating 640 waveforms to share 1D arrays that are not actually WF data), basically the best way to bypass those limitations.  Package my data and get it to a UI on the PC.

[thumble]

If I had to do it, I would use a dedicated mono or multicast UDP streaming to publish the UI precomputed data directly from the CD so I can optimize the flow as much as possible.

Regards,