Hear, hear! After all these years, the LabVIEW library is here at long last! Until now, LabVIEW users who wanted to use Yoctopuce modules had to settle for a handcrafted workaround that we designed a few years ago. But this time we're not joking anymore, we offer a true library for LabVIEW which enables you to exploit the whole potential of Yoctopuce modules.
Why so long a wait?
At Yoctopuce, libraries are not written entirely by hand. A large part is described in an internal programming language that we call Y-C. Then a homemade grinder transforms this Y-C code into source code for all the libraries. Thus, if we need to modify classes or add some new ones, we only have to modify the Y-C code and everything else is done (almost) automatically. The trouble with LabVIEW is that the source code is not text, which makes automatic generation of source code rather problematic, hence our lack of enthusiasm to write a library. But we ended up by plucking up courage and by getting on with the resolution of this difficult issue. Long story short, from the Y-C code we generate a text file which describes the VIs of the library and we wrote, in LabVIEW, a VI generator which reads this file and automatically creates the VIs. The generator, which makes intensive use of the scripting VI, is quite labyrinthine, but it works.
The library was designed to be as user-friendly as possible. To interface the function of one of your modules, you need three VIs:
- YRegisterHub to initialize the API
- The VI corresponding to the function that you want to use, for example YTemperature to read the temperature
- YFreeAPI to free the API
Here are two examples: one to read the temperature and one to toggle a relay.
Reading the temperature
Toggling a relay
Note that the two loops above are not temporized. It's not strictly required because the VIs of the library are optimized to minimize communications with Yoctopuce modules.
By default, each VI maps the first available function that it finds. It's the equivalent of YXxxx.FirstXxxx in other libraries, but you can very well use a hardware name or a logical name to resolve ambiguities.
You can obviously combine VIs. Here is a program which toggles the RELAYHI1-56FC0.relay1 relay depending on the temperature measured by the THRMCPL1-0D7C5.temperature1 sensor.
Toggling depending on the temperature (with Schmitt trigger)
How does it work?
Actually, in order to simplify the generation of VIs, we put all the complex code in a .NET DLL called DotNetProxyLibrary.dll. And all the generated VIs simply make calls to this DLL. The DLL is based on the C# Yoctopuce library. This implies that the LabVIEW library requires three DLLs: DotNetProxyLibrary.dll, yapi.dll and amd64\yapi.dll.
Note that for the LabVIEW library to work well, you must have modules with up-to-date firmware.
The VIs and the examples are delivered pre-compiled for versions 2012 to 2019. But if you work with even older versions of LabVIEW, contact us and we will see what we can do. The library is not compatible with LabVIEW NXG. We tried to transpose it and it turned into a disaster: most of the techniques that we used are not yet supported in NXG. We didn't check, but the library probably doesn't work with Linux and MacOS versions of LabVIEW.
You can download the new LabVIEW library from our library page. For the moment, it is delivered with the VIs and examples dumped together. You can "drag-and-drop" the VIs directly into your code, or integrate them in a palette by using the fastidious method described in the LabVIEW section that we added in the documentation of all of the products. Make sure to add the Yoctopuce VI directory in the list of LabVIEW search directories: Tools > Options > Paths > VI search path
We well understand that VIPM is the method of predilection to install LabVIEW libraries. But it looks like one cannot script VIPM, which makes it useless for integration into the automatic build process of Yoctopuce software. We will try to find a more user-friendly installation process. Any suggestion is welcome.
Depending on the configuration and on the way you unzipped the library zip file, Windows can decide that the DotNetProxyLibrary.dll DLL is coming from another machine and must absolutely be blocked for security reasons. If LabVIEW can't load the DLL, you obtain error #1386. You can solve the issue either by manually unblocking the DLL, or by creating in the directory where labview.exe is located an XML file called labview.exe.config authorizing to load assemblies coming from outside.
Unblocking a DLL blocked by Windows
We did a quick presentation tour but you can find everything else you need to know in the documentation of each module. And we'll certainly have the opportunity to delve further in the topic in future posts. This being said, we noticed that, in the universe of programming, visual programming and traditional programming are quite separate worlds which don't really mix. As the whole Yoctopuce team comes from the traditional branch, we hope that we didn't aim too much off-target and that our library respects LabVIEW usages and traditions. But if you have any comment, don't hesitate to tell us. We might be able to adjust our aim.