Jump to content

Leaderboard


Popular Content

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

  1. 2 points
    Well there could be two that apply! "Killing me softly" and "Ready or Not, here I come you can't hide" 😀
  2. 1 point
    You are calling Open VI Reference using a path that points to your hard drive (D:\DEBUG\debug\vi_01.vi). That VI is not inside your executable. It is possible to make this work, but your executable will break if you move the VI on your hard drive. It is safer to open a strictly-typed Static VI Reference. This loads a copy of Vi_01.vi is stored inside the executable itself: For more info, see https://forums.ni.com/t5/LabVIEW/Static-VI-Reference/td-p/3334006 http://zone.ni.com/reference/en-XX/help/372614J-01/glang/static_vi_ref/
  3. 1 point
    I love it when old posts come up and I simply can't remember writing them, but my name is on it, so it must have been me..... No, no tricks. Haven't done that in years. It was for simply LVLibs, no classes, no hierarchies. LLBs don't play well with classes (no sub-folders, no ability to store multiple VIs with the same name). I suppose the PPL is the proper replacement for this now, although that's not source code....
  4. 1 point
    As a contributor to other packages I would like acknowledgement for those contributions. This was from our user group and the general idea was that package owners can build a self-brand of sorts by being attached to popular packages but if someone makes significant contributions to many successful packages there should be some sort of recognition. I think the OpenG libraries are a good example where there may only be one owner but I'm sure there were some large contributions from several people that led to the overall success of the project. I don't know the best way to do this but the simplest might be to have a list of projects that you are a major or minor contributor to. You might be regarded as a minor contributor for any packages which you submit any meaningful code (some bug fix or new feature) while being a major contributor might be an acknowledgement from the package owner. In my mind a package may have a field for major contributors and the package owner could curate that list and link to other users.
  5. 1 point
    In general you are working here with non released, non documented features in LabVIEW. You should read the Rusty Nails in Attics thread sometimes. Basically LabVIEW has various areas that are like an attic. There exist experimental parts, non finished features and other things in LabVIEW that were never meant for public consumptions, either because they are not finished and tested, an aborted experiment or a quick and dirty hack for a tool required for NI internal use. There are ways to access some of them, and the means to it have been published many times. NI does not forbid anyone to use them although they do not advertize it. Their stance with them is: If you want to use it, then do but don't come to us screaming because you stepped on a rusty nail in that attic! The fact that the node has a dirty brown header is one indication that it is a dirty feature.
  6. 1 point
    So I'm upgrading from LV2016 to LV2019. Or attempting to, anyway. I have to use the offline version, and it keeps bailing at something like "ni-opc-support", and giving me a very unhelpful, "check your internet connection" message. Hello, this is supposed to be an offline installation?!? My other complaint is that I've installed every version of LV since 2.5 in a "LabVIEW" folder -- no version number added -- and I can't figure out how to make the NI Package Manager let me do that. So I've ended up with 3 or 4 different LabVIEWxxxx directories (depending on how far things get before the install crashes). And if I completely uninstall all NI software, NI Package Manger still thinks it's installed and won't reinstall, but since it's not really there, there's no way to fix it. I'm on my third hard drive copy. Hmm. Sorry, I didn't mean to turn this into a b!tch session. 🙄 My question is whether or not I should uninstall just LabVIEW 2016 (leave everything else on there) before attempting to upgrade? I'm not sure how much I have to take off to get a "clean" enough install, but not too "clean". If that's even the problem. And on a "funny" note, I just saw that LV2019 SP1 was released last week (I've been using 2019 f1). I'm downloading the offline version at the moment. My screaming fast work network is telling me I only have 3 days until the download is complete... Cat
  7. 1 point
    It really depends on what you are trying to do so I get that. For me even just setting the VI file to read-only would be enough, but I ran into a few times when a mass compile would want to overwrite the VI despite it having separate compile code, but that was years ago. For me the purpose was that a developer would be drilling into the code and not realize they were in a reuse function and would start messing around with it and changing things that will now make the program behave differently on one developers machine, than the others. A gentle reminder to not mess with something was all we needed. But I get your points.
  8. 1 point
    Files that don't have revisions don't need to be commited into the repository itself. GitHub has a nice feature called GitHub Releases which lets you host "release files" -- it's designed for installers/packages/binaries, but you're free to store other files there too. Each Release is linked to a tag/commit in your Git repo so you know which version of your code was used to generate the installer. Here's an example of some releases from an NI repo: https://github.com/ni/niveristand-scan-engine-ethercat-custom-device/releases/ BitBucket has a lightweight variant of this called BitBucket Downloads (the link is somewhat tangential, but it's the best I could find). I like GitHub's release file hosting more than BitBucket's, but I like BitBucket's issue tracker more than GitHub's.
  9. 1 point
    What's the reason for moving to Github? I was using Kiln to host my code, which used Mercurial. I switched to Bitbucket with Git. I had to migrate many projects from Mercurial to Git. I did the migration using the HG-GIT extension: https://hg-git.github.io The main problem I encountered was using the "large files" Mercurial extension. The automatic import tools provided by GitHub and others don't like that extension and barf. Otherwise you can use the web migration tool provided by GitHub. My workaround to the large files problem was to accept the fact that I will lose the revision history on those files. Not a huge deal, since most large files I had were installers and binaries that didn't have revisions per say. So after the migration I did a diff on the project folder, identified the large files, which were missing from the new Git project and just copied them over and pushed them up to the Git repo. Don't forget that the core GIT functionality is the same regardless of service provider. So let's say you found a way to import your repo to GitHub, you can easily turn-around and move it to GitLab, bitbucket or whatever. You're not locked-in. But it might be an issue if you are using an extension that only one service provider supports. The future is GIT. I made the jump over a year ago and haven't looked back. The service provider you choose should give you the tools you need to do your job. The reason I picked Bitbucket was because I liked and used all the other products that Atlassian provides, JIRA, Confluence etc. The tools from Github are a bit weak for my business. I also like companies that continuously improve and invest in their products, among other things. Github seems to be the popular choice for open-source, since that's how it got started. Now that Microsoft owns them, perhaps they don't have to worry about generating revenue (don't know if it's good or bad). But I don't see features that compare to what Atlassian offers.
  10. 1 point
    As a package creator I would like to be able to see how many people have downloaded my package.
  11. 1 point
    KJK@GPower reports on the NI Forums (link unavailable without tech preview, but posting here because largely unrelated to tech preview and so perhaps not covered by non-disclosure?) that: "I know that the GCentral will be the place to go for finding reuse code what I'm not sure about is if there will be an active forum where [users] can get help and support from the G-Community." So perhaps: As a user of GCentral, I (might, if I were KJK@GPower, or the person they responded to) want to discuss using a package with the creator of that package (and/or other users) via a discussion page or forum system.
  12. 1 point
    Relating to this, as a developer who might use open source code, I would like to be able to avoid installing (potentially obscure) test frameworks and similar to test code that I for whatever reason (author, company, etc) implicitly trust. I suspect this has a lot more to do with the packaging chosen though, and may not be easily manipulated by GCentral...
  13. 1 point
    Add SuperSecretListboxStuff=True to your labview.ini , reload LabVIEW new menu items will show up when you right click on MLC control. Read this thread
  14. 1 point
    Obligatory Bobby Tables reference
  15. 1 point

    Version 1.0.0.0

    848 downloads

    There it is... finaly... Because the code given in the FTDI web page is not convenient, not working and haven't been developed by real LABview programmer, I decided to create a library for the I2C. a version for SPI will come soon. This library is free to use. If FTDI want's it in ther site, I do not allow you to publish it since you didn't help any of your customer with LABview. but of course feel free to publish this link.
  16. 1 point
    I have created a new package with an updated version of the OpenG ZIP library. The VI interface should have remained the same with the previous versions. The bigger changes are under the hood. I updated the C code for the shared library to use the latest zlib sources version 1.2.8 and made a few other changes to the way the refnums are handled in order to support 64 bit targets. Another significant change is the added support for NI Realtime Targets. This was already sort of present for Pharlap and VxWorks targets but in this version all current NI Realtime targets should be supported. When the OpenG package is installed to a LabVIEW 32 bit for Windows installation, an additional setup program is started during the installation to copy the shared libraries for the different targets to the realtime image folder. This setup will normally cause a password prompt for an administrative account even if the current account already has local administrator rights, although in that case it may be just a prompt if you really want to allow the program to make changes to the system, without requiring a password. This setup program is only started when the target is a 32 bit LabVIEW installation since so far only 32 bit LabVIEW supports realtime development. After the installation has finished it should be possible to go in MAX to the actual target and select to install new software. Select the option "Custom software installation" and in the resulting utility find "OpenG ZIP Tools 4.1.0" and let it install the necessary shared library to your target. This is a prelimenary package and I have not been able to test everything. What should work: Development System: LabVIEW for Windows 32 bit and 64 Bit, LabVIEW for Linux 32 Bit and 64 Bit Realtime Target: NI Pharlap ETS, NI VxWorks and NI Linux Realtime targets From these I haven't been able to test the Linux 64 Bit at all, as well as the NI Pharlap and NI Linux RT for x86 (cRIO 903x) targets If you happen to install it on any of these systems I would be glad if you could report any success. If there are any problems I would like to hear them too. Todo: In a following version I want to try to add support for character translation of filenames and comments inside the archive if they contain other characters than the ASCII 7 bit characters. Currently characters outside that range are all getting messed up. Edit (4/10/2015): Replaced package with B2 revision which fixes a bug in the installation files for the cRIO-903x targets. oglib_lvzip-4.1.0-b2.ogp


×
×
  • Create New...

Important Information

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