Bench Testing Code (outputs, math and injectors)

Official FreeEMS vanilla firmware development, the heart and soul of the system!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Bench Testing Code (outputs, math and injectors)

Post by Fred »

This code will consist of two parts:

Part one: A self generating wheel pattern decoder, possibly with programmable pattern
Part two: Ability to control ADC inputs artificially to test code and logic.

I can see different modes being useful.

IE, behave like a normal decoder and use the stock math/adc stuff and just generate an output pattern by faking an input pattern.

And, provide specific test patterns of outputs, such as:

Run for N seconds
Run for X cycles
Inject Y times
Use Z pulsewidth
Use M cycle time
Run at Q % duty

Then you could do something like "do 1000 injections at 85% duty with a 17ms cycle time" or similar.

Similar stuff for coils, probably, too, but later.

Thoughts, details, specs, what do you want to be able to control, tell me exactly, dont be shy, i can only go "too hard". Sky is the limit, JD, go!

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
BenFenner
LQFP144 - On Top Of The Game
Posts: 360
Joined: Wed Jul 09, 2008 3:15 pm

Re: Bench Testing Code (outputs, math and injectors)

Post by BenFenner »

So for part one you want a test wheel pattern generator?
Like with options to generate a simulated "output" from different OEM crank and cam angle sensors?

I'm so out of the coding paradigm right now I'd ask what kind of protocol/API you're using/providing but I'm not even sure that's a useful conversation for us to be having right now.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Bench Testing Code (outputs, math and injectors)

Post by Fred »

The idea is to behave exactly like there was an input applied to the RPM/Position sensors, just without one. Various patterns may/will be possible, one way or another. The input patterns varying matters for testing scheduler code. The output patterns varying (doable with any, even simple, input) matters for testing scheduler code and coils, injectors, math, logic, etc.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
DaWaN
QFP80 - Contributor
Posts: 62
Joined: Thu Oct 30, 2008 10:35 am
Location: Benschop, Netherlands

Re: Bench Testing Code (outputs, math and injectors)

Post by DaWaN »

So basically you want something similar to a JimStim but instead of simulating (most) of the stuff manually you want "the bench tester" to simulate an engine in a pre-programmed way to test stuff ?
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: Bench Testing Code (outputs, math and injectors)

Post by AbeFM »

So, er... You want to use one TA card to be an engine simulator for the printed cards we're all getting?
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Bench Testing Code (outputs, math and injectors)

Post by Fred »

