crossrulz

Crosspost on the darkside: https://forums.ni.com/t5/LabVIEW/connect-LabVIEW-USB-or-LAN/m-p/4309342

The announcement for the acquisition did happen in early April.  Now it is just waiting for approval by the US government and who knows what other legal red tape for it to actually happen.  One of the articles mentioned the acquisition finalization was expected to be in Emerson's financial 2024 H1, which starts in October.  Do not expect to hear anything until that happens.

1 hour ago, Neil Pate said:

I exclusively use the bundle/unbundle, unless I am not able to for example if accessing a field in a parent class.

I tend to also follow this concept.  And, often, the accessors will be set to "Protected" so that only children classes can use them.

1 hour ago, hooovahh said:

I heard that using a property node forces a switch to the UI thread, and it wasn't clear to me if that wasn't the case for class data or not, so I just avoid them if I can.

It does not apply to classes.  In fact, the UI thread is only used in property nodes that somehow reference a front panel or something on a front panel (ex controls/indicators).  VISA property nodes, for instance, do not use the UI thread.

The downside to me for the property node for accessing private data in a class is that you have to have an accessor VI to do so.  You do not need the accessor VI if you are using the bundle/unbundle by name.

4 hours ago, HYH said:

Mentioning the new fuse name, made me find this sad list :

We've known the MathScript was EOL for quite a while now.  So that one is not surprising to me.  The Control Design & Simulation Module is a bit of a shock to me (not that I know anybody that uses it).

But the renaming of the NXG controls is interesting.  If you follow that link in the description, it will eventually lead to a github repository.  Perhaps they are now open-source?

4 hours ago, hooovahh said:

This idea was implemented. 

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Same-Height-of-Unbundle-by-Name-Terminal-Local-Variable/idi-p/1298608

Opening existing code will create bends in wires where there weren't any before.

This will only affect you if you use custom fonts.  If using the default since Windows 7, you will see no change.  Neil was using fonts to match XP.

That's unsettling.  When my current project is done, I was planning to upgrade to 2023Q1 64-bit (currently using 2019SP1 32-bit).  Apparently, I will have to put more scrutiny in my evaluation first. 

18 minutes ago, hooovahh said:

Thanks, that's it.  I couldn't find it because I was searching for Completed ideas, but apparently it was declined.

But yet technically completed with the Stall Data Flow.vim that was released in 2017 along with a bunch of other malleable VIs.

3 hours ago, hooovahh said:

I do love how VIMs came to be.  I'm having a real hard time finding it.  But there was an idea on the Idea Exchange that there should be a function that can delay any data type, similar to the OpenG Wait which takes an error in and passes it out.  Jeff K. posted on the thread saying something like "Oh yeah that is a thing, you just need to use a VIM, here is an example which uses XNodes."  It blew my mind.  Then in the next release of LabVIEW for the Mac, Jeff K. sneaked in a new VIM on the palette which some high up in R&D didn't know, which had the type specialized structure in it, which was also unreleased.  I downloaded that version just to get the VIM and structure.

Here's the starting point: Wait (ms) with error pass-through

From what I remember at CLA Summits, this was unofficial up to 2016 (called a "macro" at this point in time).  But the cat was waaaaaaaaaaay out of the bag, so NI spent time to make it a proper feature and malleable VIs started in 2017.  The Type Specialization Structure was not quite ready for prime time for another year (2018).

Keysight buying NI would be monopolistic (2 of the biggest T&M companies merging).  Not likely to happen, but I could see Keysight buying Digilent (an NI company) and Emerson buying the rest of NI.  I'm not familiar with Fortive, so I may have to look into them.

But sale by early April?!  At least its not far from now.

Edit:  Fortive owns Fluke and Tektronix.  Them buying NI would be interesting as well.  Would the parent company force NI and Tek to work together on a PXI scope again?

I might have a couple of classes floating around that hit 4 levels deep.  I would say well over 90% have 1 or 2 levels, so I voted based on the large majority.

