Electronic valve control project

[Wiglaf]

I was going to suggest that blocking coolant flow was a bad plan, but your 6 stroke link answered that

Interesting stuff. I'm very much looking forward to seeing your progress.

Admin.

I don't want to rely on that, the coolant stays.

[Fred]

I am not blocking off oil and coolant to the head, I anticipate needing to cool and lubricate the coils.

DOH, that is the second time today I missed out a "negative" word like that...

My apologies.

[rsafier]

I've been talking with Wiglaf about this project for a while now. I am a software developer and just a general tinker, understand basic electronics but not much more then that.
As far as timing 1* would be bare minimum, 1/10th would be a lot better. Processing power really is dependent on how complex you want to get. Simply emulating a camshaft doesn't take much, tho the strict timing requirements require a fairly decent clockrate. At 6000rpm you only have ~28 microseconds per degree of engine revolution. Unlike a missed spark or a fuel injection event the results of a misplaced valve tend to be a lot more destructive
Jitter has to be kept to a very very small number. As timing input is critical something more along the lines of an absolute optical encoder seems like a good idea.
Now if you want to get fancier (which is the whole point), then you might want to do some somewhat complex math based on other engine inputs to adjust the duration and timing of the valve events dynamicly to support cooler ideas like 2-stroke operation on the fly, 6-cycle, etc. And do this within the timing requirements.
I figure bare minimum would be something like 80 MIPS processor, that would get you ~2000 instructions per degree @ 6K. Of course that ignores intrupts and all that fun stuff. But luckily CPU power is "cheap and easy" to get. The hardware is definately the harder part.
There is one company that seems to have a commerical product out there http://www.sturmanindustries.com/

[ababkin]

