02-11-2024 06:59 PM
@Tesi2023 wrote:
Santhosh,
Thank you for your answer. I've read all the articles on your link below.
"NI DAQmx driver does not provide a way to override the simulated device behavior; you can add a layer on top of the DAQmx driver to make it simulate an application-specific signal.
Please read these considerations - https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Nw0SAE&l=en-US"
Regarding adding a layer on top of the DAQmx driver to make it simulate an application specific signal, is there a link or example showing how to add this layer you indicated?
Thank you again,
John Trites
There are several ways to do that, developers typically create a parent class with abstracted functionality of the DAQmx, then one child class that directly calls the DAQmx implementation and another child class that does the application specific simulation.
When you create the object, add the logic to create the appropriate child class based on whether it is in simulation or calls DAQmx driver.
02-12-2024 01:42 AM - edited 02-12-2024 01:46 AM
Santhnosh already gave you one of the prefered ways. Depending on your application there could be others.
Traditionally, before classes were a thing, people would create case structures in each VI that used the DAQ functions and selected on some global if to do the real thing or the simulation stuff. While still possible and initially likely the quickest way, it is also one of the dirtiest ways and a maintenance nightmare in the longer run.
The class variant as santosh explained has a few minor possible variations. Instead of an abstract base class it may be better to use an interface if you are in LabVIEW 2020 or later. But personally I tend to do the hardware independent simulation code in the base class rather than in a separate child class. The Open, Create or Initialize method of the base class also instantiates the according child class using the factory pattern. If those child classes are instantiated dynamically and one of them is added as always included dependency in a build application in a separate plugin folder this even allows to add later in a build application a new child class implementation for a different hardware without needing to rebuild the application.
if you are familiar with the Actor Framework or a similar message based framework like DQMH. You could also create a DAQmx actor and a. DAQsim actor and instantiate at startup whichever you want at that moment.
02-12-2024 05:01 AM - edited 02-12-2024 05:03 AM
Sorry Santhosh for misspelling your name. I was writing the response on my mobile on the way in the train and when I discovered the misspelling later on, the one hour time window to edit a post had already passed.