PCI-6601 Encoder to Counter Converter Chip Wiring

[wesdeeg]

Hello!

I was hoping anyone might has some ideas or knowledge about how to wire/implement the LabVIEW software of a PCI 6601 counter. Specifically, I am using a PC6-C-4-H5, which essentially takes a quadrature encoder output and converts it into the outputs of a standard up/down counter. So it takes in the channels A and B as well as the index of an encoder, and converts that into the Index, Up/Down signal and Clock output of a up/down based counter.

I've been having difficulties wiring this into my lab's PCI-6601 interface, even after searching through the manual. I've been attempting to modify code from the Counter Input: Count Edges (Finite Clock) VI example in the example finder, just to test if the counter alone is working properly, which I have not managed to get to work correctly. Based off the hardware manual of the 660x series, I have believed that in order to tie this counter output to counter2, I would need to tie that clock output of the chip to the SOURCE (2) pin, the index to the GATE (2) pin, the Up/Dwn output to the UP_DOWN (2) pin, and the clk output again to a different SOURCE pin to use as a trigger, as I've marked below:

 

However, running the program provides nothing but a -200284 error, which I believe correlates to the trigger not running properly? So I know that something is likely incorrect in how I've wired this system, but I haven't been able to find anywhere in the documentation that goes this specific issue, so I wanted to ask if anyone here had experience in this type of chip/wiring setup.

 

Sorry if this is a basic question, I just haven't found anything on it. Thanks in advance for any advice people have!

For reference, the exact error was:

Error -200284

Possible reason(s):

Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.

Property: RelativeTo
Corresponding Value: Current Read Position
Property: Offset
Corresponding Value: 0

Task Name: _unnamedTask<348>

[Kevin_Price]

That timeout error could be due to either a missing sample clock signal at PFI 30 or a missing Arm Start Trigger signal at PFI 27.   To get started, I'd recommend you get rid of both config calls, i.e., do not configure a sample clock or arm start trigger at all.

Further note that the 6601 should be able to accept the quadrature signal directly, then you could configure the counter for a position measurement task using A,B and Z/Index.   The shipping example "Counter - Read Encoder" shows how to do this if you choose the "No Trigger" option.

I'd recommend you start there and once that's working, *then* you can consider adding back the sample clock and/or arm start trigger one at a time.

-Kevin P

[wesdeeg]

Apologies for how late this response is, testing has been busy over the past few days. You are correct in the quadrature signal, that is something I hadn't realized before reading into the documentation further. To that end, I have been attempting to do as you mentioned, and get the encoder to read directly from the channels. However, even with a direct connection, the counter card has failed to read the channels, and we're starting to believe it is a hardware issue.

The encoder outputs are square waveforms of varying pulse widths in accordance with the stepping process of the encoder, all of which are registering (measured with an oscilloscope probe) at 4.4V. Since the PCI-6601 is advertised as a TTL/CMOS system, I thought from the literature it was fine taking inputs anywhere within the 3.5-5V range. However, nothing is registering here, not even when trying to read single channels. I've also rewired my setup to provide a square wave output directly from a function generator as a test, and that obtains no response from a counter whatsoever for the simple test of counting edges incrementally, even though the provided square wave is at 5V.

The response on the SOURCE line appears to be a derivative of a square wave, as in this image here. Is this a common issue with passing square signals into the counter card, one that requires a software or hardware setting to be shifted? 

 

Apologies if this is outside of expertise here on the boards, I'm just hoping that it's an easy setting I have to shift in LabVIEW somewhere instead of a broken circuit on the board.

Thanks for all of your help so far!

[wesdeeg]

I've become aware that the functions actually do operate, but only with counter 0. It might be due to internal settings to only allow buffered measurements on counter 0, but I'm unsure how those settings can be changed so that other counters can operate simultaneously.

[Kevin_Price]

Very generally, I'd recommend that you question and test your assumptions and conclusions.  And at least initially, do all your experiments using either MAX test panels or LabVIEW shipping examples (possibly including minimal mods, but be sure to "Save As..." any changes to your preferred working folder.  Don't just "Save" in place!)

To start, set up the situation where ctr0 seems to work appropriately with a simple example program.  Then change the config to ctr1 and *also* add a DAQmx Channel property node to define the terminals used for ch A,B, and Z.  Don't move the physical wires, just tell the task to use ctr1 for the same operation while configuring it for the signals where they've already been wired.   Try it out also for ctr2 and ctr3.

If you're trying to do simultaneous *buffered* operations on several counters, you may be running into limitations related to DMA vs interrupts as a data transfer mechanism.  DMA supports much faster sample rates, but the 6601 only has 1 DMA channel available IIRC.  (The 6602 has 3, the newer 6612 likely has more though I don't know the number offhand).

I don't recall whether interrupts are used automatically or whether you have to configure a task explicitly to use them.  The setting is called the "Data Transfer Mechanism" and can be found as a DAQmx Channel property, albeit one that requires a very deep dive.

-Kevin P

[wesdeeg]

Thank you for the advice, and yes, there were some tests I likely should have done ahead of time.

Regardless, I had looked into the CI.DataXFerMech property, and I also thought it had to be related to the DMA limitation of the PCI-6601 to solely one counter, so I should shift the others to Interrupts. However, the program I am using, after studying that, I realized is not a buffered measurement, but one using the "Programmed I/O" Data Transfer Mechanism. So the source of the issue arose from the fact that counters 2 and 3 are combined counter and digital I/O lines, while counter 0 and 1 are programmed for only counters. I'm unsure why it seems to configure 2 and 3 for solely digital output automatically, since I had only been running digital tasks for this input by an exterior encoder, but as the first 2 counters work properly I'll refrain from asking more.

The problem was just convoluted because our prior testing of counter 1 showed nothing, yet it fixed itself afterwards, so perhaps some bad wiring had caused the confusion on my end.

[Kevin_Price]

Ctrs 2 & 3 should also be able to work if the terminals involved aren't already reserved for a DO task.   I'd advise to try them out as I suggested earlier (configure to use the terminals that are already physically wired).  It might be worthwhile to post your code too, using "Save for Previous Version..." if needed to get it back to ~LV2018.

-Kevin P