ShaunR

Most recently I had to do this with QUERY_SERVICE_CONFIGA

I rest my case.

One caveat is because, as Rolf states, LabVIEW passes the lower 32 bits (Big Endian), if you are manipulating pointers returned from functions you have to be careful if they are Little Endian. You don't come across it very often in LabVIEW since many API's have a create or new function and it can be treated as opaque. But there are Windows functions that return pointers that need to be converted.

Moveblock is thread safe so can run in any thread. Some of the importsl VI's run in the root loop.

If they had put "Synergy" in there we would have had a full house in BS Bingo. This seems to have been written by PR and is usually an indication of few tangible achievements.

Copyright reasons. You can put a lot of stuff in a VI and unpack it when run. I dare say it will be addressed in time. I was just commenting on LabVIEW being one of the few not touched by it-for obvious reasons.

We were asking for unicode support well before NXG was a twinkle in the milkman's eye. I'm sure if we searched this forum we would see that we've been moaning about it for at least the last 10 years. I certainly remember raising it when Delphi got full Unicode support and, IIRC, that was RAD Studio in 2008 but we were able to use it in Delphi before then if the OS supported it. LabVIEW's problem has always been displaying Unicode, hence that hit & miss kludge in the ini settings (LabVIEW 8.x?). Since they never gave us the ability to create the proper controls/indicators, we were never really able to work around it.

If it is what I think you are referencing then it is when the VI is run (run when opened), rather than the source code itself. It is also detectable by inspection but double clicking on the VI runs it. This is why most of us place a new, unknown, VI on a diagram or run something like this. Tags Detect.vi

It's a lot worse than that. It affects all text languages that use a unicode compiler (Python, C++, Delphi et.al) and is undetectable by visual inspection of the source code. It isn't a programmers application with a bug - you can't trust the source code is doing what you think it is doing.

CVE-2021-42694 CVE-2021-42574

What ensegre is getting at is that LabVIEW has never (officially) supported unicode and at one point NI said they don't need to (in classic) because NXG supports it. There are some UTF8 primitives that means you can support UTF8 internally but many of the controls and primitives don't support it (like the file control and functions). For that you have to have replacement windows file functions but that will not help you loading projects and is not cross-platform.

You are pretty much locked into NI at this point so I would be looking for ways to mitigate and diversify without throwing everything out and starting again. That means making future choices that replace piecemeal. This is a lot easier with software than it is with hardware. Keep LabVIEW 2020. You probably have more than 5 years or so before it is completely obsoleted and you will not lose access to it with a perpetual licence. Make sure you keep the full installer and not the download installer! I still use LV2009 (through preference) and only compile for later versions as customers require it. LV2020 brings TLS and this is a must-have, nowadays so if I didn't have my own TLS solution, I would have upgraded to it from 2009. I resist the subscription model in principle. So make of that what you wish. See 2. Keep what you have. It works, right? As you add more or start to replace stuff, look for alternatives. Depends if real-time is required. By all means have an external PC with databases and servers etc but if you need a real-time controller this will be difficult. An external PC is not generally a replacement of local controllers, it is usually a configuration and data collection station. Only you can answer that according to your specific current and future requirements. Yes. I moved to this a couple of years ago and never looked back. This is maybe where you would use the external PC but it can easily be provisioned and maintained by IT. You will also have a greater pool of resources to develop with as Web Devs are what you need, and they are plentiful. TDMS is only really useful if you are doing high-speed datalogging of large data-sets. Given 7. SQL over the network and SQlite locally should be the first choice. You only need a "garbage collector" to clean up garbage It's an interpreted scripting language, with the heavy lifting done by C/C++, masquerading as a general programming language. It's also a lovey of the Linux world so expect ABI breaks often like with v2-v3.

It has that feel to it but it is far more powerful. CodeTyphon is really a fork of Lazarus but with all components already packaged. That makes it a bit daunting to begin with as there are multiple components to choose from that are very similar - but not quite - since they are from different tool-sets to do the same things. Just get it installed and have a look through the (hundreds?) of examples (Under Tools>>CodeOcean Examples). The big boon of it though is that the IDE runs on most Desktops and from there it can compile native code for hundreds of targets. At that point you are way down the rabbit hole from the forms editor, though. Another plus is that it can use Lazarus and Delphi components. So if you have 3 different sources of projects and components you can leverage.

