OMP: Prototype tester

[warpc0il]

Where's the Thank button, when you need it?

[obakemono]

Great Success!

[HarSc]

Bear with me, long post to follow!

I’d like the large number of very knowledgeable people on here to critique this hypothesis. It’s taken a long time to develop!

OMP Failures: Probable cause and repair

BASIC RECAP: The ECU has two connectors to the OMP.

The first is a 6 pin connector is an OUTPUT from the ECU which instructs the stepper motor in the OMP to move a given number of steps up/down in a range of (typically) zero to 52 steps. These steps move an armature which regulates the oil flow from the OMP. Zero corresponds to a low oil flow condition (e.g at idle) and 52 steps corresponds to high oil flow (max revs). The ECU determines the optimum oil flow position based on a number of conditions, including engine revs/temp/load. The detail doesn’t matter, but it is important to note the stepper motor will be moving constantly, chasing the optimum step number in Mazda’s algorithm. Here is the mechanism in the OMP, with the stepper motor cog driving the armature. The armature links to a shaft connected to a worm drive that determine the position of a set of sprung loaded brass plungers which control the oil flow.

OMP Photo 2.jpg (15.2 KiB) Viewed 2107 times

The second connector is to the OMP sensor which, simplistically, is a switch INPUT to the ECU which is OFF in the normal OMP operating step range, but turns ON above (typically) 52 steps from the zero point.

OMP INITIALISATION:

When the engine is started and engine revs rise above 500rpm, the ECU “calibrates/checks” the OMP step range. The ECU has no idea what step number the OMP is at to begin with, so drives the stepper motor ~60 steps towards the zero point (to guarantee the armature is at the zero point). If the armature is, say, at step 10, the end stop in the OMP will simply stop the stepper motor from moving it beyond this point. The stepper motor has limited force available, to ensure the teeth on the armature are not damaged. The stepper motor tries to move the armature beyond the zero point but a clicking can be heard whilst any “excess steps” in the 60 step “drive to zero” ECU command are exhausted. The ECU then uses this as its reference point for low oil flow FOR THE ENTIRETY of the car’s journey. See zero setting process video:

[media]http://www.youtube.com/shorts/71-o9Ky0nZQ[/media]

OMP CHECK AND CALIBRATION/LEARNING:

Once the zero point is determined, the ECU will drive the stepper motor (and connected armature) in the direction of higher oi flow position until the sensor switches ON. This MUST be above step 52 or the ECU will detect an abnormality and trigger LIMP MODE.

The above description is what I have used in my Arduino based tester, but most failed OMP’s pass this test, so what am I missing?

If the sensor switches ON above step 52, then the OMP will enter it’s “regular drive function” and move the armature up/down within the range 0-52 (or up to 59 if this is where the sensor switched ON).

VERY IMPORTANT; for the whole of the car’s journey, the ECU has NO FEEDBACK on where the armature is located, it merely calculates its current position, based on the zero datum point it set on engine start and the commands it issues to step up and down. If the system works as designed, this will be fine.

THEORISED FAILURE. The stepper motor has limited energy to move all the mechanical items to which it is connected. As can be seen from the initial zero point setting, the stepper can be stalled quite easily by increased mechanical resistance, e.g. the zero stop point.

IF there is sufficient increased mechanical resistance present (e.g. caused by grit ingress or corrosion) then the armature may “slip” (just like it does when hitting the end stop). This will result in the ACTUAL step position deviating from the “target/assumed” position the ECU believes the armature to be in. Over time, this will result in the armature getting increasingly out the target position, such that it will cause the steps to exceed the initial maximum ~52 steps, resulting in the sensor delivering an “ON” condition to the ECU. My theory is that this unexpected condition will cause the ECU to put the car into limp mode.

POTENTIAL REPAIR:

So, if correct, assuming the stepper motor and sensor operate (easy to check the basics with a multimeter), then dismantling and thoroughly cleaning the OMP internals will restore correct operation. This is slightly easier said than done, as the 5 screws on the OMP front casing are 99% likely to be seized (but can be drilled out and replaced with nuts/bolts or retapped). New seals will also likely be required - maybe the club can commision these to be made, if not available from Mazda. I think there are 4 seals in total, but I believe 2 are basic "O" rings.

The fact that used OMP's are getting harder to source, costing typically £150+, and new ones form Mazda are £700+ (I think?) then repair is a viable option. There is also no guarantee of how much longer Mazda will make new ones available.

