Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 11/13/2019 in all areas

  1. 5 points
    All of the presentations are now on the LabVIEW Wiki. You can find them at: https://labviewwiki.org/wiki/Americas_CLA_Summit_2019 Thanks Kevin Shirey and Mark Balla for producing the videos and all those that volunteered to run the cameras. This is an awesome resource to be able to go re-watch and review these great presentations again or for those that couldn't join us in person to be able to view them as well.
  2. 3 points
    I assume you meant this video? There is this older video of Dr. T and Jeff K. introducing a LabVIEW Basics Interactive CD-ROM (~LabVIEW 4), but it's not as exciting as the LabVIEW 5 promo.
  3. 2 points
    Where can I sign the petition to hand over NI's social media accounts to you?
  4. 1 point
    As a lefty, don't even get me started on can openers.
  5. 1 point
    Hi, I'm having problems building a vipc from a vipb with files containing nested vims. Getting the following error from VIPM: ERROR: 7: VIPM API_vipm_api.lvlib:Parse Build Return Message_vipm_api.vi<ERR> Code:: 7 Source:: 0053C289D635723F5DC0A4F08297566A<ERR> The following source VIs or Libraries are missing. Please correct this problem before rebuilding. b39afad9-8321-4719-86a9-dddab325fc87.vi The following source VIs or Libraries are the callers of missing files BitsSetter.vim I created a zip with the vims and the vipb file. Any suggestions how to fix this? Opening the files shows no errors. Replacing the nested vim with its actual implementation fixes the problem but I don't want to give in just yet. I'm on LV 18.0.1f4 64bit with VIPM 2018.0.0f1 Cheers bits.zip
  6. 1 point
    Merry Xmas:Symlink.llb
  7. 1 point
    Turns out there is a way to do it from within the IDE without mucking about with copying files etc (100% not obvious though). I stumbled on this totally epic write up/demo by Matthias Baudot. https://www.studiobods.com/en/niweek2019-ts170/
  8. 1 point
    I’m pretty sure that’s the easiest to implement, so I’m liking your opinion. (Trying to be non-biased, I do think that’s the better option from usability. If I pick a name in a template, it’s because I expect the provided thing to use that name. It is consistent with the class method behavior, but for cluster fields.)
  9. 1 point
    I'm favouring just freeze the name, as that is simplest for the User to understand, given that it is difficult to diagnose, let alone fix, any problem if the name adaption goes wrong.
  10. 1 point
  11. 1 point
    The Beta of LabVIEW Community Edition is now available at http://ni.com/beta
  12. 1 point
    Well, in case you ever consider going that way, I'll recommend you start by looking at the LinkIdentity parts of the code Another vector for information could also be to look at the codestreams in the "Ned, the friendly debugger" interface. While I haven't peeked much at Flarn's later progress, I do know that NED will let you switch the format of some VI resources into XML (Heap Save Format) - dunno if Flarn is utilizing that?! (be warned though - this will most likely certainly cause LabVIEW to crash if trying to load the VI afterwards) Also, for quick low-level access to the Resource Fork of LabVIEW VI's and a lot of other NI resource files -from inside LabVIEW- I suggest using the REdLoadResFile/REdSaveResFile (interface)functions found in LabVIEW.exe. That at least cut away one level of abstraction for me, back when I had the time to immerse myself in this kind of 'research'. Now off to figure out the "Keep code streams for heap peek" option..


×
×
  • Create New...

Important Information

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