Including solicitation of interest from potential acquirers

[ShaunR]

4 hours ago, drjdpowell said:

Noone in the corporate world thinks any less of Emerson for doing a very normal business thing.

It's only a normal business thing for American companies.

My hunch is that this will fail. NI are vehemently defending and has foreign customers who are heavily invested in their technology-some of who are Governments. I'm sure customers like CERN are not very happy about the situation and similar organisations have very strong influence over these sorts of matters. I hope I am right but if I am not, I wouldn't be surprised at a few more spanners being thrown in to the works later down the line after a successful bid.

I've my fingers and toes crossed for NI to ride this out.

[Reds]

Well, Dr. T came out in favor of the transaction. 
 

Thats a pretty significant commentary on how he feels about current management.

 

https://www.msn.com/en-us/money/companies/national-instruments-co-founder-backs-7-billion-emerson-offer/ar-AA16JEEA

Edited January 27, 2023 by Reds

[ShaunR]

6 hours ago, Reds said:

Thats a pretty significant commentary on how he feels about current management.

Maybe. Although he's getting on a bit and has an interest in Alzheimer's. Could also be looking at passing an inheritance where a cash drop like this would be great. Difficult to understand he'd be happy about his life's work being swallowed by another corporation just for a few decimal points of his billions in cash.

Interesting he talks about "stakeholders" instead of shareholders but it does not bode well for NI.

The plot thickens!

[Antoine Chalons]

I guess we all have a price.

This reminds me of a brilliant scene from "nueve reinas" https://www.youtube.com/watch?v=AcsfBeTAuSQ

[Reds]

2 hours ago, ShaunR said:

Maybe. Although he's getting on a bit and has an interest in Alzheimer's. Could also be looking at passing an inheritance where a cash drop like this would be great. Difficult to understand he'd be happy about his life's work being swallowed by another corporation just for a few decimal points of his billions in cash.

Interesting he talks about "stakeholders" instead of shareholders but it does not bode well for NI.

The plot thickens!

I didn't quote the part where he explicitly states his disappointment with NI's "execution" and how it has lost focus on it's "stakeholders" including customers and partners.  Check out the article and decide for yourself. I mean, he's not wrong if you ask me.

Edited January 28, 2023 by Reds

[X___]

3 hours ago, Reds said:

I didn't quote the part where he explicitly states his disappointment with NI's "execution" and how it has lost focus on it's "stakeholders" including customers and partners.  Check out the article and decide for yourself. I mean, he's not wrong if you ask me.

You mean that sentence:

Quote

Truchard said that a combination of poor execution and underinvestment in developing new technologies had allowed rivals to gain ground on the Austin, Texas-based company. 

I am not sure he means LabVIEW when he thinks "new technologies". After all that is more the purview of Colonel Kodosky...

Who probably wouldn't mind a few extra 100 million dollars for... what about spinning off G and funding an open source project making a graphical Python-based LabVIEW?

[Rolf Kalbermatter]

9 hours ago, Reds said:

I didn't quote the part where he explicitly states his disappointment with NI's "execution" and how it has lost focus on it's "stakeholders" including customers and partners.  Check out the article and decide for yourself. I mean, he's not wrong if you ask me.

Well I can assure you that he was not the person who would blindly follow shareholder value and forget everything else. I have talked with him personally on several occasions and he was as approachable as you can get. When you talked with him it was not as a number in the employee list or as an expendable necessity to run his company but as a human and he felt honestly interested in talking with you, not just as a social nicety.

He was the old style boss who cared more about his company and the people who worked there than sales and profit, which were a mere means to make his company and the people working there to succeed and prosper, not a means in itself.

Could he have decided to stop LabVIEW? Probably if he had seen that it gets a sinkhole for his company. Would he have stopped it because it cost a bit more than the company can earn from direct license sales? Certainly not, since he did clearly see the internal synergies.

So yes I’m sure he isn’t happy about what the current management has done. He likely stood behind the idea to diversify the old NI away from a mostly DAQ centered company that had pretty much reached the ceiling of that market and couldn’t grow much more  But I doubt very much that he approved to start throwing away the very roots of his company in favor of new and bolder frontiers.