Interestingly, I was testing my “failed” OMP a few days ago (which passes on my tester, but not in the car) and I noted the shaft, armature and stepper motor moved freely UNTIL I applied the slightest downward pressure the cog on the stepper motor. When I did this, and rotated the cog by hand, I could feel that at one point in the rotation a slight “catch” could be felt. I haven’y yet determined what is causing this, but my next plan is to alter the software in my tester to operate a continuous test, driving the armature up/down through the range. If my theory is correct, at some point the sensor will operate, signalling the armature has moved beyond its permitted range. I can detect that and log a fault on the tester. If I'm right, then testing OMP's for correct operation will be possible.

Does this all sound plausible?

[UtterOtter]

Very plausible. I've worked on software and hardware for 3D printers which use stepper motors, like the OMP, so I have some knowledge.

Are you running the stepper coils at the exact same current as the ECU does? Steppers can vary wildly with their stall torque depending on the current input. If your tester runs them at a higher current than the ECU (even 0.05A), then this will cause it to "succeed" the test as it had the added torque while the ECU doesn't give it enough umph.

My other point would be using something like a TMC2209 in UART mode to step the coils. It would allow you to vary the input current in software, which would mean you can run multiple tests, decreasing/increasing the current until it stalls, giving you a baseline minimum. Run this test across many known good OMPs and known bad ones would give you a vague idea of what the ECU's coil current is.

3D printers sometimes skip steps mid print, like your failure hypothesis, and they too don't really know where they are after homing the XYZ to 0. To mitigate this, the TMC2209 features "StallGuard", which allows it to detect a stepper motor's stall. You then call an interrupt and handle that depending on the use case. If your theory is indeed correct, you'd be able to detect a fault, and in theory detect exactly what "step" it occurs on. Run this multiple times to weed out any false positives and you'd be able to know exactly where in the range of motion the OMP fails.

If you combine the two, you could run multiple full run through tests using a set current range until an OMP stalls. If it stalls at a lower current than the ECU then it's good, but if it needs more current than the ECU provides, you know you have a faulty unit.

I hope that makes sense? Let me know if/what I need to clarify.

[casey]

Thank you!

That's a awesome bit of additional input - and makes a lot of sense

I have no idea what current the ECU delivers to the coils. I guess it ought to be possible to calculate this by sticking an oscilloscope on the stepper motor coil leads?

My hardware is fairly simple at this point, an Arduino coupled to a ULN2003 darlington transistor array to drive the stepper coils.

