ShaunR

2 hours ago, SebastienM said:

Here we go for the dedicated website :

maximizingvalueatni.com

Ooooh. They want it bad.

Quote

Emerson’s Public Proposal Follows Eight Months of Delay and Lack of Engagement From NI. Emerson has made numerous attempts to engage constructively with NI in private since May 16, 2022. For eight months, NI delayed and refused to engage meaningfully with Emerson. On January 13, 2023, NI announced publicly that it is undertaking a strategic review process and put in place a poison pill.

They salty  

1 hour ago, jacobson said:

the first question I would probably ask is why I would want to choose your API over the one I already was using.

It's an additional protocol to an existing commercial product. If you only want MQTT and not the rest of the features (TLS1.3, SSH, SFTP, Websockets, ICMP etc), then keep using what you have.

1 hour ago, jacobson said:

Even if you have reasons for not liking an existing API it might still be a good use of time to see if you can address those issues by working from the existing API.

I've already explained about licencing.

1 hour ago, jacobson said:

If they're unwilling to make those changes (maybe they find value in keeping everything in pure LabVIEW) then you can start working on your own API with very clear reasons as to why someone would even want to use it. 

I already know why people want (and how) to use MQTT. I just want a bit of input as to which way to jump on a decision I'm in two minds over. FYI. The decision prior to this was CoAP or MQTT. I decided MQTT.

39 minutes ago, Porter said:

FYI the first link is licensed under BSD 0-Clause

Granted. But it could still be claimed that some parts of a solution that I come up with from scratch are taken from it and therefore have to adhere to their licence. It's just better to not look and increase the likelihood that solutions to the same problems are solved in different ways and be able to show working of how one arrived at that solution should the need require it..

That's not a consideration if I use a 3rd party library, of course. And there is no reason that the 3rd party library couldn't be a LabVIEW one. I haven't taken that decision though (hence the thread).

I won't check those links out as I don't want to be accused of plagiarism if I design from scratch. 

18 minutes ago, Jordan Kuehn said:

One feature of a native broker that I would love to see is the ability to cluster brokers like EQMX or other.

Clustering requires either global storage or high bandwidth replication. That would be outside the scope of the initial foray and require (probably)a database for the former.

A long time ago I created some software called Dispatcher (the first version was on Lavag for a while). It had a nascent ability to load balance between multiple services which would register with it. It would be possible to do something similar which would be 1/2 of a cluster. With a load balancer you can do a very rudimentary cluster by making Brokers subscribe to other brokers (Client/Broker hybrids). However. Clustering isn't part of the MQTT specification and is a domain in it's own right.

It would probably pan out as a phased release. First a client, then maybe a broker with consideration for clustering coming a very distant 3rd.

Hi all.

Before you get too excited, this is a sort of discussion to help me figure out what to do for a commercial product. I'm in two minds so I thought more minds could out-vote either of them.

I'm sure some people of the community are ware of ECL. I recently released a new version which fulfilled my bug-bears about certain features I've wanted for a while. Now I'm free to implement anything I want in terms of nice-to-haves instead of "I really want this". So I settled on MQTT as it fits with my aspirations to increase the protocols and ECL now has everything at the lower levels that would be needed for virtually any high level protocol.

So the decision for supporting MQTT is made but I'm in two minds whether to use a 3rd party pre-built library and provide LabVIEW bindings of whether to write one from scratch in pure LabVIEW.

Writing from scratch would be an interesting learning exercise and licencing would not be a problem. It'd take some time but nowhere near as much as I have before a new feature release is due. I've already read the spec and prototyped some stuff and concluded it'd be a pain but perfectly doable once I put more energy in to it. The only sub-decisions I'd have to make is if it would be more elegant to do things like packet and bit stuffing in a DLL rather than LabVIEW as, for my first foray,  I have the impression it would be inelegant in LabVIEW.  But that's not really a factor, just an implementation detail (there are plenty of DLLs that ECL relies on already). I could also support the latest version but it might be a pain to support multiple protocol versions to begin with (rules, eh?).