Edited January 28, 2023 by Rolf Kalbermatter

[Rolf Kalbermatter]

6 hours ago, X___ said:

 

Who probably wouldn't mind a few extra 100 million dollars for... what about spinning off G and funding an open source project making a graphical Python-based LabVIEW?

Sorry but you are talking nonsense here. I don’t mean the part about Jeff spinning off a new company with that money although I think that’s not very likely, but a Python based LabVIEW is just utter nonsense.

LabVIEW is written for maybe 95% in C/C++ with a little Objective C and C# thrown in, and reimplementing it in another language would take only 10 to 20 years if you are lucky. If you want to make it reasonably compatible you can add another 10 years at least. And that is not even considering the abominable performance such a beast would have if you choose Python as basis.

Reimplementing LabVIEW from ground up would cost likely 500 million to 1 billion dollar nowadays. Even NXG was not a full redesign. They tried to replace the UI layer, project management and OS interface with C# and .Net based frameworks but a lot of the underlaying core was simply reused and invoked with an Interop layer.

And a pure LabVIEW based company would be difficult. The current subscription debacle was an attempt to make the software department inside NI self sustaining by implementing a serious price hike. At the same time they stopped LabWindows/CVI completely which always had been a step child in the NI offerings together with most other software platforms like Measurement Studio. They earned very little with them and did not invest much in them because of that, which made them of course a self fulfilling failure.

There is only a relatively small development team left for LabVIEW, apparently mostly located in Penang, Malaysia, if I interpret the job offers on the NI site correctly and they are probably scared to death about the huge and involved legacy code base that LabVIEW is and don’t dare to touch anything more substantial out of well founded fear to break a lot of things with more involved changes.

I think what LabVIEW needs is a two version approach. One development branch that releases regular new builds where developers are allowed to make changes that can and very likely will break things and to work on them and improve them gradually and once a year or even once every two years all the things that have proven to be working and stable are taken over into the LTS branch that professionals who pay a premium to use this version, can use with a 99% assurance that nothing important breaks.

You want to play with cutting edge features and don't mind to receive regular access violation dialogs and other such features? You can use our development release which costs a modest license fee and if you promise to not use it for anything that earns you money you can even use the community license with it.

You expect rock solid performance and no crashes and bugs that are not caused by other things such as third party additions or your hardware/OS?

Here we have an LTS version! It does not contain the latest gadgets and features and toys but we can assure you that everything that is in it is absolutely rock solid. And yes this has its price but if you use this you can be sure to focus on solving your problems and not worrying about quirks and irks in our software!

Edited January 28, 2023 by Rolf Kalbermatter

[ShaunR]

1 hour ago, Rolf Kalbermatter said:

At the same time they stopped LabWindows/CVI completely which always had been a step child in the NI offerings

I always felt they could have had a tighter integration between LabVIEW and CVI. It could have solved our lack of being able to use C callbacks for a start. A CVI node like the Formula node could have been quite useful too. 

Edited January 28, 2023 by ShaunR

[Rolf Kalbermatter]

29 minutes ago, ShaunR said:

I always felt they could have had a tighter integration between LabVIEW and CVI. It could have solved our lack of being able to use C callbacks for a start. A CVI node like the Formula node could have been quite useful. 

LabWindows CVI did use a lot of LabVIEW technology originally. Pretty much the entire UI manager and other manager layers such as File IO etc were taken from the initial LabVIEW 2.5 version developed for Windows. On top of that they developed the LabWindows/CVI specific things such as function panels, project management and text editor etc. The C compiler was their own invention I believe. Later, around 2010 or so they used replaced the proprietary compiler in LabVIEW with LLVM as compiler backend and after that they used that knowledge to replace the LabWindows/CVI compiler with the same LLVM backend.

