Continuous high-speed encoder measurement with 1kHz sampling rate

[ebeltt]

I'm continuously measuring the position of a linear encoder using a PCI-6602 counter board, and I need to know how to set it up so that the counter runs at high speed, but data is only inserted into the buffer at a rate of 1kHz.  I'm measuring a single stroke of a hydraulic cylinder, and I'm not concerned with recording high-frequency events except to the extent that they throw off the count significantly if the hardware isn't running fast enough to detect all of the encoder pulses.

What I'm finding now is that the external sample clock signal (internally routed counter output pulse) controls both the rate at which the hardware detects encoder pulses as well as the rate at which it inserts data into the buffer.  With a 100 pulse per inch encoder and a sampling rate of 1kHz, the final extended position of the cylinder is off by +/- 0.15 inches, which is unacceptable.

I need to compute a velocity from this information, so I'd rather not use software timed sampling to control this (it makes programming harder for other reasons as well - multiple asynchronus measurements).  Any ideas on how to configure the hardware to count faster than the rate at which it inserts counts into the buffer?

[Kevin_Price]

Based on your description, I kinda suspect that the problem lies elsewhere.

What causes you to conclude that the sample clock controls the count rate in addition to controlling the buffer writing rate?  Are you using an encoder signal AS the sample clock?  Otherwise, I can't easily imagine a scenario that would produce such a symptom.  The encoder signal(s) will cause the value in the count register to change on each active encoder edge, and can handle at least 10's of MHz.  The sample clock determines how often a snapshot of the count register value is written to the data acq buffer.

I wonder if you're doing a non-quadrature-based position measurement and are instead simply counting edges on one incremental encoder signal.  Then, vibration at the end of the stroke could cause you to overcount.  Also, on what basis do you attribute a 0.15 inch dicrepancy to measurement error?  How do you know it isn't an accurate measurement of a motion error?

------------------------------

Context switch.  Just read the last part of you post again referring to velocity measurement.  So you probably *are* using the encoder signal as a sample clock.  Now it's time for me to rewind.

Can you explain the requirements, constraints, and reasons?  Why the 1 kHz sampling requirement?  How accurate must the speed measurement be?  Do you need an accurate quadrature-based position measurement?

Having a specified constant sample rate of 1 kHz is probably at odds with the desire for a precise velocity measurement.  Which is more important?

-Kevin P.

[ebeltt]

<i>Are you using an encoder signal AS the sample clock?</i>

No, I'm generating a pulse output on ch7 of the board and using its internal output as the signal source for the sample clock.

<i>I wonder if you're doing a non-quadrature-based position measurement and are instead simply counting edges on one incremental encoder signal.  Then, vibration at the end of the stroke could cause you to overcount. </i>

No, before I started I created a sample program and saw that the encoder was counting both up and down, and in the current software there is a portion of the motion where the cable of the encoder rebounds and the position is detected as moving backwards in that area.  Moreover, the error at the end of the stroke varies by <b>+/-</b> 0.15" or so.  It undercounts sometimes and overcounts other times, but it's usually within that range.

What I'm actually doing is measuring the injection stroke of a diecast machine.  The software I've written computes the shot speed throughout the stroke and determines a "biscuit length" which depends only on the constant length of the shot sleeve and the final position of the ram after injection (the more metal is poured, the larger the biscuit length, and I can physically measure it after each shot).  I've been able to get much more accurate measurements than this in the past (and currently on other machines) using analog sensors, and by turning up the sample clock rate of the encoder I start to see the effects of aliasing more clearly.  That's why believe the hardware isn't running nearly as quickly as it's capable of, and it's not a real physical event.

I can't see another reason why the count wouldn't be dead-on at the end of the shot.  The cylinder only moves at maximum of about 120in/s, and I don't think there are any displacements over the resolution of the encoder (0.01") that wouldn't be detected if the hardware was running in the MHz range.  Also, I haven't read anything so far that indicates that the rate the counter runs at internally is independent of the rate at which it inserts data into the buffer.  I would have expected it to run that way, but it doesn't seem to be so.  In fact, before I started using the counter board I tried using clocked digital inputs to detect edges manually (at about 200kHz), and I was getting better results but with the same problem.  I expected it to go away with the counter board because I was pretty sure it was high-frequency vibrations throwing off the count.

<i>Why the 1 kHz sampling requirement?</i>