While Python has taken over T&M, I don't actually use it that much unless asked to. I don't even rate it as one of my core competencies. Outside of LabVIEW; for web stuff I use PHP (server) or Javascript (client) and everything else I use Codetyphon (WISIWIG IDE) or C (DLL's). When LabVIEW dies, it will be more CodeTyphon, PHP, Javascript and C depending on what I am doing. Much of what I do nowadays is UI interfacing to back-ends (DLL's, web services etc). I moved away from the LabVIEW UI so it boils down to what to use for a UI. For web stuff it is HTML & Javascript, on the client side, and Apache & PHP, on the server. For desktop it is Codetyphon (which is an open source Object Pascal competitor to Visual Studio but programs can be compiled for almost anything). I wouldn't touch .NET or C# with a 10 foot barge pole.

I'll let your IT dept. scream every point, in exquisite detail, when you tell them what you are planning and how you are not worried about their security.

For the HQ GUI side, use a browser and Javascript. You don't need a web server. You don't really need a web server on the device side either but it's useful to have a HTTP webserver to get a web page as a starting point and to configure things. Note that having a webserver is a security risk so if you are new to all this, I wouldn't suggest you have one on the devices in production but it will help you developing. You will need a Web server on the HQ side if you are doing database stuff but I'd suggest you talk to IT to get provisioning which will probably be an Apache Server-which they will maintain.

No.

I don't think this is a good use case for interfaces. Not so much the test stuff, just as a "Collection". As an aside; pedantically and academically, the difference between a List and a Collection is that a Collection is unordered so what you technically have is a List - although many use the terms interchangeably. What this means in practice is usually a List is implemented as an array (arrays are intrinsically ordered) and a Collection is implemented as a linked-list. So to access a Collection iteratively, Next/Previous must be used. That's not a desirable limitation for collections. IMO, a generalisation of collections should not limit types. This is also undesirable. A while ago I wrote a List class which was modeled on the functions in the Delphi collections class. It doesn't implement Next/Previous like here but it could be added trivially and wouldn't have the above limitations. As a specific "Array of Test Sequences" you are OK but it's not general enough for a generic "Collection/List" class.

Based on the terminology overall. It would mean that if the first SaaS version was 2022 and the latest version was 2024. If you produced software in version 2022, 2023 or 2024 and didn't keep up your subscription, you wouldn't be able to maintain any of the software.

The analogy is incongruous from your original. You stated that the licence that the second party may have, can absolve themselves of culpability. The culpability of the supplier is moot as they supplied it in good faith under the licence they have. But to your actual analogy. It depends. In the US, Dominic Black is being charged with "intent to sell a dangerous weapon to a person under age 18" to Kyle Rittenhouse who used a gun and killed people. The charge isn't the selling, per say, it is that the person being sold to was underage. However, if the intent was not to sell the firearm (knowing that the person is under 18), then the charges will fail. So again back to culpability. If the CE software is sold with the intent of making a profit, then the seller is in breach, not the recipient. Otherwise they are not. Once the recipient takes ownership they may introduce it into their software and then they are bound by whatever licence they have. If they have a proper licence, then they are free to make a profit (as you said) if not, they can't sell their own product anyway, regardless of the dependent software.

That doesn't make much sense. Only one of these parties can have culpability and culpability cannot be transferred.

So. Dependency Injection = Plug-ins?

That is far more difficult to implement. consider this-an array in a variant and a normal array: { "temps":[21.4, 23.2, 33.6], "press":[1006]; } LabVIEW arrays are single types so this is straight forward. { "temps":[21.4, 23.2, 33.6], "temps~lvtype":"dbl", "press":[1006] } You don't need to pars the array string ("temps") any more than you do now. Including the type in the array, you now have to inspect the elements of the array (at least one, if the format is the first or last element) parse it then delete it to return the array. If there are only two elements in the array, you have to see if there is a lvtype to decide if it is really an array or it's a scaler with a type.

That's a point. What happens to that? Is that outside of this subscription model?

This is true but that is only because LabVIEW features are about a decade behind other offerings. We only got TLS in LabVIEW 2020! What LabVIEW does well is hardware control and acquisition but for a long time now, NI has traded off the back of their instrument drivers. Beyond that, LabVIEW has a lot of competition that is open-source and free (as in beer) and easily extendible. If you want a nice UI with theming, LabVIEW is a poor choice. Python is much worse for UI's. But it doesn't matter if you have an HTML UI because Python is fantastic at webservers, services and TCP. The main advantage of Python over, say, PHP or Javascript is that you don't need an Apache or Nginx webserver. However, the point I'm obviously failing to make is that Python has already conquered one niche space that used to be a strong selling point for LabVIEW and making it Software-as-a-service will make it even more unpalatable going forward. Don't get hung-up on Python though. Javascript is a contender also. However Python is more ubiquitous in T&M at present. Anyhow. That's enough of the black-pills. Someone gimme some white-pills with this "progress"