"Do you know a way to set counters automatically to a specific value when TC (i.e. zero) is reached?

Question

The inputs of my 6602 counter are two encoder signals, and I want
to generate an output pulse every n-th increment of the counter.
On the National Instruments Support Pages there exists a vi
"Generate pulse every N position.llb" which promises to do that, but
there are some problems:
Here the counter is preset e.g. to 20 and then counts down to 2, 1, 0.
When zero is reached, an output pulse is generated. This pulse now triggers
the Z index channel in order to set the counter again to 20.
However, this does only work, if both encoder signals are low when the
Z pulse is active (or if both encoder signals are high or one is low and the
other high, but not in
all of these cases). The consequence is, that the
example vi does only work with X1 encoders but not with X2 or X4 encoders.
In the case of X2 or X4 encoders (or even in some cases of X1 encoders) it can
happen that not both encoder signals are low when the Z pulse is active. Them
the counter counts 2, 1, 0, -1, ... where -1 actually means a very large
number because the counter values are unsigned. From then on no further output
pulse is generated.
To solve this problem there should be the possibility to set the counter to a
specific value (here 20) when it reaches TC (i. e.), independently what the states of
the encoder signals are. It would be best, when for this the Z pulse was not
used, for many encoders do have a real Z pulse that also may be used.

Answer 1

You are right in the case when the counter is to be reset
in the presence of a reference mark.
However the problem is to generate output pulses every N-th
increment of for example a X4 encoder. Let N be 6. The
counter counts 6, 5, 4, 3, 2, 1, 0. Then an output pulse
is generated which is fed back to the Z channel. Let us assume
that the Z index reload phase has been chosen correctly. Then
the counter is reset to 6. It continues counting
5, 4, 3, 2, 1, 0 and again an output pulse is generated.
But now the channels A and B of the encoder (which were for example
low at the time of the first output pulse) are in the inverted
state (i.e. in the example high) and the Z index reload phase
does no longer match. Therefore the counter is not reset and
continues counting 4294967295, 4294967294, 4294967293, ...,
which is the U32 form of -1, -2, -3, .... After that no more output
pulses are generated since TC (=0) is no more reached.
The problem is obvious. Only in the case of values N with N mod 4 = 0
this approach can be successful. But then X4 evaluation of the encoder
signals does not make sense, because a X1 evaluation does the same.
In practice the situation is even worse. As theoretically expected
the signal generation for X4 encoders never works when N mod 4 is
unequal 0. If N mod 4 is 0 it only works sometimes. "Sometimes" means
here randomly every fourth time, when the start phase of the encoder
signals (which is determined randomly by the starting time of the
software) matches the preselected Z index reload phase. Here it does
not matter which Z index reload phase is preselected.
Therefore the example program definitely cannot be used in combination
with X4 or X2 encoders.
There are a series of further arguments why we are not really satisfied by
the approach proposed by the example vi to use the Z index channel in order to reset
the counter. One is that we have encoders with real reference marks, which have
to use the Z index channel themselves to reset the counter. Another is that we
think that it is a rather complicated approach to reset a counter when TC (i.e. zero)
is reached by checking the feedback fed Z index channel from time to time in intervals
given by the internal clock of the 6602 and then reloading the counter value
if certain conditions for the encoder channels are fulfilled.
Therefore (and of course above all in order to deal with X4 and X2 encoders) it
should be possible to reset a counter directly by hardware when TC (zero) is
reached. We suppose the given 6602 hardware is supporting this, particularly
because it is already able to react on TC (by generating output pulses) and because
we think that something like that is already done in continous delayed pulse generation
(and is only hidden in some code that is not accessible for LabVIEW users.)