Using Open FPGA VI Reference in a distributed VI

Hi all.
I have some problems with the Open FPGA VI reference. In my project I have a VI which uses the Open FPGA VI Reference. In the Configure Dialog I’m using a lvbitx file located under “C:\Program Files (x86)\National Instruments\NI VST\Custom Bitfiles”. This works as it should while running the VI on my development machine but after building an installer including all this, the path to the lvbitx file gets wrong. When I build the installer I’m using VIPB but the same problem occurs if building an installer using NI Build Spec. When I try to use the distributed VI on a “customer machine”, it automatically starts searching for the lvbitx file but the path to the file is incorrectly set to ..\..\..\..\..\Program Files (x86)\National Instruments\NI VST\Custom Bitfiles, and this forces the user to manually find the bit file. I don’t like that, the distributed VI should have the correct path to the bit file so that the user can use the VI directly.
I have found out that the path to the bit file in the distributed VI is relative to a temporarily build path used by the package builder. So, I have tried using several different temporarily build paths, but I have never been able to find a relative path that is correct. Even if my distributed VI seems to have the correct relative path to the bitfile it cant find the bitfile… Any suggestions for how to use the Open FPGA VI reference successfully on a distributed VI?
Regards
/Gunnar

Hi Gunnar,
What version of LabVIEW do you use? Something new in LabVIEW 2013 is the "Open Dynamic Bitfile Reference". With this, you could use e.g. an "Application Directory" node and build the path at runtime:
http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgahost/open_dyn_bitfile_reference/

Similar Messages

Use of "Open FPGA VI Reference" function --- Build Specification vs VI vs Bitfile

When using the "Open FPGA VI Reference" function in a LV2012 cRIO application, there are 3 options: Build Specification, VI, or Bitfile. What would be the reasons for selecting one over the others? Does it affect the resulting startup.rtexe when the cRIO application is built? I searched through the help and in these forums, but I don't see criteria for selecting one over the others; maybe I missed it.

Hello Chris,
Apologies in advance for a long reply.
The reference method won't change the functionality of your rtexe.exe. They all end up dropping a bitstream, based on a bitfile, onto the cRIO's FPGA.
To a degree, the method used to reference the FPGA code is a matter of taste, but there are situations where one method is better suited than the others.
Reference by VI:
Setting the configuration options to open reference by VI is helpful during development when you are making changes to an FPGA VI often and building/testing using the same spec. When this option is used, a bitfile is selected based on the default build specification for the project. A project may have only one default build specification. You can make any build the default by checking the option under the Source Files category in the build properties. The default build is indicated in the project explorer by the green box around the builds icon.
Reference by Bitfile:
This option references a bitfile directly. Through the configuration window, you can select one specific bitfile to open a reference to (this is not dynamic and does not change unless you physically go make a change to that path). If you're using this method, it helps to give your bitfiles more meaningful names than the ones that are automatically generated by LabVIEW. When you run subsequent compilations off of the same build specification and do not change the bitfile nname or path in the build configuration, the old bitfile is overwritten and replaced with the new one. When you are using this option, it is critical that you keep up with which bitfile is the one you want to be using. There is an option now that will help alleviate any problems referencing by bitfile through the Open FPGA VI Reference function. There is a new VI called Open Dynamic Bitfile Reference. It is typically used when you want to chose a specific bitfile to load depending on something in your host code (a configuration option etc) - but it allows you to dynamically reference a bitfile on the block diagram by path.
Referency by Build Specification:
This option is good for when you want to always use a bitfile that is associated with/compiled with the same build configuration. Say you have two options for top level FPGA VIs in your project (each with its own build spec). Both of these VIs have the same interface (read/write controls, DMA) but they run different algorithms or something. This is nice because you can easily switch your host application between them by picking the build spec associated with the FPGA VI you want to use. In this type of sutation, referencing by VI is no good because you can only have on default build spec.
cheers.
Matthew H.
Applications Engineer
National Instruments

Bind FPGA host reference to type definition in labVIEW 2012 crashes labVIEW

