ShaunR

Yes. It's not a new idea, BTW. This is the route ladder logic went for state machines in PLC's. Ignoring the boiler plate scripting for a moment. What is really missing is an intuitive way to view a program's structure. I said a long time ago that we need something similar to (the now defunct) Firefox 3D View. This could be a mode of the VI Hierarchy diagram allowing us to inspect the way subVI's are interconnected and allow us to zoom in and isolate areas of interest. Event and queue [message] tunnels or the "Channels" could easily be shown which are invisible with the tools we use today.

Just to note. ECL doesn't support UDP at present. There are plans to support DTLS (the UDP version) in the future though, I won't comment any further than that except to say that I too would be interested in the comments of users.

I don't know why they continue to push these "place a VI that transforms into a mess of code". It always seems to me they are solving the symptom, not the cause, by automating the replication of boiler-plate code we have to do when the real goal is not to have to replicate at all. A long time ago I posted a VIM that, awkwardly, implemented "named events" and the "framework" was to use that and a queue with a bit of string manipulation to send messages back again. It was basically the the same as MessengerM, shown here. It would have been much better if the event structure could use named events (wire a string to the terminal?) and have an [optional] output on the right hand side for a message out/back. That would implement the MessengerM without all this malarky. Certainly in a lot of the event driven API's I now produce, there is a "Source" on the left side of an event structure. That could just be wired across to a "target" on the opposite side to send a message back to an individual stack (aka a queue output). Bonus points if the "target" can be marked as "broadcast" to behave as "Generate user Event". I dare say that it could be refined further with a bit more thought too, since what we have to do is figure out who sent the message and act accordingly-the event structure already knows who sent the event.

And when you do, there are still options

I'm a collaborator and I'm not sure I like that. I'd prefer to be in the resistance.

I think this is a very positive thing that more should be encouraged to take part in. For Application engineers and R&D Devs to do sabbaticals, on loan, to companies would build good relationships in the industry and ensure tight cohesion and understanding between the developers of LabVIEW and the customers' that use LabVIEW. There is nothing like a dose of ones own medicine to encourage improving the taste.

A quart of oil? Robot confirmed.

Tin foil hat time We know there were discussions about SaaS that the LabVIEW dev team were resisting. I think this is the real reason why AQ left.

Storing hidden programs is not unusual for you? It's highly suspicious to me. As separate operations, Run When Opened isn't common and storing hidden programs even less so. Both together start alarms bells ringing for me.

At the risk of derailing the thread; that's not really what I was talking about. It's that I *have* to use the localheap for the function to fill with data. I then used moveblock to copy the data from the localheap to a U8 Array and it's this copy which is when I was casting to a cluster. My surprise was that a function that populated the memory *required* the memory created with localheap, not the pointer, per se. Now I should be able to moveblock it directly to a cluster, now I know what's happening, and avoid the cast completely.

Insightful and amazing you identified that from my terse comment. Yes indeed. It seems that the source was indeed a type-cast and I was unaware of this "feature". I retract my previous comment but won't delete it for historical reference. Indeed. However the function that returns it required a call to create localheap memory (in the Win32 API) which I then needed to get back into a cluster. Otherwise I would have used this method. This, in itself, was unusual so maybe I'm missing something else too in this particular example.

In this context it just means challenging existing monopolies, orthodoxies or methods. Text-book examples would be things like streaming to terrestrial TV, block-chain to banking etc.

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.