Running the code in 2022 Q3 shows the same result.  Very interesting.  Though, I very rarely have to use Type Cast.  Flatten To String and Unflatten From String do all of the conversion I tend to run into.

2 hours ago, X___ said:

I've got to ask: what is the second oldest?

Prostitution.  Adam was a farmer.

Mark Balla and Kevin Shirey managed to record a bunch of the sessions.  Links are available on LabVIEW Wiki. https://labviewwiki.org/wiki/NI_Connect_2022

The NI videos Dataflow_G links to is from the the opening keynote.

I actually found COVID helped me renew since so many user groups went virtual.  I was attending user group meetings from Europe, Texas, Michigan, etc.  Those points added up really quickly.

33 minutes ago, Rolf Kalbermatter said:

Definitely agree that it should have been done like that many moons ago already. But it was in a way maybe easier to do it like that as there was limited testing needed and maybe there was also a bit of an intention behind it as if you wanted to use new hardware you had to install the new driver and that made also a new IDE version necessary if the previous one was to old. So a bit of a hidden upgrade nudge. Now with the new NI structure where the different software departments are very much decoupled and independent from each other it proved to be an unmanageable modus operandi. It's not feasible anymore to have to pester DAQmx (and cRIO and System Control and, and, and) folks to release a new version of their software simply because there is a new LabVIEW version.

In my opinion, part of the issue was getting confidence in the "separate from compiled" feature.  I would have to dig into some history to figure out when NI started using it for vi.lib.  But shortly after that, it would make a lot of sense to push this in the drivers.  So if you really want to play the hindsight game here, it is something that should have been feasible around 5 years ago.  But NI was putting all of its marbles into NGX at that time.

Regardless, I am happy about this feature and I look forward to being able to avoid updating drivers purely for the "new LabVIEW version support" and no other changes.

We got some more clarification on the "decoupling driver versions" on the public beta forum: https://forums.ni.com/t5/LabVIEW-2022-Public-Beta/LabVIEW-2022-Beta-New-Features/m-p/4234011#M49

In short, there will be a new common location that the driver will install the LabVIEW Support to and LabVIEW will look there.  They will depend on the "Separate From Compiled" to allow the VIs to be used by multiple versions of LabVIEW.

A new hardware platform called TestScale sounds interesting.  Unfortunately, NI's web site has no information on it yet.

9 minutes ago, LogMAN said:

You need an active subscription to download previous versions. This has been the case for many years.

Yeah, but this is still a major support hole.

4 hours ago, Rolf Kalbermatter said:

T&M was good for a steady revenue, but nothing that would stand out on the yearly shareholders report. It was unsexy for non-technicals and rather boring. That was one of the big reasons to separate HP into multiple companies. An attempt to create smaller entities that target a specific market segment and could be fine tuned in the sales and marketing efforts to the needs of that market.

HP spun off the T&M into Agilent, who grew into the Life Sciences industry.  Agilent then spun off the T&M into Keysight.

Personally, I'm expecting NI to spin off the T&M part of their business into a new company in the next 5-10 years.  Whether or not LabVIEW is part of that, I have no clue.

Your DAQ sample rate is 1 second.  So you need to make sure you are pulling off the data at least at that rate.

1. Again, change your Timed Loop to a normal While Loop.  It is hurting you more than helping.

2. Change your DAQmx Read to be N Channel 1 Sample.  This will simplify things a little as you will no longer need the 5 functions just to get a single value out.  You will just need to use Index Array (expand to 2 elements so you can get both channels).

3. You need to clear the task once the loop is done.

No call for presentations.  It will be all NI.

1. Change your Timed Loop to a simple While Loop.  The DAQmx Task will limit the loop rate.

2. Don't use the DAQ Assistant.  Learn to use the actual DAQmx API.  You will make things a lot more efficient.

Well, that explains what I encountered today as well.  I did notice an extra character.  I didn't investigate beyond that.  Hopefully this will be fixed quickly in a patch.

crosspost on the dark side: https://forums.ni.com/t5/LabVIEW/Application-recovery/m-p/4213987