Trying to understand compactRIO scan rates

[David99999]

Forgive me for the simple question. I'm trying to really understand what's going on with the scan rates.

Let's say I have a compactrio, and I'm using the scan engine with a scan period of 10ms (from what I understand you don't want to try and read any faster than 10ms with the scan engine). I'm reading analog input with an NI 9208 +/-20mA current module. The module datasheet says it takes in data at a rate of 500 samples a second. The input module is clearly taking in data faster than the rio can scan. Does that mean the input module has it's own FIFO registers that it's storing its data on, and the compactrio is gradually taking from it? If so, does the input module register not ever overflow? Or is there no FIFO register on the module, and I'm actually technically losing data by using the scan engine.

And if I want to actually have the compactrio take in data at the modules scan rate, I need to use the FPGA to get up to that speed?

[GerdW]

Hi David,

---

@David99999 wrote:

Let's say I have a compactrio, and I'm using the scan engine with a scan period of 10ms

I'm reading analog input with an NI 9208 +/-20mA current module. The module datasheet says it takes in data at a rate of 500 samples a second. The input module is clearly taking in data faster than the rio can scan. 

I'm actually technically losing data by using the scan engine.

---

You are right: the ScanEngine is limiting your sample rates, depending on the actual cRIO type and the number of channels you want to read. (NI once had a whitepaper on that topic: here it is.)

And you are also right that the NI9208 has a maximum sample rate of 500S/s (in highspeed mode, otherwise just 19S/s…).

But why do you think you are losing any data? Why do you think the module will run as fast as possible when you read samples slower using the ScanEngine?

On the other hand: when you try to read several channels from your NI9208 at 100S/s then the module will easily reach its maximum sample rate of 500S/s for all channels quite easily. Now it may happen you read the same sample twice/trice when you request "new" samples from ScanEngine at 100Hz…

---

@David99999 wrote:

And if I want to actually have the compactrio take in data at the modules scan rate, I need to use the FPGA to get up to that speed?

---

To gain most performance you will use the FPGA in the cRIO sooner or later with your own VIs…

The ScanEngine is not just limiting sample rates, but also the way you can use several modules. In my case I had to switch to FPGA to be able to use single channels of a multichannel DIO module with my own requirements like arbitrary mixed DI vs DO, applying PWM signals at self-defined frequencies and counting signals/measuring frequencies at the same time…

[Jacobson-ni]

This white paper gives some additional information on how the Scan Engine operates which you might find helpful.

https://www.ni.com/en-us/innovations/white-papers/08/understanding-ni-compactrio-scan-mode.html#sect...

[David99999]

Sorry for the late response, work is hectic!

---

And you are also right that the NI9208 has a maximum sample rate of 500S/s (in highspeed mode, otherwise just 19S/s…).

---

---

Ok so that's interesting about highspeed mode. Is this a setting I can change in the properties of the module or something? I will read the manual/datasheet for that module. 

---

But why do you think you are losing any data? Why do you think the module will run as fast as possible when you read samples slower using the ScanEngine?

---

So you're saying that the module only runs as fast as the scanengine can pull from it? I was thinking that maybe it was always running at 500k S/s, but I guess not!

---

Now it may happen you read the same sample twice/trice when you request "new" samples from ScanEngine at 100Hz…

 Again, mind blown. How can I prevent this from happening? I'm assuming this would cause inaccuracies in my data. Surely the only option isn't to slow down my scan rate....?

You've been super helpful, I had no idea these types of things had to be considered. You're also making me aware how useless the ScanEngine is for collecting fast and accurate data! haha

[GerdW]

Hi David,

---

@David99999 wrote:

that's interesting about highspeed mode. Is this a setting I can change in the properties of the module or something? I will read the manual/datasheet for that module. 

---

You can change this setting in the module properties in your project.

(I think you can also change this setting in the FPGA part of your project once you use the FPGA module, but haven't checked that right now.)

---

@David99999 wrote:

So you're saying that the module only runs as fast as the scanengine can pull from it? I was thinking that maybe it was always running at 500k S/s, but I guess not!

---

The module will read samples as fast as needed when requesting less than 500S/s - or as fast as possible, which means 500S/s when requesting more than that…

(It will never ever run at 500kS/s!)

---

@David99999 wrote:

How can I prevent this from happening? I'm assuming this would cause inaccuracies in my data. Surely the only option isn't to slow down my scan rate....?

---

You are limited by the capabilities of your DAQ hardware. There is no other option: that module can only deliver samples at 500S/s at max…

---

@David99999 wrote:

I will read the manual/datasheet for that module. 

---

This usually should be the first thing to do, even before buying the hardware! (When you do this AFTER starting to code then you have done something completely wrong…)

---

@David99999 wrote:

You're also making me aware how useless the ScanEngine is for collecting fast and accurate data!

---

The ScanEngine will deliver accurate data! But it also has limits - and those limits are documented in the ApplicationNotes by NI. (When you stay within those limits then the ScanEngine is very useful!)

Maybe your expectations were wrong - because you missed to read the documentation!?

[David99999]

---

Maybe your expectations were wrong - because you missed to read the documentation!?

---

Haha well, to be fair, I'm a beginner. So yes, I read the datasheet every time before purchase, but some of these things you've mentioned were just not on my radar to consider. All is well though. I should have said "I will read the datasheet again".

@David99999 wrote:

How can I prevent this from happening? I'm assuming this would cause inaccuracies in my data. Surely the only option isn't to slow down my scan rate....?

---

You are limited by the capabilities of your DAQ hardware. There is no other option: that module can only deliver samples at 500S/s at max…

 What I meant was, is there any way to programmatically detect if I've started pulling doubles or triples of the same sample? Or some way to prevent that from happening in my code? Or is it just as simple as pay attention to what I'm doing and don't scan faster than my module card can provide data to me?

[GerdW]

Hi David,

---

@David99999 wrote:

What I meant was, is there any way to programmatically detect if I've started pulling doubles or triples of the same sample? Or some way to prevent that from happening in my code? Or is it just as simple as pay attention to what I'm doing and don't scan faster than my module card can provide data to me?

---

The simple way is to read samples not faster than they can be acquired. The calculation is quite simple:

samplerate := (500 / number_of_channels) S/s

What's the problem with reading the same value more than once anyway?

How do you know the difference between "reading the same sample again" and "getting the same value because nothing changed at the sensor"?

[David99999]

---

@GerdW wrote:

How do you know the difference between "reading the same sample again" and "getting the same value because nothing changed at the sensor"?

---

Ok that's a good point.....but IF I am reading the same sample twice or thrice, isn't that considered diluting my data with inaccuracies? Why would that be ok?

Maybe for most basic applications that aren't safety critical, this is acceptable? 

[GerdW]

Hi David,

---

@David99999 wrote:

Maybe for most basic applications that aren't safety critical, this is acceptable? 

---

When it is "safety critical" to read thermocouples faster than 500S/s then you need to look out for other (more capable) DAQ hardware!

When you want/need to use that specific module then you have to accept its datasheet.

---

@David99999 wrote:
IF I am reading the same sample twice or thrice, isn't that considered diluting my data with inaccuracies?

---

Why should that be considered inaccurate? It's (still) the most recent measurement value for that channel…