LogMAN

57 minutes ago, Jim Kring said:

Sorry about that @LogMAN. It should be publicly visible now.

Please try again and let me know:

VIPM KnowledgeBase: Disabling VIPM service (System Tray) startup when LabVIEW starts up

11 hours ago, Jim Kring said:

I've gone ahead and posted an official KnowledgeBase entry to make sure people can find this easily, in case the high-level features don't provide enough granularity.

VIPM KnowledgeBase: Disabling VIPM service (System Tray) startup when LabVIEW starts up

I am not authorized to access this page. Senpai? 😢

I do actually receive emails from LAVA.

8 hours ago, Mads said:

But then so does lots of the lvlib-stuff - seemingly disregarding that is destination is explicitly set to be the executable.

I've never seen this kind of behavior. Only support files like documents, shared libraries and the like are supposed to be placed outside the executable, but I presume you mean VIs. This is very strange.

43 minutes ago, Jim Kring said:

Actually, nothing changed with how VIPM installs itself 2020, as compared to 2019 (and older versions). The issue was that the the VIPM 2020.0 (and older) installer framework (e.g. Advanced Installer) needed to be updated for newer versions of Windows.  In VIPM 2020.1 (now in beta -- see link above) we've addressed this issue and it should install without issues.

That said, there were some bugs in NI's LabVIEW 2020 installer that causes it to fail to correctly install VIPM 2020, in some cases -- e.g. the issue where it sometimes would fail to start. NI has been working with JKI to fix this.

Wow, this is good news! I'll give it a try.

46 minutes ago, Jim Kring said:

Any feedback/issues you have are important, so please do post them and know we're listening. It's hard to keep tabs on conversations that happen in various LAVA threads, so if you'd like to see something improved/resolved, please do post it in the VIPM forum or PM me.

Point taken, I was going to post on the VIPM forum but then this thread happened and I couldn't resist...

48 minutes ago, Jim Kring said:

This can be disabled in the VIPM settings file, here:

"C:\ProgramData\JKI\VIPM\Settings.ini"

You can also disable the VIPM Service in the Task Manager under Startup. That said, I would like this to be opt-in or at least opt-out. Maybe on first start or during installation.

4 hours ago, Mads said:

build insists on putting the support functions as separate files together with the plugin

You can specify a destination on the Source File Settings page of your build specification. The default is "Same as caller". I assume your plugin is set to a custom destination, but your support files aren't, so they are put in the same folder as the caller.

If you explicitly set the destination for your support files to the application executable, it will place them inside the executable.

9 hours ago, Michael Aivaliotis said:

I tried VIPM2020. It was buggy for me. I also didn't like the new login "feature" and the notification taskbar malware. So I reverted to VIPM2019.

I agree, that feature should be opt-in and the logins are a bad joke. Also, the installer creates a task for the Task Scheduler without consent. This is prevented by our IT policies and ultimately fails the installation - silently for NIPM and with an error message for the offline installer.

VIPM 2019 it is 👍

49 minutes ago, X___ said:

Be so kind as to distill the substance of it in a post here.

• About 35 minutes of people talking about how awesome everybody is (for some reason nobody mentioned me 😢).
• At 35:30 they finally address the new design.
• At 44:00 they talk about a six year commitment for the new roboRIO controller (whatever that is) for the FIRST robotics competition, financial support for students, equality and inclusion - quite important messages these days.
• At 45:56 they announce a campaign to "put a lens on 100 game-changing breakthroughs" (collected via Twitter). They will post the best ones here (one per week).
• The last 5 minutes are NI employees from all over the globe.

Pretty much what you would expect from marketing material 🤷‍♂️

The new design probably makes green-screen capture easier.

So that just happened

I think it's time for me to watch the livestream footage.

8 hours ago, Aristos Queue said:

I liked it in theory, but I'm seeing a bunch of warnings online about Stylish having become malware that is shipping private information to third-party. You might want to investigate.

