Can I ride the LV/TS train to retirement?

[Neil Pate]

I can completely believe that C++ graph. It is probably not marching to oblivion, but is surely marching to some low constant value. Very few greenfield applications are started in C++  (apart from some computer games using Unreal I suppose)

[Rolf Kalbermatter]

It is more complex than that. First it is a trend so it is relative to some arbitrary maximum.

Second if you combine multiple items the trend suddenly looks a little different. Interesting that C started lower than C++ back in 2004 but seems to be now slightly higher than C++. It's obvious that LabVIEW always has been a minor player in comparison to these programming languages.

And if you limit it to computers and electronics as search categories it looks again different:

Edited November 10, 2023 by Rolf Kalbermatter

[ShaunR]

16 minutes ago, Rolf Kalbermatter said:

It's obvious that LabVIEW always has been a minor player in comparison to these programming languages.

LabVIEW never seems to even be listed on programming statistic websites. I refuse to believe (also) that LabVIEW has less programmers than, say Raku. Hopefully Emerson will aggressively promote LabVIEW on these kind of sites to raise visibility. NI failed to do so consistently.

[Rolf Kalbermatter]

In Google Trends LabVIEW is considered a software, while the others are considered programming languages. Many programming language comparisons don’t consider LabVIEW as they see it as a vendor software. On the other hand is G usually associated with something else. So LabVIEW falls through the cracks regularly.

On the other hand is your statistic website also not quite consequent. I would consider Delphi also more the IDE than a programming language. The language would be really (Object) Pascal.

And HTML/CSS as programming feels also a bit off, can I enter Microsoft Word and Excel too, please? Or LaTex for that matter? 😀
 

Rust on the other hand for sure is going to grow for some time.

Edited November 10, 2023 by Rolf Kalbermatter

[ShaunR]

15 hours ago, Rolf Kalbermatter said:

So LabVIEW falls through the cracks regularly.

Indeed. However, NI *should* have been aggressive in correcting that.

15 hours ago, Rolf Kalbermatter said:

On the other hand is your statistic website also not quite consequent. I would consider Delphi also more the IDE than a programming language. The language would be really (Object) Pascal.

I agree. Lazarus is the Open Source equivalent and I use a variation called CodeTyphon. But it highlights that even if LabVIEW is considered "vendor software" it should be on those lists as it is more of a programming language than HTML/CSS (as you point out). There could be no argument against inclusion, IMO.

 

[Rolf Kalbermatter]

38 minutes ago, ShaunR said:

There could be no argument against inclusion, IMO.

Maybe there isn’t other than that you and me and anyone else using LabVIEW never really was asked when they did their “reliable independent” programmer questioning. Trying to draw conclusions from a few 1000 respondents that where not carefully selected among various demographical groups is worse than a guesstimate.

Also most LabVIEW programmers may generally have better things to do than filling out forms to help some questionable consulting firms draw their biased conclusions to sell to the big world as their wisdom. 😀

Edited November 11, 2023 by Rolf Kalbermatter

[smarlow]

On 11/10/2023 at 5:58 AM, ShaunR said:

I've always been suspicious of Google Trends because it doesn't give context. The following is C++ but I refuse to believe it's marching to oblivion.

C++ marching into oblivion?  No, not yet.  But there is a lot of C# and JAVA nowadays.  The point is that LabVIEW is not an all-purpose language, and very specialized.  If they don't maintain and preserve LabVIEW as the preferred language within that specialized field, it is as good as dead.  It might chug along as a zombie for a while to maintain expensive systems that are running it.

[smarlow]

On 11/5/2023 at 6:58 AM, ShaunR said:

Another is callbacks in the Event Structure. Similar to the Panel Close event, they would have an out that can be described. 

Do you mean like a return from a dynamic event?

[Jordan Kuehn]

On 11/9/2023 at 4:43 PM, smarlow said:

All I know is that if they don't do something to make it a more powerful language, it will be difficult to keep it going in the long run.  It was, in the past always a powerful choice for cross-platform compatibility.  With the macOS deprecating (and eventually completely removing) support for OpenGL/OpenCL, we see the demise of the original LabVIEW platform.

