LabVIEW FPGA Advanced Session Resources Feedback

[NIKAE]

Hello, this is Jaehoon Ko.

I want to use this function.

But, when I download and extract this file, below error is broke out.

Could you please give me a advice to solve this problem?

I use LabVIEW 2015, RT 2015 and FPGA.

Thank you

Regards,

Jaehoon Ko

[Jon_Kokott]

Labview 2016 v16.0

target is a 9149

Installed 2016 version of package,

Labview is freezing and requires a force quit when calling "open resource by name.vi"

Get resources.vi works correctly

Refnum Contents Into the open resource by name function:

Ideas?  Fixes?

Also it is irrelivant that the fpga isn't started, I was just trying to see if there was anythign else I could do, this code has been cut down to demonstrate minimmum to reporduce.

I've also attached the bitfile for reference.

[nanocyte]

StephenB wrote:

Hi Sam,

Great questions.

1) Yes, since it uses the native LabVIEW FPGA interface sessions

2) Yes. Each child session you create needs to be typed. So you will have to specify the data type. To ease this, you could create master refnum(s) of your entire bitfile(s) somewhere and then whenever you need to get access to a specfic item, just copy this refnum constant and delete out what you dont want then rename it to Value or FIFO.

Hope this helps!

I wonder if someone could make a refnum generator where you just click a control, use the menu plugin kit to create a refnum of it using scripting or something. Seems like a big time saver.

In the shorter term, maybe we can manually make a refnum that has all the common primatives in it and post it here.

[nanocyte]

Jon_Kokott wrote:

Labview 2016 v16.0

target is a 9149

Installed 2016 version of package,

Labview is freezing and requires a force quit when calling "open resource by name.vi"

Get resources.vi works correctly

Refnum Contents Into the open resource by name function:

Ideas?  Fixes?

Also it is irrelivant that the fpga isn't started, I was just trying to see if there was anythign else I could do, this code has been cut down to demonstrate minimmum to reporduce.

I've also attached the bitfile for reference.

I'm also seeing this behavior on a 9627. It's a pretty scary crash where I can't connect to the target anymore but I can see it in MAX. it's not throwing an error to the console or rebooting.

[User002]

nanocyte,

It looks like you found a bug.  In talking to the dev team, it sounds like this is broken on remote targets.  I'm trying to figure out if it is all remote calls on certain targets, or if it's all FIFOs.  I only say that because there is a known issue already that makes it look like it may partially work for remote targets (#6).

Good news is it looks like it's possible we chould have a fix in 2017, since it doesn't look too severe.

I'll update the known issues page once I find out more.

Also, I like the idea of a ready-to-go set of refnums.

Thanks,

Andrew

[Jon_Kokott]

Please correct me if I'm mistaken; after reviewing the API for LabVIEW FPGA, using the open dynamic bitfile reference in conjuction with the FPGA dynamic interface cast can acheive the same behavior (I simply am casting it to a type with the one FIFO I need, named correctly).

Currently this is what I'm doing to get around this issue.  Is there some reason why the open by name would be superior?  The ammount of clicks required to use the name method is higher and more troublesome to explain to others.

~Jon

[nanocyte]

It's the same as any "by name" use case. For example using static shared variables vs using the VIs. It gives you much greater reusability. Lets say you had like 10 PID controllers on the FPGA. Inputs: SPTemp, PTemp, ITemp, DTemp, SPPress, PPress, I2Press .... and you want to expose an API that will let the caller select if they are setting the setpoint for the temp or the setpoint for the pressure, that all becomes simpler. You can simply create that string on the fly (SP%s). If the code base grows and you add a humidity PID controller, and you have some targets that have humidity and others where there's no humidity sensor connected, that all becomes much more straightforward to manage.

Another use case I can imagine would be if you wanted generic code to grab all your FPGA settings and throw them in a config file. If you can just list out the controls and pick them by name, that's going to be more reusable than a solution that just grabbed a fixed set.

[User002]

Nanocyte said it well.  It makes the interface a bit more dynamic. 

One use case is that it lets you build applications where the software is fixed but the FPGA code can be defined at a later state - as long as it meets a set of interfaces.

One good example of this is the Engine Simulation Toolkit.  Here, we have a set of RT code (a VeriStand "custom device" plugin in this case) that is fixed.  A user can compose an engine with N x M of the sensor types in the toolkit.  Then, the custom device can discover which sensors are there, present them to the user to configure, and finally open and run them. 

For a single instance of code, I agree - the current (non-named) method you mentioned can be simpler.  But the advanced resource VIs do bring more dynamic capabilities to the table.

Thanks,

Andrew

[Jon_Kokott]

Maybe I didn't describe what I'm doing correctly, however, I'm acheiving exactly the same behavior as you've described.  I'm conciously making a design decision that all targets with feature X name their FIFOs the same (honestly I would do that in either case to minimize the number of unique FPGA references and share common framework), however, the method is very simmilar.  I query what "features" the FPGA has, and make a decision whether to expose that FIFO based on my expectation. 

Example:

As you can see, I'm acheiving the same functionality without the "open resource by name" VI.

As I see it, there is less work in implementing this solution.  You still need to open the FPGA reference and delete everything except the FIFO you want, but you DO NOT rename it to FIFO.  I could understand the argument that you may want the ability to name FIFOs differently for different targets, but if you have equivalent functionality, why would you even want to alias a feature set that way?  It only results in more work to case out feature aliases (and using names for classes as an identifier is allready an accepted way of explicitly declaring featuresets)

[Jon_Kokott]