crossrulz

I am personally a fan of StarTech. I have not used their PCIe adapters, but their USB-RS232 adapters are really good. https://www.startech.com/en-us/cards-adapters/serial-cards-adapters?filter_bustype=pci%20express As far as working with MAX, they just need to be normal COM serial ports and VISA will do the rest.

It took me a bit of time to figure out CDS is LabVIEW Control Design and Simulation Module. Yeah, that kind of came out of nowhere, but it was really only used in academia as far as I am aware. MathScript was also dropped mostly due to it being a major PITA to maintain, especially since Matlab was such a better product to do something very similar. As soon as NI and Mathworks became friends, I saw this coming.

1. Move the VISA Configure Serial Port to before the loop. No need keep re-initializing it. 2. You shouldn't need the Flush Buffer. 3. You should not need the wait. This would also eliminate the need for the Sequence Structure 4. Since you are expecting a response immediately after you send the command (or soon after), you should not be checking the Bytes At Port. This would eliminate the need for the Case Structure. 5. Because of the termination character, tell the VISA Read to read more bytes than you expect back. In this case, I would probably use 50. The read will complete when the Line Feed is encountered. 6. Since you are dealing with space separated data, use the Spreadsheet String To Array with a space set as the delimiter to make an array of strings, each element corresponding to a piece of data. You can use Index Array if you really want them separated out.

Then, a couple of years later, NI completely redid how events work behind the scenes which corrected some things Jack mentioned, complete with an NI Week presentation.

I don't think VISA works with UDP. It will work with TCP. So you are going to have to use the UDP functions to communicate with this device.

If you can read the serial number from the device, then you can just use Format String to create the file name and then write to the file as you already are doing.

0x08 is a Backspace. In \ Codes, that is \b. A little more information on the \ Codes here: Backslash ('\') Codes Display LabVIEW Help

Wire a value into the shift register on the left side of the loop.

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.

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

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.

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?

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.

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

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.

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.

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.