Counter Task issue with NI6229 and Boralnd C++ builder

[sspeed]

Hello!

I am using the NI-6229 M series Acquisition Board and I am writing my application in Borland C++ Builder 6.

My goal is to generate digital pulses on the counter output that are syncronized with a video camera.

To do this I created a task that generates one digital pulse (5ms in high state and 495ms in low state).

I am starting this task in one thread and in another thread I am waiting until this task is done and then I am stoping it.

The problem is that on the counter output I have pulses bu the low state is much shorter than 495ms and is not even constant.

Is it possible that waituntiltaskdone function waits only until the output goes in to the low state and then it considers the task done?

If not can anyone give me a solution?

Thank you.

[Ryan_V[DE]]

sspeed,

A possible work-around for this situation is to set the "Start.Retriggerable" property to true with the DAQmxSetStartTrigRetriggerable. Then, instead of using DAQmxIsTaskDone, try polling the "CO.PulseDone" property with DAQmxGetCOPulseDone.

Hope this helps,

[Kevin_Price]

Kinda of a followup related question here.  Several months back while investigating a different issue, I noticed that the CO.PulseDone property would become True just a little too early.

In my setup, I wired a DO bit to act as the counter timebase source so I could manually feed it edges via a front panel boolean button.  For a case where the idle state was low, the property CO.PulseDone would become True one source edge earlier than the actual counter output would transition from high to low.

Any ideas why?  Does it behave differently now under newer versions of DAQmx?  Does it act this way when setup for retriggerable pulse generation? (I didn't test it in that mode and I'm not near acq. hw now)

-Kevin P.

[sspeed]

I solved this problem using retriggerable control.

I connected one DO to the counter gate and it works just fine for my application.

The pulses only start when the DO goes from low to high.

Thanks everyone for your help!

[Ryan_V[DE]]

Kevin,

While preparing a response for you, I realized that in playing with my VI I had entered the wrong delays, causing me to think that the retriggerable property would cause CO.PulseDone to stay false the duration of the low time. I then remembered that for single pulse generation, the low time is actually ignored. Therefore, if your idle state is low, the counter remains low for "initial delay," transitions high, stays there for "high time," then transitions low. After this, the task is done. If your idle state is high, the levels are reversed and "high time" is ignored.

I recreated your setup using DAQmx 7.5, and did not observe the early transition of PulseDone. This was with CO Pulse Ticks. Were you using CO Pulse Time? Perhaps you did not arrive at the same number of ticks (based on time) as the driver. Or, maybe you mistook the "low time" and "initial delay" inputs, as it is certainly easy to do. Do you know what version of the driver you were using?

Thanks,

[sspeed]

I am using Daqmx 7.5, and I was using CO Pulse Time.I did also try frequency but I had the same result.

I did not try the CO Pulse Ticks so I can not tell if it is working or not.

I am very sure that I did not mixed the initial delay  and the low time.

I even changed the idle state from low to high and the resulat was that this time the pulse width was 50 ms longer than I set it and also the period was logically 50 ms longer.

So my conclusion  was that the task is considered ended after the pulse is generated.

I already modified my code but I am sure that I can reproduce it if you want to take a look at it.

[Ryan_V[DE]]

sspeed,

My apologies. That post was directed at Kevin. You are correct about the behavior of the single pulse task. This property ("low time" when the idle state is low and "high time" when the idle state is high) is ignored for a single pulse.

Regards,