Using quadrature encoder with callback function

[gagamehl]

Well, the only problem is that it doesn’t work as I thought it would.

However I cannot wrap my head around the 2 counter + z-impulse idea and how that should help me neither.

There is a similar problem mentioned in https://forums.ni.com/t5/LabVIEW/How-can-I-generate-a-pulse-train-from-shaft-encoder/td-p/2423240?pr..., but it seems like an output terminal is needed!? I probably could get my hands on one ...

It really baffles me how this seems to be such an exotic task.

Anyway I am not willing to give up so easily, so maybe you can elaborate your idea a little more?

Cheers

[Kevin_Price]

The thread you linked has some things in common, but is focused on generating a pulse signal at specific distance intervals.  It also is meant for uni-directional motion.

My idea is only half-baked, is liable to get complicated, and even then will probably only *mostly* support bi-directional motions.  Let's do a little reality check before heading too far along that road.

How soon after a given position is achieved must you notice and respond?  You won't be able to get hardware-level precision on the timing.  The use of callbacks (software execution) and a USB-connected DAQ system (latency) limits the immediacy of your response.  So how much can you live with?

There may be a simpler approach that works "well enough", given that perfection isn't gonna be possible anyway.

-Kevin P

[gagamehl]

Sorry for the late answer but I was not available last week.

The system is not too time critical. The frequency is quite low and I basically just need to know where a sample has to be taken. If that sample is taken and processed within the callback before the next sample arrives, its fine.

Just to clarify, my connection is via Ethernet not USB. I overread that before.

Thanks

[Kevin_Price]

Can you expand on your latest message?  What "frequency" is low, and how low is it?   You talk about taking and processing 1 sample before the next sample arrives.  What processing is needed?  Why is it important to do this in near-real-time, 1 sample at a time?

Generally, what's the big picture here for your overall app?  I don't know what to suggest without a clearer understanding of how the pieces fit together.

-Kevin P

[gagamehl]

Sure, I will try to clarify.

The encoder is attached to a vehicle moving slowly along a track. This vehicle speed is not necessarily constant. Every x-distance I want to initiate a measurement from a laser sensor. The rate with which I want to take those measurements will be less than 10Hz. The received measurement is processed and plotted in real time, more or less.

One existing solution is to continuously poll the current position in software and if it reaches the desired position (determined by the counter), I trigger the measurement in the callback. But now I want the system to be triggered (sampled) by hardware, which I can do, but only in one direction with a PFI line.

So that is basically the grand scheme of it. I hope the explanation is sufficient to determine whether the bi-directionality is possible or not.

[Kevin_Price]

How do you do the laser sensor measurement?  Is it an analog signal you acquire with another DAQmx task?  Or is it a self-contained instrument you query over some communication bus or API?

If it's an analog signal, it seems to me like the most straightforward thing is to sync up your AI and Encoder task by sharing the AI sample clock.  Then scan the data in software to find the laser measurement that corresponds to the position of interest.  In addition to the equi-distant snapshots of data, you'd *also* have a complete time record of the two measurements, 

If it's communication or an API, I'm a LabVIEW guy so I'd want to make parallel loops for AI and Encoder.  Both would be "producers" and a 3rd loop would be the "consumer" of their data which did the same kind of software scanning and correlating.  Parallel operations are fairly trivial in LabVIEW, I'm not sure how readily you can set up similar things in C++.

As a point of reference, here's a brief overview of the complex hardware method:

- configure a counter task to use a non-zero value for "z index reload". 

- Choose the very specific value such that the encoder will reach 0 count at the rotation angle corresponding to your equi-distant sample points.  Note that this only holds true for 1 of the 2 possible directions of rotation.

- configure the encoder task to "pulse on terminal count"

- register the counter output signal to fire a callback function related to this particular rotation direction

- do all the same stuff with a 2nd counter task that measures the same encoder, but use the special "z index reload" value that'll reach 0 at the same angle when rotating in the *opposite* direction

- add some code that'll keep track of which direction you're traveling

- in the callbacks, consult this direction tracking info to know whether to execute the rest of the callback or skip it, depending 

So all *that* stuff just to generate a pulse at a specific rotation angle of an encoder, and then use that pulse to fire a callback, and then do the laser sensor measurement after an unknown amount of latency.  Doesn't seem like you'd be getting much for the effort.

- Kevin P