6036 E-Series AI Internal Sample Clock

I have a 6036 E-Series board and am implementing the DAQmx Analog Input. I want to use the Internal Sample Clock
instead of software timing. I've reviewed and tried to run the examples provided, but only the software timed routines
function. All of the Internal Clock routines sit and wait for the timeout to occur. Any help would be appreciated.

Hello TonP,
The code is directly from Labview 7Express "NI Example Finder", search: DAQmx Analog Input Voltage,
->Continuous Acq&Chart Samples-Int Clock.vi (filtered for 6036 E -series)-see attached cut 'n pastes.
I do NOT want to use an External Clock or Software timing. This AI routine is part of a larger picture of AI, AO, DIO
and Counters to be implemented in a large VI and eventually synch'd together (for later). I've tried all related Int Clock
examples, with same timeout result. It's as-if the Int Clock is not being addressed. Is this the same Int Clock that
AI Traditional uses? Is there only one clock? Do AI, AO, DIO use/rely on same clock? Do I need to address a specific
clock or is it automatically implied? Oh yes, this is PCMCIA.
Attachments:
DAQmx AI Voltage.jpg ‏101 KB

Similar Messages

Using an internal sample clock with a digital input

I am using an encoder to measure angle and velocity. The example that I have started with is here. https://decibel.ni.com/content/docs/DOC-6834. The problem I am having is with the Sample clock, I get a timeout at the DAQmx read. If I remove the sample clock the VI runs fine, but I have no idea of my sample rate. Below is the the problem setup with the Sample clock inline.
Attachments:
encoder with timer.JPG ‏50 KB

Hi there, a couple suggestions: first , this is a post that it is suppose to be on the DAQ board. Second, you are not being clear about the error, try to include the error code, description and its location, is it coming out of the channel node or the timing VI? Also what hardware are you using?
Now, If you open the example called "Measure Angular Position.vi" from the NI example finder, drill the DAQmx Create Channel, you will see that you are missing a couple terminals for the task configuration, I wonder if this is part of the error.
Alejandro | Academic Program Engineer | National Instruments

NI6602 pulse width measurement: Do I have to use an external sample clock?

Hi
In the .NET 4 example 'MeasPulseWidthBuf_SmplClk_Cont' it is stated in the comments that:
An external sample clock must be used.
Counters do not have an internal sample clock available. You can use
the Gen Dig Pulse Train-Continuous example to generate a pulse train on
another counter and connect it to the Sample Clock Source you are using
in this example.
I have an application running without specifying an external clock. The applications is running, but I'm not sure I can trust the recorded data. Here is the channel creation code:
   task.CIChannels.CreatePulseWidthChannel(readTaskCounter,
   "ReadPulswidthTask", 25e-9, 20e-6,
   CIPulseWidthStartingEdge.Rising,
CIPulseWidthUnits.Seconds);
task.CIChannels.All.DataTransferMechanism = CIDataTransferMechanism.Dma;
   task.Stream.Timeout = callbackTimeoutInMilliSeconds;
task.Stream.Buffer.InputBufferSize = 50000;
   task.SynchronizeCallbacks = true;
   task.Timing.ConfigureImplicit(SampleQuantityMode.ContinuousSamples);
   task.Control(TaskAction.Verify);
Note that I'm not specifying any external clock.
1) Which clock is the daq using? -It is obviously using some clock since I can collect data via this task.
2) Do I need to change the configuration to use an external clock to achieve reliable readings - as mentioned in the 'MeasPulseWidthBuf_SmplClk_Cont' example?
/mola
Solved!
Go to Solution.

Hi mola,
That specific example is for sample-clocked pulse width measurements. This type of measurement is only supported on newer hardware such as X Series boards and will not run on the 6602.
Your application that you linked uses Implicit timing, meaning that the signal itself serves as the sample clock. That is, at the end of each pulse width that you measure, the sample is deterministically latched in. So, you end up with a buffered array of every pulse width that is seen by the counter.
Best Regards,
John Passiak

