ShaunR

A decade is about how long things need to percolate through the learning institutions to reach a critical mass of employees skilled in it. Relatively speaking - yes, it is "whiz-bang" when compared to Javascript. C++ et. al. Even Rust is 10 years old. C# is 20 We really haven't moved on much from about 30-40 years ago when there was truly spectacular explosion of ground breaking invention and innovation in software and hardware by some very special people...and one of those was LabVIEW. We've tweaked, revised and added spokes to the existing wheels on the back of huge leaps forwards in hardware technology that has hidden the industry's mediocrity.

You don't need a Ph D thesis. Some people thought they could do <INSERT PROJECT HERE> better with the latest whiz-bang stuff and convinced management they could do it. I've seen it a hundred times.

Not really general purpose (yet?) but you mentioned IoT so Node-Red is worth looking at for the not-too-distant future.

Considering the distribution issues with Linux variants - and often within the same variant - where even things compiled on a different machine often won't work unless everything is "just-so"; that was at best a pipe dream. The main reason I stopped supporting Linux for ECL was for this very reason. The only safe way to build executables is on the target Linux variant - preferably on the same machine - and for that you would need the full LabVIEW. It's one of the main reasons why interpreted languages are so prevalent on Linux platforms (PHP, Python, Javascript etc).

NXG had an inherent fatal flaw. It wasn't (and would never be) cross platform. That was exacerbated by the slow progress of development to the point that NI lost the T&M market to Python. It was a good decision, rarely seen by large multinationals. The good news is that they figured out how to represent VI's as XML properly and convert the VI format to it. We have already seen that format creeping into LabVIEW in the form of projects and libraries but the VI's themselves remained propriety. Porting the ability to represent VI's in XML would be a huge improvement to LabVIEW enabling source control tools to work properly-the bane of LabVIEW for over a decade. The other much needed LabVIEW improvement is internationalisation. We have had UTF8 for a long time but have been unable to display it. Instead, we had a *hack* that never worked right and never would with the resources allocated to NXG. It's been fraught to try and display it and other means were found. If the lessons learnt from NXG means we can display UTF8, that would be another huge improvement to LabVIEW and, I think, easier than UTF16/32 without impacting current string manipulation. I'm ambivalent about the IDE. It works fine enough for me to develop but it is a poor user interface for applications. I got around this user interface problem a long time ago with Websockets so, although a bit more effort, it's not a big issue anymore. I hated the restrictive framing of NXG and it seemed to promote huge monolithic diagrams with the zoom facility. The standard LabVIEW IDE encouraged me to make small, encapsulated code modules and I could see many parts of the architecture at once when debugging. If shelving NXG means the first two issues get addressed by either more effort or porting; those alone would mean, IMO, LabVIEW has a future - a bright future. It would once again be a cross-platform equivalent to all the other text languages with all the advantages *over* the other languages that it originally had.

Just welcoming an old friend to the forum

Well. Aren't we a ray of sunshine nowadays

AQ leaves, NXG gets shelved. Insert your rumour-mongering and conspiracy theories here

Yes. Linux hates spaces

You have obviously never done Agile Development proper then since it is an iterative process which starts with the design step just after requirements acquisition. It's not a fear of failure, it is a fast-track route to failure which usually ends up with the software growing like a furry mold. But anyway. It's your baby. You know best. Good luck :)

Uhuh. Seat-of-your pants design; the fastest way to project failure.

This is the standard way to do service discovery. My "Dispatcher" implementation had a "broker" that ran on the local machine to act as a gateway to services that registered with it on that machine. External (or local) clients would then contact it to discover services and it would hand off comms to the service for direct communication. It behaved as a router rather than the usual broker and meant it didn't become a bottleneck for high speed transfers. Your framework would be a good match for the above implementation since it already has all the publish, subscribe and routing features, IIRC.

That's fine. I just don't like to distribute modified software that I produce where the licencing isn't explicit - which is why I asked you for one (thinking you had produced it as the original author).

OK. I've deleted the backport since the licence is indeterminate. I thought it was a library you had created.

