Rolf Kalbermatter

Have you built your executables for debugging? By default LabVIEW removes all diagrams from build executables and libraries and that leaves indeed nothing to debug. In the Build settings you have to enable the checkbox to built for debugging.

Congratulations on your new endeavour. Working for a space program is one of those dreams every technically inclined boy probably has at some point. It actually even tops the dream of working for Lego. 😄

This thread is about Ethernet/IP, a specific protocol used in industrial automation. While it might be possible to install Eternet/IP support on your PLC, there is nothing in the product description of Epec's controller hardware that mentions anything about it. Most controllers support CAN with CanOpen, and only very few controllers have even an Ethernet port. But all the literature mentions is that it allows integration into IoT networks, which would probably indicate that it supports some HTTP or WebSocket protocols, but hard to say for sure, how they support Ethernet connectivity in their controller software.

Yes it could if this driver was developed in LabWindows/CVI. And there are some parts that get installed with LabVIEW that were in fact developed in LabWindows/CVI and therefore will cause the runtime engine to be installed. LabVIEW runtime itself does not need it however so its logical that it does not install them. Where did you deduce that it needs the 4.0.1 version of the CVI runtime? That is an awfully old version released about 25 years ago. I would guess that the DLL needs a newer version unless it was released in the late 90ies of last century. Edit: I just see that the copyright is 1997 to 2001 so your version might be in fact not very much off. Although a never LabWindows/CVI should work too. LabWindows/CVI did not use version specific runtime libraries and the functions were usually kept backwards compatible.

It's not really weird. The NI Analysis library is only a thin wrapper around the Intel Math Kernel library. And that library does all kinds of very low level performance enhancing tricks. Part of that is that it determines at loading what CPU, number of cores and which SIMM extensions the CPU supports to tune its internal functions to take maximum advantage of the CPU features for performance reason. It so happens that the detection code for this trips over its feet when presented with an AMD Ryzen CPU and rather than falling back to a safe but not that performant option it simply aborts the DLL loading which in turn aborts the LabVIEW wrapper DLL loading. LabVIEW doesn't know why the loading of the DLL failed, just that it did fail. Of course, anyone suspecting any malevolence in that failure of detecting a competitors CPU, really must be ill minded. 😀 Realistically I suspect it wasn't malevolence, but the fact that it wasn't for their own CPUs didn't quite make the urgency to fix it very high. And NI doesn't update the AA library every few months to the latest and greatest MKL release, as that has some serious implications in terms of testing effort.

If the driver itself only consists of this single DLL, then that still does not exclude the possibility of dependencies, but a little different than what I deduced from your first post. Every C(++) compiler will use a C (and in case of C++ also a C++) runtime library for all the standard functions that a programmer expects to be able to use. This runtime library is similar to the LabVIEW runtime engine. While it is possible to include the relevant C runtime functions together into the DLL, this is often (and in Visual C by default) not done to make the DLL not contain redundant code that is elsewhere available on the system. Now most C compilers have long ago started to use version specific C runtimes. If your DLL was created with Visual Studio 2010 for instance, it is set to depend on the Micosoft C runtime version 10.0. A Visual Studio 2012 executable or DLL is dependent on Microsoft C runtime version 11.0. Each C runtime has its own set of DLLs that need to be present on the target system in order to load a DLL or EXE created in the according Visual Studio version. Microsoft Windows comes pre-installed with some C runtime installations and that can vary over time since various Windows tools are compiled with various Microsoft C compiler versions. And LabVIEW and many of the NI tools are created in various versions of Visual Studio too. So what most probably happens is that on a full LabVIEW IDE install some of the libraries or tools installed uses the exact same runtime version as your DLL. On a normal LabVIEW runtime installed machine this specific NI tool or library is not necessary and hence not installed and therefore loading of your DLL must fail. Your DLL manufacturer needs to document in which version of Visual Studio the DLL was created to let you download the according Microsoft C runtime installer from the Microsoft side (or provide that installer together with their DLL).

Obviously your DLL has other DLL dependencies. And it is the task of Windows to resolve such scondary dependencies. But Windows won't search in the directory the referencing DLL is. Instead Windows has a number of standard locations it will look for such DLLs. Make them appear in one of those directories and things are well. 1) if already loaded it will simply reuse the DLL 2) In the directory the process exe file resides 3) in the Windows\System32 directory 4) in the Windows directory 5) in the current path, which starts in the process exe directory but is affected whenever you dismiss the file dialog in an application 6) in one of the directories listed in the PATH environment variables. The quick fix is to move your DLLs in the same directory as your build exe You most likely have installed the driver at some point on your machine and it put copies of the DLLs in Windows\System32. You then copied those DLLs into your project library but all but the directly called DLLs through the Call Library Node are then basically never used since Windows will find and load the DLLs from the system directory.

