Week after week, more LabVIEW users discover our sensors and ask us if we will consider creating a full LabVIEW library for our devices. For now the only option was to write your own VI to invoke our command line library, which is neither very convenient nor very efficient. Therefore, we have decided to build a better solution, and we even have something for you to try. At this stage this is only a "proof of concept", but we are waiting for your feedback and your LabVIEW experience to make the final version of this new library as good as you would like it to be!
Edit dec 2019: a proper Yoctopuce library for LabVIEW is now available.
What is tricky with LabVIEW ?
LabVIEW is a graphical programming environment, useful in particular to interface instruments. The two main difficulties with this environment for our product line are:
- the need for a LabVIEW driver, to talk to our devices;
- the need to rewrite our library using LabVIEW graphical interface.
Regarding drivers: whenever possible, we try to avoid them. Drivers are often a matter of troubles for the user, they must be updated using a specific procedure, they cause portability issues, and they make it harder to move an application from one machine to the other. We don't like drivers.
Regarding the graphical programming, the key point is that we want a way to ensure that the LabVIEW library will always stay level with other languages. As you have probably noticed, a significant part of our high-level programming library is automatically generated for all programming languages. This ensures that all our customers get the full feature set and access to all new features that we add from time to time to our devices, regardless of the programming language being used. If there is a manual UI operation to perform on LabVIEW UI for every single change that we do on the library, it is almost certain that some will be missed.
Our solution to the driver problem
In order to avoid the installation of a native driver, we have based our solution on the NI-VISA architecture, using VXI-11 network protocol, which is natively supported by LabVIEW. It is enough to add VXI-11 support to YoctoHubs and to the VirtualHub to transform every Yoctopuce sensor and actuator into an instrument recognized by LabVIEW, that can be queried very efficiently, both locally and over the LAN. This is what you will be able to try today (on Windows only for now).
Here is how we have defined the Virtual Instrument YRequest.vi, which is used to execute queries on Yoctopuce devices:
This VI takes as input the address of the instrument (the device), using VXI-11 standard, and the SCPI command to execute. It outputs the query result. Here is a simple example of this VI:
This example simply read the current temperature from a Yocto-Temperature, and displays it as text and on a thermometer gauge. You will recognize the typical format of a device serial number, with the mandatory "instr" prefix. The SCPI command is based on Yoctopuce usual naming scheme (function name followed by attribute name), but using SCPI syntax since this is more natural for LabVIEW users. Note that in this version release, SCPI names are case-sensitive and cannot be abbreviated, which is not standard, but that will be fixed in the final version.
Our solution to the library update problem
The use of NI-VISA and VXI-11 provides a reusable brick for most low-level operations. But it will nevertheless be necessary to add a high-level abstraction layer, equivalent to the library we provide for all languages, to save the user from going back to the documentation to check every attribute name, and from manually converting strings to numbers as we had to do in the example above.
In order to do this, we will write an Express VI that will let you pick directly the type of device, the function and the attribute to read or write. We even expect to be able to get that meta-information straight from a text description of our devices, which will be automatically updated and therefore ensure that the LabVIEW gets all new features as well. If you have any good or bad experience with Express VIs, let us know: it is still time to change our mind if this does not look like the best idea :-)
A small example of LabVIEW automation
To conclude, here is a slightly more elaborated example totest our VI: the goal is simply to read a potentiometer, display its value graphically and automatically switch a relay depending on the potentiometer value. Here is the block diagram:
And here it the real stuff:
You are now ready to give it a try, using the latest version of the VirtualHub for Windows and these Yoctopuce VIs. Keep in mind that this is just a "proof of concept" for now, and that at this stage we have only implemented the strict minimum to get VXI-11 and SCPI up and running for testing. If you like it, there is more to come, so let us know!
