sync counter rising edge with digital out(as AI trigger)

[gleen]

I have a PWM application where I use a counter to generate a continuous 1KHz pulse train at a specified duty cycle. At some point in time that I need to change the duty cycle, I also need to set a digital out to high (generates a rising edge). The timing problem is that I need to send the digital out high exactly at the counter pulse with the new duty cycle's rising edge .

I am currently using the "DAQmx_Channel->CO.RdyForNewVal" property to check if the running counter is ready for a new duty cycle value before writing it and at the same time set the digital out to high. That is (in pseudocode),

    ...counter running (1KHz pulse train at duty cycle=0.5)
    if ("DAQmx_Channel->CO.RdyForNewVal"==true) {
              write freq(1KHz) and new duty cycle
              send high to digital out (digital out task is already running here so no starting and stopping)
     }

Somehow, the digital out high gets delayed randomly by 0-3ms. What does "DAQmx_Channel->CO.RdyForNewVal" really do and mean? Is there another way to introduce a new duty cycle and send out a pulse at the same time?

Thanks.

[Jesse_O]

Gleen,

The CO.ReadyForNewVal is used to determine if the card is ready to accept a new value.  In previous versions of NI-DAQmx, if you tried to update the counters frequency and duty cycle before it completed a single cycle, you received an error.  This status flag was introduced to allow users to determine when they are capable of updating the counter.

The method you described is the correct way to update your counter output frequency and/or duty cycle.  I setup a system that performs the operations you mentioned and I saw a similar delay between when I started to update my frequency/duty cycle to when the digital output was performed.  I would expect a delay due to the software timed digital output.  If you are not using a software timed digital output then you must take into account the size of your digital output buffer, data transfer mode and buffer under runs.  The buffering that timed digital I/O performs will determine when the value is seen at the output.

Regards,

Jesse O.
Applications Engineering
National Instruments

[gleen]

Thanks, Jesse.

I included a timing diagram of what I want to achieve and a block diagram portion.
I apologize for one error in my previous post, the digital out high is actually not delayed, it gets generated right after the CO.RdyForNewVal returns true. It's the duty cycle value that was used as an update the counter output that gets delayed, i.e., when CO.RdyForNewVal becomes true, the digital out high is sent but the counter hasn't output-ed yet the freq/duty cycle update.

I tried to google for the counter output buffer but I can't find any information about it. For the NI 6251 counter, I actually update only the background freq/duty cycle when there is front-panel activity (the counter actually keeps on generating the last freq/dc in the absence of any update) so the buffer, if any, shouldn't contain a few samples. Nevertheless, to exclude the counter output buffer effect, I included a 10-sec delay to flush any counter output buffer (say, 8191 samples at 1KHz) before updating the freq/duty cyle but checking for CO.RdyForNewVal still delays the desired duty cycle.

Is there a way to know how much this delay is between a counter freq/dc update and an actual change in the counter output?

[Jesse_O]

Gleen,

There is no counter output buffer.  Before when I was talking about a buffer I was referring to the Digital I/O Buffer (not counter).  If I understand you correctly, you are seeing a 2-3 ms Delay between when the CO.RdyForNewVal becomes true and when the counter's duty cycle changes.

Based upon the code I was running (I have added a picture of the code that updates the counter and digital output.  Please ignore the logic in the bottom left of the picture.  This code was only there to toggle the digital output and update the duty cycle), the counter changes approximately 1 cycle (10ms) of a 100Hz signal.  This corresponds to the 0-3ms delay you were seeing.  I would expect this type of behavior since updating the signals is software timed and that the counter will take a finite amount of time to change the duty cycle.  I have seen better results if I do not update the digital output until after I see the CO.RdyForNewVal become true after updating the counter's duty cycle.  Hopefully this will help you out.

Best of luck,

Jesse O.
Applications Engineering
National Instruments

Message Edited by Jesse O on 05-08-2006 05:04 PM

[gleen]

Jesse,

I thinkg we're trying to achieve the same thing except that I split the digital out and the counter duty cycle updates in two case structures to "suggest" to Labview to execute them in separate threads since I need to synchronize the occurrence of both digital and counter rising edges. In your case though based on your block diagram, Labview will toggle the digital out before updating the duty cycle because the counter has to wait for the error from the digital write block to propagate. The cascading error propagation delay might also be a problem in my case since it's in a loop that tries to do duty cycle updates within a millisecond.

My application is generating a running background+stimulus and acquires an ERG signal at some point which requires precise synchronization between the stimulus and the ERG signal acquisition. I used a Pulsemaster years ago to generate the precisely timed pulses which are fed back to the DAQ card to trigger the tasks in Labview. I wish I have enough counters in the 6251 so I can do everything with the computer.

Thanks for the replies.

Gleen Aduana
Sr. Network Analyst
UIC Eye Center

[Jesse_O]

Gleen,

Unfortunately, the counter does not generate any hardware signal that can be used to trigger the digital output when the duty cycle or frequency is updated.  Because of this, there is no way to get the two rising edges synchronized beyond what you have already done in software.

Regards,

Jesse O.
Applications Engineering
National Instruments