Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/24/2016 in all areas

  1. Please see the above link to download the videos The NIWeek 2016 Videos are uploaded to the ftp server. Please see this link for information on downloading the videos. https://lavag.org/topic/19154-ni-week-2015-videos/#comment-115444
    1 point
  2. A power failure crashed my LabVIEW before I pushed some important work to the repository. Recover seemed to work yet I got a message saying that the vi can't be saved and it was actually corrupted: "Cannot load diagram of "....vi"" and the only option is "cancel save". Regular cut and paste tricks didn't work and before starting to go over the Hex code I tried something that I didn't see anyone write about and it worked so here it goes for those future corruption fighters (I can't promise it will work each time though): The VI was written in LV 2011. I tried opening a new vi by using the still opened corrupted vi as a template. It didn't work. I moved up to LV 2013 and it still didn't work. Trying the same with LV 2014 did the magic. All that was left to do is to save to previous version (LV 2011) and correct the file's location and name. Done.
    1 point
  3. That's great! One other thing you might try - I think the build process should also work if the Conditional structure default case was "empty path" and that the "Linux" path was as you coded it - in that case it avoids the unnecessary hardcoded path to the .SO file in the unsupported cases (non-Linux). I think the code will still open as 'non-broken' if open on a Linux target context (as it should be) and it will open broken on a Windows context (as it should be). Its probably best that the code is broken when opened in an unsupported context - because its better to break at development time than at run-time in this scenario.
    1 point
  4. I would check the "specify path on diagram" and try passing the path into the CLFN node and use a conditional disable structure to pass in the extension (or hard code it to only support Linux targets). Best practice would be to create a subVI with the constant so that you use the same path for all instances.
    1 point
  5. The command line option only works if you know no other versions of LabVIEW are currently open. LabVIEW communicates over DDE to other versions of LabVIEW, and that is why some times you'll see LabVIEW try to open the wrong VI in the wrong version. If you double click a VI, or open it over the command line, it may choose to open it in the wrong version even if the command line specified which version to open it with. Here is a post I made on it a while ago and many other applications (like VIPM launching LabVIEW, and LabVIEW version selection tools) suffer from this issue. The work around is using the technique I've mentioned. But if you can ensure no versions of LabVIEW are running, maybe by closing them all, making a VI that runs when opened is much easier.
    1 point
×
×
  • Create New...

Important Information

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