Besides having a fast processor, i think you guys need to come up with (possibly multiple) "foolproof" safety-nets to ensure that the valves never hit the pistons.
If i was designing the system, i'd try to come up with a very simple separate standalone mechanical/digital mechanism to ensure the touch never happens.
For example: knowing the clearances, determine the maximum latest point in terms of crank angle for valves to be open (and maximum earliest point, at which they can open). If the system hits this latest point and the safety-net still sees the valve open - close it at once (and force it closed, by overwriting the EMS's signal, for anything before the maximum earliest point).
Of course my example treats the model as a binary state (open/close), so one will need to treat the continuous model slightly different. (i.e evaluate a maximum latest function that takes the lift as the argument)

Having this safety-net may mean another microprocessor, but i think it's worth it for the peace of mind.

Mechanically and sensing-wise, you guys need to make darn sure that the crank angle measuring solution is BULLETPROOF, as you understand that if it should fail, then no digital safety-net in the world is going to save the engine from chewing itself up. I cannot suggest much more specifics on this though.

For the main EMS, I would definitely dedicate one core just for the tach wheel decoding (with no other interrupts standing in the way and delaying things), or use interrupt priorities if available to assign the highest priority to the tach (while preempting all others).

I also want to add that while developing EMS for this system, you guys definitely need to test the heck out of it before running it on the live engine. <shameless plug> I am working on an engine simulator (freeSim) for similar purpose </shameless plug>
I can also suggest a good eval board for the safety-net duty: http://www.silabs.com/tgwWebApp/public/ ... F120DK.htm (same one i plan to use for freeSim)
Although 8bit, it provides 100MIPS and costs $50 for bare board.

[Wiglaf]

it's a good concern. Other than the spring return as a fail safe for losing power, there isn't any other hardware fail-safe in my design. I'd have to think about what you said to try and add more but it sounds like an overcomplication.

I had originally planned on just having a table that would represent where the pistons are, so that no matter what the hell crazy stunt valve equations you came up with, the result would get clipped by the safety table. If the angle/tach input screwed up then.. i guess it would be like breaking a timing belt. It may not be quite as catastrophic though since a cam+rocker is mechanically solid, and here a piston would overpower a magnetic field.

[ababkin]

indeed it is an overcomplication just like any other safety-net. Your safety table idea sounds similar to what i was suggesting, but if you run that table on the same core that does a bunch of other stuff, there is a chance that the safety critical stuff may get delayed or corrupted by other less important stuff. This is why i suggested having a separate (appropriately beefed up) circuitry and MCU core just for that.
The idea obviously is eliminate the failure points, and this will reduce/eliminate it on the digital hardware level, not just on firmware level as you've suggested with a safety table algorithm. Add a dedicated toothed crank wheel just for this safety hardware (with an optical sensor?), and you've got another level of safety.

more complex? yes. Upside is that this safety system will be relatively standalone and independent from the EMS used.
Hmm, i guess you can even run the whole cam control algorithm on that separate beefed up system and have all the other calculations (ignition/injection related) on an EMS (can even start with the original motronic really for the EMS).
Just shooting ideas around.

Let us know what you guys will cook up in the end.

it's a good concern. Other than the spring return as a fail safe for losing power, there isn't any other hardware fail-safe in my design. I'd have to think about what you said to try and add more but it sounds like an overcomplication.

I had originally planned on just having a table that would represent where the pistons are, so that no matter what the hell crazy stunt valve equations you came up with, the result would get clipped by the safety table. If the angle/tach input screwed up then.. i guess it would be like breaking a timing belt. It may not be quite as catastrophic though since a cam+rocker is mechanically solid, and here a piston would overpower a magnetic field.

[rsafier]

Yeah I mean having a complete 2nd processor just for that task is overkill. Assuming the firmware is bug free then it should never hang or get into some endless loop were it would run past whatever its execution time should be, in the case of keeping 1* accuracy at 6K that would be 28 microseconds. If so no issues. Lets say the power fails, well everything just shuts off. I don't think so long as the software is decent that it would be any less reliable or risky then a timing chain/belt that can strech and eventually break.
For the accuracy of timing we are looking at a 60-2 tooth wheel probably ain't gonna cut it. I've seen one place claim that they can get down to ~.3* accuracy out of it, but still there is 6* of physical rotation between the signal were its all just calcuated and a "guess". The cost of a high accuracy optical encoder is on the level of 200-300 bucks so not exactly an item you want two of. Even just something like an LT1 distrubutor is a $500 item, tho it does have a nice percise 360 pulse output per rev. Plus a low-res channel giving a fairly accurate calculated 720 pulses per rev before any software trickery.

The phase I would most likely just be something like a "cam-controller", it might help avoid extra things to go wrong. Of course it might be hard to start on something like that, that remains to be seen. I think the most complex phase of the computer control is startup. From a standstill unlike a cam which is directly connected you don't really have a point of reference, unless its stored, which is iffy at best. So most likely you'd want to start spinning the motor with valves closed or just slightly open just enough to avoid any contact but allow for no compression to aid in starting then once you get a stable speed begin your full control loop.

[GartnerProspect]

FWIW, F1 cars don't you pnumatic actuation for the valves, just pneumatic valvesprings and a traditional cam. The compressed nitrogen design is lightweight enough to make 15krpm possible. But it requires an onboard cylinder of gas because the seals aren't perfect.

However, I've been going over this very same thing for the past month or so. But all my research turns up dead ends and lost interest. The 6-cycle concept is what made me realize the great benefit of electronic actuation.

If you're able to seamlessly switch from 4 to 6 to even 8 cycle operation you open up a world of possibilities. Nevermind the nature of variable intake/exhaust actuation that makes it so appealing from a performance AND economy standpoint.

I theorized that the best way to start would be with a non-interference flat plane two-valve-cylinder head, one or two cylinder. You'll have no chance of valve-valve or valve-piston carnage, which I'd say is a very reasonable place to start.

[AbeFM]

Patents may be an issue, but that's why I was suggesting rotary valves, or some sort of slide-device, maybe start with a ducatti or something else set up for such. Controlling those electrically would be easier....

[GartnerProspect]

I can't admit I'm familiar with rotory valves used in 4-strokes. Just some two-strokes like Rotax. Any links and pictures?

This stuff is so interesting. Patents really only affect commercialized products, doesn't stop any of us from tinkering!