Callback support in LabVIEW, while not impossible to do (ctypes in Python can do it too). always was considered an esoteric thing. And IMHO not entirely incorrectly. The problem isn’t so much the callback mechanisms itself. Libffi is a reasonable example how it can be done although I’m sure if you dig in there it takes you a few days to understand what is needed just in a Windows application alone. The much more difficult thing is to allow a configuration in the Call Library Node that doesn’t require a PHD in C programming to configure it correctly to match the callback function correctly and the mapping from the callback function parameters to the callback VI inputs and outputs.

ctypes in Python is much more straightforward because Python is a procedural language like C and even there you have only very few people who can handle normal function calls and virtually nobody who gets the callback functions right!

Edited January 28, 2023 by Rolf Kalbermatter

[ShaunR]

19 minutes ago, Rolf Kalbermatter said:

The C compiler was their own invention I believe

I think the C compiler was (or was based on) on the Watcom compiler.

19 minutes ago, Rolf Kalbermatter said:

Callback support in LabVIEW, while not impossible to do (ctypes in Python can do it too). always was considered an esoteric thing.

Well. Callbacks are a poor-man's event. The C/C++ industry has always had problems with fitting event driven programming into their straight-jacket. They are being forced to nowadays with Service Oriented Programming and all they have is callbacks as an answer-leaving the programmer to figure out threading and asynchronous operation. It's why I prefer Object Pascal (Delphi, Lazarus et.al.) over C/C++ 

Edited January 28, 2023 by ShaunR

[Rolf Kalbermatter]

18 minutes ago, ShaunR said:

I think the C compiler was (or was based on) on the Watcom compiler.

No, Watcom C was used to compile LabVIEW and LabWindows CVI for Windows 3,1 because it was pretty much the only available compiler that could create flat 32-bit code at that point and absolutely the only one that supported this on the 16-bit Windows platform.

They did not have a license to use the compiler in there and it was several years before Watcom faltered and a few more years before its sanitized source code was open sourced. It still exists as open source but activity on that project is very dead.

Edited January 28, 2023 by Rolf Kalbermatter

[X___]

4 hours ago, Rolf Kalbermatter said:

Sorry but you are talking nonsense here. I don’t mean the part about Jeff spinning off a new company with that money although I think that’s not very likely, but a Python based LabVIEW is just utter nonsense.

My bad, I did not fully fleshed my proposal to Jeff K. I did not mean to rewrite LabVIEW in Python, but import some of the graphical concepts of LabVIEW into Python.

Here is it: develop a Python module that allows representing python code graphically. The execution parallelism implemented in LabVIEW would probably be the trickiest part, but I am not sure I would require it initially. And implement some type and syntax checking breaking the "diagrams" at edit time rather than at compile/runtime (typos is what I hate in text-based languages).

[X___]

4 hours ago, Rolf Kalbermatter said:

There is only a relatively small development team left for LabVIEW, apparently mostly located in Penang, Malaysia, if I interpret the job offers on the NI site correctly and they are probably scared to death about the huge and involved legacy code base that LabVIEW is and don’t dare to touch anything more substantial out of well founded fear to break a lot of things with more involved changes.

I wonder whether Emerson knows that, and if so, what their logical conclusion will be moving forward. I mean, I have no doubt what they will decide.

[ShaunR]

31 minutes ago, X___ said:

what their logical conclusion will be moving forward

Their logical conclusion would be that it's not a big market and we can't support it. You can say goodbye to LabVIEW, IMO.

1 hour ago, X___ said:

Here is it: develop a Python module that allows representing python code graphically. The execution parallelism implemented in LabVIEW would probably be the trickiest part, but I am not sure I would require it initially. And implement some type and syntax checking breaking the "diagrams" at edit time rather than at compile/runtime (typos is what I hate in text-based languages).

This is a fantasy. Python is well known for being poor at multithreading, if you can call it multithreading. 

I understand that you are just trying to find a new place for LabVIEW but getting Python to support a data-flow paradigm is probably a bit too much.

We have a number of programming languages and paradigms at our disposal so why try to shoe-horn everything into Python? Use the right tool for the task. I don't use LabVIEW when writing webserver code.

