Measuring 60 Hz signal with cFP-AI-102.

[marc1uk]

Hi Pracek, thanks for taking the time to reply.

Firstly, I'm using LV2010, without the RT module. I'd rather avoid having to get the RT module as i don't wish to do any embedded control or processing - if it comes to it I'd rather buy faster hardware (Compact DAQ/RIO) if it's able to sample at a suitable rate without LVRT - at least that way we're getting better hardware for our money rather than a development suite that won't be used.

I initially tried this with a cFP-AI-118 module in a cFP-1800 controller, and found it was sampling at well below the stated rate - this has happened from the get-go, I've yet to see it sampling anywhere close to it's specified rate.

As the cFP-1800 hardware doesn't have any RT capability I wasn't even able to deploy a network-published shared variable to it (which you can do without LVRT), so I swapped to a cFP-2000 controller. I can now bind shared variables and plots directly to channels on the FP device, but unfortunately that hasn't improved the situation. I should note that without LVRT i'm not able to enable RT FIFO functionality on the shared variables.

The FP Create Tag function is really just there to check the FP device is online and responding - it's not actually involved in the read process here (i've tried using the program structure in the detailed help for it and it's no quicker).

While looking into the detailed help I did try using FP Advise to poll at a specified rate, but again no improvement in the rate of new values.

[marc1uk]

With regards to the links you referenced, I'd seen the former before but not that latter. The KB is full of useful tips, but it can be a bit of a treasure hunt to find all the relevant articles!

The article on sampling speed notes that values are only uploaded from the controller if they're new - I suppose this could slow down your acquisition rate if your values were only changing very slowly or over too small a range to be detected, but the test signal i'm using shouldn't cause these problems. I get a nice sine wave at low frequencies but above that it gets squared off to step changes.

As for the other article on adjusting the analog input rate, I hadn't seen that before, but as i say without LVRT I can't give this a go. Given that the controller must automatically loop to sample the channels and provide updated values to the server, presumably this sort of process is already implicit in the device. Perhaps there's some way of changing the rate of that implicit loop?

Searching the KB does turn up so many variables that influence update rate it's becoming quite difficult to follow. For example I found this article on bandwidth used by the Logos RT Protocol, which it says is used by FieldPoint ethernet network modules. That seems to say that the controller waits for updates over 100ms, then returns any changed values. It also says that "if a single item reports several changes, only the latest one is used, all previous values are discarded" implying you can at most get 1 sample from every 100ms. But that would limit any module sampling at >10Hz! In fact it also says

"Note: This approach guarantees it does not miss a value. While it is unusable for a real-time protocol, it is necessary for a historical protocol, when all values are supposed to be logged into a target data repository" 

...but surely if it's discarding all changes but one over each 100ms period, it can miss any number of values! Those discarded values wouldn't be logged to the target data repository! I'm not sure what to make of this.

This article seems to suggest that much faster sampling rates ARE possible - that appears to be sampling a 100Hz signal with clearly a fast enough rate to not show significant stepwise increments. It's not 10kHz, but it's better than what I'm achieving.... but perhaps only with LVRT. It's unclear.

... but then this article here says "Each FP Read VI in the control loop adds anywhere from 0.61 (for one channel) to 0.81 ms (for eight channels) to the execution time..." and "...To calculate the control system loop time, use the following equation: System time = input time + 2(software loop time) + output time"

If FP Read takes 0.81ms, and the System time takes at least 2x this duration for deterministic samples, then it can't be possible to update at faster than ~617Hz even with LVRT!!

So sampling at 10kHz would be completely pointless!

@_@; This is all getting a bit much.

[Wayne.C]

marc1uk,

While the AI-118 sports a fairly quick update rate, the bus in the cFP is slow.  Network connectivity will also slow you down.  The best rate I have ever achieved using a AI-118 was a cFP-2220 ( top of the line) and a deployed embedded app.  It ran at 4KHz.  As I recall I got about 1KHz with a cFP-2020. 

cFP was never intended to be a very fast product.  That is why NI came out with the cRIO product line.  If you don't want/need the RealTime part, then I suggest one of the new cDAQ's with the ethernet connectivity. 

[marc1uk]

I've been looking at this article, which somewhat contradicts what the earlier article on Logos was saying - is that outdated now and LogosXT is the new standard? How can I tell which is being used?

LogosXT appears to perform in-situ buffering with sampling at a rate of 10ms. That buffering is independant of RT FIFO queuing or shared variable buffering, so in theory I should get (at most 8kB) arrays of values on each read...? But the shared variable only returns a single value??

It also says that shared variables are linked to the SVE via NI-PSP. If NI-PSP is limiting the update rate, it seems it would be better to host the variable on the cFP controller - then only my PC connection would need to communicate over NI-PSP to get updates. Presumably this would be able to speed up the process, but only if i were able to PSP subscribe to a buffered array of all the latest updates... Do I need LVRT to do this? I've tried creating a shared variable on the FP device in my project, but I can't seem to read from it. I get an "Error -1950679023: The connection to the server was disconnected" while reading the variable. Still trying to debug this error.

[marc1uk]

Hi Wayne.

I had feared this might be the case. It seems rather deceptive to have a product with a 10kHz sample rate that can only run at half that speed at most - still, even 4kHz is a couple of orders of magnitude faster than what I'm achieving at the moment. Could you share what setup you used to achieve that rate?

Would cRIO be the same as cFP in needing the LVRT module to achieve such rates?

[Wayne.C]

marc1uk,

I got it to go fast because I used LV-RT to develop, compile and deploy a standalone startup.exe.  The vi I deployed was designed to use the AI-118 to sample an AC waveform at a very specifc sample rate and then perform a measurement on the acquired samples.  The resulting measurement was then published using a Shared Network Variable that was hosted on the cFP.

In my case I needed the determinism of the RT to make sure my samples were at very specifc intervals.  I did not want USB layers or network delays introducing jitter into my data.

Since I use cFP and cRIO almost exclusively, I can't really say what the cRIO would do without RT.  But when I think about it, using the cRIO without RT is probably the same as using a cDAQ and I know you can sample at some pretty incredible rates with a cDAQ.

[marc1uk]

Right, I'll still need to look into that to be absolutely sure before we invest any further, but cDAQ may be the way to go then.

Thanks Wayne. 

.. i'd still like to know what's holding back my current vi though - you say you could get much higher rates with LVRT, but my RT application after all would just be a high priority loop - is the controller read loop really what's holding back my data? By the sounds of it you didn't pass back the raw measurements to the PC, but the output of calculations. Were those calculations based on a single measurement or many? i.e. can you only sample data at the full rate because you're only using it on the device, and passing back one result to the PC for every e.g. 10 samples?

If it were the latter perhaps the limiting factor is still the controller-PC interface, in which case having an RT loop running at higher rate wouldn't necessarily help. I could use an RT loop that builds an array of datapoints to reduce the rate of interaction, but I've read that functions such as build array should be avoided in RT loops as they slow things down. 😕 Catch 22.

[Wayne.C]

My app acquired 1000 samples and then performed a calculation.

There are all kinds of things that will slow you down.  By running a deployed startup.exe I eliminated as many of the potential delays as possible.  Don't assume that communication between your PC and cFP is instantaneous. 

As for the Catch22  -  Preallocate the array and use replace array subset to insert readings.