Speed of reading "Read/Write control" on FPGA

[JanBarton]

Hi,

I am trying to develop control system running on cRIO-9074. On FPGA there is running a simple code - reading periodically some voltages and temperatures and also controlling Analog outputs. On RT there are PID regulators and state machine for sequence control and interface for communication with UI running on PC. I have a problem with speed of reading Read/Write Control in RT. I attached picture of very simple code which I use for testing of "Read/Write Control" speed. I have found that reading out two array controls (first have 4 elements and second have also 4 elements) takes about 3-5ms. If I try to read array with 16 elements it take about 8ms and if I try just bolean it takes less than 1ms. Is this normal behavior or I am doing something wrong? I would like to run PID each 2ms but now it is not possible because of acces time of Read/Write Control. Is there any other way to speed up the access? Of course I could implement PID on FPGA but it is the last option because the PID will be special with some adaptive regulations implemented and its tunnig would not be easy on FPGA so I prefer to do it on RT.  Can you help me?

Jan

[Electromecha]

You also have the option of using Target to RT Host - DMA.  This should dramatically speed data transfer from the FPGA to the RT host.

[JanBarton]

Hi,

yes you are right. I have tried it and found that reading time doesn´t depend on number of element I am reading ( the same if I read 1 or 50 elements) but the access time is still about 3-4ms so it means that the PID cannot run faster. Any other suggestions?   

[nathand]

Do the PID control on the FPGA?

EDIT: oops, sorry, I see that you explained why you do not want to do that in the first post.

[ValkoA]

Hi Jan!

Some CompactRIO benchmarks regarding loopback speed can be found here. Your case mostly compares to the T2a (Analog In + PID + Analog Out) case, which was measured around 22 kHz loop rate on a 9024 cRIO (a more powerful standalone controller). The benchmark code used is allso downloadable from the same page.

On the long run, I would definitely recommend doing the PID on the FPGA though. Perhaps the adaptive parameters you've mentioned can be calculated and modified on the cRIO, with the FPGA only doing the gruntwork?

Best regards:

Andrew Valko

NI Hungary

[ZarArt]

 JanBarton I know it's been a while since your last post, but I happen to face the same issue. I have spent a week trying to figure out what is causing the latency (~2ms) every time I call the "read/write control" on just a U8 variable. Could you spare some hint ?

I have tested the FPGA state machine on its own and I can sample every 100us if I want. But whenever I want to get the data from the RT there is a big latency (I can see it happening on my bench scope). BTW, I also have a PID control that I would like to implement on the RT side instead of the FPGA.

Thanks

[Michael.Proctor]

Check you are not reading the FPGA via the VI server.

You need to check the address/Resource name of the FPGA in MAX and make sure it is not conflicting with a resource name that is the same.  ie both RIO0

If so then labview will add a resource IP address and route your calls via the VI Server.

Change one resource to eg RIO1

[Intaris]

You have the IP Address of your target included in the address, therefore your network stack is involved leading to more overhead.

If this is a locally attached device (no network access required) then simply change the VISA name to the Alias defined (RIO0).  The RIO drivers are NOT intelligent enough to notice that this is actually a local call with a remote address.

If it is not a locally attahced device (and network access is really required) then your latency is expected.

[MrJackHamilton]

I've run into this very problem. The solution recommeded by NI FPGA engineers was:

1. Create another 'control' for the parameter you want to possibly change from the RT in the FPGA loop.

2. Create another FPGA loop - that only xfers - the RT changed value to the other 'local' FPGA variable.

Why?: Because when you place a control/parameter in an FPGA loop - THAT IS DIRECTLY CONNECTED TO THE RT - it carries with it lots of overhead - essentially, you're asking that FPGA loop to simultaneously 'check' up with the RT if the value changed. This creates a huge lag - I've seen this on scope traces with the high-speed digital module - when we changed the timing parameters from the RT.

The 2-step/variable process - decouples the 'overhead' RT variable from the FPGA loop variable. I've seen on a scope the problem went away nearly completely when we did this.

Regards

Jack Hamilton

[Michael.Proctor]

To clarify:

1. Is this a front panel control or  internal memory that acts as a variable

2. the FPGA Loop  transfer ( xfer ) just simple runs at full loop speed transfer to the  memory block you created in 1.

How does the FPGA know at compile time if it is connected to an RT control... to allocate overhead resources