While we were talking with a customer who had some trouble with the LabVIEW library, we thought that it would be nice to have the logs of the Yoctopuce API to understand what happens. It so happens that the LabVIEW library already has a primitive able to do so, but it's not necessarily easy to use. So this week, we show you how to do it.
For those in a hurry
If you don't want to tackle the theory to understand how this works, here is a ZIP file containing two VIs. Unzip it wherever you want and open the Block Diagram of your LabVIEW application. Let's assume that it's a very simple application which reads a temperature sensor, such as the one below:
A very simple application reading a temperature sensor
Then:
- Drag and Drop the GetYoctoAPILogs.vi VI in your Block diagram.
- In the Front panel of your application, create a String indicator long enough to contain the logs.
- Back in the Block diagram, create a reference on the String indicator and connect it to the log VI.
Add the GetYoctoAPILogs VI and give it a reference to a String indicator
That's it, if you run your application, the API logs will appear in the String indicator.
It works (almost)
However, you will notice that if you press the STOP button, the applications doesn't stop. The reason is that the log retrieval VI goes on running. To solve this issue, put the StopYoctoLogs VI in your Block diagram. It's actually a global boolean variable, set it to True at the end of your application and Bob's your uncle.
Stopping the log retrieval VI
How it works
To obtain the API logs, you must use the GetLog method of the API VI.
You must use the GetLog method of the API VI
If you call this method with an empty string, you obtain the first line of the logs. If you give it the first line, you obtain the second line, and so on. If there are no more lines, GetLog returns an empty string. You must therefore test the result of GetLog and, if not empty, add the line with an additional carriage return to the String Indicator which must contain the logs. If the result of GetLog is empty, you wait for a while and call it again with the last known line.
We add non empty lines to the String indicator
Then we put everything into a nice loop:
We surround it with a loop
The issue is how to stop the loop when the main VI stops. Not being great LabVIEW specialists, we looked around for the different ways to stop loops running in parallel in LabVIEW, to reach the conclusion that the easiest to implement is a good old global variable that the main program must set to True when it wants the log loop to stop. The main inconvenient of this method is that global variables are necessarily stored in a distinct VI.
Incidentally, you must remember to set this stop condition to False before entering the loop.
We use a global variable to stop the loop
That's it for the basics, the rest of the VI is just cosmetics:
- Adding a short timeout in the loop so that it doesn't consume too much CPU while running empty.
- Before starting, emptying the content of the String indicator, just in case.
- Configuring the String indicator so that it uses a non-proportional font (Courier) and so that it displays a vertical scrollbar.
- Closing the created references, because we are not savages.
The complete VI
Conclusion
A VI enabling you to retrieve the Yoctopuce API logs wasn't excessively complex to set up, but it required some thought to do it about right. You will find this VI particularly useful to diagnose potential network issues with the YoctoHubs or even to understand what happens when you run an executable file created with LabVIEW, we thought we noticed that these executables manage DLL in a weird way an unconventional manner. If you need to debug DLL problems, check that you have at least version 50357 of the library, we vastly improved tracking of the loading of the yapi.dll.
