idle IM_AUTO fixes and development.

[stefanst]

It may very well be that idle for automatic needs to have the equivalent of 'fast idle valve' to work properly. CL may not be sufficient to deal with the associated problems gracefully.
Since I'm terribly unfamiliar with the automatic transmission on Miatas, is there any information to the ECU that indicates what state we're in? Idle up needs to happen in "R, D, L" and not in "P" and "N". Which kinda sucks, because with P-R-N-D-L we go for idle "Low-High-Low-High-High".

[AndreyB]

Since I'm terribly unfamiliar with the automatic transmission on Miatas, is there any information to the ECU that indicates what state we're in

Looks like there is maybe one data link wire - http://rusefi.com/wiki/index.php?title=Vehicle:Mazda_Miata_2001#Automatic_Transmission - AL - "Communication with ECU". What's on this wire who knows

[stefanst]

There's also 4Z (pnk/blk) and 4AC (vio/grn) which connect ECU and AT module. No idea what they do, but a voltmeter may be of assistance....

[kb1gtt]

Can you set the valve manually such that you know what your output should be for each of those conditions? If you average the outputs, you can set that as the offset, then the PID is only dealing with the changes, not the offset.

[stefanst]

Can you set the valve manually such that you know what your output should be for each of those conditions? If you average the outputs, you can set that as the offset, then the PID is only dealing with the changes, not the offset.

You're usually going from one settled state to the other state. So your I-term already modified your offset to reflect steady-state in the previous state. In other words: the offset is only ever important once- when you enter CL. After that the I-term takes over.

[kb1gtt]

Correct, however you have to wait for your I term to wind up or wind down. I suggest considering this approach to tuning PID.

-- Tune P term until stable, pick a P term based on magic and your gut. You may pick something that is just barely stable, or you may pick something that is perhaps 50% of your stable P term. Any how, pick a P term.
-- In your typical state, check how far off you are from your target. Set your offset to compensate for this, such that your output is dead on, AKA I value = 0.
-- Add a load or change the systems such that you are at an extreme condition, then increase your I term until the I pulls you back down to 0 error.
-- Check dynamic issues with large offset / step responses. Use D term to minimize ringing and increase stability.
-- Write down your results, then start over with a different P term. Keep doing this process until you have terms you are happy with.

By using the I term like this you avoid the need to wind up and wind down your I term. Also adding a band around your target helps. Such that if you are outside this band, the I term is automatically put at 0. You only use the I value when you are close-ish to your target. Basically if your P value is 100%, then your I value should be 0.

[Rhinoman]

Which transform are you using to move from continuous time to discrete time?

[kb1gtt]

We are not dealing very well with Z vs S domain. The digitizing noise could cause problems, or induce errors. For now we generally have over sampling such that the Z is very close to the S, this keeps the errors induced by Z domain minimal. We should be far from Nyquist. There is room for improvements of the Z domain black magic math. For now the induced errors seem to be small enough that they are negligible.

[AndreyB]

Once again I am enjoying PID tuning:

https://svn.code.sf.net/p/rusefi/code/misc/logs/2003_mazda_miata/20170722_idle_pid_p_0_7.7z

[video]https://www.youtube.com/watch?v=c8enThbIdtI[/video]

[kb1gtt]

which debug fields did you use?
http://rusefi.com/wiki/index.php?title=Manual:Debug_fields

I was looking to rename them in the log file, such that they display what they are in the log viewer, but I see several different options. I think you used something close to alternator debug values, but I don't know what you used.

[AndreyB]

Just added more info for "IDLE" mode which was used here http://rusefi.com/wiki/index.php?title=Manual:Debug_fields with a small correction

"Idle Air Valve" is in the logs as a named field.

[AndreyB]

@ reminds us about Comparison of PID Controller Tuning Methods by Mohammad Shahrokhi and Alireza Zomorrodi

https://en.wikipedia.org/wiki/Ziegler%E2%80%93Nichols_method

[AndreyB]

MS logs have better debug field names now, todo: use same better debug names in rusEfi and console logs.

@ has stopped by and we were able to get some pretty usable idle PID values!

At first we have assumed that period 10pm/100Hz is too fast, we've (wrongly) assumed that changes do not happen so quickly so we've spend some time trying to tune with period=200ms/freq=5Hz. Well, that' was wrong - period of 10ms or 50ms works better, you see much less oscillation with the same P parameter (I=D=0).

Tune session https://svn.code.sf.net/p/rusefi/code/misc/logs/2003_mazda_miata/20170723_12.41.35_idle_pid_tune_in_progress.msl.7z
End result & ride around the block log https://svn.code.sf.net/p/rusefi/code/misc/logs/2003_mazda_miata/20170723_great_idle_pid_tune_and_ride.7z

Even with offset of 0 things are pretty nice!

Next steps: period auto-tune, PID parameters auto-tune like for instance in https://github.com/MarlinFirmware/Marlin/blob/1.1.x/Marlin/temperature.cpp#L222

[Abricos]

You want use marlin 3d printer firmware ...)))

[stefanst]

Does anybody have any ideas/input on the subject of control-loop frequency tuning?

My basic idea is that there is no point in running the control-loop faster than the process we're controlling can react. So any process with a lag-time, we don't need to run it more often than the lag-time would prescribe. For example CL control of exhaust O2: Depending on engine-load, it takes the exhaust gases from the combustion a certain time to make it to the O2 sensor. The sensor itself also has a small, inherent lag-time. It doesn't make any sense to run the algorithm again until the results of our changes made had a chance to actually propagate to the point of measurement.

Are there any papers/advice on this subject out there in the data-ocean of the internet that deals with this subject? Any advice?

[AndreyB]

Does anybody have any ideas/input on the subject of control-loop frequency tuning?

Let's continue in http://rusefi.com/forum/viewtopic.php?f=5&t=1256