Output controllable (in real time) DAQmx signals

[js777]

Hi:

I have an question here. 

It is quite tricky to me, and I cannot find any relavant example and discussion.

Hope some people give me some information for me to look up.

--

I am trying to generate one analog signal by a DAQmx device (I have one, and am using it well) to control another device.

The output signal should be the summation of a background signal (which is decided, say a sine wave) and another controlling signal .

The controlling signal depends on the controlling input in real time, say using the horizontal location of the mouse to be the value of the signal.

The background signal is designed beforehand, and should will be running continuously (shouldn't be stopped once the system starts to make sure the synchronization between each devices).

At the same time, the controlling signal should be continuous as well.(if there is no new input, it uses either the default value or the last input.)

--

I have almost no clue on how to do this.

As far as I know, daq needs one task to write the signal in and then runs it after.

The controlling signal is a real time thing, so the task must be updated very quickly.

But regenerating tasks costs ~50ms on my computer (and I have used the low levels daqs rather than the DAQ assistant).

Also, in this case, my background/controlling signal will be stopped everytime when the task is re-generated (and this makes my synchronization failed.)

I have checked DAQmx Real-Time, but couldnt find some relavant examples, and seems it is not for my applicaiton actually (?).

One possible solution I came up is to cascade my two signals after they are generated by my daq device. And then I can use one A/O to be the background signal, and use another A/O to be the controlling signal.

However, my controlling signal will still be stopped between each loop, and the outside cascade method doesnt look smart.

Or maybe DAQ is not suitable for this application?

--

Hope some people give me some information, and then I can check them up.

Many thanks

[Clad19]

Hi Js777,

Thank you for your post to the forums.

Your application seems quite interesting. Would you be able to expand on what you are trying to achieve with this? What is being controlled? 

Would you be able to explain in further detail what you require the Analogue Output task - (background sine wave) for? Is it simply outputting a signal in order to control a different device?

I am a bit confused, as you also mention you will have an additional controlling signal? Would this be more of a Counter Output task? You mention you wish this signal to be triggered in some way using a mouse movement event? Could this be using a horizontal slider bar for example? This would be like ramping up a voltage, if this is understandable? 

You mention that the task may be regenerated, is this correct? If this is the case here is an example relating to this method of generation.

- NI-DAQmx: Retriggerable Analog Output -- LabVIEW

Here are some additional links that may be of use to you:

- Synchronize analog output and counter input on CompactDAQ

- Advanced Triggering Reference Example for CompactDAQ

- Synchronizing Analog Output and Digital Output Tasks in DAQmx with LabVIEW

Why are you requiring that the control signal be stopped on each loop iteration? Is this something related to your hardware?

If you could let me know in more detail what you are trying to achieve it will be easier to help you out.

I hope the links will be useful to you.

Kind Regards,

[js777]

Hi Dominic:

(Thank you for your reply, and probably you are the same Dominic who helped me in Univ. of Cambridge few months ago. If yes, that is great.)

I am using two analogue outputs from NI USB-6211 to control my hardware, which you can think it as a x-y scanner (each output controls one axis, and the output voltage corresponds to the position of that axis.).

So basically, I am controlling the location of the scanner.

The mission of the scanner is that: it is going to scan a pattern around a central point repeatedly and quickly.

The location of the central point is something interacted with the user (so so it will be changing in real time.)

An then I was thinking to give two signals: one is for the repeated pattern, and another one is, say, location of the mouse.

(it can work with using a slider as well, but in the end, by using mouse location might give the user a better interaction experience. )

In my understanding, if the DAQ needs to "re-draw" the output signal, the task needs to be re-generated.

Since the mouse location is changing in real time, I was thinking to run the task once,  then stop it, then check the location of mouse, then generate another new task, and then run it all again.

All are done within a short time so that the user feels instant.

If there is any method that I dont need to regenerate the task but also allows me to input the location of mouse signal to the analogue output, I am happy to do that. I probably just dont know that.

Maany thanks, js

[js777]

Hi 
it has been a long time without further reply. Hope anyone can give some suggestion.
I probably need to re-post it again?

Many thanks

[Clad19]

Hi Jhen-si,

Apologies for the late reply in getting back to you. 

I have been away for the past week. 

I wanted to confirm some points with you:

- There will be two analogue outputs to create the position (x/y) with the voltage being the corresponding to the amount moved in each direction.

- There will be another analogue output (?) to track the mouse movement? Is this correct? Or are you after the ability to track the position of the mouse in real time?

- Are there defined limits in terms of the area within which the mouse can move over? What is the maximum position possible with both x and y in relation to the voltage output?

If you are looking to restart the analogue output signals (the same type and amplitude etc), you will require a regenerative task. 

Here are some examples to look at relating to mouse position tracking:

- Determining the Coordinates of the Mouse with an Event Structure

- Get Mouse Poisition and Front Panel position

- Following the Mouse Position on a Dial, Knob and Gauge

- Calculating the Position of a Mouse Click and Plotting the Position on an XY Graph

- Register Mouse Location Using Event Structure

- Move Mouse Without Event Structure

- Setting Cursor Position Programmatically With LabVIEW

- Mouse Tracker

- Moving Front Panel Controls/Indicators With Mouse While VI Is Running

- Monitoring Mouse Movement and Moving the Front Panel

- Position Property Example

- Voltage as a Function of Position with Time Correlation

- Simple Mouse Detect Example

- Determining the Coordinates of the Mouse with an Event Structure

If you could let me know how you get on and if this is along the right lines, that would be great. If I have misunderstood anything, clarification would be appreciated.

Kind Regards,

[js777]

hi Dominic:

Thanks for replying.

Let me explain my target again (I dont mind how to achieve it).

There are only two outputs. Each one has the signal based on both a fixed signal and the location of mouse. 

I want the analog output signal to be continual (I mean continual enough, say >10000 points/second. I know it is a digital device).

The signal has two components, one is from a fixed(pre-decided) pattern and another is the location of the mouse (or any other control.).

So, let us say, the fixed pattern is value_1>value_2>....value_n, and the time between each value is delta_t. This pattern will repeats when the process completes this pattern once.

So the final results at time m*delta_t will be  " value_m" + " the corresponded value from the mouse location (x or y axis) at that moment".


I thought, If the DAQ-mx is able to generate the signal in real time, then it can work. In another words, after a value for a certain time is calculated, the value is sent to the DAQ immediately, and then the analog output will be this value. (whole this procedure is very quick, within order of micro second, I think 1 Mhz is not demanding for CPU/memory and other hardwares. )

However, in DAQ-mx, seems task needs to be created and deleted before ad after the signals modulation.(or I am wrong?)
The creation and deletion of tasks really cost too much time ( order of miliseconds in my computer.)

I dont know if there is any mode we can control DAQ without using tasks.

Anyway, here is one idea, but probably quite inefficient:

create one task, calculate the signal based on the fixed pattern (for a short time, say 20 ms, and we must know the overall clock time exactly), and take the location of the mouse at that moment for reference, and then run the task, when the task is finished, delete it, and repeat the whole mission. If the whole mission is finished in, say 30 ms, then users feel "real-time". The drawback is that the output is empty when I calculate the signal, creating the task and deleting the task.

And then I was thinink another possibility: To coalesce different actions (generating signal from on-board memory, and uploading signal to the on-board memory)

Is it possible to coalesce them, so the output is still continual?
Like, the calculation and the uploading signals to the DAQ-memory for the time delta_n+1 are done when the DAQ is generating the output for the time delta_n.
Becasue they work in parallel, so I can hide the gap in each run. But I dont know if DAQ support this (generating signal and uploading signal at the same time*.)

* the signal being generated is from memory A area, and those uploaded signal is sent to memory B area. Once the generation mission for memory A area is finished, the generation engine switches to memory B area and then keep working. Althought I really dont know if the DAQ hardware support it or not.


Many thanks
Regards.
Jhensi

[John_P1]

Hi Jhensi,

By default the DAQ device will generate the same buffer repeatedly (I'm referring to the DAQmx buffer which is in kernel memory, see here).  Although you may write to the buffer while the task is running, the buffer is continuously being read by the hardware, so there will always be some uncertainty regarding the correct position to write the new data--you'll likely get repeated samples and/or a mix of old and new data whenever you write new data to the buffer.

If you intend to write data to the DAQ device while the task is running and you want to be absolutely sure of what is output by the device, you'll want to use "non-regeneration" mode.  In this mode, each sample is only generated once so you have to continuously write data to the buffer in order to avoid an underflow error.  Here is an example of this mode put to use.

Best Regards,

[js777]

Hi John:

The non-regeneration mode looks like what I need. I didnt know it can be done like this. 
It should be able to do what I said.
I will give it a try.

Many thanks
Regards, Jhensi

[js777]

I am trying this figure https://decibel.ni.com/content/docs/DOC-7692
(actually not on the labview, but on the C++ by using including daq dll, but theoritically, they are the same thing.)

What I found is the writing is slow.

In the loop, the task_start is only ignited initially and then ignored for the rest loop, that is good.
for the writing, it is supposed to keep the buffer signal updated according to the calculation.
But the action of writing turns out to be too slow.

Here is the main structure of my applicaiton (psudo code):

//////
set daq and define the initial daq signal
other missions

LOOP{   // each loop should be finished within 30 ms to let uses feel real time
run(1st time)/ write(the rest loop) the DAQ signal (long enough for the daq device to run for the time of one loop)
other mission for the next loop
}
///////

I use sample rate of 5000 (1k) and assume each loop is 30 ms long, so I need 150 sample for the writing in each loop.
However, each writing costs about 40 ms, so the loop turns out to be too slow.
And actually it doesnt matter if I reduce the sample rate.
Seems simply the "calling" (not write yet) of writing command costs quite a long time.

I am wondering why the writing takes so much time.  And if so, it can hardly be used for the real time application.
Is it related to the hardware? or probably something wrong in my code?

Many thanks
Regards, Jhensi

[Clad19 · Accepted solution]

Hi Jhensi,

How has the provided example been going for you?

In regards to the delay you are experiencing, there will always be a slight delay incurred due to the underlying DAQmx driver running in the background.

In addition, your USB 6611 will have inherent delay due to the USB bus being used as the communication protocol. There may be a latency up to 100ms in some cases with USB 2.0. 

This driver requires a certain amount of time to change the type of output signal it is producing. 

A user will never really feel a 'Real Time' experience when using an application using DAQmx. Deterministic control applications almost always use an FPGA with a real time embedded controller. 

It is possible that other delays are due to timing considerations in your code but if you have checked these it may be a hardware limitation. 

If you could let me know how you are doing that would be great. 

Kind Regards,