I for one would like to see a much heavier support for Linux and Linux RT.  Maybe provide an option to order PXI hardware with an Ubuntu OS, and make the installers easier to use (NI Package Manager for Linux, etc.).  They could make the Linux version of the Package Manager available from the Ubuntu app store.  I know they say the market for Linux isn't that big, but I believe it would be much bigger if they made it easier to use.  I know my IT department and test system hardware managers would love to get rid of Windows entirely.  Our mission control software all runs in Linux, but LabVIEW still has good value in rapid application development and instrument bus controls, etc.  So we end up running hybrid systems that run Linux in a VM to operate the test executive software, and LabVIEW in Windows to control all our instruments and data buses.

Allowing users the option to port the RT Linux OS to lower-cost hardware, they way did for the Phar Lap OS would certainly help out, also.  BTW, is it too much to ask to make all the low-cost FPGA hardware from Digilent LabVIEW compatible?  I can see IOT boards like the Arduino Portenta, with its 16-bit analog I/O seriously eating their lunch in the near future.  ChatGPT is pretty good at churning out Arduino and RaspberryPi code that's not too bad.  All of our younger staff uses Digilent boards for embedded stuff, programming it in C and VHDL using Vivado.  The LabVIEW old-timers are losing work because the FPGA hardware is too expensive.  We used to get by in the old days buying myRIOs for simpler apps on the bench.  But that device has not been updated for a decade, and it's twice the price of the ZYBO.  Who has 10K to spend on an FPGA card anymore, not to mention the $20K PXI computer to run it.  Don't get me wrong, the PXI and CompactRIO (can we get a faster DIO module for the cRIO, please?), are still great choices for high performance and rugged environments.  But not every job needs all that. Sometimes you need something inexpensive to fill the gaps.  It seems as if NI has been willing to let all that go, and keep LabVIEW the role of selling their very expensive high-end hardware.   But as low-cost hardware gets more and more powerful (see the Digilent ECLYPSE Z7), and high-end LV-compatible hardware gets more and more expensive, LabVIEW fades more and more

I used to teach LabVIEW in a classroom setting many years ago.  NI always had a few "propaganda" slides at the beginning of Basics I extolling the virtues of LabVIEW to the beginners.  One of these slides touted "LabVIEW Everywhere" as the roadmap for the language, complete with pictures of everything from iOT hardware to appliances.  The reality of that effort became the very expensive "LabVIEW Embedded" product that was vastly over-priced, bug-filled (never really worked), and only compatible with certain (Blackfin?) eval boards that were just plain terrible.  It came and went in a flash, and the whole idea of "LabVIEW Everywhere" went with it.  We had the sbRIOs, but their pricing and marketing (vastly over-priced, and targeted at the high-volume market) ensured they would not be widely adopted for one-off bench applications.  Lower-cost FPGA evaluation hardware and the free Vivado WebPack has nearly killed LabVIEW FPGA.  LabVIEW should be dominating.  Instead you get this: 

Excellent points. All of them. I have echoed your frustrations with the ability to put Linux RT on arbitrary hardware, with lack of low/middle cost I/O boards, lack of low cost FPGA, etc.

[smarlow]

2 hours ago, Jordan Kuehn said:

Excellent points. All of them. I have echoed your frustrations with the ability to put Linux RT on arbitrary hardware, with lack of low/middle cost I/O boards, lack of low cost FPGA, etc.

It's killing LabVIEW.  They need to stop trying to use LabVIEW to only sell the top-end $$$ hardware.  It's going to end up like HP-VEE.

[ShaunR]

14 hours ago, smarlow said:

Do you mean like a return from a dynamic event?

Not really, although I suppose it is in the same category as what I would propose. I mean more like the "Panel Close?" event.

The callback would be called (and an event generated). You would then do your processing in the event frame and pass the result to the right hand side to pass back to the function (like the "Discard?" in the "Panel Close?" event).

Of course. Currently we cannot define an equivalent to the "Discard?" output  terminal. They'd have to come up with a nice way to enable us to describe the callback return structure.

[Rolf Kalbermatter]

1 hour ago, ShaunR said:

Of course. Currently we cannot define an equivalent to the "Discard?" output  terminal. They'd have to come up with a nice way to enable us to describe the callback return structure.

And that is almost certainly the main reason why it hasn't been done so far. Together with the extra complication that filter events, as LabVIEW calls them, are principally synchronous. A perfect way to make your application blocking and possibly even locking if you start to mix such filter events back and forth.

