Jump to content

ShaunR

Members
  • Posts

    4,840
  • Joined

  • Days Won

    290

Everything posted by ShaunR

  1. Me neither. What exactly are "the LabVIEW suite of offerings"? (Please don't tell me BridgeVIEW or whatever they are calling it now )
  2. Well. They are not really equivalent. System Link is, first and foremost, a configuration and asset management tool. Buggy? Maybe (I haven't looked recently) but that could be addressed. WATS is specifically a data analytics tool. WATS has more in common with Diadem than System Link.
  3. 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.
  4. 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.
  5. 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. 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.
  6. I think the C compiler was (or was based on) on the Watcom compiler. 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++
  7. 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.
  8. 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!
  9. I like your solution. I've always used moveblock with strlen which, although it seems faster, is far less intuitive. On a different note. Try not to use those utility functions at all. They all run in the Root loop! I may use them for prototyping but always replace them in production code.
  10. Yup. Sorry to be less helpful. Probably the only thing you could do is to try a different manufacturers laptop which should have different hardware. I know LabVIEW 2022Q3 runs fine on Windows 11 in my VM but that's not very useful either.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. Really? They sound kinda desperate. Especially as their offer is now under the share price rather than 38% over.
  17. 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.
  18. 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).
  19. 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.
  20. 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?
  21. 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!
  22. 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.
  23. 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.
  24. 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.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.