Re : difference between arm start trigger and start trigger

[feilong]

Hello all,

I am learning using arm start trigger to start two edge counting task simutaneously. But I don't have a good example to start with.

I just found a encoder example but it uses A B Z input which is confused to me at this statge.

So I wish someone could post a simple example to show me how this could be done. I would like to have 100KHz internal clock as CTR source, external PFI line as sample clock.for both CTR task.

I also read example "\Multi-Function-Synch AI-AO-Ext Dig Trigger.vi" and think it may do same job so I don't understand why bother arm start trigger as stated in most places for synchronization purpose.

Any advice will be apprieciated!

Feilong

[BenjaminR]

Hi feilong,

An external stimulus that initiates one or more instrument functions. Trigger stimuli include a front panel button, an external input voltage pulse, or a bus trigger command. The trigger may also be derived from attributes of the actual signal to be acquired, such as the level and slope of the signal. For the Arm Trigger, the trigger circuitry of a digitizer is armed, meaning that it is ready to start acquiring data when an appropriate trigger condition is met. Generally we use Arm Start Trigger for Counter and Start Trigger for AI/AO.

[feilong]

Thanks Benjamin,

This do help. So in the counter task, my understanding is, we don't use DAQmx start trigger and instead use a arm start trigger. And when the trigger condition met, the acquistion starts. Is it right?

I just wonder why NI couldn't unify these two triggers in counter application so make thing easier.

feilong

[NI-Bongo]

Hi Feilong,

The reason the triggers have different names for counter tasks and AIO & DIO tasks is because the fundamental purpose of them is different.  For example, when we configure a start trigger on an AI task, data is gathered onto the FIFO of the DAQ device as soon as the Start Task VI is called, but it is overwritten continuously until the start trigger is received.  The trigger causes the data to be transferred from the FIFO to the PC buffer and then into LabVIEW memory.  All the data from before the trigger was read onto the FIFO, but overwritten and never brought into software. 

Counters have no FIFO and unless you configure an Arm Start Trigger, a counter task will execute as soon as the task is started.  The Arm Start Trigger tells the counter when to start counting, but does not tell it when to pass the values along to PC memory. The gate signal is used to trigger the buffering of the data on a count edges task, for example.  I hope this helps clarify things a bit.  Let us know if you have further questions.

[feilong]

Thanks John, your post do help.

I have a specific question about the vi I am working on (attached). There' are a retriggerable pulse gen task and a encoder task in it and should run same time. but I found they never run simutaneously and always the pulse gen task is the only one to run after I lunach the vi,as monitored by oscillisope. Only after I press stop button for the pulse gen task, then the encoder task will start to run, which is fairly strange.

Could you please have a look and tell me what might be the reason?

thanks

Feilong

[NI-Bongo]

Hi Feilong,

I'm taking a look at your code now.  I am just curious what your overall application goals are so I know what you are trying to do.

Also, why are you using the 100kHz timebase for the encoder A input?  Is your encoder Z indexed?

Right now there is no link between the 2 tasks, so they may or may not run simultaneously.  It is important to remember that LabVIEW is a dataflow programming language.  It doesn't execute left to right, but rather any code that has received all its inputs will run.  Conversly, any part of your code that has not received all its input will not execute until the inputs are received.

Once I have some of these details, I may be able to give you better advice on your LabVIEW VI.

[NI-Bongo]

Hi Feilong,

Also, to clarify your questions about when you can use the Arm Start Trigger and when you can use the Start Trigger with counter tasks, the Arm Start Trigger is used to tell the counter to start counting, so all counter input task types use this.  The Start Trigger is only used for single pulse, finite pulse, and continuous pulse generation with a counter output task and the Start Trigger begins the generation.

[feilong]

Hello John,

My application is to timestamp each of the AI reading samples. I could provide a very accurate 1 pulse per second signal (from which I know the absolute time base) to as the reset terminal z fed to counter. and the 100KHz time base is fed to source terminal of the counter. The sample clock for the counter is the AI sampling clock. So by this way, every time AI read one sample, the counter will read its value too. By adding this counting value to the known absolute time base, I could know the timestamp of the current AI reading.

So there's no a real encoder in my application, I am using the encoder reading setting for counter as it provides a convinent way to refresh the absolute time base regularly so there's no accumulated time error during a long period run.

The reason I don't use the 1 PPS to feed the z terminal directly is that, the original 1 PPS external signal has too long high state so, during its high, the counter doesn't count anything. So this is why I made a pulse gen task to "transform" this original 1 PPS to a shorter form, which I could control how long it could stay at high.

hope this make clear about the application

Feilong

[NI-Bongo]

Hi Feilong,

This is a quick post.  I haven't had time to actually understand what you are doing with the counters.

In case you didn't know, you can automatically assign a timestamp to your samples by using the AI Waveform acquire.  This takes your OS date/time value for an initial timestamp (t0) and a dt based on your sample clock rate.  This has all the information you want and is MUCH easier to implement.  Let me know if this will work for you and if you need help implementing it.

[feilong]

John,

I don't think the waveform aquire would be a good choice for me as I need to timestamp each AI sample in term of GPS time with an accuracy within 100us or so. I  need to synchorize these data with other data collected by other computers. So the only way I could synchorize them is to use a unified time standard rather than each computer's own timer. I know NI has a GPS board but it's not available for our project for the cost reason.

Feilong