Continuous buffer with interrupts doesn't refill the buffer

[Kenn_N]

Gil,

Same result.  THe text file just includes up to 9

Regards,

[grivlis]

Ok, I see. It seems your computer is too slow. The reason you get only 9 ticks, is because the DIO loop exists after 3 seconds and at the slow rate you are getting the ticks, it times out before the end. Let's try a slower sample rate. I attach a new executable that executes at 10Hz only. It will take about 30 seconds to execute instead.
Be patient because the pause in the middle will be long

Gil

[Kenn_N]

Gil,

Same result. Here is the text file.

Regards

[grivlis]

This is very strange. It seems that the ticks you get on your computer are at least 10 times slower than the ones I get. I don't really understand why it should happen. Which version of windows are you running? Can you try to run it on another computer?

Gil

[Kenn_N]

Gil,

I will do that now.  I am running Windows XP though.

Regards,

[Kenn_N]

Gil,

Ok so I ran the original program on another computer, and this PC was freshly reformatted yesterday and I installed all the drivers and everything from scratch.  It does the same things, ends after 9.

Regards,

[grivlis]

I'm stumped. I don't know why this happens. Can you post the output file?

Let me also try something different. I've make a sample application that does not use event callbacks to print the buffer, just
fills the counter  buffers and then prints them out. I attach it here. When running it you should get something like this:

counter buffers before acquisiton:
counter 0 buffer begining: 0, 0, 0, 0, 0, 0, 0, 0
counter 0 buffer      end: 0, 0, 0, 0, 0, 0, 0, 0
counter 1 buffer begining: 0, 0, 0, 0, 0, 0, 0, 0
counter 1 buffer      end: 0, 0, 0, 0, 0, 0, 0, 0


counter buffers after 3000 ms acquisiton:
counter 0 buffer begining: 256226, 257226, 258226, 259226, 260226, 261226, 262227, 263227
counter 0 buffer      end: 248226, 249226, 250226, 251226, 252226, 253226, 254226, 255226
counter 1 buffer begining: 220, 1220, 2220, 3220, 4220, 5220, 6220, 7220
counter 1 buffer      end: 248222, 249222, 250222, 251222, 252222, 253222, 254222, 255222


and you can see the counter 1 buffer doesn't refill, while counter 0 does

Gil

[Kenn_N]

Gil,

I ran the programs, I think we finally have it running.  Here is the outputs.  The results2 is for t2.exe (fast one) and results 3 is for t3.exe

Now that I have this reproducible, explain again what the numbers mean.

Regards,

Message Edited by Kenn N on 11-09-2006 12:58 PM

[grivlis]

ok, let's igonre the output from t2 for now. I still don't understand the problem.

Anyways, the output from t3.exe:

counter buffers before acquisiton:
counter 0 buffer begining: 0, 0, 0, 0, 0, 0, 0, 0
counter 0 buffer      end: 0, 0, 0, 0, 0, 0, 0, 0
counter 1 buffer begining: 0, 0, 0, 0, 0, 0, 0, 0
counter 1 buffer      end: 0, 0, 0, 0, 0, 0, 0, 0


counter buffers after 3000 ms acquisiton:
counter 0 buffer begining: 256137, 257137, 258137, 259137, 260137, 261137, 262137, 263137
counter 0 buffer      end: 248137, 249137, 250137, 251137, 252137, 253137, 254137, 255137
counter 1 buffer begining: 135, 1135, 2135, 3135, 4135, 5135, 6135, 7135
counter 1 buffer      end: 248133, 249133, 250133, 251133, 252133, 253133, 254133, 255133

shows the content of the counter's buffers before and after 3000 ms of data acquisition. Each counter has a buffer of 256 elements. The gate rate is 100Hz and the source is the internal 100kHz source. This means that each buffer should acquire the counts in steps of 1000. If you look at the buffers after the acquisition, you can see that each counter, indeed, acquires the data because the difference between successive counts is 1000. (This is almost exactly true, except for the fact that the clocks of the 6533 and 6602 are not synchronized). Note that the two counters are nearly synchronized. You can see that by looking at the end of each counter's buffer and noting that the counts measured are almost the same. (the difference is because counter 1 starts a little after counter 0).

Anyways, after about 2.56 seconds, both buffers fill. When the acquisitin continues (all the way to 3 seconds), the begining of each buffer should refill again. Note that the buffer of counter 0 indeed does that. However, the buffer of counter 1, does not refill and retains the values from the begining of the acquisiton.

Gil

[Kenn_N]

Gil,

Ok that makes sense, except why is the number for the end of counter 1 a large number, shouldn't it just be 133 plus 8000 and so on?

Regards,