gemellocattivo.com

Which means "Evil Twin". Lets see your projects where you change boring into fun or create the fun from scratch.
It is currently Thu Mar 28, 2024 9:02 am

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Mon Oct 17, 2016 12:26 pm 
Online

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
I decide to do 2 things.

1) switch to a state based logic. This is pretty common in programming and can make tracign errors a bit easier so Im building this in.

So far I have:
State_Engine (not running, cranking, idling, Running, over-rev)
State_ETC (error, cranking, stall Saver, Idle, Traction Control, Normal)

I'll play with this some more probably.

2) I also spent some time thinking about how important and how fast everything really needs to be. I had it all in in 1 big loop that just ran as fast as it could but that does stuff like deciding is the cooling fan should be on WAAAAAY more often than is needs which slows down other stuff.

So I created thread at 1msec, 5msec, 10msec, 25msec, 50msec, 100msec, 1sec, 5 sec.....but I think I'm going to kill the 5sec and create a second 10msec for stuff I want fast but is not engine critical to keep the loops smaller/faster. Now the way this thing works is you set the sleep time not the run time so the timing is approximate and I may play with the sleep times a bit once I see how it's sort of working out.


My goal is to be sure fuel and spark are calculated at least every engine cycle....every 12msec at 10k. Maybe add trims every other cycle I guess because they use much rougher tables and don't change as much....every 10th would probably be fine. Cooling fan once a sec probably....just spread everything out.


Top
 Profile Send private message  
 
PostPosted: Tue Dec 13, 2016 3:08 am 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
States are an interesting topic.

1a. Keeping track of the engine 'state' is a good idea. I have 3 states (stall, crank, run), called EngineOpMode. These are mostly used to track timers and switch crank vs run tables. Idle, run, and over-run are not separate states at all for mechanical throttle software, and are part of the ETC state for ETC software, instead of including them in the engine state. I chose to limit the number of states here because EngineOpMode is mostly used to see if the engine is running or not.

1b. For ETC I have tried two methods. In one case, I first determine which state to utilize, output the state, and then select the calculation results based on the state. For this, I have Stall, Crank, Idle, Idle-1cyl (for a 2cyl, which idles on only one), Power-On, Power-Off, and DFSO. Based on EngineOpMode, pedal value, RPM, and ECT, I select the ETC control mode ID. I also latch the last mode, and keep a timer of time since the mode was switched. This is used to handle transitions in some cases. Each mode has a block to calculate TPS, desired Phi/power enrichment, spark map to use, and a vector of which cylinders are enabled. The last-mode and timers are used to soften transitions between some states (e.g dropping a cylinder, and rewetting one cylinder at a time).

1c. The second method which I am trying now for Diesel is to calculate the requests from each mode first, and then determine the state. Each block outputs a torque request only, or a min and max request. All of the positive requests are run through a MAX block, then all of the limit requests through a MIN block, and the final torque is determined. I then back-calculate which input was used, for probes. The positive requestors I have are pedal and idle. The limiting ones are over-rev, over-speed (MPH/KPH), power curve shaping (a table to set the maximum torque vs RPM), and soot limiting (calculated from airflow). Diesel software, at least compared to ETC, is a bit simpler because the torque request is directly converted to a fuel mass request and commanded immediately, without any transient delays or compensation required for ETC and port fuel injection.

Task rates:

2. I currently have three task rates with the Woodward modules, TDC, 5ms Foreground, and 20ms Background. The first can pre-empt the other two, and the second can pre-empt the third, so the BG task may be interrupted several times if the engine is spinning fast enough. I can define tasks at multiples of the FG and BG rates, but they are just implemented as a counter which skips n iterations.

If you don't need the CPU bandwidth it's not worth messing with, or using very few rates. The system I currently work on professionally does everything at 20ms. Another system I worked on before did 1, 2, 2.5, 7, 5, 10, 20, 40, 80, 160, 320, 640, 1280, and 2560ms tasks, with different 'stuff' in each one.

Since I don't think you're having CPU load issues, you could probably have very few tasks. Probably Core Engine (5ms/once per cycle), 10ms for ETC, 50ms+ for everything else. What kind of non-engine features are you planning (cooling fan, ....)?

For your trims, can you select which table to interpolate each interval and do one of them each time (e.g. every fuel/spark calculation, run the individual cylinder calculations for one specific cylinder, so each cylinder is calculated once per 12 calculation cycles)? This way you could calculate the trims for whatever cylinder will spark next. You could also do all of the transient calculations (puddle accumulation/depletion) only for one cylinder at a time, whichever cylinder you just fueled or are about to fuel. My Woodward system won't tell me which cylinder it is on (the TDC task doesn't say which cylinder is at TDC), but I only have two cylinders to calculate worst-case so I do them both every iteration. Since you have 12, splitting them up somehow might be beneficial.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
PostPosted: Tue Dec 13, 2016 9:18 am 
Online

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
Welcome back.

In EL there are 8 tasks available and I can assign them a sleep time...this is NOT a run time. So 5msec sleep means it runs, waits 5msec then wakes up and enters the que to run again but can not interupt anything, it must wait in line so if its last in line the time could be 8 or 9 or 10 msec as the whole model runs.

So my though in using all 8 threads and 2 separate 10msec thread was to reduce the chance of long waits as much as possible. At 10k rpm there is 12msec between cycles....so 9 or 10 seems the right number to calculate the fuel and spark. I put the Trims on a 25msec, so every other cycles worst case. ETC is on the 10msec.

I put the cylinder O2 reading on a 5msec....I might make that a 3 or 4 though to get better readings are higher RPM. This works by reading a NBO2 in the 3 cyl collectors and assigning the reading to the correct cylinder. These have about a 1-2 msec responce time, so 3 msec is probably the max it would mean anything and would still get me a reading for every cylinder every cycle with the latency added in.


Top
 Profile Send private message  
 
PostPosted: Tue Dec 13, 2016 12:20 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
Since the tasks have a sleep time, not a run time, would you be able to calculate the sleep time based on the execution time (possibly for the last iteration)?

Motohawk only has 3 tasks (FG Angle, FG, BG), but the library abstracts this and gives me a bunch of tasks which are multiples of FG or BG, and the Angle task is more flexible. So it appears like there's an FG RTI, RTIx2, RTIx5, RTIx10, ... and when it gets autocoded to C it generates a FG scheduler which skips iterations for x2, x5, x10, etc. The tasks are run-time based and not sleep-based.

For the 10ms task, what else is being processed at 10ms that would not be ETC related? The only things I have which aren't ETC related in my 5ms task are fuel pump control and eco-mode switch processing. I could put eco-mode in the BG 20ms task (but I didn't have a BG 20ms task when I wrote the eco-mode code), and the fuel pump control has hooks into the kill switch so it was easier to leave it in the same task.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
PostPosted: Tue Dec 13, 2016 4:15 pm 
Online

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
Ican't access the slepp time in the model, it needs to be set ahead of time. Once I have the model back on the ECU I can log the thread times and adjust the sleep times a bit if I need them closer to a real time......but I'm not sure it matters. I don't really count on thread run time for anything.

I have all the ful and spark calcs (minus the trims) at 10msec, that is on 1 thread.

On the second 10msec thread is ETC.....I think that is it at the moment.

25msec had trims, idle, Traction control (adding now)

There is a skip feature where you can have the item on the a thread but skip passes though in multiples of 2.....I'm not using this at the moment but I may once I get into testing.


Top
 Profile Send private message  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 4 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

Jump to:  
Powered by phpBB® Forum Software © phpBB Group