DAQmx APIs: Internal Design Description of State Transitions using TaskControl

[GovindaP]

Hello,

We wanted to understand the internal behaviour of the State Transitions when using
DAQmx TaskControl APIs.

An example of what we were looking for is:
What are the exact steps (happening inside) when we change the
task State from Reserved to Committed?
We wanted to know whether this will generate 'Start Trigger'?

OR, Does 'StartTask' generate a 'Start Trigger' ?
Assuming that 'Trigger Lines' have been configured in both of the above cases.


We are using 4462 and 4461 Devices and wanted to synchronize between them.
We are getting a significant phase differences between.
Any help is appreciated.

Thanks & BR,
Govinda Padaki.

[gavril]

I don't have an answer to your question but this is also a problem
that I will have to face shortly to sync three E-series DAQ cards.

From the DAQmx API, it is not clear how one can send a trigger
signal with the software. The only related function seems to be
DAQmxSendSoftwareTrigger which deals with Advance trigger only

The only way seems to connect a line from the parallel port to
a digital input line of the DAQ and use it as an external trigger.

I would appreciate more comments on this issue, i.e. how to produce
a start, reference and stop trigger by software.

Thanks,

Gabriel

Note: I am not sure exactly what an advance trigger does
because I have a E-series 6034 DAQ and don't find any reference to
a switch task, scan list or advance trigger in the related
documentation.

[Stuart_G]

Gavril

You are going to need to at least use the RTSI lines (if using PCI devices) or the PXI backplane if you are using PXI devices to synchronize the three devices together. You can export a start trigger to start all of the devices at the same time. In terms of reference trigger you would just need to hook up your reference trigger source to all three of the boards and set them up to monitor for that trigger. There are several synchronization examples which ship with LabVIEW. Use the example finder Help>>Examples and look at the DAQmx>>synchronization examples

StuartG

[gavril]

Dear Stuart,

I am not using Labview but the C DAQmx API. For the moment, I use RTSI
to synchronize several 6034E together. I share the Sample Clock between
the two tasks. See my other thread where I give an example of code
that works.

Synchronous continuous AI between 6034 devices in C/C++ with DAQmx
http://forums.ni.com/ni/board/message?board.id=250&message.id=12966

There are still some issues about that are not clear:

From the documentation, it is pretty clear how to use an EXTERNAL
signal as a start, reference or stop trigger and export them on
several devices. However, it is not clear how such signals could
be generated INTERNALLY.

For example, say that I am continuously and visually monitoring some
input values in an experiment and that I want to manuallay send a
reference (or a pause) trigger by typing a touch on the keyboard when
some condition is met. How do I do it since there is not function to send
an software reference (or pause) trigger?

Do I have to write on an PFI and connect this PFI to another
one used as terminal for the reference (or pause) trigger? Is there
a simpler approach?

Regards,

Gabriel

[sergesl]

Hello,

below is content taken from DAQmx Help that explains what each state does and when to use it. It should answer the first question. As far as sending a software trigger, the best way to do that is to poll for the event you are waiting for and start your task once the event occurs. You may also use one of the states listed below to start your task.

Explicit Versus Implicit State Transitions
When should you perform explicit state transitions, and when should you rely on the task to perform implicit state transitions? The answer depends on your application. The following list identifies instances in which you should use explicit state transitions:

Verify—If in your application users interactively configure a task by setting various channel, timing, and triggering attributes/properties, explicitly verify the task occasionally to inform the users if they have set an attribute/property to an invalid value.
Reserve—If the following is true, explicitly reserve a task: your application contains many different tasks that use the same set of resources, one of these tasks repeatedly performs its operation, and you want to ensure that none of the other tasks acquires these resources after the task begins its sequence of operations.

Reserving the task exclusively acquires the resources that the task uses, ensuring that other tasks cannot acquire these resources. For example, if your application contains two tasks that each perform a sequence of measurements and you want to ensure that each sequence is completed before the other sequence begins, you can explicitly reserve each task before it begins its sequence of measurements.


Commit—If your application performs multiple measurements or generations by repeatedly starting and stopping a task, explicitly commit a task. Committing the task exclusively acquires the resources that the task uses and programs some of the settings for these resources. By explicitly committing the task, these operations are performed once, not each time the task is started, which can considerably decrease the time needed to start your task. For example, if your application repeatedly performs finite, hardware-timed measurements, the time required to start the task can dramatically decrease if you explicitly commit the task before repeatedly performing these measurements. Explicitly committing a task also is required if you need to perform additional read operations of the samples acquired by the task after stopping the task. For more information, refer to When Should You Use the Start Function/VI?
Start—If your application repeatedly performs read or write operations, explicitly start a task. Starting the task reserves the resources that the task uses, programs some of the settings for these resources, and begins to perform the specified operation. By explicitly starting the task, these operations are performed once, not each time the read or write operation is performed. This process can considerably decrease the time required to perform each read or write operation. For example, if your application repeatedly performs single-sample, software-timed read operations, the time required for each read operation can dramatically decrease if you explicitly start the task before repeatedly performing these read operations.

[sergesl]

Message contd....

