Rolf Kalbermatter

Show your code! It's not the meaning that you simply export that main function and call it! you need to take it apart and export separate functions for at least Open, Grab and Close.

I would agree that it doesn't quite look "monsterly" but there seems to be some cross contamination between simple configuration stuff and actual test specs or data results or whatever it is. If you talk class it would only be an improvement if you start about taking these apart into more fine grained classes. Some manager class that then can contain the individual test classes. Otherwise you simply replace a somewhat unwieldy cluster through a similar unwieldy class. And that is no real improvement at all. A class simply is a cluster on some steroids anyhow. (Yes I know it is a sloppy statement but for many purposes it is quite accurate).

The best approach would be to take that code and make your own shared library from it. Export functions to Open the device, Grab Images and Close the device. Basically you do not want an executable with a main function but instead you want a shared library that seperates those indvidual functions out. Why not call the underlying library directly through the Call Library Node you may ask. Because you have a callback function in there! It may be possible otherwise but that callback really is a no go for direct LabVIEW interfacing.

Most likely because of its use of DTLS. 😁 OpenSSL's support of this was fairly "flaky" back when I did my Network library. Many problems were surrounding it, some of them were actually kind of unfixable with the DTLS standard at that time. Now this was around OpenSSL 0.9.6 or so, so I would assume that a lot has changed since. And yes I got it to work, but only had done minimum testing with it. It was clear that more extended use of it would sooner or later bring out troubles with it. Some for sure in my interpretation of the OpenSSL API at that time, but some also unfixable for me without changing OpenSSL itself.

It's just the label of the control inside the array shell. Usually invisible but certainly can have a label. And label oddness with VIMs is not that strange. They seem to have some trouble to track all the label things properly across multiple types and compared to the actual datatype it's really just cosmetics. 😁

Not yet 😁

But LabVIEW for Linux (and Mac and any other non-Windows version) has no .Net functionality, no matter if you try to use Mono, or .Net Core.

I haven't looked at MQTT but this kind of ID is usually only really used to match responses to the request and/or verify that you got the right response. It should not contain any crypto relevant value, so I would not expect it to matter. More important would be that you can reasonably guarantee that your random generator never will result in the same ID being returned within a small time window, as that makes the whole purpose of being able to match the response to the request pretty difficult. In that sense a monotonically increasing ID that eventually wraps around is actually more useful than a true random ID. Usually the client generates the ID and sends it with the request. The server simply copies it into the response without doing anything else. The client can then verify that the received response is actually for the sent out request and not some other stray request. In a connection based protocol using TCP/IP, this is usually kind of superfluous but for UDP or serial port communication it can be useful.

A LabVIEW handle is however: typedef struct { int32_t status; double value[]; } DataRecord, *DataPtr, **DataHdl; ...... ...... DataHdl handle = NULL; The important part is the double pointer in front of the handle datatype. The array declaration of the value element is more a cosmetical thing and may not work like this with your compiler. You may have to add a 0 or even 1 in the brackets to let your compiler accept it. It has no real influence on the code unless you try to use sizeof(DataRecord) somewhere, which is not recommended.

Unfortunately that is true. LabVIEW wants to link to object methods by MethodID (a 32-bit number that has to be changed when the method signature changes). If LabVIEW would instead use the MethodName (which it also stores in the Method Node, it could adapt to changes in methods as long as those changes only affect optional parameters). With access to the LabVIEW source code this would have been a change of a few hours, but with ActiveX being anyhow legacy now, even that effort is of course to much to spend.

Actually the underlaying DCOM technology that is the basis for ActiveX is perfectly able to invoke an Automation Server out of process if it detects that it can’t be run in the current process, such as when the bitness between caller and server doesn’t match. The ActiveX Server needs to be registered accordingly for both environments properly and this is what the Repair install seems to do. However it may not be always true for every Office365 installation and Microsoft definitely is trying to get away from ActiveX and is deliberately marginalizing support for it more and more.

It usually works, unless it doesn't. And that has in my case always been associated with the click to run installer that IT seems to use. For some reason this installer does not properly register the still present ActiveX libraries for Office in the Windows system. Which results in the situation that LabVIEW complains that it can't find the ActiveX classes anymore. Going into Control Panel->Applications and Programs (or something to that extend, the name keeps changing between Windows versions) and doing a Repair Install of Office 365 so far has made this work for me. But I'm not using the Microsoft Office tools to often from LabVIEW, so this feedback is at best incidential.

It's most likely organically grown. Guaranteed green and maybe even vegan. 😁 And grown and groomed by many different "developers".

That's usually the way I work too. And since there are classes I usually create a base class that is a simulation, dummy or whatever you want to call it version and then a derived one that is the actual implementation, possibly with another one that is for a different similar device or over another bus interface. My experience about trying to create a universal, generic class hierarchy for one or more device types is that it is a never ending story that will make you go back and forth over and over again as you try to shoehorn one specific instrument feature into the existing class interface to eventually notice that it breaks another feature for a different interface in the same place. Basically it is a noble pursuit to try to do that, but one that fails sooner or later in the reality.

Most likely because everybody says that same sentence, waits for our savior to bring the holy grail and then forgets about it after said savior hasn't arrived within a month or two. Some creating their own limited version of it but never bothering to go the extra mile to post it somewhere for others to not have to wait for that savior anymore. 😁

Sure you could nowadays create almost a clone without fearing an NI letter to arrive. But who wants to do that?

