PCI 6534 goes through 7 buffer iterations before receiving any clock

[kdnelson]

I use the PCI 6534 for pattern generation with external clock, using on-board memory.  I set up in Labview with DIO config...DIO param(set pattern generation loop enable)...DIO write...DIO trigger config(start on external)...DIO start(pattern generation with external clock).

My external hardware depends on the number of times the buffer has been output, and was not responding as expected.  So I checked the buffer iteration count with DIO Buffer write(no input, read buffer iterations output).  It turns out that immediately after executing DIO start, the buffer goes through seven iterations even though there is no activity on the clock input.  Even stranger, I have set up to start the buffer on an external trigger, and that external trigger hasn't occured yet either.

Besides these first seven buffer iterations, the results are as expected.  The clock signal doesn't cause any more change of output until the external trigger happens, and once the trigger occurs, the output cycles through the buffer one point per clock cycle.

How can I stop these spurious buffer iterations, so I get my first data point at my first clock cycle?

Thanks,
Karl.

[kdnelson]

More information:

The number seven in my original question is a function of the buffer length, which was 4 bytes in that case.  It would be more useful to focus on the number of spurious updates, which appears to be 30.  If > 30 scans are in the buffer, the output mark immediately moves to 30 after DIO start is called, even though there is no clock signal or start trigger.

Karl.

[e-Cash-Money]

Hello Karl,

Wha is the "Buffer State" value when you check the buffer iteration count?
Are you verifying that the buffer values are actually being output at the port lines with some sort of instrument (scope, logic anyalzer, etc.)?

Feel free to attach your code as well.  I'm curious to try it myself and see what happens!

[kdnelson]

The buffer list listed as "active."

Here's a version of my code which shows the problem.

The default value for the "Times Out" array gives a buffer with four updates.  The indicator shows seven buffer iterations, output mark at "2."

You can easily add more data to the "Times Out" array, past 30 updates, and observe that then the indicator will show 0 buffer iterations but the output mark at 30.

There is no sign that those 30 values ever made it to the outputs of the card.  I can't see them on the scope.  I also have a counter 74LS161 on channel 31.  As you see from the way that data is set up, that should give me one count every time through the buffer.  The LS-style chip should be plenty fast to count it.  But I see nothing.

Thanks,
Karl.

[kdnelson]

Oops, I hadn't quite removed all dependences on my other code.  This one should work without any trouble (I hope).

Karl.

[e-Cash-Money]

Hello Karl,

I believe that the Update Progress parameters are referring to the PC buffer.  After you use DIO start, the buffer values are being written to the onboard buffer of the 6534, but not being output on the digital lines until you actually receive the trigger.  The Update Progress parameters are referring to the transfer of data between the PC Buffer and the Onboard Memory.  That would explain the behavior you describe here:

So I checked the buffer iteration count with DIO Buffer write(no input, read buffer iterations output).  It turns out that immediately after executing DIO start, the buffer goes through seven iterations even though there is no activity on the clock input.  Even stranger, I have set up to start the buffer on an external trigger, and that external trigger hasn't occured yet either.

and here:

There is no sign that those 30 values ever made it to the outputs of the card.  I can't see them on the scope.  I also have a counter 74LS161 on channel 31.  As you see from the way that data is set up, that should give me one count every time through the buffer.  The LS-style chip should be plenty fast to count it.  But I see nothing.

This information actually indicates that the program and board are working properly (the data has been output because no trigger has been received yet).

I tested a similar VI and confirmed that data was not actually being output on the physical lines until my trigger was received.  If this is the case, this leads us back to your original question of why your external hardware was not responding correctly to the output.  If you can desribe your external hardware setup and how it is configured to read from tehe 6534, we can look into other reasons why things aren't working as expected.

[kdnelson]

Thanks for taking time to look into this.





I hope that using the Labview buffer functions to describe the problem hasn't been a red herring. I'll describe what I first observed with my hardware, and how I think you can reproduce it with any setup. I found that the buffer report was consistent with those observations so I used them as a way to report my problem.





My hardware is simply a multiplexor which gives me the output of channels 0-31 in turn on a single line. Channel 31 clocks the multiplexor and so is always 0 until the last update.





The data in the VI I attached was




254 255 255 127


255 255 255 127


255 255 255 127


255 255 255 255






So the output of the multiplexor would be one 0 1 1 1 from the first channel then 1 1 1 1 up to channel 30 then 0 0 0 1 from channel 31, then start over. But the first time through, the inital 0 is never output. (And get get to the 0 0 0 1 in fewer clock cycles than you expect.) So try:






255 255 255 127


254 255 255 127


255 255 255 127


255 255 255 255





which should be 1 0 1 1, etc. You still don't see the 0. Keep moving the 0 up until you get to the 31st spot, like so:





255 255 255 127


255 255 255 127


127 255 255 127


255 255 255 255






Then you get your 0 on the very first clock cycle. So that was where the seven buffer iterations in my subject heading comes from.





But now just construct a buffer like:





255 x x x


. . . .


. . . . (29 more lines of 255 x x x here)


. . . .


254 x x x


255 x x x


255 x x x






and check the output of channel 0. I get the 0 on the first clock cycle.





If you keep looping through the buffer, those skipped values are not skipped again.





(Note: I don't know if you'll see this effect without combining ports 0:3, hence the x x x in my example.)





I'm using Labview 6.1 on Windows XP. I suppose it could be a Labview or Driver quirk rather than something to do with the 6534. I don't have any other DIO board to test that.





Hope this explains the situation better this time!







Thanks,



Karl.

[e-Cash-Money]

Hello Karl,

I'm testing some things out here to see what is going on (thanks for the explanation!).  Out of curiousity, what version of the driver are you using?  If it is an older driver, is it possible for you to try and upgrade it to see if that helps?  

[e-Cash-Money]

Hello Karl,

Sorry that it's taken so long for me to get back to you.  I do have some questions about the code you posted.  You have a boolean control that determines if you use onboard regeneration or not.  I'm wondering why, when onboard regeneration is enabled, you do not execute the DIO Wait and immediately clear the task?  You also have the generation set for continuous but there is no while loop to continue the generation once it has started.  Is there a particular reason for this approach?

[kdnelson]

Hello again, E.Lee,

My driver version is 1.5.5f0.  I haven't looked at that link to see if it is the latest.

The explanation for the Clear in the VI I posted is that it is a sub VI in a while loop in another program; usually the clear is elsewhere.  I put a DIO Clear in it for testing because then I can test it separately without ending up with "group in use" errors.  I put a breakpoint on the Clear so it doesn't execute until I click to continue.  (You can't Wait on a Write with Loop Enabled because the write never finishes.)  In retrospect, that obviously needed explaining; sorry.

Now, here's the funny part:  I can't reproduce the problem any more, and I don't know why.  I ran the same test program I was running when I last posted (12-1), which hasn't been changed, and I see every update starting with 1.  The Buffer Write VI still reports the extra buffer iterations, but that is no longer in sync with the outputs--it's now 30 updates ahead.

The only thing I can think of that happened between then and now is a computer reboot.  I have disconnected and reconnected various wires, but I think just as they were before.  I wonder if it's possible that simply rebooting changed something.

Karl.