Initially (because it's easy), I will use my existing hardware setup and simply modify my present software from "single shot" testing to "automatic repeat" mode, looking for the sensor to operate when it shouldn't after constant up/down stepper commands. If this reveals failed OMP's correctly, then it may be good enough. If the "failed" OMP's still pass this regime, then your input will be invaluable to enhance the hardware and software to allow more control of the stepper motor current. I've done a quick Google and that TMC2209 chip looks to be a great little device

It also occurs to be that another "solution" to failed OMP's is to leave then in situ and insert a box of tricks between the ECU and the 6 pin OMP stepper plug to "amplify" the ECU output. Two issues with that, it's likely to be a temporary solution, if ingress of moisture inside the OMP is already at work, plus too much energy might start to damage the armature teeth when the ECU drives it to find the zero point and relies on the stepper stalling to complete this process. Just a thought though!

[warpc0il]

I have no idea what current the ECU delivers to the coils. I guess it ought to be possible to calculate this by sticking an oscilloscope on the stepper motor coil leads?

Probably not.

The oscilloscope will show what the voltage is, and across a known resistance will obviously allow you to calculate the current, but the current draw of a stalled motor isn't a simple resistance and you can't rely on the voltage to know what the maximum current of the source is.

You also don't know if the PCM output is just current limited or current sensing, though I'd like to assume the latter, so as current increases to nA, and PCM knows that's the motor stalled.

My understanding of the latest theory is that physical resistance in the mechanism results in this situation being miss-detected mid-range, rather than just at the end of the range, which then throws out the other parameters.

I suggest we approach ECU Testing who have vast experience with automotive electronics and electromechanical components, to see if they would add RX8 OMP refurbishment to their portfolio. Note that they already offer a service for the RX8 ABS Module https://www.ecutesting.com/product-cata ... e-combined

[UtterOtter]

PCM knows that's the motor stalled.

But this isn't a normal motor. It's a stepper motor. It's designed to "stall". To hold position it holds the coil pairs at specific voltage / currents depending on the microstepping and the rotor has ridges that allows the output to step. Stepper motors have a maximum hold current, i.e. how much current the coils can have running through at "stall" to hold the rotor in position. When designing a stepper system, you factor in the minimum hold and run currents that you can get away with so as to not overheat anything. Which is what Mazda will have done when designing it, except over time things have worn and the old minimum current (+safety margin) is no longer enough to get it to step fully. That safety margin is probably what the majority of OMPs these days are running within, as the years go on more and more OMPs will have eaten their safety margin current allowance and will start to skip steps. If you’re able to clean or otherwise decrease the mechanical resistance again, then you reinstate the safety margin once again.
Unless you're using modern algorithms within stepper motor controllers like the TMC2209, TMC2130 etc which are able to detect micro-ripples generated in the current caused by the rotor moving back past the coils in the wrong direction, you can't detect skipped steps on a stepper motor. And even then you don’t know how many steps were skipped, just that at least one step was skipped. You have to rehome the motor to find your 0 again before moving it back to where it should be.
The PCM can only step the motor backwards or forwards, by varying the voltage and current through the coils in the stator. Hence why a stepper needs a controller, it needs to precisely adjust these values to get it to move a step. Like casey said it's most likely that some steps are skipped due to mechanical resistance in the shaft, causing the mismatch. Say the PCM wants to move from step 13 to 14, it sends the voltage and current to the coils, but it's not enough force to actually move the shaft. The PCM now thinks it's at step 14, but in actuality it's still at 13, the same voltage and current through the coils now holding it there. If that happens enough, eventually it's going to activate the "endstop" at step 52 which causes the PCM to panic as it thinks it’s at an entirely different step to where it thinks it is.

Here's a youtube video of a 3D printer Extruder Stepper Motor skipping steps.
The resistance is too great for the motor to keep pushing, and it appears to "snap" back a notch. The 3D printer thinks the motor has moved X steps, when in actuality it's moved X-(skipped steps). And for this NEMA17 with a 1.8 degree step angle, and you loose every, say, 3rd step, if the controller thinks it's gone 360 degrees, the shaft has only moved 240 degrees. If you factor in the motor moving back and forth in the OMP, that can add up quickly. There is a good shot that's whats happening within the OMP.

[casey]

Simply brilliant! Thank you both. This was exactly this sort of discussion over my theory that I was hoping to engender on here. This club is blessed with so many knowledgeable people

I'm learning a lot more about stepper motors and their control too! So far, the info does seem to align well with my "mechanical resistance skipping" theory.

I have a busy week, with 2 RX-7 FD clusters in for repair, but I did a quick update to my Arduino program yesterday and debugged it in the Arduino IDE. I just need to dig out my breadboard prototype and give it a whirl. I suspect some tweaking will be needed in practice before it will work as I want I might even try AI to adjust my program - I've never done that before! Anyone got any advice on how to go about doing that?

[casey]

Thinking ahead, I was also, like warpc0il, wondering if a 3rd party might be interested in offering a refurbishment service, once we are sure we have nailed the cause of failures. That UK based outfit looks ideal. Commercially, though, would there be enough volume to make it worth their while? The discussion may be worth having, further down the line.

[qwakers]

as per my posts in the other thread, i wouldnt touch ecu testing with someone elses 10ft bargepole. there are better options out there.

[warpc0il]

@Casey see from here viewtopic.php?p=1452525#p1452525

I don't think volume would be an issue.

These companies create a process, for each unit type/version, and then just react to whatever arrives, as and when.

In some cases they may keep refurbished units for exchange but so many devices these days are coded to the vehicle, that they usually stick to a fast turnaround on the customer's unit.

[UtterOtter]

Something else has occured to me. Some 3D printers use the StallGuard tech to find their zero position. They run the motors at a reduced current until they detect skipped steps, which they figure is then the zero point. They use a reduced current to ensure we're not going to damage anything as we are TRYING to impact something. A more archaic version of this would be to run the motors at a reduced current, but just send enough steps for the motor to hit zero. So if our range of motion across an axis was 52 steps, we just force through 60 steps, and we therefore should be at zero. When it hits zero the motor just skips steps and stays in place. This was common on old PC CD / DVD drives, they'd run the stepper for the laser carrier in a direction a number of steps larger than the total range of steps. That's often what all the strange clicking and clunking noises you'd hear when you first inserted a disc. This process sounds remarkably like your description of the OMP's homing process.

So, it's possible the PCM runs the stepper motor at a reduced current / duty cycle during the initial homing process. (As in your video where the motor skips). It's possible this reduced current / duty cycle is not enough to get the armature to move so it skips steps in situ. This would be done as they know the motor is going to impact, and skip, so you'd run it with less force to ensure nothing is damaged. When the PCM then goes to find the upper limit, it would then increase the current / duty cycle again, as it thinks it knows where it is. This is then enough power to get the armature to move. However, as it failed to move when trying to find the zero point, when it goes to find the upper point it takes less than 52 steps, so the PCM panics realising something is wrong.

If you're running it at the full current all the time on your tester, it wouldn't fail to move to the zero point, and hence would always succeed the test. But the moment the PCM tries to delicately move the armature, it fails to do so due to some form of mechanical resistance, immediately resulting in a panic. I guess the best way to see this would be to actually look at the duty cycle of the coils using an oscilloscope from the PCM during the initialisation process and see if it differs from normal operation. I'd also want to look at the speed of the homing compared to normal operation. If it's running quite a bit slower than normal when finding the zero point, it would support the theory, as the trade off for the reduced current is speed.

[UtterOtter]

Your description of the homing process is precisely what happens in the OMP. What I don't know is, did Mazda do this with reduced current to the coils?

If the reduced current results in skipping, so the zero point is never reached, then "full" current applied to check for the correct "max" step range tx, then this would also result in an ECU fail, as the step count would be too low.

In all cases though, failure is conjectured to be due to increased mechanical resistance, so I think the theory (and solution) are valid, just that testing/simulating accurately on the bench requires more data. I wish it was easier to get an oscilloscope onto the stepper motor connection/leads to take some measurements......

[casey]

Some more progress with my thinking about the root cause of the OMP failures. Thoughts from others would be appreciated.

A bit more digging online revealed this very useful information from a Mazda diagnostic document. It shows the expected waveforms at the stepper motor coils when in operation, "after warm up; shortly after the ignition was turned off (without load)". I assume "without load" means with the OMP unplugged and the waveform is the output from the ECU?

Three very useful bits of information there:

1. Shape of the waveforms
2. The frequency of the waveforms
3. The peak voltage

Taking each in turn:

1. Not as I had expected. I have only a basic understanding of the signals required to drive a stepper motor, but this video shows exactly what I have set up to test the OMP, except I'm using an Arduino controller, instead of a Raspberry Pi



My output waveform to a typical coil looks like this:

These are "under load", but I'll take a look again at the waveforms under "no load" conditions. I'd be surprised if they are vastly different. Ignore the "glitch" 50% through the tops of the waveform, it's due to poor shielding of my wiring on my breadboard and breakthrough from the signal to another stepper coil. Note the waveforms in the Mazda data are much more complex though......

2. I was running my tester coil output frequency FAR too low, at around 10Hz. The Mazda document shows the cycle time is ~8ms, or 125Hz. If I run my tester at 125Hz (as shown in the waveform above, well 123.2Hz to be precise ) then the stepper motor will stall completely. In fact 40Hz is the maximum that I can use to reliably drive the OMP I have (the "failed" one from my car).

Is this a clue? Is the mechanical resistance of my OMP (through wear, ageing, corrosion or whatever) too much for the ECU signal to be able to drive the OMP armature, or....?

I really need a brand new OMP to determine how it behaves under the same conditions!

3. The peak voltage on the "OMP Control 2" signal is 35 volts at the leading edge!! I would expect some surge at the leading edge when driving an inductive coil with a sharply rising voltage, but the Mazda waveform suggests some sort of clever drive signal??

Anyone got any thoughts on what is going on?

Next steps (see what I did there ) is to:

- see what the waveforms look like under no load.
- test another failed OMP to determine at what frequency it fails to operate reliably

With reference to the latter, I have come up with some modified code to drive OMP's on test. The code does the initial maximum step test check, then displays the result. Using the maximum steps recorded (say X) the test then proceeds to step the armature backwards and forwards (X-3) steps continuously, looking for the position sensor to operate. If the sensor triggers, the test stops. If it does stop, this means the stepper must have stalled at some point, causing position errors which build up to trigger the sensor. Why (X-3) steps rather than X. By trial and error, if I set the range of "endurance" stepping at anything more, the endurance phase of testing will immediately fail. By dropping it down by 3 I have logged over a 1000 cycles with no failures (but at 40Hz, not 125Hz).

However, none of the above detracts from the theory that OMP failures are due to increased mechanical load, simply that developing a suitable test regime is more complex than I had envisaged.

[warpc0il]

The OMP control system has three modes;
- Initial Set Function
- Monitor Function
- Regular Drive Function

Plus the Fail-Safe Mode

They're all detailed in the Service Highlights document, that's in the Technical FAQ, which I'd assumed you'd already seen.

Just in casey, here's the related pages attached

Oil Metering Pump Control.pdf

(48.66 KiB) Downloaded 36 times

[HarSc]

Just in casey

[casey]

Yes, I've seen all of that data, which gave me enough information to design the Arduino based tester.

[casey]

I have ordered TMC2209 and A4988 stepper motor drivers to further explore driving the OMP stepper.

I have removed a stepper motor from my original "failed" OMP that I have been using for testing. What I have found is that I can't step it reliably above about 40Hz using my test setup, exactly the same as as with the stepper installed and driving the OMP armature. This implies the stalling of the stepper is not due to the mechanical load of the OMP mechanics, but the stepper itself - either the drive signals to the coils, and/or mechanical load inside the stepper (wear, corrosion.....).

I also tested another failed OMP and it also failed to step reliably above 40Hz (so, consistent), nowhere near the Mazda frequency of 125Hz.

I don't think my current driver chip, a ULN2003 (Darlington Pair transistors) is delivering sufficient current to the stepper coils. The 35 volt peak amplitude of the Mazda waveform is also looking to be critical to delivering an extra current surge to get the stepper to operate at 125Hz.

[casey]

I have now tested my stepper motor (removed from the OMP unit) and driven the coils using an A4988 driver. The result is the same, it will not step reliably above ~40Hz, well short of the expected 125Hz.

I have carefully examined the stepper motor and can find no fault - the coils clearly work (amd are within the resistance spec), the 2 bearings spin freely and there is no unusual mechanical resistance when assembled and spun by hand.

As I said above:

The 35 volt peak amplitude of the Mazda waveform is also looking to be critical to delivering an extra current surge to get the stepper to operate at 125Hz.

I'll have to see if I can design a driver circuit to closely mimic the Mazda 35 volt peak drive waveform....

[casey]

I managed to get hold of an RX-8 ECU and dismantled the housing to get to the PCB.

That allowed me to laboriously trace the OMP output pins on the ECU connector to identify the source component on the PCB delivering the OMP signals. It's a custom "Denso" IC, marked "151821-1280", a 20 pin SOIC device. I can find no datasheet or pinout for this chip though, despite a Google tesxt, Google LENS and AI search

It is the circled chip on this photo:

I have identified the drive signals to the OMP coils derive DIRECTLY from the 4 pins I have marked with small grey "splodges" (symmetrically positioned one pin in from the chip edges.

This chip has all the hallmarks of a "driver", with a large, inbuilt heatsink, thicker PCB traces to the 4 output pins, plus multiple ground pins to handle the current to the coils.

[qwakers]

you are correct, it is a driver circuit, googling tells me its commonly used for egr circuits on subaru's and hino trucks etc.

the closest i could get to a datasheet was https://www.y-ic.com/pdf/ST/151821-1280.html

which is for a generic version of the chip, but no link for a datasheet was forthcoming, maybe if you contact them they may be able to help?

[casey]

I don't think there is any hope of getting a datasheet for these ASIC's. There is absolutely no generic data anywhere online for the "base" (now obsolete) 151821 chip, which looks like it was mask programmed to meet each customer's specific requirements. A dead end.

My only hope now is to get hold of a brand new Mazda OMP to test and see how it differs from the "ECU condemned" OMP's I have tested. However, at £800, it's not going to happen.

I'm still convinced that a dismantle, thorough mechanical clean of all OMP parts, plus new seals OUGHT to restore a "failed" OMP. This was claimed to be the case in several Facebook posts. At first I was highly sceptical, but now believe this to be true.

However, I'll really need to ensure my tester can truly distinguish between a good and bad OMP and, at the moment, this is not the case - unless the OMP has a "gross" failure.

[HarSc]

My only hope now is to get hold of a brand new Mazda OMP to test and see how it differs from the "ECU condemned" OMP's I have tested. However, at £800, it's not going to happen.

I presume the testing here is not destructive/disassembly?

I do have one brand new in box here