How can I use a digital signal to trigger a linear encoder to start and stop sampling?

[CW_Edge]

I think what your suggesting should work, but I am trying a little vague on the using the Z-index as a Sample Clock part.

Let me use this as an example.  Lets say I have an encoder that is 100mm long with one encoder count per .005mm so there are 20,000 counts and the Z-Index marks are as follows:

Cnts Btwn       Cummulative

1500                1500

4000                5500

2500                8000

3900                11900

2600                14500

3800                18300

If I have a DAQmx counter task wired to a Sample Clock wired to a Buffer with the Z-Index digital signal wired to the source of the Sample Clock, what would I expect to have in the buffer if I ran it from one end to another?  Would I have the counts between, Cummulative, None of the above?  Also, would this be using finite, continuous or Hardware Timed Single Point as the Sample Mode?

[CW_Edge]

Something else I am running into is how do I "sample" the counter with the CI.Count property node?  Where do I wire it in?  If I wire the property node before the Start DAQmx task, I get nothing, but since the Start DAQmx is after the Sample Clock if I wire it in after, all I get are the Z-Index readings.

Is there a way to get the "live" data AND use the sample clock to get the positions of the Z-Index pulses using one task?  At first glance, it does not seem possible, but I am more that willing to be wrong on that.

Let me know if anyone has any ideas.  Thanks. 

[Chris V]

Hi CW_Edge,

I'm still a little lost on your application, but from what you described in the last few posts, I think you are looking for something like this:

Basically, your counter task will count edges, but you will only sample it based upon your z-index signal.  Your loop in this case only runs at 4Hz, but any time you have read a sample based on the z-index you will read it back and you can also monitor the current count.

Have a great day,

Chris V

[CW_Edge]

What I am trying to do is both sample the Raw Counter Data every 10ms AND ALSO somehow get the location of the Z-Index marker pulses using hardware sampling because software sampling is too slow.

At this point I am able to to one or the other, but cannot seem to be able to do both without using up two counter channels on my DAQ card.  At this point, I have used all 4 Quad Counter channels on my DAQ card so I would have to have an additional DAQ card which drastically increases the cost of the project.

I was hoping there was a way to maybe use a digital trigger to "sample" an already existing task using hardware timing, but appearently that is not possible?

For more info on the application, read above or check out "Using Z-Index on Linear Encoder to determine Absolute Position" thread.

As seems to be the case more that I'd like, I am having trouble with something I assumed would be relatively straightforward - using marker pulses on a linear scale to determine position.  From talking to the scale manufacture, this is the sole purpose for having the marker pulses so I am a little bit frustrated that there does not seem to be an easy way to do this using LabView.

[Chris V]

Hi CW_Edge,

Forgive me, but I'm a little confused.  The code I posted will do exactly that.

The encoder will be sampled only when a z-index pulse is received.  Hardware timed.

The code monitors the count of the encoder.  Right now it only happens every 250 ms, but if you change the wait to 10, it should run at approximately 10 ms.  This is software timed.  Is that the part that is not acceptable?

Have a great day,

Chris V

[Kevin_Price]

I've got a slightly different understanding of what you're after, but Chris' example remains a great starting point.  Here are the changes and reasons:

1. Configure as position measurement rather than edge counting in order to handle quadrature.  I'm specifically setting z-index enable to False so that you'll buffer unique position measurements each time you sample on the physical z-index signal.

2. Changed the Read function to retrieve a count value.  (I'm sure the Analog Read was just a typo).

3. The hw-timed capture of marker positions is handled by the upper loop.  It will map out all your

unique marker positions in terms of raw counts.

4. The lower loop is a software-timed Timed Loop that queries (and stores) instantaneous count values every 10 msec.  This simple example simply grows an array via auto-indexing, but there are better ways to do it in a real app where loop timing consistency is important.

5. Both loops get data from the same counter task.  They terminate on user request or task error.  (Note: user request directly ends the upper loop, clearing the DAQmx task, causing the lower loop to terminate on error.)

Obviously, this isn't your final app.  Really this just gives you two things:

A. an illustration of the ability to get both hw-timed buffered counts and sw-timed queried counts from a single counter channel and task.

B. a method to map out your marker positions ahead of time so you can construct some kind of look up table to use in your real app.  Your real app will presumably need to enable z-indexing on those marker positions, and then you'll need your software querying loop to "notice" the z-index reload so you can figure out how far you are from the most recent previous z-index reload and then consult your lookup table to know where you are in absolute position.

-Kevin P

[CW_Edge]

Kevin,

Before I get too far, I just want to make verify something.  You have the task source from the bottom loop (sw timed) wired in after the Sample Clock from the Z-Index.  Doesn't this mean it will only return the counts from the most recent marker pulse location?

Is there something you've done in the bottom loop that gets around that because I've tried almost this exact set-up and what happens is the bottom loop samples every 10ms, but I just get the same value over and over until the next marker pulse is reached.  So if I am moving at a constant rate, if I were to plot it, instead of a slope of a line, I would get a stair step.

Let me know.  Thanks.

[CW_Edge]

Chris V,

Similar response as to Kevin, it seems to me that the sw timed loop is sampling the data that is coming from the hw timed Sample clock.  Is this correct?

What I would like to do is use hw timing to get the Z-Index marks and the sw timing to get the current position of the encoder.  If I were to plot them both, one would be a stair step, the other would be a sloped line.

The data is there, the DAQ card has the information I need, I just can't seem to get it out.

[Kevin_Price]

1. It shouldn't matter much where in the chain of the "upper" DAQmx calls I tap into the task refnum to route it down to the lower sw-timed loop.  I chose to do it after starting the task because, well, there seems little point in doing it sooner.

2. Your other question is interesting, but probably not the *good* kind of interesting.  I tested the snippet using a simulated M-series device.  I didn't really "zero" in on the fact that the sw-queried count didn't change because it would be normal for a stationary (and non-existent) encoder to keep reporting a count of 0.  I thought I had tried a similar quick example earlier during this thread and satisfied myself that one could perform both hw-buffered captures and sw-timed queries of a single counter task's count value.   Maybe I only went so far as to verify that no DAQmx errors were thrown and mentally filed *that* away as "success."

  The behavior you describe sounds like it may well be a true barrier for your app.  Perhaps querying the instantaneous count of a buffered task will only report the most recent latched & buffered value rather than a true instantaneous snapshot between samples.  I kinda vaguely sorta recall hitting the same barrier one time long ago with E-series boards, but didn't immediately assume that limitation was still present.

<a couple hours pass until I get a few free moments>

   Hmmm, on the other hand, never mind.  I just modifed the example to try on a real E-series board I have.  I had to switch to edge counting because position encoders aren't supported, but I *was* able to both hw-buffer and also sw-query the count independently.  I'll attach that snippet below so you can try it too.  BTW, somehow I goofed on the previous snippet -- I should have wired a 'F' into the z-index enable input when configuring the encoder task.

   Anyway, based on this new (better) test, it seems there's still a decent chance you'll be able to get your needed behavior from an encoder position task.  There's no good reason I can think of why the driver or hardware would allow this access for edge counting while disallowing it for position measurement.

-Kevin P

[CW_Edge]

Thank you very much for your help.  I will try this and let you know how it goes.