Solar Code

One typical UI problem a LabVIEW developer faces is how to prevent an oversupply of events generated by some front panel objects, particularly sliders and knobs. When the user drags the slider, a lot of events with slightly different associated values pile up waiting to be processed. So if each event entails a complex code execution or communication with some equipment, we are wasting time and resources with this "ghost events". As you may know, this is an old problem and any search on NI forums will uncover several workarounds . In my experience, the best approach is to validate the event before processing it. But how? As in the image above, first wait a length of time and then check if the event associated value is still the value in the control. If not, discard (because the final value is still waiting). Sounds simple but some considerations are required: First, the milliseconds to wait (500 in this example) will both filter a higher number of unnecessary events an

Along the lines of the last post , I'd like to show you a simple .NET way to check CPU and memory usage percentage, a nice asset in resource-consuming applications. Here you have an application example with these VIs: Both are based in performance counters, so use the correct init VI and just ask periodically for the current value, as shown. If any error arises, it usually comes from the constructor, so check the System.PerformanceCounter options and look online for updated values. Download (LLB for LabVIEW 2016) See ya! ;-)

Lately I had to check the CPU temperature in a critical acquisition system, and I thought it could be a good thing to share here. I know there are several applications to do this and much more, but getting it from our code allows to react conveniently to any event. Now, IMPORTANT, the VI doesn't work on its own. First you must download the Open Hardware Monitor . Extract OpenHardwareMonitorLib.dll from the zip file and put it in the same folder the VI is located. The objects exposed in it use .NET Framework 2.0 and above, but that shouldn't be a problem in any modern machine. On the other hand, this works only for Windows , obviously. And remember, the application (either an .exe or the LabVIEW IDE) must run with administrator rights (otherwise you'll get error 1172 ). Download (VI for LabVIEW 2016) Now, if you haven't worked with .NET functions in LabVIEW, this can be a good opportunity to familiarize with them. Let's take a look at the code. First we

This is an useful snippet I've using for a long time, and still works fine in Windows 10 (though obviously won't in Linux machines). Say you have saved a new data file and you want to show it to the user. Well, this VI does it for you. If the input path is a folder, it just shows it. If it's a file, opens its containing folder and the file appears selected. It's really simple and uses a system call: Here you have it for LabVIEW '16. Download (VI for LabVIEW 2016) When managing files and folders, the function to release the current directory we saw some time ago can also be helpful.

Wow, it's been a long time since I last updated the blog. Life, you know. OK, today I bring you a very simple library to manage the Windows services you may have created (either with LabVIEW or in another language, it doesn't matter). These VIs allow to install and uninstall the service, as well as running it, stopping it and getting its current status. A lot of extra functionalities could be added if ever needed, you'll see they're extremely easy to use and modify. Download Services LLB (library and class for LabVIEW 2016) The main part of the library is made up of service.lvclass , a LabVIEW class that wraps the provided functions: install, start, stop, get status and uninstall. Maybe using GOOP here is overkill, but it's easier this way, just deploy init and close to create and dispose an instance and call the other VIs in between. This class uses .NET methods inside and as such is only valid for a Windows OS, but we are talking about Windows services her

I was thinking about good example uses for the Base64 Encoding utility I posted last week, and then I remembered: e-mails! Sending an e-mail from your application is a pretty common task. Let's say your client wants to be automatically informed when some conditions are met in the plant. So you do it, and probably use the Send Email using SMTP Cient.vi that comes with LabVIEW (since LV2013) and allows the use of secure mail servers, as Gmail. So far, so good. But what happens when you put some non-English characters in the subject line? This is usual for us Spanish speakers, and the results are not as intended, but garbage text on the other side. The answer is to use an encoded-word syntax . In this case we'll use Base64 and the VI I uploaded . The change needed in the mail client VI is minimum: Just encode the text in Base64, encapsulate it as indicated, and your subject line will be readable in any mail client, as you can see in the lower image.