LogMAN

Wait what? ... After a few minutes of browsing, I must say it will take time to get used to. Fortunately most of the things are roughly at the same place as before, so that's a plus. The site is obviously build with a mobile-first approach, which makes it slightly annoying to use for everyone else...

I never said there was an issue with using common code between projects. In fact, it makes no difference. Just to give you an idea of what I'm talking about, one of our old repositories has more than 200 individual projects in a single folder with a few hundred VIs and LLBs, most of which share code between each other! It is absolutely mental. My point is, our projects shouldn't have been structured that way in the first place and NXG makes it so much easier not to make the same mistake. I wonder how NXG handles nested projects...

Me too. In the early days (LV 6-7 era), it was common practice for us to share code between projects. The "smarter" ones of us even had dedicated directories for reuse code. As it turned out, this move was not so smart after all... Now we have older (and still active) projects that are missing entire LLBs, because they got lost when old computers were replaced by new ones. To this day we keep praying that nobody gets strange ideas about adding new features or (god forbid!) fix a "small bug" in those projects 😱 Nowadays (for the past ~10 years) any code is either part of the same repository or shared with packages (that are managed in their own dedicated repositories). This is one of the reasons I am very much in favor of how files are managed by NXG. Doing it manually has become a second nature, but is cumbersome and tiring at times. I would love to have that feature in CG 😍

Glad to hear you found a working solution. Looks simple enough to adjust to any version and bitness of LV. Not sure if this works, but it might be possible to run LabVIEW as a Windows service, which would make it entirely invisible. I'm thinking about NSSM or similar tools to turn the executable into a service. This would also allow LabVIEW to start during startup (i.e. after login) to have it up and running for CI jobs.

Move the VI to a cRIO target in your project (there is probably a way to do that with scripting somehow). The compiler will take care of the rest. Yes, you can compile VIs for very specific targets like cRIO because it is a well defined environment. However, it is not possible to cross-compile applications between Windows, Linux and MacOS if that is what you want: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P81NSAS

Anything under My Computer is compiled for the platform you are currently on. For your cRIO I think you need to have it as a target in the project first. Then you can deploy your VI to it. http://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/adding_targets_to_project/ Not that I have ever done this 🤷‍♂️

There is: https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/cli_running_operations/ What are you trying to achieve? To my knowledge there is no built-in way to avoid the splash screen. You can, however, skip the Getting Started window by enabling Skip Getting Started window on launch under Tools > Options > Environment. LabVIEW will then always create an empty VI on startup. Not sure if that is what you want.

They were added in 2019, actually. Can't live without them now 😊 Indeed, these features are very useful for corner cases. For the general case, however, I would argue that the cost (slower performance, higher complexity) probably outweighs the benefits (haven't tested it). Still, the Hidden Gems version allows you to specify a pattern, which makes it extremely flexible (not sure about the OpenG version).

I would do it in two steps 1. Discard protocol data (~00D and 037) - This is typically done when reading the data string anyway. 2. Split the payload using Delimited String to 1D String Array.vi.

Welcome to the jungle! New users wouldn't have to convert legacy code, so this is probably not an issue.

I don't know if there is any documentation for this, but a link points to a resource external to your project. You can create your own links by adding files that are not located in your project folder. It looks like your component is located on a shared network location? Maybe the conversion tool uses UNC paths and the project expects mapped paths? Maybe you can re-add those files to get it to work.

There might be a typo in @Bryan's example. The first byte should be 7E instead of 7F (based on the previous data). Still, this is guesswork at best and not much better than brute forcing every possible combination. You have proven that your code works, so this is a good time to talk with the supplier. Maybe they can provide you an example or verify that the data you are sending is correct.

In the article it says: "The ability to create modes and overloads isn’t publicly available in the newest version of LabVIEW NXG; however, we’re looking to extend these features to our user base soon."

Are you okay with people using your work and selling it as their own, perhaps making a lot of money with it? Do you want to be attributed for your work, if someone uses it in their project (or sell it as their own)? Are you okay with other people using your name to sell your work as their own? In my opinion BSD 3-Clause is a good choice if you want to be attributed without any liability or warranty. Look at SQLite Library and JSONtext for reference (they use BSD 2-Clause). Note that BSD 3-Clause is the same as BSD 2-Clause, but "with a 3rd clause that prohibits others from using the name of the project or its contributors to promote derived products without written consent." Unlicense puts your work into public domain, so there is no copyright holder. You also don't reserve any rights to your own work (anyone can do whatever with it). MIT is in some ways similar to BSD but without the need for attribution. It is a pretty popular choice though. DBAD and WTFPL need to be placed in every source file, because they apply to single files only. They also don't really address the issue. If an author didn't want anyone to sell their work as their own, they probably shouldn't place it under public domain in the first place. I'm always surprised by people who make their work open source or public domain and then complain if other people use it. What did they expect?

