PXI6602 & PXIe4497 Sync Sampling with 2 Counter Tasks

[Vibes_saves_Lives]

Hello,

I've searched this board and read a lot of posts this week and still cannot find a solution for my problem. I'm trying to sample AI channels from a PXIe-4497 and syncronize that aquistion with a CI angular position and CI frequency task. My goal was to sample angular position and speed with the same rate as the AI channels. Referencing the 4497 SampleClock works for one task, but when I try to reference this same clock for the second CI task I get an error about "Invalid timing type for this channel". Shouldn't it be possible to reference the 4497 SampleClock for both CI tasks? I've read several posts about using a generated counter to use as a clock for CI tasks, I haven't tried this because referencing the 4497 Clock should be a simple way to sync both CI tasks to the AI card's sampling.

There isn't anything complicated about my setup, simply using DAQmx create channel,timing,start and read. I have LV2013 and a PXIe-1082 chassis.

I'll keep reading though the 6602 timing posts, but if anyone has suggestions please reply.

Thank You.

[Kevin_Price]

I have limited experience with DSA cards like the 4497.  Here's how I would approach troubleshooting:

1. Experiment with the sequencing of configuring and starting your 2 CI tasks.  Does the error always follow whichever task was configured/started latest?  Or does it seem to depend on the physical counter # in the task?

2. I assume each CI task sets up sample timing by referring to the 4497 Sample Clock.  I'd next try explicit routing (not 100% sure what the 4497 supports here).  Use a DAQmx Export Signal vi or property node on the 4497 task to send the Sample Clock explicitly to a specific PXI trigger line.  Then configure both CI tasks to set up their sample timing by referring to the same PXI trigger line.

After getting past the errors, there's still a (potential) gotcha due to the signal delay of the DSA devices.  I *think* that the instant when the 4497 asserts its sample clock signal, it will be converting an analog signal that was present at the terminal block some short time in the past.  There's an unavoidable delay caused by the DSA's bandwidth-limiting filters.

   So the AI value at that sample # represents something that happened in the past while a CI value at that sample # represents something happening at the same instant.  You'll need to address this.  One thing people do is read and discard enough AI samples to compensate for the filter delay.  Just understand that it probably won't do a perfect job since the delay is not generally an integer # of samples.

-Kevin P

[Vibes_saves_Lives]

Thank you for the advice Kevin.

I found that regardless of the VI order, the DAQmx CI Freq task never accepts a SampleClock as a timing configuration. The error I receive says the configuration must be "on demand" or "implicit", which makes sense. The DAQmx CI Angular Encoder task accepted the SampleClock and works great in the continuous sample mode. I don't know why, but the 6602 will not accept the DAQmx CI Angular Velocity task. This will produce an error just from simply running the create channel VI (attached pic). I would be interested if this is a bug or simply not supported by the 6602.

The 4497 does not seem to support the Export Signal VI node.

[Kevin_Price]

Sorry, I skimmed right past your initial mention of one CI Ang. Pos and one CI Freq task.  Angular Velocity is a new-ish task type that I've never used, and it seems likely the 6602 doesn't support it.  I'd guess it's only for STC3 counters (6612 or X-series MIO).

Further, on the 6602, CI Freq must indeed use "Implicit" timing.  Coupled with the inability to export the 4497 sample clock, sync is going to be considerably more complicated if even possible.  The 4497 must generate its own sample clock, CI Freq cannot use *any* regular sample clock, CI Ang Pos needs to share someone else's sample clock, but you haven't found a way to export one from the 4497.  And we still haven't even dealt with lining up the t=0 points for all the tasks.

[time passes...]

Just looked up the manual for DSA devices.  If you search for "export", the earliest hit will refer to exporting a sample clock to sync with a non-DSA device.  So allegedly, there should be a way.  If/when you figure *that* out, you can then work out how a shared trigger signal will work across the tasks.  Note: CI tasks need to configure this as an "Arm Start Trigger" rather than the more usual "Start Trigger".  You'll need to use a DAQmx Trigger property node to get access to it.

Sorry so dense and cryptic, this is all the time I've got at the moment.

-Kevin P