Data Acquisition Idea Exchange

[#1]

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

 

[#2]

hoplà!

[#3]

I like this idea, but it would be incredibly difficult to implement.

Basically, this would require a software model of how each and every DAQ card will function in every simulated situation:

1) Every DAQ card will need to be characterized

2) in software, according to

3) every single kind of input (or a custom input, as defined by the user), and

4) every possible kind of routing, and

5) these models will need to compare "realistically" to actual hardware

Not only would this be a LOT of R&D time and effort spent, but the last point about this model being "realistic" approaches impossible.  Just how accurate does the software model need to be?  To answer that, it would require additional specifications every time a new product is released, and additional support every time a customer finds a certain application where that specification is inaccurate.

[#4]

See:

http://forums.ni.com/t5/Data-Acquisition-Idea-Exchange/Specify-source-of-simulated-device-data/idi-p...

This fits in nicely with this idea.

I dont understand why this is so difficult, I dont think we need an real world model, just want to acquire simulated data that matches the expected signal, I have never really acquired a slightly noisey sine wave.

I think a property node in the daqmx api called simulated.source (polymorphic) that could take a waveform from constant or array and returnde back on read would not require any simulation models.

[#5]

What about a simulation interface similar to the way that the FPGA simulation interface operates? We can simulate the input on any FPGA device by setting the simulation mode in the project?

[#6]

I really like this idea, and it has to be said that we get a lot of requests for implementing custom simulated data with DAQmx simulated devices.

I don't think that this would be too difficult to implement, either. I base this purely on the fact that a lot of these features would just need to be built on top of the existing generic properties and methods that all NI-DAQmx Simulated Devices inherit anyway!

[#7]

I don't know how I overlooked this proposal, but after telling it to someone from NI, I've proposed something similar here, getting the response that it was already proposed.  So, I only want to show that I'm interested too!

[#8]

stijnhel, if you are interested give the idea a Kudos.  That is how the folks at NI know our interest in the idea.

[#9]

For me, the current simulated devices are completely useless. For example, my process monitors a safety switch, and since the DIO of the simulated device goes high in rapid succession, my simulated process constantly goes into emergency shutdown mode and I cannot realistically operate it unless I have real hardware present or code around it.

As an alternative solution, I propose a simple action engine that contains all possible inputs and outputs (with specs and limits defined as for the real device).

Now we should be able to create our own VI that runs in parallel and simulates the instrument and interacts with the IO as received via the action engine. It would receive the simulated DAQmx outputs (AO, DO, etc.) as inputs and writes to the inputs (AI, AO) as our instrument would. For example if one of the digital outputs (simulating a valve) goes high, it could sense that and gradually ramp a certain AI up (e.g.. the one measuring the pressure actuated by the said valve) and vice versa.

Of course we would only need to implement code for the few connectors that we actually use, so a custom simulated device could be quite simple.

The action engine acts as a middle man. The simulated DAQ functions would blindly read and write to the action engine, without really caring what happens to it. 

[#10]

I can agree with altenbach's first statement for sure.  The only real value the current simulated instruments provide is for someone who is not familiar with the API to make sure the driver (in a software sense) will not scoff at their choice of API calls.

Being able to define a simple range/shape of waveform for the simulated output would be extremely useful.  Being able to vary that akin to a function generator would be even better.  There are may cases where NI hardware would be more valuable for purchase if a concept could be proven prior to purchase.  This stems from folks be skeptical of all hardware NI or otherwise but being able to develop applications prior to making a large hardware purchase would be extremely valuable.  Can we at very least hope for a phased approach into this set of features that people clearly would love to use?