ShaunR

Generally it is LabVIEWs implementation of OOP. The poor compile times, the complexity, the maintainability, the ballooning of the code base and the bugs. Classical LabVIEW is easy and arguably produces more robust code that is easy to understand for engineers rather than CS academics. I often talk about "pure" and "applied" programmers (an analogue to pure and applied mathematics) and Classical LabVIEW is great for applied programmers. OOP is unnecessary complexity in all but the most fringe use cases and it has sucked all the development resource of the language for features that could have benefitted how a vast majority of production code, that does real things, is written. But no. Interfacing with the windows subsytems, that I'm used to never uses objects. It uses functions in dynamic libraries that take data arguments. Opaque pointers to objects is the quickest way to a GPF and in LabVIEW that means taking out the IDE too. It is only when you get to .NET that you forced to start interfacing with objects and I think you know how unimpressed I am with that-it's banned from my projects. If I want to use .NET I would use C#, not LabVIEW-one advantage of being a polyglot, so to speak, is that I'm not limited to one programming language and can choose the best tool for the job.

Exactly!

Without successfully being able to convey the fundamental difference between LabVIEW and, say, C[++] or pascal and the many other procedural languages that OOP was proffered as a solution for. You should perhaps put my comments to one side while you fill out the feature set of the API. I will leave you with this, though. Why isn't a VI an object?

It doesn't support it at all because messaging is a method of breaking dataflow and, if I am feeling generous, it is an equivalent of dataflow with one input to satisfy. The idea that dataflow is "data flowing" - moving from one place to another - is a simplification used to teach the concepts. In fact, it is about "state". What defines a dataflow language is that program execution continues when all inputs are satisfied. Execution state is manhandled in other languages and concepts, by ordering function calls (procedural) or unwinding a call stack (functional) and still proves the main problem of them today. This is why we say that dataflow languages have implicit, rather than explicit, state. Specifically "execution state" is implicit rather than "system state". From this perspective, you have broken dataflow for excellent reasons and are proposing to add back it back in with added complexity so that it "looks" like dataflow again - a problem of your own creation like so many other main-stream, non dataflow,concepts, when applied to LabVIEW. The solution will be a service, actor or whatever you want to call it, that has visibility to global execution state. In classical labview we would just call a VI as non-reentrant from the three loops and allow the implicit nature to take care of ordering and progress of the loops. However. I understand the desire for "completeness" of your API and that's fine. However. Futures are a fix for yet another self inflicted problem of OOP dogma so I don't agree that there are no OOP concepts involved. In LabVIEW, futures are an architectural consideration; not one of implementation.

If you use Yocto then one of the formats for output is a VM image aside from the more usual *.img and *.iso. The NI repository has a Yocto recipe for building NI-RT. After 3 days of fighting with Python and compiler toolchains, I popped my cherry with a Raspberry PI and custom Image (which are included in Yocto and all worked fine). Onwards and upwards to NI-RT. I got to the stage of finding out that everything turned to crud because Yocto isn't backwards compatible (I had 2.2 and NI use 1.8) so rage-quit at that point and posted on here after seeing Daklus comment If you want to really be depressed. Follow the link in the readme.md of meta-nilrt for "Building the Layer" where all your questions will be answered.

Ahh. But I am all the way I need enough to merely debug SQLite, OpenSSH and OpenSSL on some semblance of the NI-RT target. I care not for DAQ, VISA, Vision or anything else. Since this is for internal debug. I don't really have any open source obligations either, unless I distribute the VM. The aforesaid binaries I use have already been researched and I comply with the licences for the end products. The new plethora of licences of the RT-Target will cause me to research each individually for compliance. The risk of overlooking a clause that predatory licence practices rub their hands with glee at, means I would probably not if it is more than some arbitrary number of hours or days. That effort would also have to be replicated every time there is a new release and I would probably end up spending time writing tools and systems to catch changes.The Linux community seem happy with this arrangement (even though Linus Torvalds isn't). I would therefore rather just not use it and have not used it prior to windows 10 for these exact same reasons to the extent that I withdrew Linux support even though most products work with it. Thus I will be prevented from sharing the fruits of that [VM] labour before it has even begun. That is the tragedy of the commons of open source. Of course. I could just install the old-ass version of Yocto and decimate my version 2.2 which took 3 days of pursuing rabbits down very deep holes to set up and get working . That wouldn't help me preventing others from the same pain of getting hold of a VM, though.