My other route is to use a 3rd party library and write LabVIEW wrappers. Certainly the easier route for implementation but most libraries only support MQTT 3.x rather than version 5. Then we get to the dreaded licencing. The most complete implementations have awkward licences and the permissive ones are a little incomplete in terms of features and version support. I would definitely need a DLL (not really a problem) and the library would need modification to use existing ECL transports. Current implementations tend to handle the TLS and websockets themselves but I obviously want to use the ECL. Those transports are far more configurable and I want it to fit in with the methods used in all the other protocols (we don't need multiple different ways of defining a X.509 certificate for use, do we?). Additionally, most 3rd party libraries use OpenSSL 1.1.1 whereas ECL uses 3.x so some internal functions must be rewritten  to account for deprecations.

So from scratch (lets call it 1.) means no licence headaches, support latest MQTT version but longer to implement (I estimate 2x longer) but using a 3rd party (lets call it 2.) will be much quicker but require modification, headaches with licences, maybe only MQTT 3.x  and probably a lot less hair at the end of it.

Where I am at the moment is I have both 1 & 2 as stand-alone (which was part of my feasability investigation) where I can connect to a server and subscribe to a topic (no publish, no authentication or funny stuff like Will, QoS and Retain).

So I have to decide which route to go the rest of the way with (1 or 2) or maybe there is another?

Thoughts?

Interesting to note that only 46.4% of shares are held by institutions (as of a couple of months ago). That leaves a whopping 53% in private hands. The directors have been selling some but not all their shares so it' doesn't seem like rats leaving the sinking ship - rather taking advantage of the higher share prices while hedging their bets.

Fun times!

30 minutes ago, Rolf Kalbermatter said:

Not the System Engineering Group that tried to make DCAF and similar.

Ah. DCAF. That was it.

31 minutes ago, Rolf Kalbermatter said:

They have a different division that you and I haven't seen much of yet but that makes complete test systems for EV, semiconductor and other high value potential industries.

I'll have to look into that. From your description, it sounds even more like a takeover attempt to remove competition. I know NI acquired OptimalPlus which was data analytics and in Emmersons domain but not much more than that.

1 hour ago, Rolf Kalbermatter said:

What they want is the test system division which makes complete test systems for the EV, energy and space markets.

NI's system division is quite weak. (What was that awful system software they wrote in LabVIEW?). Maybe they want the customers and talent but I don't see them wanting any of the software. NI, historically, has been a software tools provider for customers and alliance partners to build bespoke systems around their hardware and, if you look at places like CERN and SpaceX, the systems are designed and maintained by in-house LabVIEW developers. Emerson could be worried that the relatively recent systems acquisitions and branching out is eating at their market share so they decided to take out the nascent competitor while they can but NI is no start-up.

1 hour ago, Rolf Kalbermatter said:

to save them from the Emerson hostile takeover bid

They have already saved themselves. Emerson have already admitted that (in not so many words). It will really depend on if the shareholders see a future for NI and are happy with the direction. NI are firmly in the driving seat of this now and it's clear that there is little interest from the board in selling-hence Emersons appeal to shareholders.

I'm feeling comfortable that I'll still be writing LabVIEW software for the next few years and the attempt will go the way it did in 2015. But shareholders are a fickle breed so only time will tell.

Plot Twist:

NI makes a hostile takeover of Emmerson to bolster their systems division. 

31 minutes ago, Rolf Kalbermatter said:

https://www.emerson.com/en-us/automation/automation-and-control

It looks like they are only really interested in the hardware side of the NI business as they are a bit thin on the ground there. For software they seem to be geared towards cloud analytics and control. I don't see much of a place for LabVIEW in their software catalog except as a stop-gap to transitioning LabVIEW customers to their platforms.

2 minutes ago, Rolf Kalbermatter said:

I'm fully aware of that. It just means that this could be an additional hurdle for them to take, not that it is the only one.

It's not a hurdle. It ensures the shareholders control the sale - as it should be. NI have played this by the book and, as I said previously:

On 1/15/2023 at 11:35 AM, ShaunR said:

they will see what the shareholders think of it after having mitigated the threat.

2 hours ago, Rolf Kalbermatter said:

Yep. But a very significant amount of shares (if not even a fully controlling amount) was at least until a few years held by the three founders and in the form of trusts through family members. So it will probably come down to the question if any of the heirs feels enough to sell their share to Emerson for some quick cash or not.

Just buying the shares isn't good enough. They have to first get the shareholders to revoke the trigger for dividends and that would probably take the agreement of more than one or two other major shareholders.

28 minutes ago, Neon_Light said:

Do you have a link to a VSC setup to develop a DLL for Labview? 

Sorry, no. I'm a heathen and use GCC with CodeBlocks.

Quote

“Although Emerson would have preferred to reach an agreement privately, given NI’s announcement that it is undertaking a strategic review, and after refusing to work with us toward a premium cash transaction over the past eight months, we are making our interest public for the benefit of all NI shareholders,” 

And there we have it! They couldn't get them to sell, they tried maneuvering for a takeover (which was thwarted) and now all they can do is appeal to the shareholders. 

1 hour ago, Neon_Light said:

this would provide a function-pointer to a Labview function/vi which would then behave as a callback function.

No. You cannot call LabVIEW VI's as function pointers in unmanaged code ... period!

I will reiterate:

On 1/15/2023 at 3:42 PM, ShaunR said:

You will have to create a C/C++ wrapper DLL that creates and registers the callback with the function and inside that callback use PostLVUserEvent to send it to LabVIEW.

It's only worth going to the original driver and interfacing directly with LabVIEW *IF* it means you don't need a callback.

LabVIEW cannot supply callbacks for unmanaged function calls. You will have to create a C/C++ wrapper DLL that creates and registers the callback with the function and inside that callback use PostLVUserEvent to send it to LabVIEW.

You've read those articles but haven't quite understood that you need a DLL wrapper and it is what actually registers and executes the callback with the function.

14 hours ago, Rolf Kalbermatter said:

That was actually my first name I came up with when reading that press release from NI.

About the dilution of shares, it was exactly my understanding that this is to fight against a hostile takeover. But the rest of the press release does not sound like they are trying to fight to be taken over, rather the opposite, and that felt kind of contradictive. 

Whether they would allow a takeover or not is really up to the shareholders. A professional group wouldn't be tying the hands of their shareholders with outright condemnations of potential future owners. My understanding is that this was an automatic response triggered by their share structure to prevent such things. This action will mean it cannot easily be forcibly taken-if that is actually what is going on.

If you remember. Elon Musk increased his holdings in Twitter to 10% just before he bought them out. Twitter didn't mitigate it like this though.

My interpretation was that they acknowledged someone was prowling and making moves and, now they are aware, they will see what the shareholders think of it after having mitigated the threat.

13 hours ago, X___ said:

https://finance.yahoo.com/news/ni-appoints-cfo-140000382.html

$450k per annum with 100% bonus and 1.5M stocks. It beats the crap out of what you get for playing the piano.

13 minutes ago, X___ said:

https://www.reuters.com/markets/deals/ni-explore-options-including-sale-amid-interest-emerson-electric-sources-2023-01-13/

No that much of a surprise. Emerson have been eyeing NI for a long time. Here's something from 2015...

1 hour ago, Rolf Kalbermatter said:

That were my thoughts too, but I read it on Yahoo. And while they don't usually tell total bullshit like some other news sources, their reporting is usually not very accurate.

Well. It would be consistent with: 

Quote

reduce the likelihood that any person or group gains control of the company through tactics like open-market accumulation

and since they state 

Quote

interest from potential acquirers and other transaction partners, some of whom have already approached the company.

and time (or lack of it) seems to be important

Quote

provide the board and shareholders time to make informed decisions.

my money is on a hostile takeover.

Interesting...

It's not the usual option for selling a company. You don't dilute your shares if you are going to sell. You normally do this sort of thing either if cashflow is a problem or you are facing a hostile takeover.

3 hours ago, LogMAN said:

Here is the kind of response it produces for LabVIEW:

The responses are impressive but it doesn't look like we are getting replaced any time soon... 

Very much the tail wagging the dog but it could certainly replace many of the managers I've worked with.

2 hours ago, X___ said:

ChatGPT: An error occurred. If this issue persists please contact us through our help center at help.openai.com.

They should give it an error code. I would suggest Error ID:10T

There are a number of interesting points here though.

1. It evaluates logical inconsistencies - it's doesn't seem to be just a look-up or query engine.
2. It doesn't know how to say "I don't know" or suggest alternative sources where information may be sought - It doesn't comprehend its own limitations.
3. It behaves more like an Oracle than, say, quoting or suggesting papers where certain arguments or theorems were undoubtedly gleaned - e.g. Leibniz,  Riemann et. al.

Did you also ask it for the source of it's information or to introspectively analyze it's own answers to see if it could identify the flaws in it's own reasoning? 

Yes. I was much more impressed with the imaging AI's.

This video builds a website. The imaging is very straight forward and produces excellent results. He then uses ChatGPT to make some text (which isn't that awe inspiring) and then puts it all together with one of those do-it-all web services. In reality, the only impressive thing here is the imaging.

However. ChatGPT is only used for a bit of content, not for creating the website proper. He spends a lot of the video creating the web pages in a service to use the images. I think the days of web businesses like Shuttershock are over though.

NXG was XML, was it not? Good job they abandoned it.

2 hours ago, jcarmody said:

I asked it to and it said something about not being able to do graphics.

Sigh.. No early retirement for me then. 

5 hours ago, Antoine Chalons said:

all I've seen is this (on the french section of NI forums)

I suppose if I was prepared to give Skynet my telephone number I could have had it translate for me.  But from Google it seems that was another fail to do LabVIEW.

Even so. All the examples of how fantastic it is for text languages seems to always be fairly trivial examples - mainly single functions, that they cajole to an answer.

My first impression is that it's an excellent natural language interpreter but not impressed with the claim that all our coding jobs are in danger. I'm much more impressed with the Graphics AI's such as Midjourney.

Everyone is losing their minds over ChatGPT. Well. Text programmers are 

Anyone played with it to try and produce LabVIEW code?

5 hours ago, bna08 said:

I could select Use Default If Unwired in these cases and not use the wire at all, however, that will set the reference value to null and I won't be able to use it anymore. 

Right click on the tunnel and select "Linked Input Tunnel>Create and Wire Unused cases"