6602 encoders terminals

[mattmatt]

Hello! I'm new to the TIO world, and have some questions about the board I own: PXI-6602.
I'm afraid I will have to throw it away (anybody interested ?).

My goal would be to generate pulses (in order to trigger an acquisition) upon linear or angular
positions. Something like: "I want you to generate one pulse every N ticks on this axis".

One way to do this is to generate pulses, using one encoder line. This is not enough, because
in doing this I would loose the direction of movement, and if the movement is not perfect, I will
loose the real position. I really need to count up and down to know where the mechanical part
really is.

So I have to use one EncoderChan. The problem is that it generates pulses only when the
position is zero?

One solution to solve this is to hardwire the output of the EncoderChan to the Gate input:
each time the encoder reaches 0, it will use the pulse to trig my acquisition
and will take the ZidxVal. (I could not make this loopback connection by software. Not
possible with this hardware?)

I see some more problems with this solution: I will loose the actual position of the mechanic.
I could use another counter in order to follow the position. I noticed that this device seems
not to allow counters to use arbitrary pins when used in encoder mode. Am I correct?

I will then have to hardwire the encoder to both Ctr inputs.
But I have about 6 axis (only one is used to trigger at a time, but I have to be able
to switch between them by software).

Any comment?

Salutations

Matthieu Dubuget

[Kevin_Price]

First off, yes you're right.  In encoder position measuring mode, you must hardwire the encoder signals to the correct counter pins.  Both A & B channels, plus any index pulse -- all must be hardwired.  [Aside: the new M-series multifunction boards allow software assignment of these signals, but only provide onboard 2 counters]

So that accounts for 6 of your counters and their input pins.  Now then, how to generate a sample clock every Nth edge of a particular encoder channel?

You can do this by configuring a 7th counter to *programmatically* use that encoder channel as its timebase while it generates a pulse train.  I'm not near my LV box, but you can look under the DAQmx property nodes, maybe something like DAQmx Channel-->Counter Output-->Timebase-->Source.  Possibly instead under the DAQmx Timing property node.  Wherever it is, you'd wire in the name of the pin where the desired encoder signal is wired, likely in terms of PFI #.   (Even when Counter 4 has that signal physically wired to its Source/Ch_A pin, Counter 7 can programmatically "see" that same pin in terms of its PFI # to use it as a timebase.  You won't need to parallel wire anything on the terminal block.)

Then if you configure your counter output channel in units of Ticks, you can just specify High Time and Low Time such that they sum to N.  Now your 7th counter will generate a pulse every N cycles of the specified encoder signal.

Finally, all the other 6 counter tasks will specify the 7th counter's output as their sample clock signal.

-Kevin P.

[mattmatt]

I thanks you for your reply, Kevin, and also for your numerous posts in the forum, that helped me understand my problem.

I can not use your solution: if between two mechanical positions that should correspond to pulses, the robot stops, come back a little, and then continue his forward movement, the second task, counting pulses on one channel only of the encoder, won't know it and generate a pulse before the expected position is reached. I really need one encoder task.
Real machine movements are subject to such oscillation.

The only solution I found would allow to do the job for 4 encoders: one counter for absolute position knowledge, and the other one to generate pulses. But I would not be able to use
it in arbitrary direction...

So. Since we own a custom board that is able to do the job, I will use it. The drawback is it's price (it also contains two 100 MHz digitilzers...), and the fact that it is a PCI board, not a PXI one: I will have to add one cable between the PC and the PXI rack...

Salutations

[Kevin_Price]

I get what you're saying about mech oscillations, but am not sure if you're abandoning the approach for the right reason.  I'm having a tough time mentally reconciling some of the things you've described:

1. Dividing down an encoder axis signal to generate a sample clock.  To me, this implies that you don't need maximum positional resolution in the data you acquire.  It is also unlikely-seeming that all the interesting waypoints in the path will exactly correspond to positions with the same spacing as your divide-down factor.  In other words, it seems that you're setting yourself up to acquire data that will require further processing.

2. Choosing different encoder axes as the master timebase for that sample clock.  This implies that your choice of "master" is somewhat arbitrary.  5 of the encoders won't be positionally sync'ed to the sample clock anyway, so why not make life *really* simple and sample with a constant-frequency clock?  Accurate time information would then allow you to interpret dynamics of the joint motions. 

3. The need/desire to have acquisition data at certain specific waypoints within the motion.  I'd think a constant freq sample clock at a fairly high rate would get you enough data at and near the waypoint to allow for some good interpolation / curve fitting.

Many years ago, I worked up an app to characterize motion dynamics across a gear train.  It used a whole bunch of sync'ed counter/timer tasks to measure speed variations based on precise time measurements of the encoder edges.  I set it up that way because the encoders were fairly low resolution and it seemed that time-based measurements offered better precision.  A couple years later, someone else approached the same app by simply performing constant-rate sampling of the encoder positions.  He then did various kinds of filtering and interpolations to produce his analysis results.  I compared the results of the two approaches, hoping to confirm the superiority of my approach, but I found the results to be quite comparable.

Moral: it's nice to make exactly the right measurement in the first place, but it doesn't always pay off.  Sometimes a simpler measurement followed by some fairly simple post-processing is plenty good enough.

So, why does it seem important to you to capture data exactly at every Nth position?  Why wouldn't it suffice to capture all positions at some constant rate, then interpolate to estimate them at those specific Nth position points?

-Kevin P.

[mattmatt]

I really need to acquire datas at fixed mechanical positions in this case, because:
- I'm just writing a plug-in to drive a new electronic. This plug-in will be called by an application I can not modify.
- As a rule, when possible, I tend to prefer fixed time acquisitions (the actual reason for this is that it allows the
  electronic to work at constant rate -> more stable). But this solution become difficult when we reach high
  speeds: in order to have a point in each cell of the cartography, we have to increase the frequency
  of acquisition, which is not always possible (bandwitdth of data transfer, physic, ...).

Hoping my answer makes sense for you: it would be quite long to detail all aspects of our work (ultrasonic
data acquisition).

Salutations

P.S. Our home made board will do the job and more. So: I have one NI board to resell.

[Kevin_Price]

Ok, gotcha.  No room for compromises when you've gotta interact with other software / hardware. 

There actually are some complex things that can be done that *may* work, but are tough to guarantee.  They involve configuring the encoder counter to "pulse on terminal count", configuring for a 2-pulse encoder while wiring A to gnd, hardwiring that encoder counter's output pulse to its Z-index, setting the Z-index reload value to N.  Two problems remain: the motion needs to be predominantly unidirectional, and the Z-index reload requires knowledge of A,B states at the instant of the pulse.

So it's a good thing you can handle this stuff with your custom board and call it a day...

-Kevin P.