Hi,
I am using FPGA target device 5641R and labview FPGA 2012 with 5640R ver 1.7.
On the configure window of open FPGA VI reference function, choosing the dynmaic mode shows broken arrow when wired to the 5640R configuration VIs (i.e. Configure timebase, Configure ADC default, Configure ADC NCO functions). So i tried the other option which is binding the FPGA host reference to type definition and choose the control from path C:\Program Files\National Instruments\LabVIEW 2012\instr.lib\ni5640R\Configuration\NI-5640R VIs\ni5640R FPGA VI Reference.ctl. But after that when i try to save the VI on which open FPGA VI reference function is placed, labVIEW crashes. I am unable to figure out the reason. Earlier I was working with labVIEW 2011 and it was working fine there. Any suggestions would be highly appretiated.
Please see the attached images for more details.
Thanks
Attachments:
1.png ‏33 KB
2.png ‏71 KB
3.png ‏40 KB

Check out this thread. It looks like someone else ran into a similar issue and made changes that fixed their application.
http://forums.ni.com/t5/IF-RIO/correct-5640r-template-use-recommendation/td-p/1331918
Jeff B.
Applications Engineer
National Instruments

Open Vi object reference waveform chart

Hi, I'd like change a property of an indicator in a VI from another VI (In particular i want to clear a Waveform Chart) I used Open VI Object Reference but i am not able to access to History Data. How can I do?
Solved!
Go to Solution.
Attachments:
ClearChart.vi ‏7 KB
test.vi ‏12 KB

Sorry, I made what you have told me:
now i have this error:
why? If you have implemented a correct Vi can you give me it please?
Thanks!
Attachments:
ClearChart.vi ‏14 KB
test.vi ‏12 KB

Using Open VI Reference to run a VI, on an RT target, with sub-VIs not loaded

I've been using Open VI Reference and Call By Reference Node to remotely run VIs on my RT controller. I
usually wire string data to the vi path input, but this
requires the VI to be in memory. I understand (from LabVIEW help) that I can wire a path to this terminal and specify a VI that is
not in memory, but is on the disk. NI has an example that
confirms my understanding. I get errors when I attempt to do the same
with VIs that have sub-VIs; I suspect that the problem is that
the sub-VIs aren't in memory and that the top-level vi doesn't know where to
look for them (because the paths aren't specified). All of the sub-VIs are on the RT system (in the same directory), they're just not in memory.
Is there a way to get LabVIEW to look for sub-VIs on the disk? I don't want to rely on using a startup application and rebooting to get my VIs into memory.
Thank you,
Jim Carmody
Software Engineer
G2 Technologies
www.g2tek.com
Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice

Hi Jim,
It sounds like you are going about calling VIs remotely the correct way. It would be very helpful if you could post the errors you are receiving. I also wanted to know if you saw the note at the bottom of the article that says your VI library must contain everything your top level VI calls.
Eric A.
National Instruments
Distributed I/O Product Support Engineer

No VIs listed for VI option in "Configure Open FPGA Reference"

I have a cRIO and I was using the Open FPGA Reference function to load a bitfile by specifying the VI name. This was working fine.
I have been compiling all day, and I just deleted a control and then changed a DMA FIFO datatype. When loaded and ran calls to the FIFO returned an error. So I tried refreshing the VI specification, but now when the dialog comes up, there are no VIs listed.
No idea what's wrong here.
Solved!
Go to Solution.

1) I commented out the FIFO when I compiled (forgot to switch it back on); so that's why the error occurred. Whoops.
2) I still don't know why I could not browse for the VI, but I was able to drag and drop.

Open FPGA reference - slow?

I'm trying to do some data acquisition through a cRIO 9101 attached to DI, DO and AI modules. Right now, I have something like a Read AI VI in my cRIO application that opens the FPGA reference, reads the control (using the read control node), then closes the FPGA reference and returns the read value to the calling VI. My issue is that this seems mindbogglingly slow.
I use this VI and the corresponding DI and DO VIs that are pretty mucht he same internally in a handful of places throughout my code and at least in one spot where I've timed it, it takes something like one full second to run this VI. The culprit seems to be the open FPGA reference VI.
At this point, can anyone suggest what I'm doing wrong?
Is this the right way to go about this, given that my access to the FPGA needs to be fairly scattered throughout my code?
Should I perhaps just write the FPGA reference into a global variable and initialize it once at the start and use it everywhere from the global?
An alternative that I've got going right now is to use the first call VI to only use the open FPGA reference once, then store the reference in a shift register.
Both of these soultiuons create some issues with closing the FPGA reference. Can anyone comment if closing the FPGA reference is really all that necessary?
Thanks,
Chris