When Should You Use the Start Function/VI?
To explicitly start a task, call the Start function/VI. You auto-start a task when you perform some other operation that implicitly starts the task. For instance, calling a Read function/VI or a Write function/VI might implicitly start the task if one is not already started. How to specify this behavior depends on the operation that your task performs. By default, the Read function/VI and the Write function/VI for a single sample automatically starts a task.

Starting a Finite Measurement Task
If you have specified a task to perform a finite measurement, you do not need to call the Start function/VI, nor do you need to change the default behavior of the DAQmx Read function/VI. Calling the Read function/VI starts your task, performs the finite measurement, and stops the task after the last sample is read. The task returns to its state before you called the read operation. However, if you need to perform additional read operations after the task has been stopped (in other words, if you want to read earlier locations in the buffer), the default behavior is insufficient for two reasons:

The task is returned to the Verified state and the samples are no longer accessible.
Future calls of the Read function/VI start new read operations rather than reading from the completed operation.
For this situation, explicitly commit the task by calling the Control Task function/VI with the action parameter set to Commit. Then, after performing the initial read operation and before performing the subsequent read operations, set the Auto-Start Read attribute/property to False.

Starting a Continuous Measurement Task
For a continuous measurement, explicitly call the Start function/VI, perform the desired read operations, and call the Stop function/VI to stop the continuous measurement. When you perform a read operation in a loop—regardless if the read operation performs a single-sample, on-demand read, or a multiple-sample, hardware-timed read—call the Start function/VI before entering the loop and call the Stop function/VI after leaving the loop. Refer to Continuous Analog Input Programming Flowchart for a sample programming flowchart.

Starting an Analog Output Task
The behavior of the Write function/VI is more complicated. Calling the Write function/VI always results in the task transitioning to at least the Committed state. Whether the task transitions to the Running state depends on the value of the Auto-Start parameter.

For single-sample write operation, call a single-sample version of the Write function/VI. This call implicitly starts the task, writes the single sample, and stops the task. For a multiple-sample, on-demand write operation, call the Write function/VI, but also set the Auto-Start parameter to True, which by default is set to False. This call implicitly starts the task, writes the multiple samples, and stops the task.

For a multiple-sample, hardware-timed write operation, first call the Write function/VI to write the samples to generate, explicitly call the Start function/VI, wait for the samples to be generated by calling the Wait Until Done function/VI, and then explicitly call the Stop function/VI. Refer to Finite Analog Output Programming Flowchart for a sample.

If you attempt to perform a hardware-timed generation with the Auto-Start parameter of the Write function/VI set to True either because you explicitly set it to true or because you are using a single-sample Write function/VI, the operation might fail because the samples that you write are not transferred to the device in time to generate the waveform. As a result, when performing hardware-timed generations, always write at least part of the waveform to generate before starting the task.

Improving Performance with the Start Function/VI
There are other situations in which you should explicitly call the DAQmx Start function/VI and the DAQmx Stop function/VI, even though you are not required to do so. When you call the Read function/VI or the Write function/VI in a loop, you can significantly improve performance if you explicitly call the Start function/VI before entering the loop and call the Stop function/VI after exiting the loop. Without explicitly calling the Start function/VI before entering the loop, the task must implicitly transition from its current state to the Running state before performing the read or write operation. After the read or write operation is complete, the task must implicitly transition from the Running state back to its previous state. These implicit state transitions occur for every iteration of the loop, which is inefficient.

[GovindaP]

Hello,

I would like to rephrase my original question so that I get specific answer.

How are trigger lines (PXITrigX) related to StartTask and StopTask?
I would like to know the timing diagrams if available anywhere.

Thanks & BR,
Govinda Padaki

[thayles]

The Start Task function/vi strobes a bit in a register on your board to start your sample clock running.

1. If the source of the Start Trigger is None, strobing this bit produces a pulse on the ai/StartTrigger terminal and the acquisition begins immediatly. This pulse can be routed to other boards via PXI Trigger lines or RTSI lines.

2. If the source of the Start Trigger is other than None (ie. digital or analog) than strobing this bit (Start Task) does not begin the acquisition. The acquisition begins when the trigger condition is met. When the trigger condition is met, a pulse is produced on the ai/StartTrigger terminal and the acquisition begins immediatly. This pulse can be routed to other boards via PXI Trigger lines or RTSI lines.

So to send a software Start to all your boards, pick one as the master and route its Start Trigger to the other boards. You *do not* have to configure a digital or analog Start trigger for the master board. Its Start Trigger type can be None. The pulse will be sent when the Start Task function/VI executes.

Pause and Reference triggers do not work this way. You must have a digital or analog type of Pause or Reference trigger. To send a Pause trigger to your board by hitting a key, you would configure a digital Pause trigger (source PFIx )for your master board, connect a DIO line to a PFIx, make a digital output task and when the key is hit, write the value to the DIO line that will cause the Pause trigger to occur. Route the master's Pause trigger to other boards via PXI Trigger lines or RTSI lines.

Exporting of Triggers in DAQmx is done with the Export Signal Function/VI and its properties. Importing Triggers is done by declaring the source of the Trigger to be the PXI Trigger/RTSI line used in the export.