10-16-2007 01:51 PM
10-17-2007
07:35 PM
- last edited on
09-30-2025
10:14 AM
by
Content Cleaner
Hello Estern,
Thanks for contacting National Instruments.
It is possible to do a continuous read from an encoder. This method is similar to buffered event counting. The shipping example Meas Angular Position-Buffered-Cont-Ext Clk shows how to use an external sample clock to take readings from an angular encoder at regular intervals. If you are in LabVIEW, you can select Help->Find Examples to navigate to the NI Example Finder. The example can be found under the path: Hardware Input and Output -> DAQmx -> Counter Measurements -> Position.
If you modify this example, you can specify an analog input task to run in parallel to the counter task. You can also specify a start trigger for the encoder task so that the encoder task and the AI task begin at the same time. The sample clock source for the encoder task can then be specified as analog input sample clock pin. The following screenshot shows the basics of setting this task up.
There are numerous support resources for programming with DAQmx. Getting started with DAQmx and Learn 10 Functions in NI-DAQmx and Handle 80 Percent of Your Data Acquisition Applications are all great places for getting started.
Please post back if you have any questions or concerns.
Message Edited by BrowningG on 10-17-2007 07:37 PM
10-22-2007 12:36 PM
10-22-2007 01:12 PM
FYI -- the reason things work for you without the trigger node is that the error in/outs were routed to enforce correct execution sequence via dataflow. Specifically, dataflow requires your counter task to start before the AI task. However, because the counter task borrows its sample clock from the AI task, it cannot take any samples until the AI task also starts. Hooray for dataflow!
Subtle point: during the few odd msec between the two task starts, the counter task will be "armed" and any motion of the encoder will change the hardware count register. You just won't sample and store anything until the AI task starts generating sample clock signals. If your first buffered count value is non-zero, this is probably the reason why.
The "Arm Start" trigger illustrated in the screenshot can be used to counteract this. With an "Arm Start" trigger, the hardware count register won't start updating as soon as you call DAQmx Start. It will only start after receiving the configured Arm Start trigger signal.
Though I haven't used a USB-based M-series device, I would expect the "arm start" trigger to be supported there. However, I think you may need to wire at least one additional trigger property, the one that defines the arm start "trigger type" as "digital edge". Also, the trigger source would need to be changed for your particular example -- the specified AI trigger signal doesn't exist in your untriggered AI task. Have a look at this screenshot for another example of setting up the Arm Start trigger.
-Kevin P.
10-23-2007 06:46 PM
Hello Estern,
There is a difference between a Start Trigger and an Arm Start Trigger. An Arm Start Trigger will arm the counter, while a Start Trigger will allow the counter operation to begin. Without a Start Trigger, an Arm Start Trigger behaves the same as a Start Trigger (it will both arm and start the counter task). It is important to note that a Start Trigger is only supported in single pulse, finite pulse train, and continuous pulse train generation counter tasks. In all other counter tasks (such as a count edges task) you can only use an Arm Start Trigger.