LabVIEW FPGA Advanced Session Resources Feedback

[StephenB]

The performance will be identical once you get rid of the warnings. See known issue 1 to figure out how. Also, when RIO 14.0 releases you wont have to change the ini key, it will be on by default.

see known issue 2 to learn how to manage the reference.

for my benchmarks I was using a powerful PXI express controller, which is much faster than a 9068

the plan is for this same functionality to be available in native Labview. It will look different though.

[Dmitry]

One more glitch - Resource Info Out returned by GetResources.vi has FIFO Resource Names converted to lower case, while Register Names are left intact. This is important for Resource Name look-up - both categories should be handled the same way. In case its not possible to fix FIFO Name case conversion - Register Names should be forced to lower case ...

I think this is an important add-on to LabVIEW FPGA Module - allows decoupling reusable host-side code from FPGA Host Interface resource names. However, there seems to be room left for improvement - my application code is peppered with low-level calls that have nothing to do with the application itself ... Any chance of a sneak peek into the native LabVIEW' look & feel' ? Would it be available in LabVIEW 2015 Beta ?

Thanks,

Dmitry

Certified LabVIEW Architect

[Dmitry]

Error -63198 on OpenResourceByName

Hi Stephen,

I’ve been using the Advanced Sessions Resources for about a month – running a small test application with sessions for 3 FPGA Controls. Everything was working fine.

I recently added some functionality – increasing number of sessions from 3 to 7. To my surprise,  7-th call to OpenResourceByName was consistently returning Error -63198: “NI-RIO:  (Hex 0xFFFF0922) The system has run out of resources. Close a session and retry the operation.”

Running the test once more resulted in sessions 6 and 7 returning Error -63198, on the next run, sessions 5,6 & 7 returned the error, etc. However, after restarting LabVIEW it got back to just session 7 returning  the error. Rebooting Windows did not change the behavior – session 7 returned same error on the first run. It looks like some sort of a resource leak to me.

My development environment:

1.          LabVIEW 2014 (14.0) 32-bit

2.          NI-RIO 14.0.1

3.          Windows 7 Professional 64 bit with all recent updates

4.          NI-9146 Extension Chassis Target

It appears that FPGA Interface Control Names and Types do not matter – putting any of the 7 OpenResourceByName calls in Diagram Disable Structure prevents code from throwing the error.

Upon getting the error my code explicitly closes all Advanced Session references and the FPGA Reference.

I cannot upload my code – it tests proprietary reusable components and pulls a bunch of infrastructure classes (100+ VIs on the Host side) into the test application.

Any idea what is going on here?

Thanks,

Dmitry

[ttrr]

I encountered the same problem before. If you use a remote RIO device, the number of resource you open is limited. The remote means that you use a host machine or a PXI target to open a RIO device on another host machine or PXI target.

When you specify Device address in Open Dynamic FPGA Reference function, you'd better use short path like RIO0 instead of full path with IP address like rio://1.1.1.1/RIO0. I think that LabVIEW considers the RIO device with full path as a remote device even it is actually local to your host.

[Dmitry]

Hi ttrr,

Looks like you are (unfortunately) right - FPGA on NI-9146 is a remote target. It does not have an RT controller for running LV code locally ...

I did try calling Open FPGA VI Reference multiple times - resulting in only the first 7 calls returning valid references. Running the test multiple times resulted in 6, 5, 4, ... references available - so there definitely is a resource leak in LabVIEW FPGA Module or RIO driver stack ...

This seems like a severe scalability issue (and a show stopper for me) for using Advanced Session Resources approach with remote targets.

Does anybody know if there is a magic key I can add to nirio.ini or some other .ini file to increase number of simultaneous FPGA sessions on a remote target ?

I may need up to 28 Advanced Sessions for the current application.

I do have a workaround for decoupling Host-side reusable code from FPGA Interface Control names - it requires creating a class with a read and a write method for each top level FPGA VI control (7 items times 4 classes in my case) and injecting an object of each class into reusable code on Init (Dependency Injection Pattern). But this smells of Needless Complexity and I would prefer resolving the issue through native LabVIEW features ...

Thanks,

Dmitry

[StephenB]

Hi Dmitry,

As the simultaneous connections issue is not specific to this download (although certainly exacerbated by it), your best bet is to open a service request via ni.com/support

No reason to mention this download since you can hit that limit by simply opening 8 references with Open FPGA reference.

However, the reference leak is certainly not good. Considering you made code to show this reference leak and you have the hardware available there to validate the problem, can you share this code? Obviously do not include any of the rest of your IP... just the simple reference leak snippit. Of course I could create some myself but I really want to make sure we are doing exactly the same thing.

Thanks!

[Dmitry]

Hi Stephen,

I've submitted a Service Request (#7434043) on the leak yesterday. Test snippet is trivial - just configure it with any available bitfile for your remote target:

Cheers,

Dmitry

[samsharp99]

Hi Stephen,

Our team has been looking to use this toolkit again and while we were aware of the limitation around having 7 remote FPGA resources open at once, we have found another issue which we were unable to understand the cause of.

Specifically, we were taking the main FPGA reference and within a loop (designed to run at reasonable rates - e.g. 10-100ms) open a child reference (to a dynamically named element), read/write from the control/indicator and then close the reference (all while keeping the main reference open). The reason for opening and closing the reference is to avoid the 7 simultaneous sessions issue.

What we are finding is that we are getting errors with remote target disconnecting (e.g. -63040/-63044 errors) when we try to do this at these sorts of rates and only when we put in a loop rate of >1-2 seconds can we do this successfully.

It seems that creating/destroying the child references seems to have a detrimental impact on performance & causing disconnects.

Do you have any ideas why this might be and what the solution might be?

[maherhome]

All,

I'm trying to create a basic test using the Advance Sessions Sources and am getting a FIFO name error (-61206) from the Get Single Resource Session node.  The messy diagram below is showing the test VI on the right and a client VI on the left.  The idea is to pass an FPGA reference and the FIFO name "FpgaDataIn" and the test VI grabs the FIFO by name and writes to the FIFO. 

One issue to overcome is my beginner skills: the FPGA reference passed to the sub-VI apparently needs to be compatible with the FPGA reference control on the SubVI - which defeats the purpose of supporting generic FPGA references.  There must be a way to specifiy a control that accepts a generic FPGA reference (dynamic FPGA cast?  (which I've never used)).

Putting that issue aside for a moment, even when I define a FPGA reference control with a signature compatible with the passed FPGA reference I still get the 61206 error.  I noticed forum post's related to upper/lower case and tried everything lower case (I THINK - I'm not positive I did it completely - but it's tedious with the FPGA reference signatures) - but still had problems.

I read how the Get Single Resource Session needs a constant reference with a single "FIFO" fifo and have that.

Any tips would be greatly appreciated.

Thanks!

Steve

[ttrr]

Hi,

I think that you have to use Open Dynamic Bitfile Reference function to get a dynamic FPGA interface. Then, you can use that interface to get reference to a single resource.