Showing results for 
Search instead for 
Did you mean: 

Simulating NI USB-6001 using NI MAX

Go to solution

@Tesi2023 wrote:


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 -"


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.

Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 11 of 13

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.

Rolf Kalbermatter
My Blog
Message 12 of 13

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.

Rolf Kalbermatter
My Blog
Message 13 of 13