Well, OpenCV has various parts which were C++ since a very long time, some of them with C wrappers but not everything. And they moved more and more to a C++ API as that makes writing code easier once the proper ground works are defined. So for a pure C API you will need to go back quite a bit. Also while I haven't checked recently the OpenCV library did not remove the classic C API last I checked. Maybe they did in the meantime. But image manipulation is not something you can easily interface to with the Call Library Node anyhow even if the API is pure C. The memory management problems associated with images are complicated enough that trying to directly interface this to LabVIEW is going to be a very painful exercise. LabVIEW is by nature a by value programming environment which would be terribly wasteful to apply to pictures. This means you have to somehow create an interface between the two anyhow that wraps the whole in a way that makes it intuitive to use in LabVIEW without the inherent overhead of treating everything by value. This is best written in C but with LabVIEW specialities in mind, and this is also what quite a big part of IMAQ Vision is actually about. So while you can try to interface to OpenCV directly up to some point, it's not going to make a pretty interface to use, since you will have to bother every user of your library with C specific trivia that a normal LabVIEW user is not used to (or write a huge interface layer in LabVIEW that wraps everything up and uses techniques that would be easier implemented in C(++).

You can not call C++ objects with the Call Library Node without going into custom assembly programming. C++ is NOT binary compatible between compilers and often not even between compiler versions so there is no common ground on which the Call Library Node could even start to attempt to provide an interface to that. What you have to do is developing your own shared library wrapper in C++ that exports standard C functions that you can then call with the LabVIEW Call Library Node. In the most simply case you could simply wrap each method of an object with a function like detailed in the labview wiki here: https://labviewwiki.org/wiki/DLL/shared_library While this is the quickest approach to getting something working it is not the most convinient approach for other potential LabVIEW users of your library since you basically hurdle them with many C++ API intrinsicacies that a typical LabVIEW programmer has no idea about.

All incantations of the Winutil VIs out there are in fact from that library or its predecessor. Also the VI copies in this Multipanel Example.

I simply took the library from the NI site and threw out anything that was accessing the DLL and then changed things to work for both 32-bit and 64-bit. I'm guessing it would therefore be under whatever license it was, which I think would be the NI Example Code License, whatever that actually means.

I find the description of the command syntax in the manual anyhow highly ambigious and unclear. Usually GPIB devices from that time were supposed to state one long list of capabilities in the form of abbreviations. Those were pretty important before IEEE 488.2 was released, since the GPIB bus had many capabilities and most devices only supported a subset of them. IEEE 488.2 defined a minimum set of capabilities that a device had to support in order to claim 488.2 compatibility (in addition to basic command syntax and such) and after that this capability list got almost completely redundandent. A GPIB complying device that does not support 488.2 is supposed to list these capabilities somewhere. Usually they were both mentioned in the manual as well as a sticker somewhere on the outside of the device.

Just as an extra reference point, this post contains a redone winutil.llb file where all the references to the private winutil DLL have been removed and as far as possible replaced to compatible direct calls to the according Windows APIs. In addition the Call Library Nodes have been updated to be compatible for 32-bit and 64-bit operation and I also added one or two functions from this example into the library as well. In order to support seamless 32-bit/64-bit support one has to make sure to use the new Windows control contained in that lib for everything and modify any other Call Library Nodes your project may use accordingly too. https://forums.ni.com/t5/LabVIEW/How-to-run-an-exe-as-a-window-inside-a-VI/m-p/4096356#M1179928

I was refering to the instrument manual. That one has absolutely nothing to do with VISA whatsoever. It has about two half pages of IEEE description and some very limited command description. Not very extensive in any form and flavor. NI VISA on the other hand is very capable of also accessing IEEE488.1 devices, which is the name of the old style IEEE488 interface specification. Doing so is however not trivial as those low level settings can be obscure and not easy to understand without knowing how the GPIB bus works on signal level. And it is usually not necessary since all the modern devices simply work with IEEE 488.2 settings which are the default when you open a GPIB VISA session. But reading through the entire thread again, I would say the first thing you should do is to make sure you send the correct string. For Voltage mode it seems it should contain 10 characters whereas for current mode it would need 8 characters.

VISA can access also IEEE488 devices. The relevant settings can almost all be accessed through VISA properties.

The manufacturing year is irrelevant. When that device was designed in 1981 or before, that’s the technology it uses. Your device may contain a new firmware which fixes a bug or two but certainly not with new improved functionality. As to those settings they absolutely positively must exist in NI-Max. They are functionality of the NI-488.2 driver and have absolutely nothing to do with your specific device. Or are you using something else than a NI GPIB interface to connect to the device? This is what you should see for your GPIB controller in MAX: As you can see there are a number of settings that could be relevant. Considering the age of the device I would guess playing around with Bus Timing (make it slower as the old GPIB controller used in that device might not really be up to snuff with modern GPIB timing), and Assert REN when SC (assert remote enable hardware handshake) might actually have an influence. There should be a similar section with options when you select your device instead in the device tree. But I couldn't find an image of that easily and I haven't used GPIB in several years so can't quickly get a screenshot from one of my machines. As to the GPIB section in the manual there is absolutely nothing that resembles anything IEEE 488.2. They only mention IEEE488 and the little they have in there is absolutely not 488.2 compatible in any shape or form. HP used to fill 10-20 pages and more about all the different GPIB capabilities and features of their devices and several 100 pages about the commands you could use! 😀 The GPIB standard may be technically several magnitudes less challenging than PCIe, to just name one, but you needed to know more about the different capabilities of the device and your controller to make it work. IEEE 488.2 was an attempt to define a common set of features a device and controller should use and also to define some basic commands and their syntax (such as *IDN?).

Hmmm, that's one old piece of hardware. I found a manual here: https://www.opweb.de/deutsch/firma/Data_Precision/herunterladen/Data_Precision--8200--service--ID8215.pdf and its covere page has a copyright of January, 1981. Instruments from that time do not comply to IEEE 488.2 at all since that standard simply did not exist then. That only was released in 1987. Accordingly GPIB instruments where using all kinds of weird GPIB settings, including instruments from the GPIB inventor HP itself. You may have to actually go into NI-MAX and change settings for the instrument or even the GPIB controller itself, that listen to names like "enable readdressing" and other possible settings. This was way into the 90ies the main issue about connecting legacy GPIB instruments to a computer. The fact that the few available GPIB controller chips all had their quirks and bugs, that had to be worked around in the instrument firmware, did not make it more simple.

This used to be trivial to do up to LabVIEW 5, a little more complicated in up to LabVIEW 7.1 and got really difficult with LabVIEW 8.x. I have never tried to do it with any LabVIEW 20xx version. While it still should be mostly possible for pure software applications that do not use any hardware, both NI and 3rd party, it would be a major pita to try to do it with most of the NI drivers nowadays. Possibly that the application Hooovah proposes can help with that but otherwise I don't really see any possibility to do it reliably. Part of the message does indeed sound like they might refer to actually replacing the Windows shell (usually Explorer.exe) with the LabVIEW executable. That is another possible approach but combining that with an USB portable app installation would really mean that the whole system would have to boot up from the USB device. Shell replacement in itself is not that complicated (it comes down to replacing/adding HKEY_Current_User\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell with the path to your executable that you want to perform as Windows UI instead of the Explorer desktop). The problem is during development/debugging where you do not really want to have that setting active. Generally you want to have a protected way to SystemExec() explorer.exe anyhow from within your own shell.

Well of course does LabVIEW have to retain the HWND of the container where it places the ActiveX Window. And this is simply a specfically allocated window handle for the container since an ActiveX control requires a parent window when being instantiated and LabVIEW for obvious reasons does not want to hand the full front panel HWND as that would give the ActiveX Control every possibility to mess with the LabVIEW owner drawn front panel (as you know LabVIEW controls, except the ActiveX and .Net Container are not implemented using window controls with their own HWND as with other standard Windows applications, but are fully owner drawn by LabVIEW itself). I still think that the approach with peeking into the object pointer to retrieve information, while being fun to do if you love this low level stuff, is an absolute and big NO-NO for anything that is supposed to leave your mancave.

I have a fair amount of experience with SVN and a smaller amount with GIT. At our company we still use SVN, not because it is super perfect but because it simply works. I have not managed to get myself into a real mess with SVN. The worst that can happen in my experience is that some operation doesn't terminate properly and you have to do a manual cleanup to be able to continue. Enter GIT and that changes dramatically. It's very easy to do just about anything in GIT, including mistakes. And I can not count the number of times in which I spend several hours of unraveling some mess I caused by selecting the wrong GIT action for some reason. The fact that the naming of the different GIT actions is sometimes rather ambiguous and the parameters can be mind boogling complex doesn't hel that either. The few times I did something wrong in TortoiseSVN I simply went into the command line and entered a few simply enough commands through svn.exe and all was well. TortoiseGIT is very easy to do things wrong and the GIT command line, .... well it feels like having to do a one year study to even understand the basics of it. 😀

That's because if you do any overlay of anything in LabVIEW, LabVIEW will be forced to fully redraw the entire control every single time rather than trying to use optimized region update APIs in Windows. And the graphics driver for your video card seems to have some trouble with proper region drawing. Of course full redraw will be usually considerably slower so it isn't a perfect solution at all.

How would you do HTTPS without TLS? And it depends about use of LabVIEW. For a general in the field IoT application I wholeheartedly agree. Trying to build such a system in LabVIEW is going to be reinventing the wheel using a high end CAD tool while you can take ready made wheels from the shelf. If it is however part of final step during inline testing of a product, with the whole test system controlled by LabVIEW, it may be useful, although calling a Python script would still most likely be much easier and maybe a few milliseconds slower than fully integrated in LabVIEW. But then the specification sounds a little bit bogus. Rather than requiring that the firmware needs to be written securely to the device, it should simply state the protocol that the device can support. Security in a (hopefully) closed in house network really shouldn't be a concern, otherwise you have a lot more trouble to be concerned about than if the firmware is written securely to the device.

So is your link to the DUT over public internet or an internal network? If the first, the client may want to reconsider if that is the way to do firmware updates, if the second, someone seems to be utterly paranoid. I don't think it is to useful to use the TLS functionality for this. This is on TCP/IP level an are you seriously doing firmware updates over TCP/IP? Or are you rather using HTTPS instead which could have been done with the HTTP(S) client functionality since about LabVIEW 2014 already. If you need more specific control you might have to go with something like the Encryption Compendium instead. https://lvs-tools.co.uk/software/encryption-compendium-labview-library/

It could make sense if the PostgreSQL DLLs were compiled with Microsoft Studio 2010 or 2012 or similar (not sure which Visual Studio version is used for compilation of LabVIEW 2015) and set to use dynamic linked MS C Runtime library. It is old enough to not be standard on a recent Windows 10 installation and not new enough to not be tightly coupled with a specific Microsoft Visual C runtime version. Since about Microsoft Studio 2015, the Visual C runtime has stayed at version 14.x and doesnt with each new version require a new runtime. It's still possible that a newer Visual Studio application won't work with an older runtime but the opposite works usually without a glitch.

Not really safety precautions. Most C(++) compilers will strip by default all symbols from linked non-debug code, unless these symbols are needed for certain puposes like function export tables. While these functions also return a pointer to some sort of export table, they are not official export tables, just as virtual tables in C++ aren't really export tables. The name is unneeded as far as the compiler is concerned, so they get all stripped. This has certain anti reverse engineering reasons as someone distributing a release version isn't usually interested in letting its users reverse engineer their software (just check your license agreement you entered into when installing LabVIEW 😀) but the main reason is really that these symbols simply blow up the executable image size for no useful reason and it's an easy thing to do by the linker. The functions with retained symbol names in there are usually functions that are also exported in the official export table. GetCIntVIServerFuncs() existed before LabVIEW 8.0 and was/is mostly related to functions needed by various VI Server interfaces. The first version of VI server was a very small set of exported functions that got called by a CIN. This was then changed into the fully diagram accessible VI server interface as we know it now around LabVIEW 5. Sometimes the LabVIEW compiler needs to create callbacks into the LabVIEW kernel. Initially this was done through direct calls of exported functions but that was changed for several reasons to call a special internal export interface. Hiding things was likely more a byproduct than the main reason for this, making this interface more uniform among the different platforms was likely more important. The C Interface supposedly took this idea further and here hiding LabVIEW internas might have been part of the decision. But because this privately exported function table is highly inflexible and can only be amended to in subsequent LabVIEW versions but never modified without creating serious trouble with version compatiblity, I think it's not something they would want to use for everything. The advantage is that you do not really need to use dynamic link functionality for this except for the one function to get at this interface, so there is one simple function that will use platform specific dynamic loading and everything else is simply a function pointer call into a table at a specific offset. A COM like interface would be much more flexible in terms of version compatibility and NI uses that in some parts even across platforms despite that real COM isn't supported on non-Windows platforms, but it is also a lot more complicated to create and use even when you program everything in C++.