Category: LabVIEW Blog

Most of us are used to right hand mouse control and few are by nature left hand-ers and they use mouse in their left hand. Have you ever tried swapping your mouse to the other hand and draw the LabVIEW wire? Then try giving it a chance now, I tell you that you will feel a great difference. Don't just try it for few minutes, but take it as challenge for an hour or day even after your brain says "Oh God..! It's hard, go to your default hand." By default, I'm a right hand user and in our work, colleagues had a fun of using other hands. Initially it was very hard to even draw a single wire from one VI to other VI but what I discovered trying…

There would be some hard times as a LabVIEW developer when you're able to find libraries available for windows but not for your NI Linux targets. Some times it would be relaxation when we want that library for our NI-Pharlap based target, because to some level you can call the windows based DLL/Library APIs in NI-Pharlap. However, when it comes to Linux based NI target, it's quite frustrating that we can't find right libraries because as LabVIEW developer we always biased with Microsoft Windows mindset. Recently I came to such regrets then a 'yay' moment after bumping in some rough surfaces. For one of the LabVIEW application with ByteLabs, we found a library available in windows but we wanted the same library for our NI-Linux based RT target. Our team…

A typical application in LabVIEW development flows through the stages likeApplication Start-up StageApplication Running StageApplication Exit StageOver the years this became evident to many developers and hence they all unanimously agreed upon design patterns like state machine. A state machine template (like JKI simple state machine) usually have these three stages of an application (as initialize state, your process states, errors state, exit state so on) and enable the developer to easily bring up the application to end customer without worrying about how exit process works. These templates are so helpful if your application runs on single while-loop or to-the-max if your application is within one target.However, if the application extends between more than one targets (like inter-process application) then we realize that we're crossing the limits of these templates'…

You can emulate an NI-Desktop Real Time(RT) System in a virtual machine using VirtualBox from Oracle. This helps in great ways...You don't need a separate PC to check your logic in real NI-RT without even an extra physical PC in your side. Testing in customer site would not require additional logistic of other PC.You don't need cRIO or PXI to start learning/coding your RT applicationCheck my virtual machine running NI-RT below with 1-core processor, 512MB RAM and 2GB HDD which I created within 2 hours from scratch.I want to credit and thank the user "D4N!3L3" in NI forum who was the one successfully did this virtualization of NI-RT and put it up in this idea exchange. The instructions given by him/her is very crisp and short where I lost searching…

In my last post I gave a simple method used to simulate the unavailable hardware (be it cRIO, bench-top instruments, PXI or any kind) which can communicate to LabVIEW application. I also mentioned that I simulate using data sockets which I will explain in this article. Data socket is a pretty much like a global variable. According to NI...DataSocket is an easy-to-use, high-performance programming tool that is designed specifically for sharing and publishing live data in measurement and automation applications between different applications and between machines across the Internet. DataSocket for LabVIEW simplifies live data exchange between different applications on one computer or between computers connected through a network.Simulation using data socket is more similar to earlier explained simulation using boolean as input to instrument driver VI. On top of…

Very often while working in the real-time systems, you may be in a situation you couldn't test some cases of your software due to the unavailability of the hardware associated with that code. This is especially true when the you're working in the National Instruments RT like cRIO (Compact RIO), myRIO, sbRIO or even PXI. This is also very common scenario when the hardware exists in a remote place and you are coding & debugging from other location of the world. Adding simulation codes to such software would help a lot avoiding such stopping-points of software testing. The key to simulation is usage of a simple boolean input and case structure which decides to use whether the simulation code or real hardware code.Data generation from instrumentIf your module uses a…