swenp

Hi Alex,

It seems like an awful waste of space for embedded applications like FPGAs.

when programming LabVIEW FPGA the output is VHDL code which is compiled and optimized by the Xilinx compiler. So you cannot transfer LabVIEW memory management to FPGA. And because of that I don't think that there is any waste of memory wrt. FPGA programming.

Alex,

in the build spec you have to set the destination directory for all of your dynamic VIs to a folder, not to the executable.

And the dynamic VIs need their frontpanel to be called by the Run VI method, so change the settings in the build spec accordingly. you can do all this on the Source File Settings page of the build spec.

I attached a simple RT project that works for me. It calls a dynamic VI in app.dir\data. This VI just writes a txt file to the same folder containing the actual timestamp.

RT_dynamic.zip

Hi Alex,

create an empty startup executable, build and run as startup. If you use the default settings the "App.Dir" property will now always point to /c/ni-rt/startup, even if you connect with your development system and run VIs from within. That way you can build your Sub-VI path relatively to "App.Dir".

For loading VIs by path you have either to include them in your build spec with "Always included" just like on windows machines. Or tranfer them by ftp using e.g. filezilla. I never found any VIs saved on the RT target when just deploying from development system.

You could use .NET to kill a process by name:

That's strange. I did a clean install of openSUSE 12.1 in a new VirtualBox appliance and just installed LabVIEW 2009.

I could upload the appliance somewhere, but it's a VirtualBox one (~5GB)

As far as I can see there are no 2.4/2.6 kernels available for openSUSE 12.1. But you need the older kernels + sources to compile some kernel modules during the LabVIEW install process if you wan't VISA or GPIB support.

But if you just hit the 'n' key when asked for VISA and GPIB support the installation will complete without errors, no need for gcc + kernels sources in this case.

jkuehn,

for shared variables changing the aliases file should work supposed you are using them by adding a library to project, adding a shared variable to library and drag&drop the shared variable to your code.

By double clicking the shared variable on the block diagramm the URL to the variable should start with your cRIO target name, not with an IP address. On my machine it works

If your host executable has to connect to the target by e.g. VI server, or UDP/TCP you could parse the aliases file upon start-up for the actual IP address to use.

Thanks Ton and Aristos Queue,

for some reason I never stumbled upon the GetAllDescendents method, maybe I should have read the manual

But now I'm happy with that, thanks again.

Swen

What is the best way to retrieve a list of all files (not only VIs) from vi.lib, resource, instr.lib and user.lib that the VIs from my currently opened project are linked to?

At the moment I am building source distributions with the "Exclude files from vi.lib" etc. checkmarks unchecked and the "Preserve file hierarchy" checked.

But building source distributions takes a long time, often fails, and I don't need the files from my project compiled and exported, just the ones from vi.lib etc.

So I am searching for a better solution, any ideas? Somehow the source distribution itself is retrieving the information I need, but how?

Regards,

Swen

Greg,

as this sounds very strange to me I would contact NI support directly.

We have also used the EK1101 and it can be a problem to get them working correctly.

But the cRIO controller shouldn't be corrupted in any case I think, that sounds bad.

Good luck,

Swen

Greg,

we have successfully used Beckhoff EtherCat Bus Coupler + IO Modules with cRIO Controllers in some projects.

What type of hardware are you using exactly? Did you download the latest XML files for your modules from the Beckhoff site? Are you using the latest drivers from NI?

Regards,

Swen

Interesting suggestion. Just out of curiosity, what makes you think it would be GDI-related? I would think that LV shouldn't need any rendering resources during a build. This could be checked by adding the GDI Objects column to Task Manager, though.

I took the hint from our internal knowledge base for building large apps.

But if you watch the number of GDI handles e.g. with the Process Explorer during a build, you will notice that the number increases as soon as VIs are loaded into memory.

For a build with a lot of VIs this could lead into a problem, but I have never run into this by myself.

Hi Martin,

in addition you could try

1) Increase number of GDI objects available click

2) Activate 3GB option for your OS click

3) Save all VIs without blockdiagram before building

Cheers,

swen

The LabVIEW help for the "Open VI reference Function" says

If you wire a path, LabVIEW waits until the user interface is idle to load the VI from disk. If you wire a name string, LabVIEW does not need to wait until the user interface is idle, as it does not load a VI from disk. LabVIEW will only search in memory for a VI with a specified name.

But this is not true if you wire a strictly typed VI reference to the type specifier input. In this case the open reference is blocked as long as the user interface is active, e.g. the user is navigating through the menu. Is this an expected behaviour?

Cheers,

Swen

Dyn.vi

Main.vi

You won't be able to write a file on your Host-PC (Desktop) directly from the RT-System (sbRIO). But writing to the disk of the sbRIO will do with the standard File I/O VIs, assumed the given path is correct. The syntax is the same as on Windows-PCs, e.g.

c:\ni-rt\test.txt

should be a valid path on your RT-System.

But be aware that File I/O is crucial for RT-Performance. Sending your data to your Host-PC using Network-Variables or the new 2010 Network Streams could be an option, depending upon what exactly your are trying to do.

Cheers,

Swen

JG,

The Native LabVIEW Config API works as well as LabVIEW XML

the XML palette doesn't appear for Real-time targets in my LabVIEW projects.

Did is miss something? I would love to use the build in XML parser without using 3rd party products.

Cheers,

Swen

Ton,

you are right.The All VIs in memory won't work due to the restrictions you mentioned.

But the Exported VIs in memory works if you haven't explicitly denied access.

To be sure adding the line

server.vi.access="+*"

will export all VIs in memory.

The line

server.vi.access="-*"

will deny access to all VIs.

However I would love to be proven wrong.

Ton

You could register dynamic events for the controls you want to watch or record. That way you just have to write a "recorder" VI, no need to change anything in the VIs you want to watch. Put the events received in a queue or save them to a file and you have anything you need to replay the events.

The CANopen Library from NI seems to be designed for acting as a master in the network, not for acting as a slave. That is, you can create sync frames, heartbeats etc. and control slaves by sending NMT frames. But you can not react on them.

Maybe you want to use a second CAN module in parallel, e.g. the USB8473s and use the CAN-Frame/CAN-Channel API to react on frames like sync or NMT.

Hi _Y_,

the last time I used the NI CANopen library (LV (8.6) it didn't support sending PDOs upon receiving sync frames. It could only create a cyclic sync frame that was sent by the CAN card. You can also create cyclic PDOs that are sent hardware timed, but as far as I know you are not able to react on a sync sent by another controller.

The Node ID is used for building the arbitration ID and for network management functions. I recommend you to read the CiA 301 Standard which also explains the different PDO types.

It can be received for free (after registraion) from http://www.can-cia.org

Cheers,

Swen

Hello,

...

Hi KoBe,

I would like to know if a RT-target like cRIO or cFP can call VI's by reference, which would be the basis of changing the software on the RT-target in realtime.

Yes they do.

Maybe this thread from ni.com helps you.

In the example shown there the VI is loaded once into memory to be called by name later. Replacing the VI on disk won't work with this setup. You could open the reference by full VI path and close it afterwards, but I'm not quite sure if this works if you exchange the VI on disk and reload it later.

Regards,

swenp