ShaunR

nipbcfk.sys is a system filter driver for the PCI bridge. All remedies you will find for PAGE_FAULT_IN_NONPAGED_AREA when a system driver is involved will be something like "Uninstall the driver and contact the vendor" Only NI can fix this one.

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.

Maybe it requires privilege escalation because it's in an executable. Maybe it needs a confirmation to run the command. The only way you will know is to not hide the cmd window and run it with the "/k" switch so you can see what it's actually doing.

Snippets don't work very well and the meta information is stripped by some websites and browsers. It is always better to post the code. Probably the "cmd /c where nvcc" isn't finishing for some reason (waiting for input?) and as you have the cmd VI set to wait until completion, it just gets stuck there.

I overlooked it in the initial post but NI also changed their Rights Agreement. They's fighting hard. That last one is a doozy and is probably the "poison pill" Emerson are talking about.

Really? They sound kinda desperate. Especially as their offer is now under the share price rather than 38% over.

Ooooh. They want it bad. They salty

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. I've already explained about licencing. 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.

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