My VI is fairly complex, I do single reads and writes in various locations throughout the code, but never repeatedly in rapid succession. To facilitate this, I had a subVI that just reads analog values from the FPGA and it is within this subVI that I had the sequence of Initialize FPGA ref. --> read --> close FPGA ref. This was the initial solution that was giving me trouble, each call to this sub VI would take a very long time.
My solution right now is to initialize the FPGA reference once at the start of the application and store it in a global, then use that reference every time I do a read/write. This leads to not closing the reference until the application is done, which, in my application, really doesn't happen unless there's a system reboot, power failure, etc. So at the end of my application frequently, the reference will not get closed.
I assume that opening the reference does not store any state information that would survive a reboot (i.e. storing something in flash), so not closing the reference shouldn't be an issue. If anyone has any information to the contrary, please let me know.
Thanks,
Chris

The buttons in main the vi get locked after opening a vi reference in a subpanel and using buttons within the subpanel.

I am trying to open a reference to a vi in the subpanel of the main vi. However after the vi opens in the subpanel and after pressing a few buttons in the subpanel the buttons in the main vi get locked, i.e. I can't even close the main vi or control anything else. Is there any way how I can avoid this happening?

> The buttons in main the vi get locked after opening a vi reference in
> a subpanel and using buttons within the subpanel.
>
> I am trying to open a reference to a vi in the subpanel of the main
> vi. However after the vi opens in the subpanel and after pressing a
> few buttons in the subpanel the buttons in the main vi get locked,
> i.e. I can't even close the main vi or control anything else. Is there
> any way how I can avoid this happening?
This is most likely happening because in either the top or sub panel,
there is an event structure that is queuing events, and is set to lock
the panel until the events are handled, and because of the logic in the
diagram, the events aren't being pulled from the queue.
So, you have a deadlock. You are waiting
on the panel. The panel is
waiting on the diagram. And the diagram is waiting on something else.
So, if there are indeed event structures involved, determine where in
the diagram things are delaying. Also, if you do not need the panel to
lock until the event is handled, you can change the setting in the
events dialog on the structure. But the events will still be queued
until the diagram starts executing.
Greg McKaskle

I have a VI A. I want A to call another VI B and execute. After B executes, I want it to close automatically and go back to A. Is this possible ? I tried using open reference and those methods, but I am not able to do it. Can someone help me ? Thanks !

Thanks !
Kudos always welcome for helpful posts

Re: I have a VI A. I want A to call another VI B and execute. After B executes, I want it to close automatically and go back to A. Is this possible ? I tried using open reference and those methods, but I am not able to do it. Can someone help me ? Thanks !Hi Stephan ! Thanks ! I guess I explained my question not so right. I've created a customized menu and at the instance of me selecting a menu, a VI should load itself dynamically. I am using call by reference. Sometimes it works and sometimes it won't. In short, what I want to achieve is load VIs dynamically and close them dynamically once they finish executing. Thanks !
Kudos always welcome for helpful posts

Close FPGA VI Reference breaks when moving project...

I created a cRIO project with an FPGA target, and assigned the output of Open FPGA Reference to an indicator.
When I moved the project to a different computer, the wire to the indicator broke, so I selected "Bind to Typedef..." on the Open FPGA Reference node, replaced the indicator, reconnected all the local variables from old indicator to the new one, and deleted the old one. So far so good.
But now, when I move the project to a different computer, the wire to the Close FPGA VI Reference breaks.
If I delete and replace the broken wire whenever I open the project on the new computer, everything's fine. Am I stuck with that? It could be worse, I guess, but I'd like to fix this for real. Any suggestions?
Thanks in advance.