Can buffered digital edge detection only be performed using an external sample clock?

I am working on an application where I need to measure the speed (rpm) of a motor as it starts up using the output of its built in hall effect sensor. The sensor should output 2 pulses per revolution of the motor. My plan is to count the pulses from when the counter (counter 1) is armed to when it is up to speed. Looking at the M series manual, the CVI (v8.5.1) help, and the examples it appears that this can only be done using an external sample clock. Is there a way to route an internal sample clock to the appropriate terminal on the counter so that I do not need to add additional hardware?
I am currently using a PCI-6289, but the final application will use a CDaq-9188 chassis (using one of the the built in 32-bit counters).
Thank you for your assistance.

Thank you for your input.
However, I did forget to mention one detail of the application. I need to buffer the edge counts so that I can graph the speed of the motor as it starts up. I need to be able to acquire the edge counts at reqular intervals so that I can determine how fast the motor was rotating at each point. So far I have not been able to find an example of doing this without and external sample clock. As I mentioned, in the final application I will be using the 32-bit counters on a CDAQ-9188 chassis. The only thing I can think of at this point is to generate a pulse out of the second counter and use that as the sample clock. Will this work?

NI 6343 Internal DI Sample Clock counter name text string?

I need to add a frequency test to my remote site (remote debug). Could someone tell me the text string as counter name for NI 6343 Internal DI Sample Clock? Thanks.

Does your remote computer have MAX installed? This is the easiest way to see what the device alias is.
You can always just try Dev1 and see if it works. This is the default when the very first device is added to a system.
If you can deploy code to the remote system, you can also use the DevNames property of the System Node from the DAQmx System Setup palette. This will show you all of the names of the devices in the system and you should see your device there.

Using AI Sample Clock to Trigger Counter Samples

My basic question is: Is the ai\SampleClock signal only active while an analog input task is running?
The details are:
I have an X-series PCIe-6321 multifunction DAQ card. It is controlling a SCXI chassis and has a SCXI-1180 and SCXI-1302 so I can control analog inputs of the chassis as well as access the 4 counter on the card. My application requires that I use all 4 counters to measure a frequency input signal and synchronize the samples to the analog input signals. I have created 5 tasks, 1 for the AI and 1 for each counter.
I am using LabVIEW 8.6.1 with the latest NI-DAQ drivers on and 64-bit Vista OS
1. Are there any driver or hardware restrictions that would cause this solution not to work?
2. Can I use the ai\SampleClock as in input sample clock for each of the frequency tasks? If I do this will the sampling start be syncronized? I.e. if I start each of the frequency tasks first, will they wait until the AI task is started before they start sampling?
3. If that doesn't work, do I need to route the sample clock from the AI task to a PFI line (PFI1) and then use that as input to the frequency task sample clock?
I usually do option 3 when synchronizing two cards in PXI chassis and only use the software task start in stead of of synchronizing on a digital start, since the sample clock will control the samples anyway. I need to know if the same behaviour works with the scenario above.
Thanks,
Bob
Prolucid Technolgies Inc.
Solved!
Go to Solution.

Hi Bob,
I can confirm that the ai/SampleClock will only be active while the AI task is running. As far as the other questions go:
1. You'd have to provide more information about what you looking to do exactly, but there is no problem with routing the sample clock of the Analog Input task to be used with the Counters. I would read through the section of the X Series User Manual that discusses sample-clocked frequency measurements (starting on page 7-16) for some more information about what is actually going on during this configuration to make sure it suits your requirements.
The frequency of the signal to be measured should be at least twice as fast as the sample clock of your AI task.
2. You can indeed route the signal to all four tasks at the same time (you can refer to the Device Routes page in MAX to double-check routing restrictions). The sampling will be synchronized provided the four counters are started before the AI task, but the counters will be armed at different times unless you configure an Arm Start Trigger (see page 7-45 of the X Series User Manual). I would consider using the ai/StartTrigger if you wish to do this.
The effect of not arming the counters at the same time would be a different number of periods to average on each counter for the very first sample (assuming averaging is enabled). This might not be a big concern but I just wanted to point it out.
3. The routes are available internal to the board so external routing isn't necessary, you can just specify to use the AI Sample clock for the clock of each counter and the routes will be made for you. If you prefer to export the signal on a PFI line and route it back in on a different PFI line this option is also available to you but shouldn't be necessary.
I hope this helps you get started. I'd make sure to take a look at chapter 7 of the X Series User Manual if you get a chance since it describes how all of the counter configurations work in more detail. If you have any related questions don't hesitate to post back.
Best Regards,
John
Message Edited by John P on 12-01-2009 07:52 PM
John Passiak