This kind of idea comes up frequently and various people have tried to solve it. In the end almost everybody ends up writing a simulator for his specific device and then moves on, since there are other projects to be done that deliver income. Writing a generic simulator sounds like a good idea, until you start to work on one. First problem, lots of instruments have very different ideas of how they want to behave on invalid input, wrong sequences and conflicting settings. Some simply go into a lock mode that you have to take them out of, sometimes with a literal kick in the ass by pushing the power button. Others will refuse wrong settings and some ignore it and act like there has nothing been sent. A few try to be smart and will change anything needed to make the new settings work, even though you told them in the previous command to go into this or that mode. The next problem is often that writing the specific command instruction file for your generic simulator is almost as trouble some as implementing it from scratch. Either simulator only supports the most trivial command response pattern and the command instruction file is trivial but the behavior of your simulation is far from close to your actual device, or it supports many modes and features and your command instruction file is getting complicated too. And almost with every new device you want to simulate you are pretty sure to need to go into your simulator to add an additional feature to support some quirk of your new device. The end result is that there are many people with good intentions to write such a beast and none who goes beyond a simply device specific simulator, and even that one is seldom really simulating the real thing close enough to be able to test more than that your program works if everything is going right, which in reality it often doesn't.

That custom control editor is one of the more arcane parts of LabVIEW. It exists since at least LabVIEW 2 and has seen only small improvements since. And according to its original creator back at that time it is a pretty nasty piece of software code that would need a complete rewrite to be able to make more elaborate modifications to it. Chances for that to happen are about 0.0something % nowadays. Unless someone somewhere is willing to pour a few millions into this. 😎

My snarky response would be LabVIEW NXG. 😀 More realistically you could consider the LabVIEW realtime and LabVIEW FPGA as parts of a bigger suite. BridgeVIEW morphed into the LabVIEW DSC (Data Logging and Supervisory Control) Module long ago (LabVIEW 7 or so), which is an addon, similar to Vision Control and such. But it is legacy: 32-bit only, not really improved for a long time, it is still using SQL Server Express 2012, which is not compatible to the latest Windows versions.

I'm not convinced. They either have no idea about how complicated LabVIEW is or just hoped they could put some sand in the NI managers eyes by teasing them with what they thought is still NI's pet child.

That is partly NI's work. They were pretty aggressive about defending their idea by applying for quite a few patents and defending them too. Of course if you go to the trouble to apply for a patent you have to be willing to defend it, otherwise you eventually loose the right to a patent anyways. And they did buy up some companies that had something similar to LabVIEW, such as DasyLab for instance, although in my opinion DasyLab didn't quite go beyond the standard "wire some icons together" similar to what HPVee did, and what Node-Red is doing too. But they tried to use some structures that were darn close to LabVIEW loops and that was a prominent NI patent. So NI eventually approached them and made them the offer to either buy them or meet them in front of a judge. The rest is history.

Well, I do have a VI library that can talk VI Server, at around LabVIEW 6 to 7. The principle seems still pretty much the same, but there were a few zillion new attributes and methods added to the VI Server since, and classes, and what else.

Actually, as far as the UI goes it depends quite a bit what you want to do. For fairly simple UIs that "just work" it's still an amazing easy system. If you want to support the latest craze in terms of UX design, then yes it is simply stuck in how things were 20 years ago. Basically if you need a functional UI it works fairly easy and simple, if you need a shiny UI then LabVIEW is going to be a pain in the ass to use. Nowadays Beckhoff and Siemens and others have their own UI solutions too, but in comparison to them LabVIEW is still shiny and easy. Beckhoff does have the advantage that their UI is HTML5 based so easy to remote but it looks like a stick figure compared to a Van Gogh painting when you compare it to a LabVIEW front panel. My dream was that they can develop something that allows the LabVIEW front panel to be remoted as HTML5, but seeing the Beckhoff solution I start to think that this project failed because they did not want to settle with simple vector graphic front panels but wanted to have a more native looking impression in the web browser. And yes documenting the VI Server binary TCP/IP protocol and/or adding a REST or similar protocol interface to the VI server would be an interesting improvement.

No, Watcom C was used to compile LabVIEW and LabWindows CVI for Windows 3,1 because it was pretty much the only available compiler that could create flat 32-bit code at that point and absolutely the only one that supported this on the 16-bit Windows platform. They did not have a license to use the compiler in there and it was several years before Watcom faltered and a few more years before its sanitized source code was open sourced. It still exists as open source but activity on that project is very dead.

LabWindows CVI did use a lot of LabVIEW technology originally. Pretty much the entire UI manager and other manager layers such as File IO etc were taken from the initial LabVIEW 2.5 version developed for Windows. On top of that they developed the LabWindows/CVI specific things such as function panels, project management and text editor etc. The C compiler was their own invention I believe. Later, around 2010 or so they used replaced the proprietary compiler in LabVIEW with LLVM as compiler backend and after that they used that knowledge to replace the LabWindows/CVI compiler with the same LLVM backend. Callback support in LabVIEW, while not impossible to do (ctypes in Python can do it too). always was considered an esoteric thing. And IMHO not entirely incorrectly. The problem isn’t so much the callback mechanisms itself. Libffi is a reasonable example how it can be done although I’m sure if you dig in there it takes you a few days to understand what is needed just in a Windows application alone. The much more difficult thing is to allow a configuration in the Call Library Node that doesn’t require a PHD in C programming to configure it correctly to match the callback function correctly and the mapping from the callback function parameters to the callback VI inputs and outputs. ctypes in Python is much more straightforward because Python is a procedural language like C and even there you have only very few people who can handle normal function calls and virtually nobody who gets the callback functions right!