Hi Ron,
I do not believe that there are any other workarounds for this behavior. I've been attempting to fix this myself in another way, but it seems that due to the simplistic nature of the close reference vi, it is not possible to go about this in another way when distributing applications. I will try to see if we can make a product suggestion for this in the future releases of the software.

Opening/Closing Queue Reference By Name

I'm curious if opening and closing a queue reference to put information onto the queue, using the queue name -> obtain queue -> enqueue -> release queue(Non Force) is problematic. I thought i saw a thread a long time ago that opening/closing a reference to a queue over and over could lead to a memory leak, even if the original queue never was released. Obviously, i'm ignoring the general pass the wire(by value) correct labview way.
Instead of opening/closing using the queue name i could also wrap the queue reference in a FG after originally creating it and work on the reference that way. Ignoring the "right way to do it" are there still downsides, other than programing correctly, to open/closing queue reference's in this fashion such as memory leaks.

PaulG. wrote:
I have never heard of any unwanted consequences of repeatedly opening and closing any reference. The trick is to make sure a reference gets closed when no longer needed. I don't see any reason not to implement queues the ways you describe. I've done all three and haven't had any issues that I know of. If opening and closing a queue reference repeatedly caused a memory leak that would be considered a bug.
I have to disagree here. A couple of years ago I was using a DAQmx Write with "autostart" option set to TRUE in a loop (ca. 100ms timing) to constantly make sure, that in application standby my Digital Outputs kept the values they ought to have. This reproducibly caused a blue screen on Windows after 6 hours of the program running in standby. As it turned out, LabVIEW was using a new reference to the task for every call of the Write, because with autostart set to TRUE it had to create the task beforehand and close it afterwards. After the mentioned peroiod of time, LabVIEW ran out of reference numbers, as the support explained to me.
Of course, even LabVIEW Help says to avoid using autostart=TRUE with DAQmx VIs in a loop, but only because of the overhead the repeated Create and Clear is consuming. Naturally, I have learned that the hard way now.
So - Create the reference once, use that same reference all the time (FG is fine, I think - I use this method for obtaining my logfile reference all over the place!) and close it only, when you don't really need it anymore.

Error 42 occurred at Open Application Reference in DynamicDownload.vi

Hi！
I want to create an executable from a VI wich calls a dll created by Simulink and Simulation Interface Toolkit.
After I compile the simulink module with MSVC++ 6.0 in MATLAB,and then use this dll in LabVIEW,
the following message appears:
Error 42 occurred at Open Application Reference in DynamicDownload.vi->SIT_InitEstablishTCPConnection.vi->SIT Initialize.vi->Untitled.vi
Returning to Select Host dialog.
Possible reason(s):
LabVIEW: Generic error.
What should I do to have an executable which works correctly?

I have the same Problem here with the Error 42 on open application reference.
Can someone pleas explain what this error means, and what the reasons are for this error?
I have two exe files, and i am trying to open the application reference of the other exe when i get this error.
First i thought it has something to do with the .ini file settings, which by the way is nowhere explained...
here my entries:
server.tcp.acl="290000000A000000010000001D00000003000000010000002A10000000030000000000010000000000"
server.tcp.enabled=TRUE
server.tcp.port=3360
server.tcp.serviceName=Image Monitoring
server.tcp.access=+*,"+*","127.0.0.1","Localhost"
server.vi.access=+*
server.vi.callsEnabled=TRUE
server.vi.propertiesEnabled=TRUE
server.ole.enabled=TRUE
server.tcp.paranoid=TRUE
server.tcp.servic=My Computer/VI Server
tcpServer.log=TRUE
tcpServer.logPath=c:\TestStand\Tools\Image Monitoring PC\serverlog.txt
server.app.propertiesEnabled=TRUE
if i build a simple exe with call on open applicationr eference it works. but not with my main application,
so this is why i need to know what causes the Generic Error???
Is there a possibility that there have to be certain entries in the ini file of the calling exe? and what would those entries be?????????

Error 1054 Open VI Object Reference

