Rolf Kalbermatter

I love number 7). 😀 Serves you right if you used DAQmx Express VIs! The recompiling of VIs is not enough punishment for such a crime! 😎

Technically very much so. But it is an effort to support multiple platforms. If you intend to commit some backing to Shaun/LVS-Tools I’m fairly convinced he can come up with some proposal. And if he wants to I can even offer some support. But I’m very sure he can do it also alone if there is some incentive. 😀

Well. It's more likely a very resounding "I have no idea if I'm ever going to need that. For now I just refrain from commenting on the matter!" 😎

Ok, this is not gonna work like this. The sample code you show uses gobjects to start its own loop and do event handling all through it. gobjects is basically a glib task handling system. It's in fact its own execution system and is for instance used as base of gtk and in extension GNOME. But these are build on top of gobjects. LabVIEW has its own execution system and marrying two of them together is a major exercise in coding. In fact it is almost never done since it is so difficult to do right. You will need to try to find the lower level interface of this aravis library. It will require you to call lots of functions with the arv_ prefix and similar, but you must avoid anything that starts with g_. Basically you would need to start writing something like IMAQdx with many of its functions but instead of calling into IMAQdx you call into the arvis library. It's doable but not for the faint of heart. Basically trying to interface to image acquisition hardware and libraries is very difficult. Always! And there is a reason these libraries cost money and there are very few freebies here. The Arvis library itself seems to be free. Its LGPL licensing can be problematic for anyone wanting to use it for a commercial program. And while it states to be LGPL there are actually files in there that state to be GPL. So licensing is not completely clear cut there. Incorporating GPL software in anything other than GPL software is basically impossible.

I'm not sure you did a service here. Trying to do callback functions through Windows messages is both not straight forward and in fact the master class of interfacing to a shared library. Considering that his shared libraries are .so files, he also obviously is not on Windows but Linux,

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.