There is an option to mass-edit VI documentations in VIPM, although it's probably not the right tool. Maybe you can hack a solution. I don't recall if there is a function for this in the OpenG libraries, but they all have license notices and I would be surprised if they were edited by hand. There is a tool for that (of course): https://choosealicense.com/ If you don't want to accept contributions or issues for your repository, make it an archived (read-only) repository or put a notice in your readme file (anyone is free to fork and change it anyway). There is a blog post on how to do it on GitHub: https://github.blog/2017-11-08-archiving-repositories/ Vision is not my area of interest, so I wouldn't use it as a product, but I like to browse projects to learn about problem solving strategies and perhaps find a few nuggets. Don't worry about style or documentation, especially if it's a gift. I'm sure there are a few people on LAVA that are more than happy to get something new to fiddle with 🙂

Very strange. Ping looks fine. TTL=128 also indicates that the machines are on the same network, so packages should send fine. Are you able to copy large files between the systems with reasonable speed? Also, you can use Wireshark to monitor traffic between your machines. That way you can check if a package gets lost, resend or blocked by other data. In the past I had trouble with cheap NICs that weren't able to keep up with many small packages because of checksum offloading. This was particularly problematic on Windows 7 and seems to be fixed on Windows 10. You can try disabling it in your NIC settings. Note that there are multiple offload options.

@kronoseleven What is the ping between your clients? As @drjdpowell mentioned, 16.2 seconds is not normal. The no-delay function won't do much of a difference.

It works slightly better if you select the control first (the dots stay visible). Still, poor design choice. They actually don't work well on different zoom levels. Edit: How do you attach videos but not display them into a post (does it automatically for me)? This thing is freaking huge... NXG Resize Array Zoomed.mp4

Here are some of mine. SystemDesigner - Although it is essentially MAX and only works with NI hardware, I like the fact that it provides an overview of the hardware, access to various documents (pinout, specs) and the ability to create and test measurement tasks from within LabVIEW. Not to mention the auto-generated code when placing tasks into VIs. Captured Data - Finally I can easily capture, export and import data without having to write custom code. Capture data once and use it often. This is very useful for testing code in development and prevents misuse of "Make Current Values Default", which tends to bloat VIs. It is also possible to just drop data into any compatible control (i.e. graph) without any manual labor. Build Queue - It is somewhat broken, but I like the fact that it can build packages in parallel. There is great potential for much faster builds when compared to CG, especially for large an complex projects. Learning - I like the way NXG guides users through learning projects (of which there are quite a few). Highlighting elements in the UI is very helpful for self-paced learning. Online Help - Not specifically a feature of NXG, but I like the way the new manual is structured. The context help could use some improvement though. Controls and indicators - I like the design of NXG controls and indicators. They look much better than modern controls in CG, especially when used in combination with a Windows 10 theme. That said, I hope they add support for system controls soon. Automatic File Organization - This is probably number one or two of features in NXG I really like. Moving files inside a project now automatically moves files on disk. No more housekeeping. Still, I miss virtual folders a lot.

You probably got it from this KB article (also includes VIs for other platforms): https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019NZfSAM

If memory serves right, this is because LabVIEW does not take Windows themes into account. Essentially, the window drawn by LabVIEW gets surrounded by a border that is provided by Windows. You should see different results if you change your theme to one that has smaller or no borders. Also, Window Bounds does not include the window border. It is implicitly mentioned in the context help: "The four elements in the cluster are the top, left, bottom, and right values of the front panel window, which includes the interior region, scroll bars, title bar, menu bar, and toolbar." Your best bet is to use Window Bounds and subtract the border size manually. Unfortunately, it will break again if the user changes themes.

I think what you are looking for is this: I haven't tested it, but your VI should stay within the boundary of a single screen.

This is what happens when you change the UI scaling while NXG launches (because what else is there to do?) And icons can be a little frustrating at times... Icons make me happy.mp4

One thing I absolutely like about NXG is the fact that it goes to extreme levels for absolutely no reason. What could possibly go wrong? Yes, this is a single VI. NXG 4.0 has a terminal limit of 128x126x126x128. Yay, no more clusters