Should LabVIEW try to prevent its users to shoot themselves in their own feet?

No of course not, there are already enough cases where you can do that, so one more would be not a catastrophe. But that does not mean that is MUST be done, especially when the implementation for that is also complex and requires quite a bit of effort.

[ShaunR]

56 minutes ago, Rolf Kalbermatter said:

And that is almost certainly the main reason why it hasn't been done so far. Together with the extra complication that filter events, as LabVIEW calls them, are principally synchronous. A perfect way to make your application blocking and possibly even locking if you start to mix such filter events back and forth.

Should LabVIEW try to prevent its users to shoot themselves in their own feet?

No of course not, there are already enough cases where you can do that, so one more would be not a catastrophe. But that does not mean that is MUST be done, especially when the implementation for that is also complex and requires quite a bit of effort.

We've had these arguments before. I always argue that It's not for me to define the implementation details, that's NI's problem.

We already have blocking events (the Panel Close? greys out the "Lock Front Panel" checkbox because it's synchronous). The precedent is already there.

What I think we can agree on is that the inability to interface to callback functions in DLL's is a weakness of the language. I am simply vocalising the syntactic sugar I would like to see to address it. Feel free to proffer other solutions if events is not to your liking but I don't really like the .NET callbacks solution (which doesn't work outside of .NET anyway).

Edited November 14, 2023 by ShaunR

[Rolf Kalbermatter]

6 minutes ago, ShaunR said:

What I think we can agree on is that the inability to interface to callback functions in DLL's is a weakness of the language. I am simply vocalising the syntactic sugar I would like to see to address it. Feel free to proffer other solutions if events is not to your liking but I don't really like the .NET callbacks solution (which doesn't work outside of .NET anyway).

Unfortunately one of the problems with letting an external application invoke LabVIEW code, is the fundamentally different context both operate in. LabVIEW is entirely stackless as far as the diagram execution goes, C is nothing but stack on the other hand. This makes passing between the two pretty hard, and the possibility of turnarounds where one environment calls into the other to then be called back again is a real nightmare to handle. In LabVIEW for Lua there is actually code in the interface layer that explicitly checks for this and disallows it, if it detects that the original call chain originates in the Lua interface, since there is no good way to yield across such boundaries more than once. It's not entirely impossible but starts to get so complex to manage that it simply is not worth it.

It's also why .Net callbacks result in locked proxy callers in the background, once they were invoked. LabVIEW handles this by creating a proxy caller in memory that looks and smells like a hidden VI but is really a .Net function and in which it handles the management of the .Net event and then invokes the VI. This proxy needs to be protected from .Net garbage collection so LabVIEW reserves it, but that makes it stick in a locked state that also keeps the according callback VI locked. The VI also effectively runs out of the normal LabVIEW context. There probably would have been other ways to handle this, but none of them without one or more pretty invasive drawbacks.

There are some undocumented LabVIEW manager functions that would allow to call a VI from C code, but they all have one or more difficulties that make it not a good choice to use for normal LabVIEW users, even if it is carefully hidden in a library.

[ShaunR]

16 minutes ago, Rolf Kalbermatter said:

Unfortunately one of the problems with letting an external application invoke LabVIEW code, is the fundamentally different context both operate in. LabVIEW is entirely stackless as far as the diagram execution goes, C is nothing but stack on the other hand. This makes passing between the two pretty hard, and the possibility of turnarounds where one environment calls into the other to then be called back again is a real nightmare to handle. In LabVIEW for Lua there is actually code in the interface layer that explicitly checks for this and disallows it, if it detects that the original call chain originates in the Lua interface, since there is no good way to yield across such boundaries more than once. It's not entirely impossible but starts to get so complex to manage that it simply is not worth it.

It's also why .Net callbacks result in locked proxy callers in the background, once they were invoked. LabVIEW handles this by creating a proxy caller in memory that looks and smells like a hidden VI but is really a .Net function and in which it handles the management of the .Net event and then invokes the VI. This proxy needs to be protected from .Net garbage collection so LabVIEW reserves it, but that makes it stick in a locked state that also keeps the according callback VI locked. The VI also effectively runs out of the normal LabVIEW context. There probably would have been other ways to handle this, but none of them without one or more pretty invasive drawbacks.

There are some undocumented LabVIEW manager functions that would allow to call a VI from C code, but they all have one or more difficulties that make it not a good choice to use for normal LabVIEW users, even if it is carefully hidden in a library.

None of that is a solution though; just excuses of why NI might not do it.

[Rolf Kalbermatter]

3 minutes ago, ShaunR said:

None of that is a solution though; just excuses of why NI might not do it.

That's because I don't have a solution that I would feel comfortable with to share. It's either ending into a not so complicated one off for a specific case solution or some very complicated more generic solution that nobody in his sane mind ever would consider to touch even with a 10 foot pole.

[ShaunR]

37 minutes ago, Rolf Kalbermatter said:

That's because I don't have a solution that I would feel comfortable with to share. It's either ending into a not so complicated one off for a specific case solution or some very complicated more generic solution that nobody in his sane mind ever would consider to touch even with a 10 foot pole.

It's only software  One isn't constrained by physics.

[smarlow]

9 hours ago, ShaunR said:

Not really, although I suppose it is in the same category as what I would propose. I mean more like the "Panel Close?" event.

The callback would be called (and an event generated). You would then do your processing in the event frame and pass the result to the right hand side to pass back to the function (like the "Discard?" in the "Panel Close?" event).

Of course. Currently we cannot define an equivalent to the "Discard?" output  terminal. They'd have to come up with a nice way to enable us to describe the callback return structure.

I have a design that uses a Notifier to return data from a dynamic event back to the thread that generated it.  I used the data type associated with the event as the type for the notifier.  It's kind of clunky, but it works.  By typecasting the event refnum to a string, and using it as the name of the notifier, I believe it guarantees a unique notifier name.  If they were to build this "notification" into the event, it would act as a return.  The node could be on the right as you describe, and would have the same type as the dynamic event data.  A "Wait on Return" or "Callback" function would be added to the Events palette that functions like a "Wait on Notification" function.  

 

 

I think they could wrap up this implementation into a tidy solution for returning data from a dynamic event:  

 

[smarlow]

This implementation would mean the data for the "callback" has the same type as the dynamic event.  But if you use a cluster or class, it would be easy enough to separate the calling data from the return using sub-clusters. Copies of the calling data would be in the return, but that would be relatively harmless.

[crossrulz]

I avoid named queues and notifiers.  So what I do is put the notifier reference in the event data.  This makes the calling VI in control of the reference.

[ShaunR]

13 hours ago, smarlow said:

This implementation would mean the data for the "callback" has the same type as the dynamic event.  But if you use a cluster or class, it would be easy enough to separate the calling data from the return using sub-clusters. Copies of the calling data would be in the return, but that would be relatively harmless.

We have the Start Asynchronous Call for creating callbacks in LabVIEW. There are a couple of issues with what you are proposing in that callbacks tend not to have the same inputs and outputs. What we definitely don't have, at all, is a way for implementing callbacks for use in external code (in DLL's). While what I'm proposing *may* suffice for your use case, it's the external code use case where LabVIEW is lacking (which is why it makes Rolf nervous ).

Edited November 15, 2023 by ShaunR

[Neil Pate]

18 hours ago, crossrulz said:

I avoid named queues and notifiers.  So what I do is put the notifier reference in the event data.  This makes the calling VI in control of the reference.

yup, exactly how I do it too. For me the notifier has a variant data type so (unfortunately) needs to be cast back to real data when the return value comes

[hooovahh]

1 hour ago, Neil Pate said:

yup, exactly how I do it too. For me the notifier has a variant data type so (unfortunately) needs to be cast back to real data when the return value comes

Typed Clusters takes care of most use cases with this.  I have had times when two separate applications are talking to each other, and in those cases if the type def cluster changes, then both applications need to be built so the data matches.

[smarlow]

Using a class might help.

[Neil Pate]

On 11/15/2023 at 4:46 PM, hooovahh said:

Typed Clusters takes care of most use cases with this.  I have had times when two separate applications are talking to each other, and in those cases if the type def cluster changes, then both applications need to be built so the data matches.

Not for me though, my low level messaging uses events and that is just waaaaay to much drama to have separate events for every message. I wrap it up a layer with typedefs though, just the data is transported in a variant.