Jump to content

swenp

Members
  • Content Count

    22
  • Joined

  • Last visited

  • Days Won

    1

swenp last won the day on November 15 2011

swenp had the most liked content!

Community Reputation

6

About swenp

  • Rank
    Active

Profile Information

  • Gender
    Male
  • Location
    Cologne / Germany

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2011
  • Since
    2004
  1. Hi Alex, 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.
  2. 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
  3. 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.
  4. You could use .NET to kill a process by name:
  5. 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)
  6. 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.
  7. Take a look at resource\Framework\Providers\Builds\Installer\CDK_Utility_GenerateGUID.vi as it generates the unique IDs you are looking for. They are used to uniquely tag the folders inside your build specs.
  8. 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.
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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.
  14. 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
  15. The LabVIEW help for the "Open VI reference Function" says 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.