Programmatically retrieve Sample Clock signal source as DAQmx terminal?

[Kevin_Price]

Q: Is there a DAQmx Property node I can query that will give me a "DAQmx terminal" type of output which identifies the task's sample clock signal? 

It would be fine if the result is an internal signal, such as "/Dev1/AOSampleClock".  I just need something of that type which I can wire into another task's  DAQmx Timing.vi to define a shared sample clock programmatically.

I have an existing Action Engine to generate a (shared) sample clock with a counter.  One of the outputs is a DAQmx terminal indicator I retrieve by querying a DAQmx Channel property node for the counter output task's Output Terminal.  I can then feed this DAQmx terminal wire to other Data Acq Action Engines to define this signal as their sample clocks.  One nice feature of this approach is that I can start and stop the clock at will.  This lets me easily pause my sampling, then read fixed quantities of most recent data from the other data acq tasks in sequence, then restart the sampling.  With this approach,  I can retrieve synchronized non-continuous data despite the sequential reads.  (I could also change the sample rate on the fly if I felt like it.)

Ok, well and good.  But I'm faced with a situation where I'd like to port most of this system over to another test rig that has no spare counters.  But it *will* have a spare AO timing system and probably a spare AI timing system.  So I was trying to make my sample clock Action Engine more universal.  I wanted to make it smart enough to be recognize an input channel as AO or AI, and then create a dummy AO or AI task solely for the sake of the resulting clock.  To fit into the existing terminal wiring scheme, I'd like to be able to query this task and get back the sample clock signal in DAQmx Terminal name form, like "/Dev1/AOSampleClock".

I've got a workaround that involves querying the device name, querying the task type, and building the appropriate string from the parts.  But it still seems like the kind of property I might be able to extract with a direct query.   Is there one?  I couldn't find it as a Timing property, a Channel property, or a Task property.

-Kevin P.

[Paul_C.]

Hi Kevin,

I found a DAQmx timing property that shows you the sample clock source.  I verified that this results in "/Dev1/ao/SampleClockTimebase" with the shipping example: Cont Gen Voltage Wfm-Int Clk.vi (This can be found by going to Help » Find Examples in LabVIEW and navigating to Hardware Input and Ouput » DAQmx » Analog Generation » Voltage).  I also verified that it returns "/Dev1/ai/SampleClockTimebase" when using the Cont Acq&Graph Voltage-Int Clk.vi example (This can be found in the Example Finder under Hardware Input and Ouput » DAQmx » Analog Measurements » Voltage).  This should allow you to programmatically determine the sample clock source being used in a task.  Please let me know if this is not what you're looking for.  I have attached a picture of the property node.



I hope this helps,
Paul C.

Message Edited by Paul C. on 09-28-2007 03:35 PM

[Kevin_Price]

Paul,

Thanks.  I had found that property, but its title - SampleClockTimebase - didn't sound promising.  It sounded like it would simply identify the internal timebase from which the sample clock was derived, rather than identifying AISampleClock itself.  That has typically seemed to be the meaning of signals with the word "timebase" in their name.

Because of the name, I'm not sure if I actually tried it before so I'll go off and try it now.  I'll send it into a counter task as a signal to measure so I can tell whether it's a timebase clock running at, say, 20 MHz or the actual sample clock at, say, 1 kHz.  Then I'll report back what I find.

-Kevin P.

[MarkGrot]

Hi Kevin,

Paul is correct in his post.  Querying SampClk.Src will give you the sample clock source the task is using, such as /Dev1/ai/SampleClock or /Dev1/PFI0.  SampClk.Timebase.Src is a seperate property and returns what you describe.

You can wire SampClk.Src to programmatically change your terminals.  This is useful for exporting clocks, using them for other tasks, etc.

[Kevin_Price]

No go.  I tried the highlighted item SampleClock->Source and the similar submenu item SampleClock->Timebase->Source.

The former couldn't be routed to the counter for counting purposes.  The latter could, but it reported itself as a 20 MHz timebase, and the counter task confirmed that rate.

So, still looking for a query-able property that programmatically returns the signal that I'd manually select in a terminal constant as "/Dev1/AOSampleClock"...

-Kevin P.

[Kevin_Price]

Or maybe there's a version issue because that's not how it works on this end.  Attached is an example vi in 8.20 along with screenshots of the diagram and the front panel results from trying the 2 properties in question.

-Kevin P.

Message Edited by Kevin Price on 09-28-2007 06:54 PM

[Neil_S.]

Kevin,

