Cat

Thanks all! I'm glad to hear there's a (slightly tarnished) silver lining in the dark cloud of this new paradigm. We have a ELA with NI for basically what used to be the Developer's Suite. I've finally figured out the concern about having to pay perpetually for a perpetual license is coming from our contracts people. Now I've got to convince them that they just have to pay for the first year of the service part and after that we don't need it. (and Shaun, I love retirement, but kids these days just don't know how to program like us old folks 🤣)

Hellooo? Anybody home? For those of you who don't remember (or weren't even born yet when I started posting here 😄), I work for the US Navy and use a whole bunch of LabVIEW code. We're being forced to "upgrade" to Windows 11, so figured we might as well bite the bullet and upgrade from LV2019 to LV2024 at the same time. And then the licensing debacle began... Due to our operating paradigm, we currently use a LV2019 permanent disconnected license for our software development. This was very straightforward back then. But not so much with LV2024 and the SaaS situation. Add to this the fact that I can't talk to NI directly and have to go thru our govt rep for any answers. And he and I are not communicating very well. I'm hoping someone here has an answer to what I think should be a really simple question: If I have a "perpetual" license with 1 year service duration for LabVIEW, at the end of that year, if I don't renew the service, can I still use LabVIEW like always, as if I still had my old permanent license? I realize I would not have any more support or upgrades, but that's fine. I've read thru the threads here and in the NI forum about this, but they mostly ended back when no one really knew how it was all going to shake out. So are we locked into either our ancient LV versions forever, or are we going to be paying Emerson/NI every year for something we don't really need? Cat

Thanks for the response. I hadn't thought of asking about LabVIEW courses. This position is actually more than "just" LabVIEW programming. It's the software part of a team that designs/develops/tests/fields data acquisition systems. So an engineering degree is helpful to being able to see the big picture. Or so the guy who does the hiring believes... I personally fit in the "lots of experience but no certification" slot. That's why I didn't think it would be necessary to require it. Plus it will make it harder to fill the position. If I go that route, having never taken the exam myself, I'm wondering if the group mind here thinks CLD would be good enough, or should it be CLA? Especially considering the person will have to be the "A"rchitect as well as the "D"eveloper.

Subtitle: Cat's continuing attempt to finally retire I retired from the gov't (US Navy) around August of 2019. Since the gov't is the gov't they didn't think about replacing me until after I retired. So being a good little civil servant I came back part time as a contractor to fill the gap. The basic requirements for my replacement were: 5+ years LV work, engineering degree, experience working with large data sets, experience working with large (2500+ vi) code sets, able to work independently (I have always been a team of 1). The gov't finally hired my replacement and they started work in January of 2021. It still being pandemic time, I didn't have a lot of face-to-face (or mask-to-mask) interaction with them, but I got more and more worried when I did. While they had a lot of fundamentals down, there were glaring gaps in their technical knowledge. They were more of a okay beginner programmer than the solid intermediate to expert level that we needed. And they had obviously only ever worked in a team where everything was spoon-fed to them and then someone cleaned up after them. They were let go. This person had 6 years of programming LabVIEW on their resume. But it was obviously 6 years of programming LV badly. Going forward, how do I not repeat this mistake? Should NI certification be required, and if so, is CLD good enough or should it be CLA? Any other suggestions? I really want to retire!! Cat

hooovahh -- what you're talking about is one of our options. Shaun -- we hunted around and those commands don't seem to be available on LinuxRT On top of the "standby" issue, after much back and forth with NI, we discovered that the system drive in the IC isn't removable. And it can't be encrypted. While we probably could have worked around the former, the latter is a show-stopper for our user. So, looks like we're ditching the NI "Industrial Controller" and going to someone else's "Industrial Computer". Plain jane Windows 10, 2 removeable drive slots, all of which will make life much easier. Not to mention we can buy 4 of them for the price of one IC-3173. 🙄 Thanks for the responses, guys!