IMO, LabVIEW's biggest weakness is the UI. Python isn't a good improvement on that and vice-versa. LabVIEW would also be a very expensive and cumbersome development tool just for planning and maintining python applications. Perhaps a more realistic solution would be to improve the LabVIEW VI server so that it could interface with other languages directly using TCP - make it more like an RPC interface. That may scratch your Python fetish itch.

[Rolf Kalbermatter]

1 hour ago, ShaunR said:

IMO, LabVIEW's biggest weakness is the UI. Python isn't a good improvement on that and vice-versa. LabVIEW would also be a very expensive and cumbersome development tool just for planning and maintining python applications. Perhaps a more realistic solution would be to improve the LabVIEW VI server so that it could interface with other languages directly using TCP - make it more like an RPC interface. That may scratch your Python fetish itch.

Actually, as far as the UI goes it depends quite a bit what you want to do. For fairly simple UIs that "just work" it's still an amazing easy system. If you want to support the latest craze in terms of UX design, then yes it is simply stuck in how things were 20 years ago. Basically if you need a functional UI it works fairly easy and simple, if you need a shiny UI then LabVIEW is going to be a pain in the ass to use.

Nowadays Beckhoff and Siemens and others have their own UI solutions too, but in comparison to them LabVIEW is still shiny and easy. Beckhoff does have the advantage that their UI is HTML5 based so easy to remote but it looks like a stick figure compared to a Van Gogh painting when you compare it to a LabVIEW front panel.

My dream was that they can develop something that allows the LabVIEW front panel to be remoted as HTML5, but seeing the Beckhoff solution I start to think that this project failed because they did not want to settle with simple vector graphic front panels but wanted to have a more native looking impression in the web browser.

And yes documenting the VI Server binary TCP/IP protocol and/or adding a REST or similar protocol interface to the VI server would be an interesting improvement.

[ShaunR]

1 hour ago, Rolf Kalbermatter said:

My dream was that they can develop something that allows the LabVIEW front panel to be remoted as HTML5

Actually you can sort of do this already but it's not native. Websockets made this possible. All it requires is to be able to map a web page to a front panel and come up with a protocol. It is surprisingly easy as long as you don't use panes.

It would seem to be a nice feature to just lay down LV controls and for them to be replicated remotely, but then it'd just look like a LV front panel in a browser - you might as well send an image.

You need to be able to customise the HTML and the LabVIEW IDE would make an awful HTML editor. It's far better to make the HTML (or get a web-dev to do it) and tell LabVIEW what controls were pressed - effectively separating LabVIEW from the FP the user interacts with.

But I was thinking more of VI server being the interface for LabVIEW as a back-end, function server so that in addition to the above, it could also act as binding for other languages (RPC). They did something similar with their webserver where you could call functions but it was a hideous solution requiring deployment of the NI Webserver and Silverlight etc. You could map a web page address to a VI to call. VI server has much finer granularity than just user VI's and, IMO, should have been the starting point.

Edited January 28, 2023 by ShaunR

[Rolf Kalbermatter]

46 minutes ago, ShaunR said:

But I was thinking more of VI server being the interface for LabVIEW as a back-end, function server so that in addition to the above, it could also act as binding for other languages (RPC). They did something similar with their webserver where you could call functions but it was a hideous solution requiring deployment of the NI Webserver and Silverlight etc. You could map a web page address to a VI to call. VI server has much finer granularity than just user VI's and, IMO, should have been the starting point.

Well, I do have a VI library that can talk VI Server, at around LabVIEW 6 to 7. The principle seems still pretty much the same, but there were a few zillion new attributes and methods added to the VI Server since, and classes, and what else.

[X___]

On 1/28/2023 at 8:21 AM, ShaunR said:

This is a fantasy. Python is well known for being poor at multithreading, if you can call it multithreading.

I don't know about that. For me multithreading works when all my cores usage are maxed out. I see that in both LabVIEW code and Python code.

Edited January 29, 2023 by X___
typo

[X___]