Hi Ppl,
I'm using LabVIEW 8.6 and I'm debugging a code that uses the Open VI Object Reference node. The parent reference thats passed in is a refrence of a VI instance and the vi object class is the control type. Though the control is present in the VI, the node returns error 1054 and says object not found.
I'm wondering why this was. However when the parent is the VI reference itself instead of the instance VI this works. I'm not able to understand the problem.
Thanks,
Sathish

Sorry, I made what you have told me:
now i have this error:
why? If you have implemented a correct Vi can you give me it please?
Thanks!
Attachments:
ClearChart.vi ‏14 KB
test.vi ‏12 KB

Open vi by reference is very slow

Hi !
I have this main vi which is the user interface and it calls several
subVIs sequentially (subvi 1, subvi 2, subvi 3 etc). the subVIs in turn
have subVIs which belong to a DLL, I chosen to use CALL VI BY REFERENCE
since my sequence is not fixed. when i run the main VI however, the
time taken seem to be much longer than what it should be.
One observation which I made was that when I have one of these SubVIs
opened. The main VI runs smoothly and can be completed in a matter of
seconds. What can I do to run this Main VI smoothly and efficiently
without having to open my SubVI ?
Goy

Hi
thank you guys for your reply. I think that its a good idea to
load the subVIs first by placing them in a non executing section. allow
me to describe the program in a little more details simply for
completeness
Layer I Main VI (also the user interface)
Layer II Sub VIs (a series of VI which are dynamically called)
These VIs are actually test cases. I made them dynamic because I have
huge set of different tests and each time I run the main VI, I may only
call a few of them to run. Thats why I chosen it instead of using a
state machine. It works fine for me.
Layer III Hardware Drivers (VIs which interface directly to hardware)
These VIs are called by the subVIs in layer II. I had collectively put
these VIs into DLL for easier organisation. I believe the additional
time taken was actually due to loading the VIs from the DLL in this
layer.
question : what can I do to let the Main VI in Layer I to
know that I be using VIs from Layer III ? is there a way to include DLL
into any VI to let it know it will be loading these VIs. As suggested,
one way of coz is simply to put a VI which reside in the DLL into a non
executing part of the main VI. I shall try next week when I get back to
work.

Hi experts, how to use open sql to read data from one " maintenance view"?

i want to use this part of data within report ,so how to use open sql statement to read data from one " maintenance view"?

Hi
You can't use OPEN SQl statements to fetch data from maintenance view
You have to use only Database views
see the different types of views and the difference
The followings are different types of views:
- Database View (SE11)
Database views are implement an inner join, that is, only records of the primary table (selected via the join operation) for which the corresponding records of the secondary tables also exist are fetched. Inconsistencies between primary and secondary table could, therefore, lead to a reduced selection set.
In database views, the join conditions can be formulated using equality relationships between any base fields. In the other types of view, they must be taken from existing foreign keys. That is, tables can only be collected in a maintenance or help view if they are linked to one another via foreign keys.
- Help View ( SE54)
Help views are used to output additional information when the online help system is called.
When the F4 button is pressed for a screen field, a check is first made on whether a matchcode is defined for this field. If this is not the case, the help view is displayed in which the check table of the field is the primary table. Thus, for each table no more than one help view can be created, that is, a table can only be primary table in at most one help view.
- Projection View
Projection views are used to suppress or mask certain fields in a table (projection), thus minimizing the number of interfaces. This means that only the data that is actually required is exchanged when the database is accessed.
A projection view can draw upon only one table. Selection conditions cannot be specified for projection views.
- Maintenance View ( SE54 )
Maintenance views enable a business-oriented approach to looking at data, while at the same time, making it possible to maintain the data involved. Data from several tables can be summarized in a maintenance view and maintained collectively via this view. That is, the data is entered via the view and then distributed to the underlying tables by the system.
Please have a look at below link. It will help you.
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21ed06446011d189700000e8322d00/frameset.htm
for more detailed info look on:
http://www.sap-img.com/abap/what-is-the-different-types-and-usage-of-views.htm
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/abap+dictionary&
Reward points for useful Answers
Regards
Anji

Using Open FPGA VI Reference in a distributed VI

Similar Messages

Maybe you are looking for