LabVIEW and Sound/Vibration

[AliasLetMeIn]

My system is cRIO 9035 and using the NI 9230 module.  I am taking data from this module, processing it with sound and vibration VI's, and sending a final value to an HMI system using Network Published Shared Variables.  When I deploy my startup vi I get no errors indicating the sound and vibration packages aren't on my cRIO, as I shouldn't get the errors because I NI Sound and Vibration 19.0 installed.  My problem is I cannot get the processed values (by processed I mean values from the Sound and Vibration VI's) to read anything other than 0 unless I run the startup vi from the development PC through labview.  If I take a pre-processed values they come across just fine and it seems that something is happening with the Sound and Vibration Toolkit.  As a side note I am also using a thermocouple module that comes across just fine as well with no issues.  It only seems to be data coming out of the Sound and Vibration VI's.  What would cause this even if it shows I am licensed in the NI License Manager for NI Sound and Vibration 2019 and I have NI Sound and Vibration 19.0 installed on cRIO?

[cbutcher]

Is it the same VI that you're dragging between targets to run from cRIO/Windows (and are you building an RT-exe and setting to startup for the cRIO side?) or are they two different VIs?

The working thermocouple makes it sound like your VI is running fine, so I'd guess some problem between the cRIO measurement and the Network Variable outputs.

Are you using SNVs (or is it NSVs?) for the TCouple too?

Are they hosted in the same place (cRIO vs Windows, Distributed System Manager, etc)?

When you take "pre-processed values", what do you do differently?

If you could show some (cRIO, probably) code that would make it easier to guess what might be going wrong (or directly identify the problem).

[AliasLetMeIn]

Yes it is the same VI that I am running.  I build, set as startup, and deploy to the cRIO.  When the cRIO starts up that VI does run and I get data coming back to my HMI using Network Published Shared Variables for both thermocouples and accelerometers.  If i take the data coming directly from the accelerometers and send using NPSV they come across just fine.  However, if I process the signals with Sound and Vibration VI's it never sends a value back and keeps it at 0.  

Now if I take that same VI and use my development PC with labview to run that VI it will connect to the controller and deploy the VI, then all data comes across as intended even when I am processing the signals with Sound and Vibration VI's.  I won't be able to upload the VI or an image for a few days. But I am not thinking it is code related.  It feels like I am missing a toolkit or the license for the toolkit I am using is the proper license.  With that being said I thought labview would bark at you if you tried to deploy using Sound and Vibration VI's without the Sound and Vibration software being installed on the cRIO.

Thanks for your response.  I really appreciate it.  If you're still thinking the code is needed I can probably upload it in a few days or I can possibly upload a photo of the code for the area of interest.

[AliasLetMeIn]

Here is a picture of the VI of interest.  The while loop runs continuously.  I can extract data from everywhere up until the point it enters the FFT vi from Sound and Vibration.  However, if I run this startup vi from Labview everything works great. 

[AliasLetMeIn]

I have a work around for this issue that is working.  I’m basically streaming the data from the cRIO to the HMI to perform the frequency analysis on the HMI side.  I know the cRIO 9035 doesn’t support DaqMX but it still should support the Sound and Vibration suite correct?  Thanks to whoever provides information on this.

[dsb@NI]

Glad you found a work around. Sorry for the long delay. Yes, the cRIO 9035 can run Sound and Vibration measurement-analysis VIs on the RT side. SV VIs are not written in LabVIEW FPGA and will not run on FPGA targets.

If you found a solution that enabled you to run SV functionality on your RT target, please post back so that the community may benefit from your efforts.

BTW: I could not discern the source of the issue from the screenshot you posted, but it was interesting to see that the code took the maximum integrated spectrum value in the specified frequency range. Were you trying to measure the maximum integrated vibration level at a single frequency component? In your domain, is that more relevant than the overall vibration level?