View unanswered posts | View active topics It is currently Sat Dec 16, 2017 2:02 pm



Reply to topic  [ 15 posts ]  Go to page 1, 2  Next
Bench Testing Code (outputs, math and injectors) 
Author Message
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14913
Location: Home sweet home!
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!


Thu Jan 13, 2011 11:13 pm
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Wed Jul 09, 2008 3:15 pm
Posts: 360
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.

_________________
BenFenner's 1994 Black SE-R
BenFenner's 2000 Black M-Coupe


Thu Jan 13, 2011 11:20 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14913
Location: Home sweet home!
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!


Thu Jan 13, 2011 11:27 pm
Profile WWW
QFP80 - Contributor

Joined: Thu Oct 30, 2008 10:35 am
Posts: 62
Location: Benschop, Netherlands
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 ?


Fri Jan 14, 2011 3:51 pm
Profile
Post Whore!
User avatar

Joined: Sat Feb 16, 2008 12:11 am
Posts: 629
Location: Sunny San Diego
So, er... You want to use one TA card to be an engine simulator for the printed cards we're all getting?


Fri Jan 14, 2011 7:23 pm
Profile ICQ YIM
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14913
Location: Home sweet home!
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!


Fri Jan 14, 2011 9:54 pm
Profile WWW
DIP8 - Involved

Joined: Fri Dec 24, 2010 5:04 pm
Posts: 19
- 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.


Sun Jan 16, 2011 4:33 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14913
Location: Home sweet home!
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.

Quote:
- 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.

Quote:
- 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?

Quote:
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!


Mon Jan 17, 2011 2:01 am
Profile WWW
Post Whore!
User avatar

Joined: Sat Feb 16, 2008 12:11 am
Posts: 629
Location: Sunny San Diego
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.


Mon Jan 17, 2011 6:05 pm
Profile ICQ YIM
LQFP112 - Up with the play
User avatar

Joined: Thu Sep 10, 2009 9:23 am
Posts: 244
Location: Dayton, OH
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-characterization.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.


Mon Jan 17, 2011 6:31 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 15 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.