LabVIEW FPGA Advanced Interface Tools Discussion

[StephenB]

make sure you're extracting the entire contents of the download zip file into a directory somewhere before running the install vi.

[aalg]

aalg 30-Apr-2013 3:08 PM

I just want to get some clearifications: I am working on a project that was coded using DIO64 long time ago(windows 98 and Labview 5.01). My duty is to change the code using FPGA(NI-pci 7811R with break out box) and of course current Labview 2012(windows 7). In the previous coding of the project a lot of call library function calls and Code Interface Node(CIN) were used. I am wondering if this tool will be useful for my project.

Thanks,

Abdul

[samsharp99]

I've used this in a couple of projects now and this has been excellent for our high-channel count projects (over 100 channels) and dynamically reading data from the FPGA by name rather than using the built-in FPGA functions. We had to do some adjustments to reduce the overhead of reading the items (i.e. reading out an array rather than individual items) but this provided a very workable solution. Thanks for your effort in producing this.

There is one minor request - is there any possibility of putting this toolkit into a VI package for use with the VIPM? We'd like to use VIPC files with our projects but I couldn't get the VI package to build & work with the installer.

[StephenB]

Hi Sam!

Thanks for the positive feedback. Always good to know this is providing value. For performance you might want to check the latest revision. You can now look up the address of an item ahead of time (outside a time critical loop) using the new "address look up" sub palette and then pass that value to the low level read/write calls in the new "fpga interface wrapper" palette inside your time critical loop. I've seen over 50% performance increase for a large application doing this.

So to retrofit existing code, look up your names outside your timed loop using the address look up palette and also get the FPGA session reference (in the "utility" sub palette), then pass those addresses and FPGA session reference into the time critical loop and call NiFPGA read/write

As far as a VI package... I really want to do this as well. I just recently upgraded some of our code to VI packages so I know how to... but I haven't had the time to do so for this. I'll put it on my todo list if I get time. If you do it yourself, there is a vipm or LabVIEW bug that makes it a bit annoying... you have to take the MNU files out of the libraries/classes (and update any parent mnu files calling sub mnu files to no longer look for mnus inside libraries/classes) or else the built vip has broken palettes.

[samsharp99]

Hi Stephen, thanks for the quick response!

I attempted to create the VI package myself but I was unsuccessful - I wasn't sure whether or not to try and pick out the installed files for my LabVIEW version and create the package that way or to try and include the package as you have done but run the installer VI after the install is complete? Another option would be to modify the installer VI so that it runs without user intervention? I didn't spend too long looking at it though.

I was more interested in your other comment regarding the performance increase - I created a couple of benchmark VIs to compare the read by name to doing the address lookup (putting the indicator names and addresses in variant attributes) and then using the lower level read function to get the data. I didn't see any improvements in the read time for reading 119 I32's - it took about 73ms for each iteration in both cases. Even doing a simple read of the same indicator 10,000 times didn't show any performance difference between them - about 0.8ms per read.

I wonder if perhaps this is due to the fact I'm using it with a CompactRIO - I guess the ethernet/TCP overhead comes into play here but you might see these improvements when you're using FPGA cards rather than an ethernet device?

In any case - I hope you'll get around to putting this into a VI package at some point!

[StephenB]

Hi Sam,

Are you opening a connection to the FPGA with this library remotely? Aka from a laptop calling FPGA open with "rio://<ip>/RIO0" instead of "RIO0"? In that case, I agree the network overhead will be the biggest factor.

What I was discussing is doing this:

can be much slower than doing this:

(which does the look up outside the loop, but the read inside the loop... rather than both in the loop)

[samsharp99]

Hi Stephen, your examples are almost exactly the same as mine! Yes - I am accessing a target cRIO via ethernet. That explains why I'm not seeing any performance improvement with the second method! Thanks for clarifying!

[David_Sprinkle]

Stephen, thanks for your work on this.

We're running our code on a cRIO (9074).  I'm having some trouble specifying the location of the bitfile on the RT host.  No clue where it might be located.  My understanding is that somehow the bitstream is embedded in the RT executable as a result of the standard "Open FPGA  VI reference" function.  But this function gets replaced by your utilities.  What then? Any suggestions?

Thanks again.

-dave sprinkle

[samsharp99]

I may be wrong (or there may be a better method), but what I have always done is to copy the bitfile onto the cRIO via FTP and then set the path to be the path to the bitfile (e.g. c:\<path to bitfile>.lvbitx ) on the cRIO. What I have also done in the past is have the path stored in the configuration file for my application.

[David_Sprinkle]

Thanks for the suggestion, Sam.  This approach worked for us.  Fiddly, but OK.

So here's my take on the toolkit:

Pro -- The toolkit allows us to "generify" access to the DMA FIFOs.  Previously, we were maintaining essentially identical copies of our DMA service routines, one for each DMA FIFO, because the standard FIFO read method doesn't allow the choice of FIFO by argument.

Con -- The toolkit doesn't allow front-panel access to clusters, just a limited set of fundamental types.

Here's my question:  Can we use both interfaces simultaneously?  The standard interface for access to our front-panel clusters, and the advanced interface for programmatically specifying which DMA FIFO?

Thanks.

-dave sprinkle