ShaunR

I won't check those links out as I don't want to be accused of plagiarism if I design from scratch. 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!

Ah. DCAF. That was it. 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.

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. 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.

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.

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:

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.

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

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.

No. You cannot call LabVIEW VI's as function pointers in unmanaged code ... period! I will reiterate: 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.

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. $450k per annum with 100% bonus and 1.5M stocks. It beats the crap out of what you get for playing the piano.

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

Well. It would be consistent with: and since they state and time (or lack of it) seems to be important 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.

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

They should give it an error code. I would suggest Error ID:10T There are a number of interesting points here though. It evaluates logical inconsistencies - it's doesn't seem to be just a look-up or query engine. 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. 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. Sigh.. No early retirement for me then. 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?

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

C:\ProgramData\National Instruments\Partners

Interesting. I assumed you used the TEK one here. It looks very much like the whole API is a "work in progress" as many functions are not supported and... Do they distribute the DLL source code as part of an SDK?

The caveat here though is that USB is not an easy interface even in LabVIEW. I've heard that many people decide to make a MAX configuration instead of USB driver because it's just so damned low level and does anyone remember the difficulties with webcams? I use libusb and a 3rd party wrapper for the RTL-SDR which is not only far easier but much faster. A wrapper and DLL driver is probably a must for asynchronous callbacks - it's not for the faint-at-heart. The only time a USB device is easy is when it presents itself as a COM port which I very much doubt for streaming high speed IQ data.