Hi all (no, I'm not really retired yet, lol), My latest toy is an IC-3173. I need to be able to programmatically (LV, of course) put it into a reduced power state (analogous to Windows standby/hibernate/sleep). And then "wake it up" every hour for 10 minutes. I'm running LinuxRT. Does it even have a concept of standby/hibernate/sleep? Cat

So I'm upgrading from LV2016 to LV2019. Or attempting to, anyway. I have to use the offline version, and it keeps bailing at something like "ni-opc-support", and giving me a very unhelpful, "check your internet connection" message. Hello, this is supposed to be an offline installation?!? My other complaint is that I've installed every version of LV since 2.5 in a "LabVIEW" folder -- no version number added -- and I can't figure out how to make the NI Package Manager let me do that. So I've ended up with 3 or 4 different LabVIEWxxxx directories (depending on how far things get before the install crashes). And if I completely uninstall all NI software, NI Package Manger still thinks it's installed and won't reinstall, but since it's not really there, there's no way to fix it. I'm on my third hard drive copy. Hmm. Sorry, I didn't mean to turn this into a b!tch session. 🙄 My question is whether or not I should uninstall just LabVIEW 2016 (leave everything else on there) before attempting to upgrade? I'm not sure how much I have to take off to get a "clean" enough install, but not too "clean". If that's even the problem. And on a "funny" note, I just saw that LV2019 SP1 was released last week (I've been using 2019 f1). I'm downloading the offline version at the moment. My screaming fast work network is telling me I only have 3 days until the download is complete... Cat

We "upgraded" to Windows 10 version 1903 (from 1803 or 1809, I don't remember) and iperf3 went from ~450 MB/s to ~2 GB/s. Yay! Unfortunately, 1) the IA gods have not deemed 1903 worthy so we're not supposed to even have it installed, 2) there is question of whether this a fix, or something that will disappear in the next version, and 3) ironically, 1903 is causing issues with various types of hardware NICs (not a problem for us -- so far). But, for the moment, we've got something that works. Thanks to all for responses, and thanks to Gribo for suggesting iperf3. It's made it a lot easier to test network throughput. Cat

We could try running iperf, just to confirm it's the loopback adapter and not the code. But as I said, we've run the same code with 2 hardware NICs (10G) connected on the same computer and it works fine.

The point of the loopback adapter is to use TCP to communicates to pass data between two different executables ( one C and one LV) on the same machine. The machine has 2- 1G and 4- 10G physical network adapters. Can you explain more what you mean by "link could be fully local"?

We've set the loopback adapter the same way we've set up hardware NICs (at least as much as is applicable). I'll confirm that QOS and Nagle specifically have been dealt with. The C dev tried fastpath (even tho it was supposedly deprecated a while back) but that didn't help any. The computer has a very fast CPU. Two of them, actually. I guess the implication is that the hardware NICs are doing something the CPUs can't.

Hi all! Long time, no talk to. 🙂 I'm supposedly retired, but then decided to go over to the Dark Side and become a contractor. We'll see how long that lasts... Current issue: A C developer and I are sending data via a MS loopback adapter between a C app and a LV app on the same machine (Windows 10). Past iterations have worked great (after that little bug in LV11 was fixed). The new system, however, needs a much higher continuous data thruput -- somewhere in the neighborhood of 900 MB/s. The loopback adapter is topping out somewhere around 500MB/s. If we switch from internal TCP to connecting two 10G NICs in the same box, the data gets passed with no problem. So it's not the code, and we know how to configure hardware NICs for large data thruput. We've tried everything the web seems to offer, including a lot of things that have been supposedly deprecated. We've tried using localhost, 127.0.0.1, a 192.68 address, and various other IP addy options. If you google "how to speed up a loopback adapter" or any variant of that, we've probably tried it. Does anyone have experience with tweaking a loopback adapter and have any suggestions of things to try? If it matters, the computer is a screaming fast dual Xeon with 128 GB of memory. Cat

I use ini files. If I have complex data types, or large amounts of data required, the ini points to files where that data is stored. Also, LabVIEW annoyingly creates an ini file for every executable, so I figure I might as well use it. Cat

Crud. I replied to this, but it never showed up in the feed. Huh. Anyway, yes, I'm turning this over to one of our C folks to deal with. I'm not sure if I can get the .NET version past our Information Assurance zealots, but a regular old dll I can call with a CIN will be fine.

I just discovered that my latest needs-to-be-done-yesterday project requires communications via an Apache Qpid broker (v0.4 and AMQP 0-10). Since I didn't even know what AMQP was before yesterday, I'm a bit behind the curve on this. I have downloaded LabbitMQ, but I'm assuming that won't work with Apache Qpid? I was hoping that the whole open standard thing meant that different implementations of AMQP should be able to talk with each other, but the following link regarding interoperability between the two seems to say that this often isn't the case. There is a Native AMQP client for LabVIEW on GitHub, but it is missing all the vis (at least from what I can tell), so isn't much help. I posted an "Issue" to the Repository, but don't know when/if I'll ever get a response. Any thoughts/comments/suggestions? Cat