Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Incorrect encoder angular position by one pulse ( 1024ppr --> 0.35deg /pulse, but 0.2 ~0.4 deg/pulse)

Hello guys,

I have some trouble to get pressure reading by every encoder pulse ( every 0.35 deg) using encoder.

Currently, I am using quadratic encoder (A,B, and Z).

I have two tasks. One is for angular position (encoder) and another is pressure reading (pressure sensor)

Both tasks shares same external clock. The execution of the loop is no problem.

When I checked the excel file that I measured, every pulse didn't give the 0.35 deg (360deg/1024 ppr).

The value slightly fluctuated I mean up and down like 0.2 ~ 0.4 deg per pulse.

Is this reading reliable and reasonable?

I am actually measuring intake and exhaust pulse by crank angle.

I am afraid that a few degree difference would result in invalid pulse shape.

For your reference, I attached Vi file that I tested.

Thanks for your help and assistance in advance.

 

 

0 Kudos
Message 1 of 2
(2,513 Views)

Issues:

 

1. Your config for the encoder is set for 1024 pulses/rev.  As the help says, that's interpreted as 1024 pulses *EACH* for channel A or channel B individually.  With X4 decoding, you'll be able to have a resolution that's 1/4 that size (360 deg / 4096 counts).  You can measure increments < 0.1 degree.

 

2. It's unclear whether your tasks are actually synced b/c the AI task is triggered externally while the counter task isn't.  Even though both use the same external signal as a sample clock, the counter task could start sampling first if the AI trigger hasn't been asserted yet.

 

3. I don't know whether your expectations about the data are reasonable.  You seem to expect one sample per encoder increment.  That would *only* be pretty reasonable if the external clock signal *is* the A or B channel from the encoder.  It still may not be 100% correct though.

   The problem would be that the same edge responsible for being the sample clock is also used to change the count value.  This is a bit of a hardware race condition -- which part of the circuitry registers the transition first?  There's no way to know whether the count register changes just before the sample clock edge registers or just after.

  The best workaround I can suggest is to trigger off the Z-index signal, clock the AI off one of the encoder channels, and simply create the position data in software knowing that each sample must represent one full cycle of ch A, i.e., a 360deg/1024 increment.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 2
(2,435 Views)