I'm only using that specific number because it's convenient.  I'm also recording data from pressure sensors and some analog string pots, and that's the rate they're running at.  I have to compute velocities, chop waveforms apart, do some position-averaging (as opposed to time-base averaging), etc, and it's just convenient to assume a consistent 1ms sample spacing.  More importantly though, I have to collect data from potentially 7 different machines at once and I can only handle so much of it at a time without overflowing buffers or missing events in software, so I don't want to process excessive data, and events that happen more quickly than 1ms in the diecasting process aren't very important because they involve such small displacements of metal.

<i>Having a specified constant sample rate of 1 kHz is probably at odds with the desire for a precise velocity measurement.</i>

As long as I accurately know the position at time A and time B, and there's a well-known time difference between them, I can calculate an average velocity over that time just fine.  I don't need a huge amount of time-domain precision for this application, or even super-precise velocities (2% is plenty).

For the record, my encoder chA is wired into Pin2: CTR0 Source, and chB is wired into Pin40: CTR0 Aux.  There is no Z signal, but I'm zeroing the counter after each shot in software.

[Kevin_Price · Accepted solution]

Ok, you're clearly on the right track here, so I'll focus on some specifics.

1. How do you know that the +/-0.15" discrepancies are *measurement* error rather than *motion* error?  Why could it not be a true and accurate measurement of a motion that can vary slightly from nominal?

2. I wonder some about electrical noise and glitches that may produce spurious edges.  The fact that the behavior was better using a limited sampling rate (200 kHz) on digital inputs may be that some of those glitches were so short that they were never captured.

   I've done a ton of encoder work with the 6602 board and I can definitely confirm that the count hardware is sensitive to edges into the 10's of MHz.  (I know its 80 MHz for edge counting, but think I remember it may be in the 20-40 MHz range to accomodate the additional signal propagation times of the quadrature decoding circuitry). 

   One small point of clarification.  You talk about the speed that the counter "runs at".  The count value is a register whose value gets changed entirely by the circuitry, *independent* of the sample rate.  Whether you sample with hardware-clocked count buffering or with unbuffered software polling matters not a bit to the circuitry that increments/decrements the count register value.  (In other words, I am completely confident that you would get the same end position measurement if you took 1 single software-polled sample after the end of the move rather than sampling at 1 kHz throughout.)

   So, if the count value is off, it's because the circuitry is detecting count-producing edges that shouldn't be there.  Something you could try is to configure digital debounce filtering for the input PFI lines corresponding to the encoder Source and Aux inputs.

-Kevin P.

[ebeltt]

Something occurred to me here that I think proves you must be right about how the hardware is running.  Using my current 1kHz sampling rate I'm actually able to measure velocities above 100in/s, and with a 100 pulse per inch encoder that means the hardware must be running above 20kHz at least (which means it's almost certainly at or near full speed).

Why could it not be a true and accurate measurement of a motion that can vary slightly from nominal?

I'm not entirely sure what you mean here, but what I can say is that at the end of each shot there's a few seconds worth of data where the ram isn't moving at all and the metal is solidifying.  This is the position which should correspond to a given biscuit length, and using analog sensors it does (+/- 0.05 inches or so).  Using the encoder though, it varies from the real physical result by +/-0.15 inches or so (and part of the purpose of the upgrade to digital sensors was to increase the accuracy here).

I wonder some about electrical noise and glitches that may produce spurious edges.

Well it seems like you've helped me narrow it down either to that or to a physical vibration with a displacement greater than 0.01" and above the threshold of a counter running in the MHz range (which I find very hard to believe).  So I think you're right, that electrical noise is a likely culprit.  I just assumed the 5V threshold was unlikely to be exceeded by noise, but I never tested the assumption.

The count value is a register whose value gets changed entirely by the circuitry, *independent* of the sample rate.

That's what I'd thought originally, but I'd convinced myself it wasn't true after seeing the inaccurate results.  I'm pretty sure you're right though, that the hardware must be detecting electrical pulses that don't correspond to real movements.

Something you could try is to configure digital debounce filtering for the input PFI lines corresponding to the encoder Source and Aux inputs.

I'll definitely try that.  Thanks for the help.

[Kevin_Price]

Just a couple other quick thoughts regarding the possibility of electrical noise.  I'm no expert in the area but have picked up some rules of thumb along the way.

1. Whenever possible, the best way to deal with noise issues is to reduce/eliminate them at the source rather than compensating at your daq device.

2. Generally speaking, an encoder that puts out differential signals will usually offer better noise immunity.  Use the differential signals to traverse the longer cabling run and then put a differential-to-TTL converter right next to (or inside) the terminal block.

-Kevin P.

[ebeltt]

A ran a dedicated shielded cable for the encoder all the way from the machine to the DAQ system and also tightened a loose connector.  The problem seems to have gone completely away now.  Thanks for the help.