change detection with timer

[Travis G.]

Hello Yuri33,

Have you tried configuring a start trigger for just the analog input task with the trigger source being the change detection event, rather than configuring start triggers for your counter and digital tasks?  You'll have to reverse the order in which your tasks are started, with the analog task starting first, then counter, then digital.  Let us know if this allows you to synchronize the tasks. 

Regards,
Travis G.
Applications Engineering
National Instruments
www.ni.com/support

[Kevin_Price]

Another tidbit to add to Travis' suggestions: last time I checked into it, counter INPUT operations cannot use the regular digital Start Trigger.  There's a special trigger called an "Arm Start" trigger that can be used for counter input measurements.  It can only be accessed through the DAQmx Trigger property node.

I would have thought that the Digital Input task *could* use a regular Start Trigger though, provided you didn't already have an error from trying to configure a regular Start Trigger on the counter input task.  I tried to look at your code, but I'm back at v7.1 and couldn't open it.

I think Travis' idea should get you where you want to be.  Since the digital task's change detection event is really the key synchronizing signal, it's important that the analog and counter tasks are started *before* the digital task.

-Kevin P.

[Yuri33]

Thanks for you input guys, but I believe I've solved the issue.  Your suggestion of using the DI task as the start trigger will not work in my application, because I need to start collecting analog data before the first change detection.  That is, the counter timestamp and the analog task need to start synchroneously, and and change detections after that start need to timestamped such that they can be correlated with the analog data.  You were right that the count edges task needed to use the Arm Start trigger and not a start trigger (I'm not sure why this is the case, but examples found on this website point to the Arm Start trigger).

The other key was that the ai/StartTrigger could not be routed to the counter tasks.  This was circumvented by creating a simple digital output task on an unused port, and routing the output to an RTSI pin (not RTSI0, however--no matter what I did, it always seemed that terminal was being used for something else).  This RTSI terminal can than be set as the start trigger (for the analog input task) and the arm start trigger (for the count edges task).  After all the other tasks are started, a simple write to the DO task will start everything synchroneously.

Finally, as I discoved while experimenting with the code, there can be no start (Arm or otherwise) for the change detection event.  Remember that by it's nature, it doesn't have a regular sample clock, so synchroneously starting it with other tasks is fairly useless.  You just need to start it programmatically before the other tasks--it won't fire until one of the change detection lines trigger it.  Also note that rather than letting DAQmx handle it, it was easier for me to force the routing of the change detection event to the gate (sample clock) of the count edges task by routing the signal to another RTSI terminal.

Using this scheme, I've even managed to include a couple of other tasks (analog output and a retriggerable delayed pulse using the other counter), all synchronized to the "universal" DO start trigger.  These M series boards can do quite a lot!

I haven't attached the code, because I've added some other things that are unique to the application I'm building, but if anyone is interested, I can post a stripped down version that demonstrates the idea.

I have one more question, however:  A change detection task is monitoring 6 lines on port 0.  I also have a retriggerable delayed pulse task (CO Pulse Time) whose trigger I want set to one of the lines that the change detection task is monitoring.  Every attempt to do this in software runs into resource conflict errors (the change detection task monopolizes the port 0 terminals), so I've jumpered that line to another line on port 1 in order to trigger the pulses.  Is there a means to share this line without having to use this jumper in hardware?