HW divider from encoders

[Daaaavid]

Dear all,

can I ask you for help with programming in Labview? I need to trigger the measuring of some
material properties according to the position in space. The position of probe is measured
by the encoders (linear and angular) and the sampling is very fast, so I need to use HW
divider (e.g. DAQmx Create Virtual Channel (VI) - CO Pulse Ticks).
The dividing on each encoder will be defferent (the number of low/high ticks). And I need
to send just one TTL signal to trigger to take measuring data from the probe. Is it
somehow possible to send one TTL signal in one task for triggering if at least one HW
divider sends the edge (at least one axis just arrived to the right position), please?

Thank you for responce in advance.

[Kevin_Price]

It's difficult to say without more details.  Amongst them:

- what DAQ device(s) do you have available for this job?   Or are you free to purchase something appropriate?

- are the encoders incremental or absolute?   If incremental, how do you establish a known "zero" position?

- you say you want to generate a pulse when "at least one" axis just arrived.  What should happen when the 2nd axis arrives?

- Do you want 1 sample each time the appropriate event occurs, or do you want to *trigger* a finite sampling operation?

-Kevin P

[Daaaavid]

Dear Kevin P,

thanks for your reply.

1) I am using NI6612 card for synchronizaton the position and taking data. (Acquire data from the encoders.)

2) Encoders are incremental. Zero is set in the begining of the measuring. And I need to measure by the probe every time when the probe moves for X mm in the 3D space. It means that the probe moves along some trajectory - 3D curve. And I know that I need to measure (send TTL edge to acquire measuring data) every e.g. 100 pulses from encoder 1 or 35 pulses from encoder 2 or 45 pulses from encoder 3.

I have an idea to do it like here: https://forums.ni.com/t5/Example-Programs/Divide-Down-an-Encoder-Signal-or-an-External-Clock-by-an-I...
But it must be done for three encoders and I need only one output task (or terminal) for sending TTL to trigger the measuring by the probe.

3) When one, two, ... or all axes just arrived to the right position send TTL edge.

4) I need to send only one TTL edge when some of the used encoders just arrived to right position.

[Kevin_Price]

1. The 6612 is a great option, no need to look elsewhere

2. I'm not so sure about this part.  X mm displacement in 3D space is not the same as X mm displacement in a single axis.

   Briefly, there's no *hardware* way to pulse after X mm worth of net 3D displacement.  You could only hope to poll the 3 axes quickly in software, calculate 3D displacement, and create a pulse when you cross the X mm threshold.

3. To pulse each time any 1 of the 3 axes crosses an X mm interval, you can make use of the change detection available on digital port 0.  You'll also end up using the internal signal "Change Detection Event".

4. "Some" is still vague.  The conditions for pulsing still aren't clear.  "Some", "Any", "All" have been used somewhat interchangeably in your description, but they have different meanings and implications.

-Kevin P

[Daaaavid]

1. That's great. Thank you!

2. a) The first step which I am solving is following problem: My probe is moving in 3D space, but
only along straight lines parallely with just one axis (it can be any of three carterian axes). So
one axis is moving, the rest two
are staying. I need to measure by probe every time when probe moves by 5mm from its last position.
Since the probe moves along just one axis I am using just one encoder to evaluate the right
position of the probe (if it moves just by 5mm from last position). But it can moves also along
oter axes (always along one axis). If I am thinking correctly, I need three encoders on three
axes (in 3D). I need HW dividing for each axis to evaluate the position of the probe.
If one axis has just arrived to the right position (first, second or third asis), send TTL edge
(as signal to acquire data from the probe).

2. b) Yes I tried to calculate 3D position from encoders position, but it is quite slow. That
is why I need HW divider of encoder pulses to evaluate right position of the axis.

3. OK, thank you. I have to have a look on it.

4) When I used word "some" I meant following variants:
   a) only encoder 1 just arrived to right position
   b) only encoder 2 just arrived to right position
   c) only encoder 3 just arrived to right position
   d) only encoders 1 and 2 just arrived to right position
   e) only encoders 1 and 3 just arrived to right position
   f) only encoders 2 and 3 just arrived to right position
   g) all encoders 1, 2 and 3 just arrived to right position
...it means at least one encoder is in the right position.

The opposite case, when the TTL edge cannot be sent, is only one. It means none of encoders is in right position.

Thank you,

David

[Kevin_Price]

continuing...

2b).  It shouldn't *have* to be very slow.  I would expect you to be able to run a software polling, calculating, and occasional reacting loop upwards of 100 Hz.   IF you do it efficiently by starting the tasks before the loop and stopping them after.

    But maybe 100 Hz isn't fast enough?   Or maybe you really need hardware-level repeatability and precision?

3. You would have to physically wire from each of the 3 "divide down" counter outputs to pins on digital port 0.  You'd need to configure a DI task with "change detection timing", sensitive to the appropriate edge of each of those signals.  Then you'd need to use DAQmx Export Signal to route the internal "change detection event" signal out to a PFI pin.  That pulse can then be the signal used to take a probe measurement.

4. Your use of the phrase "just arrived" might be throwing me off.  I think of it as meaning, "just now in time"   Maybe you mean it more like, "just barely in space?"

    I'd also want to emphasize some distinction between "position" and "motion increment".  You describe things in terms of position, but the divide down task is going to work based on increments of motion.  Of particular note: direction changes are liable to throw it off.  It only reacts to the total # of encoder edges it saw.  Even if all of them come from the axis vibrating back and forth with 0 net displacement.

-Kevin P