On 1/28/2023 at 8:21 AM, ShaunR said:

We have a number of programming languages and paradigms at our disposal so why try to shoe-horn everything into Python? Use the right tool for the task. I don't use LabVIEW when writing webserver code.

Simple: to be understood by and be able to share code with others in academia. I have a few options: python, MATLAB, Mathematica, possibly C/C++ but certainly not LabVIEW. I dabble in all other languages, but in terms of cost and adoption, the choice is easy. I understand that for automation and delivering slick UI to paying customers it might not cut it, but if Emerson drops it, everyone will have to reconsider their options.

As far as I am concerned, the writing has been on the wall a long time ago as far as LabVIEW was concerned. What saddens me the most is that its graphical paradigm hasn't percolated (much) in other languages (Node-Red and some other experiments being rare and not-so-impressive exceptions).

[Mads]

3 hours ago, SebastienM said:

I can't imagine a NI salesman saying to SpaceX, NASA, [insert critical industry here] ect... "sorry guys, but now you can go f... yourselves with your LabVIEW code base because we have decided to discontinue it."

Perhaps it would be better if Elon bought NI and shifted the focus back to "the software is the instrument (and the car, and the rocket...and everywhere)"😀 Bringing the electric car from tiny boring cars to where it is today is a journey the G-language deserves as well.

[Rolf Kalbermatter]

On 1/29/2023 at 6:06 PM, X___ said:

As far as I am concerned, the writing has been on the wall a long time ago as far as LabVIEW was concerned. What saddens me the most is that its graphical paradigm hasn't percolated (much) in other languages (Node-Red and some other experiments being rare and not-so-impressive exceptions).

That is partly NI's work. They were pretty aggressive about defending their idea by applying for quite a few patents and defending them too. Of course if you go to the trouble to apply for a patent you have to be willing to defend it, otherwise you eventually loose the right to a patent anyways.

And they did buy up some companies that had something similar to LabVIEW, such as DasyLab for instance, although in my opinion DasyLab didn't quite go beyond the standard "wire some icons together" similar to what HPVee did, and what Node-Red is doing too. But they tried to use some structures that were darn close to LabVIEW loops and that was a prominent NI patent. So NI eventually approached them and made them the offer to either buy them or meet them in front of a judge. The rest is history.

Edited February 3, 2023 by Rolf Kalbermatter

[ShaunR]

16 hours ago, SebastienM said:

In the end if LabVIEW is discontinued or let dying I could move completely from NI and honestly they would deserve it.

We shall see. The "Fat Lady" hasn't sung yet and Emerson shareholders seem more than a little unhappy about the takeover. I'm still bullish on this failing despite Dr T's intervention.

The more I look at it, the more this seems like taking out the competition as opposed to diversifying and entering new markets. I think System Link was probably the trigger for this as it could, in the future, take Emersons offerings head-on and provide a far more superior top-to-bottom solution given NI's driver, LabVIEW and Test Stand support.

[hooovahh]

On 1/27/2023 at 10:17 AM, Reds said:

Well, Dr. T came out in favor of the transaction. 

With a slightly snarky tone, I want to ask if this is part of the 100 year business plan NI has.  On a personal level I just hope LabVIEW can stay relevant until retirement.  I do still have a perpetual license to 2022 Q3, which supports Windows 11.  So even if NI goes away I'll be able to be in my language of choice until 11 is no longer supported. 

LabVIEW has changed the way I think about programming in such a way that I think it is hard to go to other languages.  My brain thinks in parallel paths, and data dependence, not lines of code and single instructions.  Whenever I develop in C++ I can't help but feel how linear it is.  I'm sure higher level languages are better, but at the same time I don't really want to change.  As long as I can work at a place that needs test applications, and doesn't care how they are developed, I'll be happy pushing LabVIEW.  The fog of the future is hard to see though.  The next year or two looks very uncertain in my career.  But looking at the past, working in LabVIEW has felt like winning the lottery.  Thinking about this helps me stay positive.

[bjustice]

For what it's worth, I echo Hooovahh's thoughts here