NI PCIe-6351 Count Edges Channel error on fast TTL - Multiple Sample Clock pulses were detected

Hello,
I am trying to use a PCIe-6351 to record the arrival times of a fast TTL pulse stream (generated by an Excilitas/Elmer Perkin APD). The TTL pulses are 2.5 volt amplitude, 20 ns duration, with a gauranteed dead time of 50 ns between pulses. I am trying to use the the Count Edges function, with the 100MhzTimebase as the input terminal and the input to counter 0 (PFI8) as the sample clock. After a few seconds of acquiring data at 100 Mhz, the application throws the following error (-201314):
"Multiple Sample Clock pulses were detected within one period of the input signal"
I had thought that because there is 50 ns dead time between pulses, multiple pulses would never arrive within a single clock cycle of the 100 Mhz timebase. Is there any way this might not be the case? Alternatively, is it possible that the counter is triggering on some jitter around the edges of the pulses? If so, is there any way to filter such high frequencies without losing the 20 ns pulses?
I have read through the forums for similar problems with photon detectors, but have not been able to resolve this issue. Thank you for the help.
Matthew Bakalar

It sounds like the input signal is being detected as multiple edges.
The PFI filtering feature on the X Series card likely isn't going to be suitable for you. The minimum setting is actually exactly 20 ns, which should in theory guarantee a 20 ns pulse passing through. However, if the signal is high for anything less than that there wouldn't be a guarantee (depending on the phase of the timebase relative to the rising edge of the signal)--considering rise times and that there is evidently a glitch in the signal itself, it probably isn't actually a continuous 20 ns high time by the time the DAQ card sees it.
What you should do instead:
Configure a second counter as a retriggerable counter output (single pulse).
Use your external signal as the start trigger for this counter output task.
Set the initial delay, high time, and low time for the counter output task all to 20 ns (the minimum).
Use the internal output of the counter output task as the sample clock source for the original edge count task.
The counter output will be triggered when it sees the external signal, wait 10-20 ns, then generate a 20 ns pulse. If there is a glitch on the trigger line during this 30-40 ns that the output is generating, it will be ignored. The counter output will be re-armed in time for the next pulse given the minimum dead time of 50 ns between pulses.
Best Regards,
John Passiak

Buffered event counting. Why can't I explicitly sequence generating the Sample Clock Pulse and reading the counters?

