cRIO FPGA AI 9201

[Arnie1]

Hello,

I have an FPGA application, whic reads 8 channels of analogue data through an NI-9201 module. The first 4 channels require high-speed sampling, whilst the last 4 channels can make do with slow sampling.

Initially, I used two loops, one running every 12.5us to sample the first 4 channels and a separate, slower loop running at 10,000 us for the other 4. Note that the specified minimum sample rate for this AI module is 2us, so the fast loop is within this constraint, but if all 8 channels were sampled, then the minumum time would be 16us, which is greater than the set 12.5us for the fast loop.

The two loop approach worked OK-ish, but the second loop would introduce jitter into the first loop, dependant on relative sample rates. (Due to the built-in channel arbitration system.)

I was therefore about to re-arrange the sampling of all 8-channels into a single stacked sequence, whereby each of the first 4 channels is sampled sequentially with a sepcified wait time, of say 2.5us, between each sample-sequence. Then, a fifth channel would be sampled in the same way, but this fifth channel would rotate between each of the remaining 4 channels.  This would maintain the overall loop time of 12.5us (5 x 2.5us) with the result that the last 4 channels would be sampled effectively at 1/4 of the rate of the first 4 channels.

This seems OK in theory, but then I read the following in th eNI help section:

Understanding NI 9201/9221 Scanning

To scan the channels of the NI 9201/9221, configure an FPGA I/O Node with the channels you want to acquire from the module. The channels are scanned in numerical order. They are not scanned in the order of appearance in an FPGA I/O Node.

The first time an FPGA I/O Node configured with channels on an NI 9201/9221 module executes, the NI 9201/9221 module performs two setup conversions before converting the first channel. The module stores the channel list from the most recently executed FPGA I/O Node. The module does not repeat the setup conversions for subsequent FPGA I/O Node reads that are configured with the same channel list. The module performs the setup conversions only if the channel list changes.

Refer to the Analog Input VI in the labview\examples\CompactRIO\Basic IO\Analog Input directory for an example of handling the setup conversions in the FPGA VI block diagram.

Does this mean that if analogue input channels are accessed individually with separate FPGA I/O nodes, then because the channel list (single channel?) is different each time, the module will carry out two test conversions every time. If the minimum access-time is 2us, this could add at least 4us to each access?

Is this correct?

If so, is the best way to scan the AI channels, to put as many as possible channels into a single I/O node?

Thanks

[GrahamG]

I think I understand the what you are trying to do for your program. I have a couple of questions however to understand it better. You stated that your top loop was running at a 12.5us iteration time. What is the significance of this?

The 9201 is specified to sample at 800k for one channel or 500k for multiple channels (scanning). This should mean that it will scan across all 8 channels and still get back to the first one in the 2us that you specified. Can you not read all 8 channels at the max sampling rate of 500k and then post sample the data received fro the last 4 channels to cut it down to the timing that you need. As soon as you start using the MUX within the module it will have to scan past every channel whether you are sampling them or not so I would recommend just sampling from every channel in one node.

If I have miss understood your application needs would you post the two code options up here so I can take a look and I will try and assist further.

Best regards

[Arnie1]

Thank you for the reply. I think my question has been partly answered but just to explain better the application requirements:

1.) the 12.5us loop is the time I have to read 4-channels and then to do some simple maths on the readings. Presently, the 4 channels are read in one FPGA I/O node and I have verified that the loop runs in exactly12.5us (by togling a DIO and checking the signal on an oscilloscope). If the minimum time to read one channel is 2us, then there is some 4.5us spare for the calculations. So the loop timing fits OK.

2.) I have another slower loop which reads from the remaining 4 channels using a similar FPGA I/O node, but I found that depending on the rate of this second loop, it can introduce jitter in to the timing of the first loop, so that it does not always finish in 12.5us. I guess this is as a result of the arbitration logic for channel access. The timing of this second loop is actually not very impostant as it only monitors slowly varying signals, so 10 - 100ms is OK for this.

3.) I have also found that if the second loop is rearranged with 4 separate FPGA I/O nodes, each reading one of the remaining 4-channels, with a set time interval in between each (all arranged in a stacked sequence), then with certain time interval settings the jitter caused to the first loop can be eliminated.

 However, I was wonedring whether it would be better to combine all the AI channel-reads into one loop to optimise FPGA resources and performance, but I have since found out that:

a.) The arbitration system on the NI-9201 cannot be completely disabled (Arbitrate if Multiple Requestors is the only option) and since it's a multiplexed device, I'm not clear if arbitration occurs at the channel level or at the device level?

b.)  There is an implication from the NI Help Information that accessing (scanning?) the AI channels on the 9201 requires two set-up conversions to take place before the actual channel read, when the FPGA I/O node channel list changes. This can add 4us to the normal read-time. However, it is not clear from the Help statement whether accessing single-channels counts as the FPGA I/O channel list having changed and therefore causing the two set-up conversions to take place?

The above could mean that  the best arrangement would be as suggested, to read all 8-channels in one FPGA I/O node access. However, if the minumum read/access time for each channel is 2us, then 8x 2 = 16us and so I would need to rethink my fast loop as it could no-longer run in 12.5us.

This is why I was considering a structure that  would read 5-channels sequentially, in a stacked sequence, with the 5th channel alternating sequentially between each one of the last 4 channels. This would give a minimum loop time of 5 x 2us = 10us. I had thought that by reading one channel at a time, with only one channel listed in the FPGA I/O node in a stacked sequence, the issues with possible arbitration should be avoided, but now I'm not sure.

Thanks

Arnie.

[Arnie1]

Graham,

The significance of the 12.5us is that 8 readings are averaged to provide an input into a PID loop that runs every 100us.

However, perhaps I have misunderstood the specifications of the 9201. I had taken the 2us as being the time to read one channel when used in mult-channel set-up, such that the time to read 8-channels =16us.

However, if 2us is the time to read (scan) 8 channels then no problem!

I'll do some tests.

Thanks

Arnold

[Arnie1]

Hello, again,

The scanning time for the 9201 appears to be 2us per reading, per channel and not 2us for all 8-channels.

Therefore, could someone tell me whether scanning the channels through two or more FPGA-I/O node lists in labview will result in worse performance that if all the channels are scanned in one node list? I ask this because of the help info regarding set-up scans which apparently take place if the channel list changes (see above). Can someone confirm the situation with regards to the 9201?

Thanks

[StevenH]

Hi Arnie,

I would say that best practice is to use one FPGA-I/O Node and expand the nde to acquire from all eight channels.

This way you should certainly be able to acheive the 2uS sample interval, rather than having multiple nodes.

Hope this helps,

Steve

[Arnie1]

Steve,

thanks for the reply. I've snce tested out all the possible configurations and concur that the use of a single node provides the best timing results. 

I did try scanning 4-channels in one I/O node followed by a 5th channel in another I/O node set-up in a second sequence to the first scand, but this gave variable timings around 800 ticks (@40MHz), whereas all 8 channels in one node, produced a reapeatable 640 ticks (=2us per channel).

So, it does seem correct to say that whenever the I/O node channel list changes the 9201 module does some extra initial scans, adding 3-4 us to the process, such that in the above example you have 4x2us for the 4 channels, then, say, 4us for the changeover, then 2us for the 5th channel and another 4us for the changeover to go back to the first 4 channels. The total is, therefore, 18us and it less efficient than scanning all 8 in one go.

thanks,

arnold