Absolute Angular Position Calculated From Encoder Is Shifting After Accelerations

[AMAGIS]

Background:

I want to measure and record the angular position of a driveshaft using an encoder, sampled at 51200Hz, synchronized with the sampling of other analog signals. The absolute position (0Deg to a known reference) is shifting after change of speed.

For a TL:DR version, skip to the questions at the bottom

My current hardware is as follows:

Chassis: cDAQ-9189, connected to my PC via Ethernet.

Cards:

NI 9401 (Digital Encoder for angular position – 51200Hz, should be synced when 9220 signals are sampled)

 -  Dynapar Nexgen 221440B12E (1440PPR encoder with Z channel, Datasheet )

NI 9220 (Accelerometers and Mics– 51200Hz)

NI 9862 (CAN)

NI 9203 (Pressure Sensors 1000Hz)

NI 9213 (Thermocouples – 10Hz)

NI 9234 (Mics – 51200Hz)

NI 9231 (Accelerometers – 51200Hz)

Current Status:

I had a similar question earlier in the year that was answered already and things appears to be working wonderfully. Synchronizing Angular Position Across Multiple Sample Rates; Best Practices. 

I've been able to successfully  sample my angular position, synced with the data collection timer from the NI9220 and the data looked great at first glance. I was able to calculate RPM based on the change in angle as well as the frequency in which the angle reset increased with speed, as expected. 

I have 0deg = Top Dead Center (TDC) for Cylinder 1. The encoder will do one full revolution and then reset back to 0 and continue this process.

However, when the engine speed changes, 0deg no longer equals TDC. The encoder collar is keyed on both sides and is not slipping. This has been confirmed and reconfirmed with manually cranking the engine over till TDC and confirming the output of the encoder in Labview. 

I can confirm that 0deg indicated in the data is no longer TDC when I compare the angular position output to either the cam position sensor output or the injector current trace. While the injector pulse may phase a few degrees, it does not phase 280deg+.

The encoder position does not seem to phase as long as the engine speed is static, only after a change in engine speed.

Note:Top graph "ValveCOverC6" is actually Encoder (0-360deg)

Injector Current vs Angular Position (Crank Angle Degrees) at a static speed (1200 RPM):

You can see that the current pulse is always between an indicated 90deg and 120deg. If the encoder output was drifting position during this, you'd see a much wider band from those two high current traces (Ignore the shorter ~6amp pulses, those are something different).

Below you will see a transition from 1200 rpm to 700 rpm. You will see the perceived phasing of the injector during this speed change. Then there a screen shot of the data of it resting at 700RPM after the decel event. You'll notice that the injector is back to a steady value but much different angular location than what it was at 1200RPM.

Transition 1200 to 700

 

 Injector Current vs Angular Position (Crank Angle Degrees) at a Transition

 

:

Static Speed (700rpm)

Injector Current vs Angular Position (Crank Angle Degrees) at a static speed (700 RPM):

 

LabVIEW Setup:

I've attached my VI and project.

AngularPositionTask

Questions:

How exactly does LabVIEW calculate "anglular position?" I know that's a broad question but by that I mean, if I am sampling relatively slow, slower than the position is changing, is LabVIEW calculating a new angle every time a pulse comes through despite the slow sampling and when it is finally sampled, it will send out it's current position?

How is it possible for my zero to be off consistently if I have and am using the provided Z channel reset?

How to a fix it so that I can sample the position at 51200Hz and have it such that the position is absolute to a known reference (z channel)

[Kevin_Price]

Thanks for providing a large amount of info, unfortunately I don't personally have enough time to unpack and absorb all of it.  I tried to give things a quick overview though so let me focus on the specific questions:

---

How exactly does LabVIEW calculate "anglular position?" I know that's a broad question but by that I mean, if I am sampling relatively slow, slower than the position is changing, is LabVIEW calculating a new angle every time a pulse comes through despite the slow sampling and when it is finally sampled, it will send out it's current position?