Thanks for the heads-up. I actually limited access to *.ni.com, specifically, so I should be fine.

I would like to end the day with positive (and hopefully constructive) feedback, so here is a list of pros on the new design:

• All the old links still work
• Broken pages (that I knew of) are fixed
• The top navigation bar takes less space (148px to 97px), which gives a bit more space to the page content
• Mobile view works much better than before, at least for general navigation (most of the content didn't change as far as I can tell)
• All the text in header and footer is bigger than before, which makes it much more readable, especially on higher resolution and smaller screens (not zoomed)
• It "feels" slightly faster than before. Not sure if it's me imagining things, but the site seems more responsive than before (perhaps they improved on lazy loading?)

This is certainly something I can get used to (not that I have a choice anyway). However, I strongly suggest to use a different color palette for content pages. Dark green links, different shades of gray, and black text are almost indistinguishable and look very dull. Please give me some eye candy 😢

Other than that, I'm quite okay with most of the changes.

8 minutes ago, Mads said:

If I have to say one positive thing about the new look its that the color palette is probably very very rare....

Well, they probably didn't find the slider for color and thus decided to fix it later (or their monitors have much higher contrast than mine). For now I have installed Stylish to fix my links. Imagine if this was the default 😊

Here is one possible solution. So much fun!

Here is a trivial task for you. Find the links:

1 hour ago, ensegre said:

But uh, that is the help page for 8.2.

It's now updated to https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/customizing_your_work_environment/#How_LabVIEW_Stores_Option

Don't hesitate to update the Wiki if the information is outdated.

8 hours ago, Michael Aivaliotis said:

So NI pushed out their new logo and website. What do you think?

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...

2 hours ago, drjdpowell said:

That's more of a Source-Code-Control issue than multiple LabVIEW projects using common code. I have clients where there are multiple projects using common code, but all code is under a single repo.

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.

3 hours ago, drjdpowell said:

I'm not sure yet about NXG changes here.  I have basically two types of reuse.  VIPM packages developed usually on an earlier LabVIEW version and used across many projects at many customers (with the main ones being on the Tools Network), and customer common code shared by different sub-projects for a single customer.

I wonder how NXG handles nested projects...

21 hours ago, hooovahh said:

I personally don't think I've shared code between projects for anything real project anytime recently.  But I can remember times that I did it and didn't have any real problem.  Likely because I was mindful of what effected what.

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.

22 hours ago, Fra_Sabba said:

In a Windows system I would like to open a VI, modify it and finally compile it (only this VI) for a different target, for example Linux x64 (cRIO hw).

22 hours ago, Fra_Sabba said:

I'm wondering if the cross-compile functionality is provided with some function/method exposed.

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.

22 hours ago, Fra_Sabba said:

So LabVIEW can cross-compile a VI.

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

19 hours ago, Fra_Sabba said:

How I can compile programmatically the VI for the target Linux_x64 (cRIO hw)?

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 🤷‍♂️

5 minutes ago, Mefistotelis said:

Is there even a command line interface to LV?

There is: https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/cli_running_operations/

5 hours ago, Fra_Sabba said:

I'm looking for a way to run "LabVIEW.exe" hidden (I'm using LabVIEW 2018) , so without the splash screen and the starting window.

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.

10 hours ago, Neil Pate said:

Holy guacamole! When did this make it into vanilla LabVIEW? I have been using the OpenG one for so long now...  it is present in 2019 and not in 2015..

I noticed its opposite number is also now in, nice 🙂

They were added in 2019, actually. Can't live without them now 😊

7 hours ago, JKSH said:

I'm not sure why NI created new VIs instead of exposing the Hidden Gems ones.

7 hours ago, JKSH said:

Note also that the out-of-the-box version has fewer features:

• The Hidden Gems version allows you to Ignore Case
• The OpenG version allows you to Ignore Case AND Ignore Duplicate Delimiters

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.