Interactive DaqMx simulation interface ... (Popup panels for simulated hardware) ... Or better, DaqMx Simulation API for process simulation ...

[manu.NET]

Hello,

How often you have build Labview applications using simulated DaqMx boards ...

And how often you were limited by the default behaviour of simulated boards ... ( Sinewave for analogic inputs, Counter square signal for digital inputs ... )

It would be nice to integrate in DaqMx simulated boards, the abilty to modify the default behaviour of simulated inputs ... thru dedicated popups

It would be nice, for each task linked to a simulated daqMx board, to launch a popup window ...

• For digital input, give the abilty to modify for each configured channel , the current binary value.
• For analog input, give the ability to choose between a fixed value, a sine wave, a square signal ... white noise ...
• For digital output, give the ability to view the current setted values
• For analog output, give the ability to view the current simulated output value on a waveform chart ...

A more powerfull tool could also integrate a simulated channels switching mechanism ... A simulated output could be linked to a simulated input 

This feature could be a good way to create an application which could simulate a complete process ... this application could be used to validate a complete system

(such a kind of SIL architecture)

Other idea .... A complete daqMx simulation API ...

• Creation of an API which could instanciate a simulated daqMx board (Wich could be seen via MAX)
  • Takes place of the actual limited daqMx simulated board
• This device could then be accessed by other application thru daqMx
• This API could have access to all channels of this simulated device.
• This API could force, programmatically, the value of the simulated input channels according to a realistic process model

Something like this ...

 

[jorsh]

Great idea!

I had something very similar made myself 12 years ago for the PLC simulator we used to control production tool. In simulator we had ability to set DI and AI individually, and display DO and AO. Also, because for most of the AO our system was supposed to have AI (setpoint/feedback) we had ability to "connect" AO to the same AI number. So, our control will be always happy. When you want to test abnormal behavior you just disconnect AO from  AI and type value manually.

[kosist90]

That's great idea, I wish they could implement something like this... 

[Buli]

Could not agree more with this idea! This feature would be a big help and could lower the debugging time significantly.

[doogle]

Being able to see what the simulated Digital and Analog Outputs are doing would be very great!

At the moment there's no visibility and there's no way of probing to confirm operation without hardware.

At least with inputs you can see something happening, even if it's not what you want.

[Henrik_Volkers]

I like the action engine (or alike) approach...

Still see some timig challenges for NI-Scope or other high bandwidth modular instr. 

but everything more flexible than the existing would be wellcome.

[gsmolnycki]

Just encountering an issue recently where I'd like to implement automated testing for a large application as part of a CI system, only to find out that this has been a suggestion for nearly 10 years and is now the single most upvoted idea. This type of simulation interface is not only common, but absolutely required in most other commercial development environments. How otherwise is it possible to test without giving developers each their own hardware? How is it possible to get reliable, repeatable tests? Very disappointed to see the lack of response from NI here.

[LetThereBeNick]

I agree with gsmolnycki here. The ability to control data simulated by virtual devices is not a "nice-to-have." Without it, I can't do any serious developing in LabView from home, where I don't have physical devices. The impression I get from NI support is that they are quick to write off essential improvements as "too much work for me." But guess what? Telling thousands of people for ten years to re-squiggle their wiring whenever they need to work away from their devices has generated a whole lot of compensatory work on the end of the users.

If anyone else is reading this as they start getting into LabView, remember that an Arduino can be controlled by C code that is not proprietary and hidden from you. Fixing this debugging problem in C is possible. Fixing this in LabView takes 10+ years of crossing your fingers. Choose how you want to spend your coding time.

[simplemaan]

As an NI CPI teaching virtual LabVIEW training online, I very much agree with the limitations of simulated DAQ devices because the simulated signal cannot be altered and is inappropriate in most cases, either in timing or whatever.

All of these ideas would be improvements, but here’s one more that I think would be quite simple to implement with minimal revision to DAQmx:

Just allow the user to choose the source of the simulated waveform from a file, preferably tdms, in the simulated device properties.

The existing, familiar noisy sinewave, and the random digital i/o has to be created or stored somewhere - just allow the user to redirect one or more channels of the simulated device to a file of their choosing.  Checkbox for “Use the same signal for all channels” or option to specify a file with the same number of channels as the device.  (Provide a default file which will give the noisy sinewave).  The strength of tdms files is that both analog and digital waveforms could be easily created and saved using express VIs, a real device or whatever source, and replayed by the simulated device.

This would allow simulation of real systems and in my use case, teaching of exercises by simply creating appropriate files that have the right data and timing characteristics.  If the end of the file is reached, just repeat it.

Maybe make analog and digital simulated device outputs write a tdms file, too.