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 instrument
If your module uses a hardware to get some data (example voltage measurement), then you can create a simulation code as shown below. The "True" case of the case structure is the simulation code which gives the random number and "False" case of the case structure will get actual data from instrument.
If you are debugging the issues associated with actual data (like data being not populated properly in graph), then you can collect some data from instrument when it’s available, and then put that data as constant in the simulation case instead of random number generation.
Commands to instrument
If your hardware modules receives command from your software, then you can simulate it like below. You can add an indicator in the simulation case with the same datatype being sent to the instrument.
While testing, you look at the front panel of the instrument module and confirm if your expected message is out in simulated indicator. In this way can confirm that your software works nicely as per your logical expectations up-till the instrument modules. Beyond instrument modules you would need actual instrument to validate the software.
I use one more technique of "Data Socket" to manually simulate the actual instrument behavior. I will give hint about that technique in next blog post.
Ajay is a professional developer and architect of NI-LabVIEW applications with extreme interest in getting the hardware connected to LabVIEW and automating the stuff. Recently he is also putting his hands in NI-TestStand to get very dirty on it. He is also a good mentor for the various interns in his career. He is ready to help the people in techie roles.