At irregular occasions I need to grab counts from several counters, and buffering the counts must be done simultaneously for all counters. I'm modeling my approach after zone.ni.com/devzone/cda/tut/p/id/5404 which someone kindly pointed out in an earlier thread. However, that example only uses one counter, and you can't test the synchronization with only one counter, so I am using two counters configured the same way, and they're wired to a single benchtop signal generator (for example at 300 kHz).
What I want to do, I can test in a loop with a somewhat random wait in it. I want to drive a hardware digital output line high for a few ms and then low again. The hardware line is physically connected to terminals for my timing vi's Sample Clock Source and so will cause them to buffer their counts for later reading. After I pulse this line, when I know new good buffered counts await me, I want to read both my counters. If their bufferings are simultaneous, then each counter will have counted the same number of additional counts since the last loop iteration, which I can check by subtracting the last value sitting in a shift register and then subtracting the two "additional counts" values and displaying this difference as "Diff". It should always be 0, or occasionally +1 followed immediately by -1, or else the reverse, because buffering and a count could happen practically at the same moment.
When I do this using a flat sequence to control the relative timing of these steps, so the read happens after the pulse, the counters often time out and everything dies. The lengths of time before, during, and after the pulse, and the timeout value for the read vi, and the size of the buffer and various other things, don't seem to change this, even if I make things so long I could do the counting myself holding a clipboard as my buffer. I've attached AfterPulse.vi to illustrate this. If I get 3 or 10 or so iterations before it dies, I observe Diff = 0; at least that much is good.
When I use two flat sequences running in parallel inside my test loop, one to control the pulse timing, and the other to read the counters and do things with their results, it seems to work. In fact, Diff is always 0 or very occasionally the +/- 1 sequence. But in this case there is nothing controlling the relative timing such that the counters only get read after the pulse fires, though the results seem to show that this is true. I think the reads should be indeterminate with respect to the pulses, which would be unreliable. I don't know why it's working and can't expect it to work in other environments, can I? Moreover, if I set some of the pulse timing numbers to 1 or 2 or 5 ms, timeouts start happening again, too. So I think I have a workaround that I don't understand, shouldn't work, and shouldn't be trusted. See SeparateSequence.vi for this one.
I also tried other versions of the well-defined, single sequence vi, moving the counter reads to different sequence frames so that they occur with the Sample Clock Source's rising edge, or while it is high, or with the falling edge, and they also often time out. I'll post these if anyone likes but can't post now due to the attachment limit.
Here's an odd, unexpected observation: I have to sequence the reads of the counters to occur before I use the results I read, or else many of the cycles of this combine a new count from one counter with the one-back count from the other counter, and Diff takes on values like the number of counts in a loop. I though the dataflow principle would dictate that current values would get used, but apparently not so. Sequencing the calculations to happen after the reads fixes this. Any idea why?
So, why am I not succeeding in taking proper control of the sequence of these events?
Thanks!!!
Attachments:
AfterPulse.vi ‏51 KB
InSeparateSequence.vi ‏49 KB