No, it's not really like that.  Down at the device hardware level, there's an integer count register.  Quadrature state changes cause that count to increment or decrement in response to hardware edges.

   Layered on top of that is *sampling*.  A sample clock will cause the instantaneous count value to be latched.  And the DAQmx driver manages data transfer of such "sampled values" up to the host PC.

   When your app makes a query for data, the raw integer counts may *then* be turned into floating point angle measurements, according to how you configured your task.

How is it possible for my zero to be off consistently if I have and am using the provided Z channel reset?

It seems unlikely to me that this will end up being an inherent device or driver problem.  It's very possible for software "errors" to misalign data even if the hardware is in sync.  

    One way this can happen is when data is gathered from multiple tasks and then shown on graphs (or in files) as being simultaneous, just because the samples were requested from the tasks at approximately the same time.   However, those task reads may not necessarily have cleared out the buffers.  One of them may have been reading 1 second worth of data that represents the time period from 1.5 seconds ago until 0.5 seconds ago.  Another may have the 1 second of data from 1.2 seconds ago until 0.2 seconds ago.  And so on...

    This is *not* a random or uncontrollable phenomenon.  It *can* be prevented.  But it can also happen easily when software is written according to wrong assumptions, even when those wrong assumptions seem reasonable.

How to a fix it so that I can sample the position at 51200Hz and have it such that the position is absolute to a known reference (z channel)

---

As a *diagnostic* step, add a DAQmx Read property node after each DAQmx Read call.  Query for the # of Available Samples.  When your software reads maintain data sync, these numbers should be quite small, possible as low as 0.  If you see some of these #'s get larger during your speed change transitions, that'll be a good clue.

Edit: Distinct from all this is the issue of hardware sync, which it appears you have *not* taken sufficient pains to establish.  I didn't dive in deep enough to say for sure, but I don't see anything that syncs the tasks with hardware signals.  My cDAQ experience is limited and I didn't investigate all your devices, but I further suspect that you have additional unconsidered sources of non-sync if your sound & accel measurements are done with Delta-Sigma devices which insert a non-negotiable delay into the acquisition path.

-Kevin P

[AMAGIS]

I just saw your message and haven't had time to unpack all of it either or add the readnode idea but I appreciate the input. In the meantime I did go back and just monitor the z channel alone and that appears to be shifting; so it's not necessarily the daqmx angle calculator.

The double pulse in the encoder data is to reinitialize the ECM to cylinder 1’s cylinder event; coupled with the crank sensor the ECM knows exactly where the engine is at both angular position and cycle (Combustion, Exhaust, Intake, or Compression).

You can see in the first image below that the Z channel increases between cylinder 5 and 3 (Firing order 1-5-3-6-2-4 where the double pulse is Cylinder 1) This means the Z channel is triggering between approximately 120 and 240 CAD (Closer to 240). This z channel input should always stay in the same position relative to the cam sensor. In the second image, at a different engine speed, the Z channel indexes between Cylinder’s 1 and 5 or 0 and 120CAD.

[Kevin_Price]

I can't confirm your conclusions.  I don't know your field, I don't know your specific setup, I never use MAX-defined tasks, I can see that your tasks aren't sync'ed in hardware, I can see that you move data around your app via Shared Variables which I never use due to their long-term poor reputation, and the graphs you showed are not coming from the LabVIEW program you posted so there's some other unknown data processing stage somewhere too.

I'm way too far removed from the necessary details to offer any conclusive advice for the full app.  Here's what I *would* advise.  Run a shipping example for continuous encoder measurement while you run your engine.  See if your Z-index causes the position reading to re-zero itself anywhere besides when it approaches +/- 360. degrees.   That'll be a much more straightforward test of your (seeming) hypothesis that DAQmx or your DAQ device are not doing a proper job of tracking angular position.

My bet is that you'll either find perfect tracking, or there will be some kind of electrical noise or signal incompatibility.   Over the course of lots of experience, I've not known the internal counter hardware to "get confused" this way when when fed with appropriate signals.

-Kevin P