Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 01/22/2024 in all areas

  1. Good Read here, a bit depressing https://nihistory.com/nis-commitment-to-labview/
    4 points
  2. After making someone's day on the NI forums last fall for yet another CRC variation, I decided to go look for a fully-implemented LabVIEW reuse library I could just link to for the next such request. I really couldn't find one. Hence, the attached. It's intended to be a user.lib reuse library (although the attached zip includes a small demo project with a test VI). There's really only about two genuine VIs in the library, both are malleable to adapt to the poly/init integer sizes. One is the CRC computation VIM and the other is a lookup table builder; you have the option of pay-as-you-go (eight shifts/tests and conditional XORs, aka "brute force"), or you can take the computational hit upfront once and build a lookup table. Outputs are tested correct for the lengthy list of "well-known" CRCs (included in the library as some handy typedef'd cluster constants), when tested against some reputable online calculators. What is NOT done: I haven't made any serious attempts at benchmarking performance, brute force vs. lookup table. I'd be happy to have the LAVA community beat this up and suggest improvements in: speed, code elegance, style, whatever. Dave CRC.zip
    3 points
  3. Here is some info on what changes there are in the new release. https://www.ni.com/docs/en-US/bundle/upgrading-labview/page/labview-2024q1-changes.html This is not the major release of the year so there isn't too much to talk about. As for fixing the build issue I wouldn't hold your breath. I've already seen someone mention that the build for an lvlibp failed with error 1502. Cannot save a bad VI without its block diagram. But turning on debugging allowed it to build properly.
    2 points
  4. There is an App Builder API which will allow you to accomplish this task, but it is not officially supported by NI. The VIs are in [LabVIEW 20xx]\vi.lib\AppBuilder\AB_API, and there is an examples subfolder there with a few examples that should help you get started.
    2 points
  5. I date back from the pica.army.mil email list but never used Usenet. I am so not anonymous that I had a bunch of members of that mailing list drop by in one of my old labs say hi and gift me with a NI screw driver (this was back in the day where NI was gifting their users with goodies and trying to cultivate their relations with universities, just to give an idea of how far back I am talking about). I was already pestering about LabVIEW shortcomings (to my defense, that was pre-undo). Nothing changes...
    1 point
  6. Sure: https://github.com/RolfKal/openg-lvzip
    1 point
  7. Thanks for the question. A Post-Processing VI may be used on LV 2012 or later in the Application Builder. In this case, the Developer uses the Post-Processing VI to copy over the installed Run-Time Engine (or any other installed Framework) to the Application.app so that it can run without the need to install separately the same version of RTE (or any other installed Framework) on the client's i386, x86_64, or arm64 hardware. Despite NI not providing an installer for the macOS LV, there is a pathway to create an application that "stands alone", i.e., that binary is self-sufficient. Obviously, you can use Packages, Nix, RPM Package Manager, Jamf, etc. to create an installer. However, it turns out that you can handle most of these issues inside LV itself. As for Apple Silicon (arm64) native LV (2023 Q3), it is also possible to create a standalone application. I finally got this to work early this morning and will post it on the the link above after doing some testing. What this means is we can send zipped application files out to anyone who has macOS hardware and they will work as standalone apps. Macophiles don't like installing "drivers" in the sense of heading over to https://www.ni.com/en/support/downloads/software-products/download.labview.html#443308 . My concern is that NI is pulling LV for macOS in March after 40 years and that Apple may drop Rosetta 2 at some point in the future. At least, LV "development" can continue on the macOS side on both x86_64 and arm64 for the foreseeable future for those who own permanent licenses. NB: macOS LV development is limited by drivers, especially for the arm64 native LV (2023 Q3). Native LV (2023 Q3) is fast on the newer M1 & M2 processors, but doesn't have drivers for NI hardware because of the challenges in developing for Apple's latest derivation of the Darwin kernel. Many of us, hope the Emerson will see the benefit and open source LV. Until then, the installed base will keep coding in G as is. BTW, for a 2021 LV application and the 2021 RTE, it should run on Catalina. As above, you could build a standalone app and test it on a Catalina VM.... Install Runtime Engine 2012 NIVerified.vi
    1 point
  8. 1 point
  9. You can NOT install LabVIEW RT on non-NI hardware without a license from NI! And they have so far hesitated or stalled to say if they ever plan to sell such a license. What you can do is install NI Linux RT on whatever hardware you care since the Linux kernel is GPL software. And that is also what the NI Github repository is about. To provide a means to fulfill the GPL requirement to have the source code to the GPL covered software accessible to any user. What the NI Linux RT Github repository does NOT contain are the LabVIEW RT runtime kernel , NI-VISA, NI-DAQmx, NI-this and NI-that since they are closed source software and the Linux kernel comes with a special GPL clause that allows people to build and distribute closed source software that runs on it. Quite some kernel folks would love to get rid of that clause and force everybody to open source everything everywhere, but that didn't even fully work for kernel drivers, where they did a lot of effort to prevent closed source drivers from being able to do high performance operations. The big point here is that NI Linux RT is NOT LabVIEW RT. The whole LabVIEW RT runtime and NI driver stack are closed source and you can not install it on random hardware without an according agreement from NI. If you install NI Linux RT on your Jetson hardware, what you basically get is a somewhat expensive Raspberry Pi or Beaglebone Black board with additional soft RT capabilities but no LabVIEW target support at all! And no, the LabVIEW Hobbyist Toolkit can't be easily repurposed to run with such a hardware either. It's support is limited to ARM Cortex A hardware platforms and you may be able to get the according schroot image installed and running on the Jetson, but that is an entirely different thing than getting NI Linux RT installed on the Jetson. It is legally questionable but maybe you could get away with it, but it is technically quite a suboptimal solution as the schroot environment in which the LabVIEW RT kernel is running is a limited non-RT capable virtual machine running on the normal Linux host on your Jetson.
    1 point
  10. Hello All, I am trying to apply some principles to dynamically theme a UI in LabVIEW a la Google Material (https://m3.material.io/). I have created a theme class to define the different color schemes for the different situations (light mode, dark mode, whatever else) after loaded from a file. I am getting things to work pretty well overall EXCEPT I cannot find a good way to change the following colors: Listbox: border (the blue box surrounding the two listboxes shown in the screenshot) MulticolumnListbox: border (gray in the screenshots so not too big of a deal) MulticolumnListbox: horizontal lines (cannot see anything that implies dynamic coloring for this) I will go ahead and attach the VI but I doubt it will be very useful for figuring this out - all the coloring will happen via another VI. I just need to figure out the properties to make this happen. Or to be gently let down by telling me it isn't possible for those items and I have to figure out a work around........ side note, this is not where things will actually be put on the screen, so don't get bogged down in that weird detail test vi to theme.vi
    1 point
  11. There are some computer vision libraries out there (OpenCV, Emgu, AForge etc.) that make capturing a camera feed easy.
    1 point
  12. I had issues with 2023Q3 64/32 build , that would just crash when a build started. Turns out when deleting a file the project still had the file list (missing item) probably project file wasn't saved after removing the file , ... Once I removed the missing item from the project , in this case the missing was in the main tree not the dependency or in memory section. Anyway, maybe this would help, took me a minute to find it because in my case mass compilation also crashed LabVIEW.
    1 point
  13. I threw this together, and maybe someone will find it useful. I needed to be able to interact with cmd.exe a bit more than the native system exec.vi primitive offers. I used .NET to get the job done. Some notable capabilities: - User can see standard output and standard error in real-time - User can write a command to standard input - User can query if the process has completed - User can abort the process by sending a ctrl-C command Aborting the process was the trickiest part. I found a solution at the following article: http://stanislavs.org/stopping-command-line-applications-programatically-with-ctrl-c-events-from-net/#comment-2880 The ping demo illustrates this capability. In order to abort ping.exe from the command-line, the user needs to send a ctrl-c command. We achieve this by invoking KERNEL32 to attach a console to the process ID and then sending a ctrl-C command to the process. This is a clean solution that safely aborts ping.exe. The best part about this solution is that it doesn't require for any console prompts to be visible. An alternate solution was to start the cmd.exe process with a visible window, and then to issue a MainWindowClose command, but this required for a window to be visible. I put this code together to allow for me to better interact with HandbrakeCLI and FFMPEG. Enjoi NET_Proc.zip
    1 point
  14. Totally anecdotal and not fully verified and may not be relevant to you but I have had to abandon development of a couple of VIM's in 2023 since I have started using it. Just did not want to compile. If I converted to a standard instance (Can't remember the exact wording of that menu item) it would be fine but as a vim I just have broken run arrows everywhere. I am wondering if they have changed something in 2023 regarding vim's.
    1 point
  15. We've been on 2022 Q3 64-bit for Windows and RT applications for a little over a year. Both the RT and Windows builds fail, but RT way more frequently. I try tracking down the offending VI, I try renaming classes back and forth, I've tried checkbox roulette in the build settings, and I've tried changing the private class data. The only thing that consistently works, is clearing the compile cache over and over until it builds. Then usually running from source fails to deploy and I clear it over and over until that works, which usually breaks the build again. My failure mode is different in that I don't see it hanging on initializing build. All that being said I'm glad to leave 32 bit behind.
    1 point
  16. There have been a couple of patches released for LV 2023 Q3 that you can install from NIPM that fix (among other things) some App Builder issues. If y'all install those patches and still see issues, I know that LV 2024 Q1 is releasing shortly, which also includes some App Builder fixes. Additionally, if y'all are able to share code, feel free to PM me and I can get Bugs filed to R&D for build issues that we can reproduce in-house.
    1 point
  17. Well this is timely. We upgraded to 2023 Q3 64-bit a couple months back. No major issues at the time, even transitioning to 64-bit and programming RT. However for the last several days I have RT builds that proceed successfully but simply will not execute on the target. These were already built and deployed after the transition just fine, but now after minor changes it refuses to build something that will run. It's certainly possible I have a problem in the code or whatnot, but your post popped up on day 3 of me fighting this so I figured I'd chime in.
    1 point
  18. @Rolf Kalbermatter I know you did not mean this, but I love it!
    1 point
  19. You are right, frameworks do have significant learning curves. Still, if a framework can (potentially) satisfy your needs, even if it looks very complex, you shouldn't be afraid to take a closer look. You can probably filter out most of the frameworks by reading the readme. No need to learn and compare all of them (unless you are scientifically interested of course 😉). Very interesting, thanks for sharing! Among other things, he lists quite a few frameworks, some of which haven't been mentioned yet (see timestamp 19:32). I couldn't find the slides, so here is my attempt to restore the links: Composed System STREAM (bitbucket) Dave Snyder Lap Dog API (GitHub) Delacor DQMH (product page) James Powell Messenger Library (bitbucket) JKI State Machine Object (built on JKI State Machine) (GitHub) Mark Balla Message Routing Architecture (LAVA) NI Actor Framework (part of LabVIEW) NI Distributed Control and Automation Framework (DCAF) (product page) S5 ALOHA Application Framework (product page) Event Source Actor Package (NI forums)
    1 point
  20. 2,911 downloads

    Copyright © 2007, GTech Automation All rights reserved. Author: Dave A. Graybeal --see readme text for contact information Instructions: This code has been tested to run under LabVIEW 8.2.1. Unzip the code into any folder of your choice and open the example called, GetRefExample.vi. This shows how to use the 'Get Reference To All Controls.vi' as well as the 'Get Control Reference by Name.vi' to obtain a reference to all controls and how to search thru those reference to obtain the reference you want. Features: Get Reference to All Controls.vi -Gets the references and labels to All the controls on the front panel of the calling VI. -Is Able to search thru all Tab Controls recursively to compile a complete list of Controls from the front panel. Get Control Reference by Name.vi -Polymorphic VI that allows for searching list for single reference or an array of references. -Gets a Specific Reference from the List of All Controls by Control Name(Label). Get Control References By Match Pattern.vi -Gets an Array of References for all Controls containing the regular expression in the label. Change Log: 1.0.0: Initial release of the code. 1.1.0: Changed the Class ID of a Tab Control from a constant to a Property Node (To support Future LabVIEW Releases) 1.2.0: Added Get Control References By Match Pattern.vi (Authored By: Justin Goeres) Thanks! Modified GetRefExample to Include the Get Control References By Match Pattern.vi Improved some performace by removing unnecessary Items from Loops (Thanks JFM!) Removed all Dialog boxes from VI's and replaced them with proper error output messages. Added shift registers where necessary to ensure proper error is passed out of each VI. Recompiled under LabVIEW 8.2.1.
    1 point
×
×
  • Create New...

Important Information

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