Kevin, thanks for all the work.
>Have you run with the little execution highlighting lightbulb on? -Yes. In versions of this where there is no enforced timing between the counter and the digital line, and there's a delay inserted before the digital line, it works. There are nearly simultaneous starts on two tracks. Execution proceeds directly along the task wire to the counter. Meanwhile, the execution along the task wire to the digital high gets delayed. Then, when the digital high fires, the counter completes its task, and execution proceeds downstream from the counter. Note, I do have to set the timeout on the counter longer, because the vi runs so slowly when it's painting its progress along the wires. If there is any timing relationship enforced between the counter and the digital transition, it doesn't work. It appears to me that to read a counter, you have to ask it for a result, then drive the line high, and then receive the result, and execution inside the counter has to be ongoing during the rising line edge.
>from what I remember, there isn't much to it. There really aren't many candidate places for trouble. A pulse is generated with DIO, then a single sample is read from each counter. -Yup, you got it. This should be trivial.
>A timeout means either that the pulse isn't generated or that the counter tasks don't receive it. - Or it could mean that the counter task must be in the middle of executing when the rising edge of the pulse arrives. Certainly the highlighted execution indicates that. Making a broken vi run by cutting the error wires that sequence the counter read relative to the pulse also seems to support that.
>Have you verified that the digital pulse happens using a scope? -Verified in some versions by running another loop watching a digital input, and lighting an indicator, or recording how many times the line goes high, etc. Also, in your vi, with highlighting, if I delete the error wire from the last digital output to the first counter to allow parallel execution, I see the counter execution start before the rising edge, and complete when the line high vi executes. Also, if I use separate loops to drive the line high and to read the counter, it works (see TwoLoops.vi or see the screenshot of the block diagram attached below so you don't need a LV box). I could go sign out a scope, but think it's obvious the line is pulsing given that all these things work.
>Wait! I think that's it! If I recall correctly, you're generating the digital pulse on port0/line0... On a 6259, the lines of port 0 are only for correlated DIO and do not map to PFI. -But I'm not using internal connections, I actually physically wired P0L1 (pin 66) to PFI0 (pin 73). It was port0/line1, by the way. And when running some of these vi's, I also physically jumper this connection to port0/line2 as an analog input to watch it. And, again, the pulse does cause the counter to operate, so it clearly connects - it just doesn't operate the way I think it is described operating.
For what it's worth, there's another mystery. Some of the docs seem to say that the pulse has to be applied to the counter gate terminal, rather than to the line associated with the sample clock source on the timing vi. I have tried combinations of counter gate and or sample clock source and concluded it seems like the sample clock source is the terminal that matters, and it's what I'm using lately, but for example the document I cited, "Buffered Event Counting", from last September, says "It uses both the source and gate of a counter for its operation. The active edges on the gate of a counter is used to latch the current count register value in a hardware register which is then transferred via Direct Memory Access...". I may go a round of trying those combinations with the latest vi's we've discussed.
Attachments:
NestedSequences.png ‏26 KB

6120 external sample clock

We have been successfully using the 6052e for some time now to acquire our radar�s analog output. This output consists of a data signal synced with a 20 Hz analog trigger that also comes from the radar. This has been a nice easy solution but now we have increased our frame rate from 20Hz to 60Hz. Quantitatively, the old system was taking 20Hz X 9,984 samples = 200 KS/s, while the new system takes 60Hz X 9,984 samples = 600 KS/s. The 6052e no longer could handle the increase so we purchased the 6120.
The problem we have now is that 6120 does not seem to support the same acquisition technique that we used with the 6052e.
Here is what we are doing with the 6052e:
We use the 6052e to generate a pulse train with frequency correspondin
g to our sample rate, which is gated by a signal that turns on when the trigger pulse occurs and stays on for a fixed number of samples. We then route that pulse train back into the board as our external sample clock. The problem seems to be that the 6120 does not support the external sample clock.
The reason we use this technique with the 6052e is to guarantee that we get the same number of samples between triggers.
Ian Starnes
Sr. Software Engineer
NIITEK, Inc.

Ian,
I am going to guess that you are experiencing this problem because our S-Series boards such as your 6120 use a pipelined FIFO ADC process. Specifically, our S-Series boards do not send the last 3 samples of an acquisition when using an external clock. The last three samples remain in the FIFO on the card. Therefore, if you begin your acquisition, receive a trigger pulse, then receive 9,984 clock edges on the sample clock, and then read all the samples in the buffer, you will only receive 9,981 samples. Consequently, if you set the AI Read.vi to read 9,984 samples it may timeout because it is still waiting for three more samples to be acquired. This would create the allusion that the external clock was not working with the 6120.
The good news is that i
t is easy to solve this issue. You simple need to read 3 less samples the first time AI Read is called. Therefore, the first time you call AI Read you need to read 9,981 samples and then the next time you call AI Read you will continue to read 9,984 samples. This will ensure that you will get the same number of samples between triggers except for the first time which will be short three samples. However, with this method, the first three sample of each trigger will be the last three samples from the previous trigger signal.
Please see this KB for additional information on how to ensure that you get the proper amount of data for each trigger signal that you receive:
http://digital.ni.com/public.nsf/websearch/D64CD277A6B739A186256A73007E7BCC?OpenDocument
Please let me know if you are still having difficulty or if the information I provided did not help resolve the issue.
Regards,
Bill B
Applications Engineer
National Instruments

Counter Output as Sample Clock of Digital Signals

I have a situation where I need to use a hardware counter as sample clock of digital output signals.
How do you specify the "Counter Internal Output" signal as a sample clock of digital output?
I want to do something like this:
// Create counter task
  CNiDAQmxTask m_Task(_T("ATask"));
  m_Task.COChannels.CreatePulseChannelTicks(_T("Dev1/ctr0"), "", _T("20MHzTimebase"), DAQmxCOPulseIdleStateLow, 0, 10, 10);
  m_Task.Triggers.StartTrigger.ConfigureDigitalEdgeTrigger("PFI0", DAQmxDigitalEdgeStartTriggerEdgeRising);
// Create digital output task
  CNiDAQmxTask m_Task2(_T("ATask2"));
  m_Task2.DOChannels.CreateChannel("Dev1/port0/line0", "", DAQmxOneChannelForAllLines);
  m_Task2.Timing.ConfigureSampleClock("XXXXXX", 0, DAQmxSampleClockActiveEdgeRising, DAQmxSampleQuantityModeFiniteSamples, 400);
How do I specificy "counter 0 Internal Output signal" instead of "XXXXXX" above, i.e. the sample clock of the digital output signal. Can't find the name of the signal anywhere in the documentation and help files. I have a 6259 DAQ board.
/pek

Thank you for your answers, but I can't get it to work.
When I use "ai/SampleClock" as sample clock everything works correct. When I try to use a counter as sample clock the task completes imediately, before any digital signals has been sent/measured. The task even completes before I have started the trigger, which is very confusing. No error appears.
I think that something is wrong about how I setup the counter. I use the code below:
// Create counter task
CNiDAQmxTask m_Task(_T("ATask"));
m_Task.COChannels.CreatePulseChannelTicks(_T("Dev1/ctr0"), "", _T("20MHzTimebase"), DAQmxCOPulseIdleStateLow, 0, 100, 100);
m_Task.Triggers.StartTrigger.ConfigureDigitalEdgeTrigger("PFI0", DAQmxDigitalEdgeStartTriggerEdgeRising);
// Create digital output task
// The code below works with "ai/SampleClock" as sample clock
CNiDAQmxTask m_Task3(_T("ATask3"));
m_Task3.DOChannels.CreateChannel("Dev1/port0/line0", "", DAQmxOneChannelForAllLines);
m_Task3.Timing.ConfigureSampleClock("Dev1/Ctr0InternalOutput" /*"ai/SampleClock"*/, 0, DAQmxSampleClockActiveEdgeRising, DAQmxSampleQuantityModeFiniteSamples, 400);
// Create samples
CNiUInt32Vector ui_data;
for(int i = 0; i < 200; i++)
for(unsigned int j = 0; j < 2; j++)
    ui_data.Append(j);
// Create digital writer
CNiDAQmxDigitalSingleChannelWriter m_writer3(m_Task3.Stream);
m_writer3.WriteMultiSamplePortAsync(true, ui_data);
// Wait until task completes
m_Task3.WaitUntilDone(-1);

6251 AO sample clock

Hello All,
I am using a M6251 board for analog output. However, I have the problem that the board only allows discrete increments in the frequency of the Analog Output sample clock. The frequency step-size varies, depending on the sample-clock frequency, and reaches around 10kSa/s when the sample clock is running at 1MSa/s. Am I doing something really stupid, or is this a limitation of the board? The digital pulse-train generation does not seem to have this limitation. If this *is* a limitation of the board, is there some way of overcoming it? I have tried to re-route one of the counters into the AO sample clock, but, when I do so, I get an error message saying that resource is already in use.
Any help will be greatly appreciated.

There are two things that I can think of that could be causing the behavior that you're seeing. The first is that you are using the onboard Frequency Generator to generate the AO Sample Clock. If this is the case, you will notice that the Frequency Generator has limited capabilities in the frequencies it can generate. If this is the case, use the default AO Sample Clock as the clock for your AO application. M Series devices have a dedicated timing engine for AO applicatins, hence, no onboard subsystem (i.e. counters, PFI lines, etc.) will be used up if you use the AO Sample Clock default selection for timing your AO applications.
The second guess that I have is that you are not specifying your AO application correctly in order to get the generated waveform frequency you're expecting. Their are several parameters that you need to set in order to get an expected frequency with AO - rate and samples per channel. Have a look at How Can I Calculate the Output Frequency of my Analog Output. This knowledgebase might currently be written with Traditional NI-DAQ terminology, but it should still help. Also, remember that even though you specify a certain update rate on your analog output, the actual update rate will be slightly different because of limited resolution of the divide down.
Jared Aho

Accessing the Sample Clock

I wish to use the sample clock of my E-Series board to establish a time base (which will have greater resolution than LabViews standard millisecond timers).
How can I do this?
Also, do I have to be acquiring data in order to use the clock? Or, can I still access the clock to use as a counter even when I'm not taking data?
BC

Hi,
You can use the "timed loop" functionality in LabVIEW 7.1 to use your E-series card's timing to control your software.
Check out this example:
http://venus.ni.com/stage/we/niepd_web_display.DISPLAY_EPD4?p_answer=&p_guid=EDFBFDB844C96972E0340003BA7CCD71&p_node=%20201207&p_rank=&p_source=External&p_submitted=N
You basically set up a while loop that uses a DAQmx Task to perform timing.
-Sal

672PCI 6723 error when attempting to generate DO signal with 20kHz sample clock

I have a piece of code that successfully worked on the PCI-6224 card, but when I tried to implement the same code on the PCI-6723 card I have run into problems.
Here is the code that I am using:
ManchConversion6723();//produces SendIt array of series of 1s/0s
// DAQmx Configure Clock
DAQmxErrChk (DAQmxCreateTask("",&taskHandleFRQ));
DAQmxErrChk (DAQmxCreateCOPulseChanFreq(taskHandleFRQ,"Dev3/ctr0","",DAQmx_Val_Hz,DAQmx_Val_Low,0,20000,0.5));
DAQmxErrChk (DAQmxCfgImplicitTiming(taskHandleFRQ,DAQmx_Val_ContSamps,72));
// DAQmx Configure Digital Output
DAQmxErrChk (DAQmxCreateTask("",&taskHandle));MessageBox("D");//vj
DAQmxErrChk (DAQmxCreateDOChan(taskHandle,"Dev3/port0/line0","",DAQmx_Val_ChanPerLine));MessageBox("E");//vj
DAQmxErrChk (DAQmxCfgSampClkTiming(taskHandle,"/Dev3/Ctr0InternalOutput",20000,DAQmx_Val_Rising,DAQmx_Val_ContSamps,72));
// DAQmx Write Code
DAQmxErrChk (DAQmxWriteDigitalLines(taskHandle,72,0,10.0,DAQmx_Val_GroupByChannel,SendIt6723,NULL,NULL));
// DAQmx Start Code
DAQmxErrChk (DAQmxStartTask(taskHandleFRQ));
DAQmxErrChk (DAQmxStartTask(taskHandle));
When I arrive at the DAQmxCfgSampClkTiming line, I receive an error stating:
DAQmx Error: Measurements: Requested value is not a supported value for this property.
PropertyAQmx_SampTimingType
You Have Requested: DAQmx_Val_SampClk
You Can Select: DAQmx_Val_OnDemand
Task Name: _unnamedTask<0>
Status Code: -200077
I believe the problem stems from the source variable of the function. I am simply tring to send the data out at the 20KHz rate.
Any help would be greatly appreciated. Thanks in advance!
Solved!
Go to Solution.

Nevermind. Seems as though the PCI-6723 does not contain correlated DIO channels. In other words, sample clocks can not be tied to the DIO channels to allow for digital waveform generation. According to the AO Series User Manual, this applies to NI 6731/6733 Only. The error was trying to tell me that only a single transmit or receive channel was allowed.
For this reason, I will just stick with my PCI-6224 card.
Sorry for the confusion.

Sample clock of DAQ assistant

I am using DAQ assistant to generate output voltage and another DAQ assistant to measure input voltage. I am to sepecify teh clock type for the two DAQs. I want the same clock type for both the DAQs so that the data from both DAqs are synchronized, that is run with the same clock. I m not using any external clock and want it software timing. I want to know if it is okay to select internal clock type for the output voltage DAQ assistant and then select external clock type for the input voltage DAQ assistant and select the clock source as the analog output sample clock?
OR if i select the clock type as internal for both the DAQ assistants will the data be synchronized?

Hi Amber,
Analog Input is not retriggerable,
meaning that once you stop the task you have to restart the entire task
(including the analog output). But if you want to just stop displaying the data
on the input channel, simply encase the Measurement
output in a case structure with a Boolean control that you can click to update
the graph or not.
If that doesn’t work for what you’re
trying to do, please give more details as to your overall application so the
community can help answer your specific questions.
Mark E.
Precision DC Product Support Engineer
National Instruments
Digital Multimeters (DMMs) and LCR Meters
Programmable Power Supplies and Source Measure Units
Attachments:
Not update voltage.png ‏5 KB

Use analog input as sample clock

Hi,
I have a PCI 6115 DAQ card. I currently perform an
analog acquisition on ai0, with an external clock on PFI7. But
sometimes, my clock signal is not high enough and the acquisition does
not occur. At some NI show, I heard a trick to solve this problem :
plug the clock on analog input (say ai1), the clock signal gets
amplified by the card internal amplifiers, and then route this
amplified signal to the sampling clock. This seems to be a wonderfull
solution, but I cannot find out to actually redirect the amplified ao1
to the sampling clock. Does someone know how to do it ?
Thanks a lot,
Jérôme Lodewyck

I tested the attached example on a simulated device so hopefully it will work on a real one without any kinks. You didn't specify your programming environment, so I'm assuming you're using LabVIEW. If not, hopefully you can translate to the appropriate ADE based on the picture of the block diagram.
In the example, I'm using an AO task to program the analog trigger as specified. This has two consequences. First, you won't be able to perform hardware timed AO while the AI acquisition is running. If this isn't acceptable, you'll need to try the second approach described in the next paragraph. Second, you'll have to wire the signal to PFI0 instead of an AI channel. With this configuration, the signal will be seen with a +/- 10V range and referenced to AI Gnd. Since the trigger DAC is an 8 bit comparator circuit for this board, you'll have ~80 mV of resolution. You didn't mention what the amplitude or DC offset (if any) of your signal is, but hopefully this resolution will suffice. You can use the level and hysteresis properties for the analog trigger to filter out noise in the analog signal or account for DC offset.
If the constraints listed above aren't to your liking, you can try to use a second AI channel as a trigger channel. This has some advantages and disadvantages. The disadvantages are that this requires you to use a trigger with your AI task and it also requires you to acquire another channel of data. You mentioned the trigger wasn't a problem so this can probably be taken care of with simple analog start trigger. The data can easily be thrown away, but depending on your sampling rates, it might require a lot of extra bus bandwidth or processing power when scaling the data. On the positive side, it doesn't require you to use up your AO channels needlessly and you can apply gain to the input signal in order to effectively increase the resolution of the trigger circuit. You can also apply a low pass filter and different terminal configuration if desired. The gain, coupling, terminal configuration, filtering, and coupling applied to the signal is controlled by the values used in the Create Channel VI and the Channel Property node. To create an example that does this, simply start with one of the shipping examples for an Analog Start trigger, change the trigger source to one of the AI channels instead of a PFI or APFI pin, and change the clock source to the AnalogComparisonEvent as shown in the attached example.
That should do it. Good luck with your application and post back if you have additional troubles.
Attachments:
AI - External Clock Using Analog Trigger Circuit.vi ‏81 KB
AI - External Clock Using Analog Trigger Circuit.JPG ‏60 KB

6036 E-Series AI Internal Sample Clock

Similar Messages

Maybe you are looking for