Het is uiteindelijk zoals altijd met PID regelingen... one way the find out.

Yep. Morgen maar eens wat rijden.
Al ben ik bang dat de wet van behoud van ellende van toepassing is.

De kwaliteit van de regeling wordt in hoofdzaak bepaald door de snelheid van het mechanische systeem.
Dus zoals je al stelde: De snelheid van de wideband.
Maar ook de snelheid waarmee het mengsel zich door de motor verplaatst. Meer toeren is simpelweg een betere regeling.

Om verder de gedachte te bepalen.

Als de motor loopt wordt door de microprocessor steeds een, ik noem het maar, main running loop doorlopen.
In de loop vindt er 92 maal een aanroep van een routine plaats (lcall), de helft daarvan is naar een zelfde routine die dus 46x per loop wordt aangeroepen.
(deze routine wordt om om om met 1 van de andere routines aangeroepen);
In deze routine wordt telkens de Lambdasonde uitgelezen.

Per main running loop wordt telkens 1x een loggingframe uitgezoenden.
Ofwel bij een logging framerate van 25/ sec  (zoals in het lagere toerengebied) wordt de lambdasonde 25x46 = 1150/sec aangeroepen, ofwel om de 0.86 ms !
Bij hogere toeren, waardoor dus vaker per seconde de main loop door interrupts veroorzaakt door de vliegwielsensor onderbroken wordt, kan de framerate zakken naar zoiets als 12/sec.
Dan wordt de lambdasonde dus altijd nog 12*46= 552 maal uitgelezen, altijd dus nog om de 1.8 ms !!

De lambdasonde wordt dus ergens om de 0.8 a 1.8 ms uitgelezen.
Ter indicatie: bij 7000RPM draait de krukas in 1.8 ms slechts 75 gr rond er vind dan hooguit 1 ontsteking in die tijd plaats bij 7000 RPM.

De sonde wordt dus meer dan snel zat uitgelezen, de beperkende factor wat betreft de deadtime in de PID is dus de sonde zelf.
Er zijn controllers waarvan de maker beweert dat die om de 5 ms worden uitgelezen, wat dus een feedback snelheid geeft van het systeem die ook nog steeds meer dan snel genoeg is
Daar moet het PID systeem op afgestemd worden.

Duidelijk verhaal en duidelijk verwoord. Ik verwacht als ik de getallen met de huidige Spartan 1 zo zie dat er niet veel verbetering meer in zit.

Op zich is het zoals de fueling nu is goed. Meer dan goed zeker als je het vergelijkt met de oorspronkelijke narrow band regeling.
Je mod heeft ons een smoother maar ook snellere wagen opgeleverd met een sterk verbeterde controle over de AFR/lambda waarde.

Beiden weten we wat goede exact gedoseerde fueling doet qua gevoel en vermogen.
Ik sta zeker open voor het vervangen van mijn wideband door een sneller exemplaar, al speel ik ook met de gedachte zelf wat te brouwen qua sonde en controller combinatie.

-edit- Je duidelijke post laat zien dat middels een snellere, veel snellere sonde er heel veel moois te bereiken is qua regel kwaliteit!

Als tussenweg hebben we de oem vesie met open source software besteld van 14point7.
Om te bezien of we met aanpassingen van de firmware/software wat kunnen bereiken.

Interessante gedachte.

Piet en Yits, jullie kunnen het heel duidelijk uitleggen, bedankt.

Carriere in het technisch onderwijs als volgende stap?

Het echte werk komt nu toch echt van Piet hoor!

NOOOO........jij weet veel meer van PID regelingen dan ik.
Daarom laat ik dat ook min of meer stiekum aan jou over ...  

En de firmware van de oem controller laat ik weer over aan Maarten, so...

Heet dat teamwork?

Gaan jullie samen voor de klas staan

Ik zit even die code te bestuderen...

Naar mijn bescheiden mening een iets te simplistische anti-windup implementatie van de integraal actie. Gewoon een keiharde clipping van de integrator.

Veel beter is de methode waarbij je stopt met integreren als deze geen effect meer heeft op de uitgang. Dan hoef je niet eerst een half uur een integrator leeg te laten lopen voordat de uitgang weer eens reageert. Is een paar regels code en de integraal werkt dan zoveel mooier.

Heeft ie die aparte opwarm routine ook niet nodig, die er waarschijnlijk in zit omdat er anders massive overshoot zou zijn vanwege de veels te vol gelopen integrator.

Citaat van: jeroen74 op 04-11-2015 22:16:29
Ik zit even die code te bestuderen...

Naar mijn bescheiden mening een iets te simplistische anti-windup implementatie van de integraal actie. Gewoon een keiharde clipping van de integrator.

Veel beter is de methode waarbij je stopt met integreren als deze geen effect meer heeft op de uitgang. Dan hoef je niet eerst een half uur een integrator leeg te laten lopen voordat de uitgang weer eens reageert. Is een paar regels code en de integraal werkt dan zoveel mooier.

Heeft ie die aparte opwarm routine ook niet nodig, die er waarschijnlijk in zit omdat er anders massive overshoot zou zijn vanwege de veels te vol gelopen integrator.

Volledig mee eens    _{(het is dat het in het Nederlands is, dan kan ik het nog lezen. Maar begrijpen ho maar........)}

Uuuh, welke code zit je te bestuderen Jeroen?

Deze code

Ah juist, de code van de controller.
We hebben er hier nog niet naar gekeken. Het ding is nog onderweg.
Wanneer ie hier is gaan we daar es mee aan de slag