Good idea to move. Thanks. Maybe move the other responses here too? I really don't want to pollute the other thread. The problem is that if you do manage to get an image from a device, it probably won't be compatible with a VM. It may be ok to put on another identical platform, though. When you compile Linux stuff, there is a whole tool-chain dedicated to figuring out what system you are compiling on and then setting a shedload of compiler switches and includes (which never work out-of-the-box, in my experience). Cross compiling is even worse. Linux is the worst platform to maintain.. Of course. NI could supply us with one then licencing, obnoxious build tools et. al. wouldn't be a problem and we can get on with the proper programming instead of sorting out 1980s build systems.. As far as licencing is concerned. Linux doesn't make it easy. The onus is on us to identify all the different licences and then comply. Since distros are an amalgam of software written by a multitude of crazy militants; each have different ideas about who can and can't use their software; it is a minefield. The Linux kernel on it's own is a known quantity (GPL) and if they have produced a custom kernel, that is sticky. But who knows what what NI libraries and support binaries from 3rd parties have been added (well. NI do).

Why would you want a dataflow construct when the language supports it implicitly, then? Unless it is to fix the breaking of that dataflow because of the LVPOOP ideology. However. If you are trying to make a distiction between OOP and OOD. Then I am in agreement since OOP is not required for the latter.

You haven't noticed? It probably has something to do with being one of the 5%.

Have you built a VM with the NI-RT Linux? I had a go but they are using an old-ass version of Yocto.

It doesn't matter. If it's for communication then prepare the listener for your definition (whatever that may be) and then use that and move on to important things about the code-just be consistent. I get fed up being asked to ponder philosophical significances in OOP.

LabVIEW 2016 supports TLSv1.2.

Be aware when benchmarking globals that their access times are heavily dependent on how many instances there are and whether reading and/or writing. They deteriorate rapidly as contention for the resource and copies of the data increases..

Place the polymorphic VI on the diagram and click the label at the bottom. A menu with all the functions will appear which will enable you to choose from all the functions. Copy and paste the VI (or drag with the mouse+CTRL to create a copy) and choose another function as before to create another function.

You don't need to defend yourself on some arbitrary forum. The relationship (or lack therof) between yourself and NI is between you and NI alone and it is up to NI whether they want to challenge or defend their IP. Questioning a companies' integrity in public is highly unprofessional and you do not need to respond.

I have several use cases in mind with the usual software distribution and distributed databases/file systems. A few others too that are closer to what you are describing but they are more a case it could be used but there are probably better ways-I would know more later. Service discovery is a means to an end for DHTs if you consider supplying a key-value pair a service. The difference between Kademlia and Chord is basically how they search and contact providers of specific key-value data with an expectation that someone will but without caring who. If one of each service is expected in a system then I'm not sure what would be gained and there would certainly be much faster ways but if you wanted to spread configuration data amongst all services for fail-over (effectively a distributed database) then maybe. Off the top of my head. You could probably use the routing table from a DHT in some way but it's a big "depends".

Has anyone worked with, implemented or investigated DHTs in LabVIEW? I'm particularly interested in Kademlia/S/Kademlia and Chord so would appreciate any input specifically about those, but any other DHTs that have been played with would be great for discussion.

I'm not sure what you mean by "entirely offline". Javascript libraries can be loaded in any browser off of of the local file system so online servers are just the delivery mechanism for the Javascript code. Dynamically updating the variables in that Javascript has a number of options from Websockets, WebRTP, the local NI Webserver and so on. If push came to shove, you can use the .NET Internet Explorer browser control on the front panel and pretend it is just a graph control.

I investigated some but not plotly. I settled on flot for the Websocket API for LabVIEW and it is the API used for the Dashboard example . Raphael was a close second but it is more generic in drawing vector graphics as opposed to just graphing/plotting so is harder to use. I have mentioned before that I now use browsers exclusively for LabVIEW UIs so if the main attraction is the data sharing aspect of the plotly online service or if you are constrained by it appearing on your FP, then it's probably not what you are looking for. If it is for creating superior graphs then it is perfect.

Except for the bits that are not

You are absolutely correct but a non-reentrant VI is the equivalent of a blocking socket as opposed to an asynchronous one and we can argue all day about the pros and cons of that. (It usually ends up as "it depends")

Seems to be an error in the LabVIEW read function rather than an OBEX protocol error (which would have "OBEX Error "). I would expect this sort of error if the server was closing the session before attempting to read. What does the server log say about the connection when you see this error?

Seeing as you have not specified what the error is; I had to mind-meld with your Raspberry PI 3 and it informs me it is just trolling you.

While true, it is fairly easy to mitigate using property nodes to handle groups of controls. The main reason I refuse to use tab controls is because of the difficulties with control scaling and positioning - especially with splitters on the FP and tab itself. Otherwise I have no particular problem with them.