start digital edge not supported by 6612?

[Bauer_CT]

I am trying to support some equipment we have in the field. We are reading a linear and angular encoder trying to synchronize them. We are using PXIe-6612. I am already using the CTR7 to generate a sample clock that the two CI tasks share, wired back into an available PFI line (PFI7 I believe). That's working fine.

I was synchronizing the start just by calling the two "DAQ Start" VI's "at the same time" in a sequence structure (we are using LabVIEW 2014). There are questions as to whether this is adequately synchronized. In fact I found quite a difference if I would start angle first then linear, or if I would start linear first then angle.

Anyway, start trigger should be easy so I thought I would do that. I have an Allen Bradley PAC in the system that can output a DO and I wanted to use an available PFI line (PFI6 iirc) as a start trigger.

Unfortunately when the customer runs this code, the DAQmx Trigger call returns error -200452, which makes it seem like I can't use that function on this card. From what I can tell from the rest of the literature, it should actually work fine.

Thanks for any insight anyone can provide. Of course this is made more complicated by the fact that I don't have physical access to the hardwrare at the moment...

[Kevin_Price]

This is an unfortunate area of what I'd call "asymmetry" in the DAQmx driver.  You can use the regular Start Trigger for AI, for AO, for DI, for DO, and for CO tasks.  But not for CI tasks.

For CI tasks, you can accomplish the desired result with an "Arm Start Trigger", which you'll need to configure using a DAQmx Trigger property node.  Define the Type (Dig Edge), the Source (or maybe it's called Terminal?), and the Edge.  The behavior will be just what you'd expect from the regular Start Trigger.  I seem to recall there's a subtle technical distinction between them, but have never seen it have any bearing on the things I've worked on. 

BTW, a simpler way to sync acquisition would be to start the two encoder tasks before starting the sample clock task from CTR7.  Starting the task will cause the counter to start incrementing or decrementing with encoder cycles and the first sample clock will then capture an instantaneous position.  The absolute values of those two positions don't particularly correlate to one another because they didn't start counting simultaneously.  They only *capture counts* simultaneously. 

   The difference you can make with the Arm Start Trigger is that both tasks *will* start counting simultaneously.  Thus the first sample gives you two positions that *do* correlate -- they are the absolute displacement from the time of the shared Arm Start Trigger to the time of the first shared Sample Clock.

-Kevin P