No, Abe. I want to use the same two timers used for RPM/Position capture in internal mode instead of Input Capture mode, thus creating code events (which you can't see) and allowing normal scueduling of events from those events (which you can see) and testing almost every part of the code in isolation of external signals such as JimStim provides. I want to eliminate the requirement for the JimStim from testing. JimStim and real engines/sensors will only be required for testing the actual decoders then, more or less.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Joseph Davis
DIP8 - Involved
Posts: 19
Joined: Fri Dec 24, 2010 5:04 pm

Re: Bench Testing Code (outputs, math and injectors)

Post by Joseph Davis »

- a functional battery compensation table.
- a "jog" function, where I can manually press a button and continue the defined test for as long as the button is depressed. The idea is to fill one 100mL graduated cylinder perfectly, so deducing the other injector's flow from that is trivial.
- a timer for the jog button. Run time of N seconds plus used jog time will let me note approx how long to run a test of the same injector in the future.


If you want to fool with KS protocol, I am planning to deduce injector dead time by comparing delay from when the injector is energized to when it "clicks" open according to a KS mounted to the fuel rail. Entirely optional as I have a DSO I can do this with already. I'm not sure what is proposed for KS handling (hardware filter to an ADC, actual DSP, a mixture) but it might be a useful test environment.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Bench Testing Code (outputs, math and injectors)

Post by Fred »

Joseph Davis wrote:- a functional battery compensation table.
I'm curious about this. Of course the code will have this (it already does) but on the bench you could set duty to near zero and increase gradually until you saw fuel start to appear. That could be done with either a software pot or a hardware pot on a spare or misused ADC input (hw would be easier for initial tuning). Clearly the knock sense idea is better. Another good approach would be to watch the current across the injector with a scope, you can pretty easily see its characteristics from that.
- a "jog" function, where I can manually press a button and continue the defined test for as long as the button is depressed. The idea is to fill one 100mL graduated cylinder perfectly, so deducing the other injector's flow from that is trivial.
How about a software "stick on" button and a timeout for safety and another "stop now" button? Otherwise you'd need a binary logic hw input to achieve this safely, which is possible I just don't know which one or how to make it clean with the other real ems software integrated. I guess you CBF doing multiple runs to determine the exact period required, hence the request. Fair enough.

If you estimated 100ml would take 16 seconds and you set the timeout to 20 seconds and were poised over the PC "stop" button, clicking it when you hit 100, that should fill your need, right? It could then store the count or other data in a memory area ready for retrieval.
- a timer for the jog button. Run time of N seconds plus used jog time will let me note approx how long to run a test of the same injector in the future.
By timer, you mean measure how long the button was? Or the total? Or either as the other can be deduced? Or do you mean "press momentarily and it will run for 5 more seconds" type of thing?
If you want to fool with KS protocol, I am planning to deduce injector dead time by comparing delay from when the injector is energized to when it "clicks" open according to a KS mounted to the fuel rail. Entirely optional as I have a DSO I can do this with already. I'm not sure what is proposed for KS handling (hardware filter to an ADC, actual DSP, a mixture) but it might be a useful test environment.
It's not on the radar at the moment, sorry, but when it is, I'm sure you'll be involved :-) see earlier comment re current shape and scope for now.

This is obvious, but it'd be worth noting down what the possible variables are and what can/can't be controlled:

Voltage (could easily be fixed at a certain level, also quality of this, sag during cycles, etc)
Actual flow curves (to be determined)
Fuel pressure (also quality of pressure, dampers, rail design ,hose design, etc)
Fuel viscosity (use something fixed such as toluene, or normal gas, or e85, etc, possibly varies in a non linear way?)
Injector dead time (how long electricity is applied and fuel does not flow)
effective pw (how long fuel actually flows for)
total pw (sum of idt and epw)
duty (possible variation from heat generated)
period (possible electrical effects from varying frequency)

Did I miss anything?

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: Bench Testing Code (outputs, math and injectors)

Post by AbeFM »

It would seem there has to be an "effective dead time" - and you could probably get it pretty quickly by just running the test twice:

1) Open valve for 10 ms openings till you've filled volume X
2) Repeat with 1 ms openings
3) Trivial math.

I generally do my injectors this way, using the wideband, which isn't great, but it works much better than using any spec I've ever seen. I have seen people monitor the current to the injector (which I kinda like - you can actually SEE the pintle stop moving). If this could be calibrated, that seems a sensible way to go to me - especially since you can get an equivilent out of it by actual functional testing as outlined above. What's nice about that is you could do it real time.

One thing I've mentioned before is the closed-loop auto feedback method outlined above using the wideband. What bothers me about all of these is for very small amounts of fuel, the injector opening time can dominate, and it's not a negligible amount: 0.85 ms opening time, and a "target" open time of 0.5 ms. Hence the fuel flowing while the pintle is partially opens is important. This is why I like the current monitoring method: You can see the pintle move, and get some good feedback.

Anyway, getting a bit off-topic. I was wondering, on a more basic level - how will you test the code if the timers are busy??

Any advanced knock sensing would want timers I'd think. And it's something important.

Certainly something to put in missing or skewed inputs - i.e. noise.
User avatar
EssEss
LQFP112 - Up with the play
Posts: 244
Joined: Thu Sep 10, 2009 9:23 am
Location: Dayton, OH

Re: Bench Testing Code (outputs, math and injectors)

Post by EssEss »

AbeFM wrote:I have seen people monitor the current to the injector (which I kinda like - you can actually SEE the pintle stop moving).
Dynamic flow is no way related to this trick (or the knock sensor zip-tie trick). I spent some time on my own injector flowbench to prove it to a co-worker. Check this link for a little more insight: http://www.injectordynamics.com/dynamic ... ation.html

this guy does it right, and I've independently verified it - most people don't go to this extent, except ford and myself :D. Every single injector I've characterized exhibits the same behavior around opening which a static straight-line interpolation misses. If you use big injectors and low duty the error turns out to be pretty big - especially if you didn't characterize it wrt battv.
Post Reply