quadrature encoder based triggering

[John_P1]

The problem is that the Z index doesn't reset the counter directly, but rather when the Z index, A, and B signal are all in the correct phase, the counter will reset on the next timebase tick.

The two main things that are different between your code and mine are:

1.  X4 vs. X1 encoding.  I would just go with X1 to be honest unless you need the higher resolution in your software analysis.  Using X4 doesn't really increase your trigger resolution since the reset will only happen when A and B are in a certain phase, but if it also causes the counter output event to be shorter (I'm not sure about this, but I suspect it might) then this could explain your problem.

2.  Not using digital filtering.  This effectively syncs the A and B signals to the internal timebase.  If the signals are not synchronized, then the counter update could happen either immediately before or immediately after the timebase tick (which is what is timing the Z index reset).  Synchronizing the A and B signals to the timebase ensures the counter update happens immediately after a timebase tick and so the Z index pulse would always be the maximum length.

The counter output behavior for encoder tasks isn't very well documented as far as I can tell--knowing the exact behavior is important to understand why your version isn't working and why my version is working.

If you just want to get it working try configuring it like I did with X1 encoding and using a digital filter on the A and B lines.

Best Regards,

[saratoga]

Thanks, that makes a lot of sense.  I had assumed that since the problem was intermittant that the phase of the A+B signal had to be correct (or else I would never get any triggers), but if its dependent on the internal timebase rather than fully asynchronous that would probably explain it.  I'll experiment with X1 and possibly filtering.

Don't get me started on NI's documentation, or lack thereof.  

[SteveD123]

I have had exactly the same requirement. I have put in a request on the Data Aquisition Ideas Exchange here: http://forums.ni.com/t5/Data-Acquisition-Idea-Exchange/Every-n-encoder-pulses-callback/idi-p/3157548. Please indicate your support!

[vekkuli]

Great thread, John and Mike! I'm currently working on a very similar concept and what you had here is a very promising start. There is a twist, however, in what I'm looking to accomplish: I need a closed-loop control to adjust the phase and interval (z-index value) of the exported output pulse. The controller is implemented on the software side, the measurement is triggered by the exported counter output and there is a non-negligible measurement delay.

The value at the core of this concept seems to be the "z-index value" (or "Skip Count"), but I don't think it's possible to really manipulate it on the fly. It would be ideal, of course, to find a way to still be able to utilize the internal/hardware events for much better determinism, but at the moment I don't see any other way to achieve the setup than doing everything (counting ticks, generating pulses etc.) on the software side.

Do any ideas come to your mind?

[Kevin_Price]

Are you dealing with bi-directional or uni-directional motion?  If uni, you can probably approach it a simpler way.

Configure for retriggerable single pulse generation.  Use the Z-index as the trigger, use the A channel as your external sample clock, define your delay and pulse timing in terms of "cycles of A".   Other than a small dead zone very near the Z-index, you'll be able to have hardware sync between encoder pos and your output pulse *and* you'll be able to change the pulse specs on the fly to change the angular position where the pulse is emitted.

-Kevin P

[vekkuli]

Very nice! The documentation does mention that some of the pulse specs can be adjusted while the task is running. Is there a particular reason why the Z-index would be the trigger? I will probably get to do some testing next week, so I don't know yet how the pulse triggering behaves if the tripper overlaps the previous pulse.

The system will have to consider bi-directional motion, although the pulses should only fire when new distance is covered in one direction. What you described should still apply on the pulse generation side. I've been thinking about using one counter for the quadrature encoder setup from John's and Mike's discussion and using another counter for the pulse. The quadrature encoder counter would use a small initial Z tick value and the internal output would function as the timebase for the pulse generation. Are there any obvious problems with this idea?

[Kevin_Price]

Reason for Z-index as trigger:  I assumed the Z-index was important as a reference position and you would generate a pulse at some angular offset from it.

Using the internal output of an encoder task as a timebase for pulse generation doesn't sound right to me.  Maybe you could use it as a trigger, but I'm not sure that'd be especially helpful or necessary.

Can you give more detailed background on your system and the pulse timing requirements?

-Kevin P

[vekkuli]

I see what you meant then. In this case the Z-index is not conceptually linked to the control subject. You can imagine a typical line scan system with continuous stream of material that has a repeat-pattern to which we wish to sync. Reason why I thought about using the internal output as the timebase is that it might inherently deal with the bi-directional movement in the approriate manner. I can imagine it doesn't sound conventional—it's simply something I thought might in theory take care of the business, admittedly in a very roundabout manner.

[Kevin_Price]

You said:

the Z-index is not conceptually linked to the control subject. You can imagine a typical line scan system with continuous stream of material that has a repeat-pattern to which we wish to sync

I still don't really have a solid grasp on what you're looking to do.  I have no idea what your "repeat-pattern" might be or exactly what's meant about "syncing" to it.

I wonder if you might benefit from an external quadrature decoder that can resolve your encoder into pulse and direction signals.  That would at least give you a digital edge for every change of direction and you can always know direction instantaneously without needing to compare consecutive position samples.  That doesn't cover everything you need, but it might be an important step?

-Kevin P

[jql524]

Hi, sir. I am using NI PCIE-6323 board and want to get incremantal encoder pulse counts. But when I connect the A and B phase to PFI8 and PFI10, GND, 5V power, I can not get response. So would you give me some advices? Thanks very much.