The problem here is that there is no indirect or direct internal route from the AI Sample Clock or AO Sample Clock to the onboard counters with either M or E Series boards.  However, you can still accomplish this route by exporting the sample clock to an external PFI or RTSI line and then using this PFI line as a source.  This does not require external wiring but does use up one of your external PFI lines.  You can do something like the following:



Regards,

Neil Stoddard
Multifuction DAQ
Product Support Engineer
National Instruments

Message Edited by Neil S. on 10-01-2007 09:33 AM

[Kevin_Price]

Neil,  thanks for the reply.  I'd like to explore a couple more things because some of these details aren't easily found in the published docs.

1. I get what you're saying about the lack of a direct route, but there's still a piece that I find puzzling.  I can drop down a DAQmx Terminal diagram constant and select an item named "/Dev1/ai/SampleClock/".  Then I can wire that terminal constant into a Counter task to specify it as the source of the signal I want to measure.  And it works out just fine.  Apparently, DAQmx must do some smart magic behind the scenes to route via an available PFI or RTSI.  (And 3 cheers for that, BTW!)

   So it seems to me that the problem isn't that DAQmx can't figure out what to do with a terminal named "/Dev1/ai/SampleClock/" -- clearly it can.  The problem is that there doesn't seem to be a property I can query that will return a DAQmx terminal wire containing the "/Dev1/ai/SampleClock/" designation.  Are we sure there isn't one?  Mark's earlier reply suggested there is / should be.

2. The output from the query for DAQmx Timing Property-->Sample Clock-->Source is "/Dev1/ai/SampleClockTimebase".  I would have expect my desired terminal value of "/Dev1/ai/SampleClock".  What is the purpose of the former?  What can be done with it that can't be done with the similar-sounding DAQmx Timing Property-->Sample Clock-->Timebase-->Source?  (I've found that I *can* pass the latter along for counter measurement, but not the former.  It seems to me though that any place where the former might be passed along that the latter could be used instead.  That would free up the former property to return what I expect and what Mark reported.

My setup is Dev1=M-series 6259, LabVIEW 8.20, DAQmx 8.6. 

-Kevin P.

[Neil_S.]

Kevin,

Now I get the problem.  I thought this error was due to a routing problem but it is actually due to the driver returning an incorrect value.  The DAQmx Timing -> Sample Clock -> Source should return "/Dev1/ai/SampleClock" when you are using onboard timing.  I assumed, incorrectly, that the error was due to some routing constraint when it really was due to the fact that I was trying to route /Dev1/ai/SampleClockTimebase instead of /Dev1/ai/SampleClock as I assumed it was doing.   /Dev1/ai/SampleClockTimebase cannot be routed to the counter, however /Dev1/20MhzTimebase (which is what is returned by the DAQmx Timing -> Sample Clock -> Timebase -> Source returns) and /Dev1/ai/SampleClock can be.  Therefore the error occured when using the one property and not the other. 

Thanks for catching this one.  This incorrect behavior was reported to R&D (#4E2AKUVF) for further investigation.   One thing to note: if you select a PFI line as your sample clock the property returns the correct value.  This problem occurs with both AI and AO.

-Neil S.

[Kevin_Price]

Thanks Neil -- 1 more followup regarding the workaround you proposed with an explicit routing to RTSI. 

Specifically, when exactly does DAQmx make its decision about how to perform its automatic routing?   How can I make sure my manual routing instructions don't step on its toes?

One of the workarounds I abandoned went like this:  Configure a dummy AO task, route its sample clock manually up to RTSI, pass the RTSI terminal through an output terminal for use by other tasks.  However, I needed a method to verify that the RTSI terminal I wanted to use was actually available.  The only way I know to do that is to ask for the routing, try to reserve / commit the task with the DAQmx state model, and look for an output error that tells me the resource is already reserved.  Then try again with a different RTSI terminal.

Now that *might* be enough to work, but I'm not sure.  I'll have other tasks hanging around out there which have been mostly configured, but not necessarily started, or even reserved / committed.  These other tasks may be relying on DAQmx auto-routing.

So....  Suppose I have partially configured 3 other DAQmx tasks which may depend on auto-routing.  Then I configure this AO task with a manual routing to RTSI0 and reserve / commit it.  Later I start those other 3 DAQmx tasks.  Will they have already decided what RTSI line they *intend* to reserve, but not yet reserved it?  Or do they only decide when I start (or reserve / commit) them?  Will they be aware of and able to avoid my manual signal routing?

And in a related note, is there a better programmatic way to query this kind of stuff than the trial-and-error looping?   Something that means, "Hey, DAQmx, identify the available RTSI terminal(s) I can use here". 

-Kevin P.