Backported to LV2009. what's the licencing for this? Edit. Removed software due to indeterminate licencing.

The major use case for UDP I would have is for COAPS (which, incidentally, has service discovery rather than node discovery). Most node discovery methods require a known entry point (gateway, router, default port etc) and it's hard to get away from that that in a reliable way across numerous network architectures.

Very hard to do but can be done-non trivial. You will obviously have to talk to your client and find out exactly what they mean - get one of the USB sticks they use . Maybe you'll be lucky and they just mean using the LabVIEW application as the windows shell, which I do on production-line machines.

It's a compromise between convenience and security and partially solves the "trust" issue by having really, really trustworthy organisations There have been other alternatives proposed but the "trust" issue has never really been solved adequately, to date. I trust me so my certificates are great (for me). The problem with that is then distribution. SSH. which is arguably the progenitor of modern TLS, got a lot of things very right. We haven't really moved on from that model except to make a whole new business sector for the key management.

I don't think there is anything off-the-shelf, to my knowledge - Bluetooth has it's own encryption scheme. I think you are looking at using some existing TLS client/server implementation and replacing the underlying Socket connection with a Bluetooth connection. Edit: Thinking a little more. there may be another way. the caveat would be it would only work for RSA certs in this scenario, There is an example of RSA Encrytion/Decryption. You could load an x509 cert, extract the keys and use the encryption functions to encrypt the bluetooth data. This wouldn't handle the authentication but it's some of the way there. It might be possible to check the authenticity separately from the encryption but I'm not sure at the moment.

You can't outsource security If you understand that all TLS communications are interceptable by governments because of CA's, then you might also be reticent when dealing with some governments.

Congratulations. It will go great and it's a fantastic area to grow into. You won't regret it but i very much doubt you will be back at NI - it'd be a step backwards.

I wouldn't. HTTPS is just one protocol. I personally use secure websockets which is much better suited to this sort of thing IMO, Most of these use TLS though and more recently I've been playing with DTLS. If I don't use those sorts of protocols then I use SSH but that's nothing to do with what the OP is asking as it doesn't use X.509 certs (which is,as you know, just a standardised certificate format). I think that's just middle-management phrasing. I wouldn't be surprised if the device already supports this method of updating and they were told it uses X.509 certificates "for security". but we diverge..... The main thing to ascertain is whether Certificate Authority certs are required or if self-signed certificates can be used. They both allow "securely writing"; the difference is authenticity. This dictates whether things work out-of-the-box (in the same way as your web-browser works out-of-the-box) or you have to add pub key certs to root bundles. Personally I prefer self-certs for this sort of thing as it provides greater granularity for who can access the device, I don't trust Certificate Authorities, and when IT get a whiff of you requiring company CA certs, they usually try to get involved. It really depends on whether you have control over the server though.

This is quite a common requirement nowadays, especially within the IoT sphere. Many embedded devices come with libraries for what is called OTA (Over The Air). A multitude of devices are then monitored and configured (including software/firmware updates) via a web server. I wouldn't be surprised if the NI Systemlink uses something similar (via either HTTPS or MQTT). TLS is quite burdensome for constrained devices, specially if you have to put a webserver on the device to upload rather than using OTA libraries. To be honest. This isn't something I would use LabVIEW for. There are much better solutions available specifically for this purpose.

You will have to re-architect that if you want to.... By the way. The TCPIP I described earlier is a layer to break cohesion - meaning that the VI's can be controlled by anything, in any language, including Test Stand. So if you want the "on demand" aspect, then that is probably the easiest way forward.

Another thing I did with the aforementioned was to add TCPIP (a later version). It meant you could launch a VI and then communicate with it via strings sent from Test stand - even on remote machines. The wrapper was only slightly more complex than the pure launcher but it meant you could configure the devices on-the-fly, abort or reset devices and query state information with simple strings from Test Stand (I used SCPI-like commands). Anyway. I diverge. You've probably guessed by now that the choice you had was to have an instance per device which you control and sequence from TS, which is what I was describing, or an application that does it and reports back to TS, which is what you are designing. The others have given you options for the latter and I was just giving you a method for the former.