Projet 2014/2015 : allumage cartographique IGNIMZ compatible rupteur et capteur mz

Je ne sais pas pourquoi, mais je tenterais bien un essai de ton programme sur mon banc de test

voici les deux fonctions et l'affectation des variables correspondantes :
x est le régime moteur en tr/mn
y1 est le temps entre la fin du top capteur et la coupure d'alim de la bobine (l'étincelle quoi!) exprimé en ms
y2 est le temps entre la fin du top capteur et la réalimentation de la bobine (le debut de la charge) exprimé en ms
tu peux recopier direct les deux lignes de code dans ton programme, il y a même les ";" en bout de ligne

 //coefficients de la polynomiale d'ordre 3 obtenus avec la méthode dite de Ruffini-Horner
 y1=1.28325535+x*(-0.0008349+x*(0.00000016943+x*-0.00000000001047));
 y2 =57.4171145+x*(-0.0214077+x*(0.0000029453+x*-0.0000000001421));

normalement tu obtiens cela mais en plus lisse (pas d'effets de segments de droite comme dans la courbe théorique)

As tu comparé la courbe souhaitée et la courbe polynomiale ?

Moi j'obtiens cela avec ton équation de retard ????



Pas terrible la courbe réelle du retard : peux tu m'éclairer.
J'avais déja regardé cette option et j'arrivais (de mémoire) à la même conclusion, mais je peux me tromper.

pour la courbe réelle, l'allure que tu obtiens est bien la correcte. elle n'est pas si loin que ça de ce que l'on attends



alors si tu veux coller à la courbe de référence (rouge), il faut augmenter l'ordre du polynôme. avec un ordre 6 ça donne ça



le temps de calcul n'est pas trop augmenté si on garde la  méthode dite de Ruffini-Horner pour la transformation en somme/produit

y = 0,000000000000000000000582x6 - 0,000000000000000015926233x5 + 0,000000000000173225871332x4 - 0,000000000961445062745614x3 + 0,000002914866041095770000x2 - 0,004700547665609750000000x + 3,271247705024730000000000


devient
y = 3,271247705024730000000000 + x(- 0,00470054766560975+x(0,00000291486604109577 + x(- 0,000000000961445062745614+x(0,000000000000173225871332+x(- 0,000000000000000015926233+x0,000000000000000000000582)

là, je te la donne sans avoir testé le code. il faut faire gaffe au nombre de digits avec l'ordre 6 car tu as vite n'importe quoi si tu n'es pas vigilant. 24 digits c'est correct normalement

pour l'instant du début de charge, une exponentielle décroissante marche aussi bien, avec l'allumage carto, on se fout du dwell. c'est un héritage des vis platinées. le truc important c'est que la bobine soit suffisamment chargée au moment de l'étincelle... donc 5ms c'est bien. en plus ça consomme moins aux régimes bas et intermédiaires.

tu peux essayer ça pour y2

y2=57,604*pow(2.71828,-0.00042738*x);

en tout cas je suis content de voir que prog est compatible

la suite....

voici les deux lignes de codes testées

y1=3.27124770502473 + x*(-0.00470054766560975+x*(0.00000291486604109577 + x*(- 0.000000000961445062745614+x*(0.000000000000173225871332+x*(- 0.000000000000000015926233+x*0.000000000000000000000582)))));
y2=57,604*pow(2.71828,-0.00042738*x);

à substituer aux deux précédentes

le calcul à l'air de passer mais j'ai un doute sur la capacité de l'arduino à gérer 24 digits (y1 et Y2 sont déclarés en 'double' pas en 'long' ni en float.

après, si ça ne marche pas, il faudra trouver un solveur plus puissant que celui que j'utilise pour tenter d'avoir des équations plus simples avec moins de digits

Je vais consacrer quelques jours à ta méthode en utilisant un programme simplifié.
Nous verrons bien ce que l'ATMEL 328 sait faire.
Qu'utilise tu comme outi/logiciel pour obtenir ton équation polynomiale (excel est loin de suffire)

j'utilise excell mais je ne suis pas très content du resultat. je cherche en ce moment un outils plus performant qui puisse me donner des équations simples qui seront calculées par l'arduino.

je viens de réaliser une comparaison entre
ta courbe théorique en vert, du retard angulaire en fonction du régime moteur
la courbe expérimentale en bleu du retard angulaire en fonction du régime moteur
la courbe expérimentale en rouge du retard de l'étincelle après le top capteur



les équations qui ont été saisies dans l'arduino sont les suivantes

y1=3.27124770502473 + x*(-0.00470054766560975+x*(0.00000291486604109577 + x*(- 0.000000000961445062745614+x*(0.000000000000173225871332+x*(- 0.000000000000000015926233+x*0.000000000000000000000582)))));
y2=57,604*pow(2.71828,-0.00042738*x);

si tu me donne un série de points régime/retard, comme ceux des courbes que tu as déposées sur le fofo, je testerai l'équation ad-hoc

de toute façon, à ce stade du projet, je pense que les écarts relevés entre courbes th et courbes exp ne sont ni significatifs ni critiques. surtout quand tu sais comment les courbes th ont été déterminées... maintenant il faut tester tout ça sur un vrai moteur pour voir ce que cela donne en vrai

Oui tu as raison.

Je vais continuer à rentrer mes tâbles (c'est moins scientifique, mais je maîtrise mieux).
Excel ne peux pas servir et avec une interprétation de lagrange, je me suis rendu compte qu'on faisait vite des conneries (après 2 à 3 heures de luttes acharnée avec la bête).

Effectivement, il faut que je fasse une maquette : je vais très bientôt m'y atteler.
Je veux surtout rapidement savoir si je peux me passer d'un boitier métallique.

Ce soir, j'ai réalisé un petit programme simple pour utiliser mon microswitch de façon à pouvoir aisément changer de courbe.
J'ai également amélioré mon banc de test :



En bas la carte ARDUINO UNO supportant le microcontroleur qui équipera l'IGNIMZ.
En haut le microswitch et des accès pour réaliser les mesures en sortie, le coaxial délivre l'info capteur (fournie par un générateur de fréquence durant la phase de mise au point du logiciel)

Une led rouge indiquera probablement la sélection de la courbe 0 (déphasage nul sur toute la plage de fonctionnement et rapport cyclique de 40%)
Une autre led bleue sera probablement mise en place : elle clignotera à la fréquence de l'étincelle pour indiquer le fonctionnement de notre IGNIMZ.

Après avoir rentré stupidement quelques tables dans le programme puis fait un programme de lecture du switch, je me suis aperçu qu'il y avait plus simple que ce que j'avai prévu initialement :

Utiliser le chiffre (compris en 0 et 15) obtenu par lecture du switch de sélection de table pour le multiplier par une table de base de haute précision.
Je n'aurai qu'une table à rentrer (je vais augmenter les points à 260) et nous pourrons donc la multiplier par 0 - 1 ------15 pour réaliser nos essais.
De cette manière nous auront facilement 16 tables possibles

Les premiers essais ne sont pas mauvais

je t'avais conseillé d'utiliser les switchs pour l'adressage de tes points. après, tu peux ne faire d'une lecture lors de l'init comme tu le suggérais. par contre même si cela colle pour les protocourbes, je ne suis pas sur que les ordonnées des courbes réelles puissent être "multipliées" pour passer de l'une à l'autre.

une polynomiale?

niallof a écrit: je t'avais conseillé d'utiliser les switchs pour l'adressage de tes points. après, tu peux ne faire d'une lecture lors de l'init comme tu le suggérais. par contre même si cela colle pour les protocourbes, je ne suis pas sur que les ordonnées des courbes réelles puissent être "multipliées" pour passer de l'une à l'autre.

une polynomiale?  

Pour la lecture des switchs, j'ai secoué pas mal ma carte et rien n'a bougé, donc j'ai logé la lecture dans le programme loop (programme principal)

Tu m'as foutu la migraine avec la polynomiale (trop de chiffre et trop de conneries si on se gourre !!!) mais on y viendra peut être.

Il faudra aussi que je regarde ton équation pour la durée (quoique placer une deuxième table dédié durée pourrait être pas mal !!, actuellement je fonctionne avec une équation qui me fourni un rapport cyclique de 40% (pas top à hauts régimes puisqu'on charge peu la bobine !!)

Je vais d'abord  optimiser mon programme : passage à 260 points de la table + définitions de 2.5us du pas minimum (à la place de 130 points et 5us) + relevé des courbes pour voir si c'est nickel.

Il y a encore l'histoire du chien de garde à voir (reset toute les 2 secondes, si rien ne se passe par exemple) : il faut que je tranche entre un le chien de garde de l'ATMEL328 ou bien faire un truc un peu plus propre (genre monostable retriggerable).

Bref, encore pas de mal de boulot  

je ne pense pas qu'il faille se prendre la tête pour le moment entre tableau et polynomiale. surtout que les courbes sur lesquelles nous travaillons restent des courbes complétement approximatives. disons que nous avons une bonne idée de la gueule que ça doit avoir mais qu'on ne sait pas précisément la position des points.

en plus, les capteurs dont nous disposons, associés aux jeux mécaniques et à la prise de mesure du point mort haut nous donnent une précision de l'ordre du degrés.

un site pour les polynomiales

http://www.xuru.org/rt/TOC.asp

ma dernière poly : un ordre 8 avec moins de 0,5 degrés d'erreur sur tout l'intervalle



les polynomiales ou tout autre système d'équation présentent plein d'avantages
- un temps de traitement réduit et constant (0,45 us de traitement pour les deux valeurs. celle de l'étincelle et celle du début de charge)
- un espace mémoire réduit aux polynomes (9 termes pour celle du dessus...)
- peu de valeurs à saisir

par contre, pour que cela soit éfficace il faut beaucoup de points...

après il faut que tout le reste fonctionne...

pour le rapport cyclique ou dwell, je t'ai donné l'équation du temps de charge en fonction du régime qui t'assure 5ms de charge minimum. il est inutile de se fixer un dwell de 40% ou 70%. ce truc est une survivance de l'époque des vis platinées qui fixent un dwell constant quelque soit le régime moteur. avec la commutation pilotée de la bobine, il vaut mieux privilégier une charge satisfaisante (sans faire fumer la bobine bien sur). en plus tu économise ta bobine à bas et moyen régimes puisque tu ne l'alimente que 5ms sur 30ms à 2000 tr/mn. cette alimentation réduite de la bobine est importante à bas régime car c'est là que l'alternateur ne charge plus trop...

0.5 degres equivaut a 0.15 mm de variation sur le point dallumage ??? pour un 250 !

ben oui, c'est ce que je dis. même si graphiquement on s'éloigne de la courbe de référence, on s'écarte physiquement si peu qu'on s'en tamponne.

les chercheurs du forum sont dans une situation complexe
la chose n est pas simple
je pense que beaucoup , comme moi , souhaitent vous voir aboutir a des resultats

Non non, ce n'est pas si compliqué.
Il y deux théories qui émergent :

- soit piocher dans deux tables comportant chacune un certain nombre de points (une table pour le retard et une table pour la durée) et accepter qu'il y ai un peu d’imperfection (ce qui se passe entre deux points de table : légère erreur mesurée de 0.5° qui peut être divisé par 2 en multipliant le nombre de points de la table de retard).
C'est ce que propose votre admin adoré

- soit calculer à partir d'outil mathématiques les deux formules (celle du retard et celle de la durée) et les introduire dans le programme.
Cela présente l'avantage de ne plus faire d'approximation puiqu'il n'y a plus de points mais un calcul directement lié au RPM mésuré. Mais ces courbes présentent aussi des difficultés et une erreur égale aussi à 0.5° pour un ordre 8 (c'est à dire une équation comportant 8 coefficients)
C'est ce que propose Niallof qui semble mieux connaitre le sujet que moi

Pour les deux méthodes, il restera possible d'introduire plusieurs courbes, mais avec la mienne, en obtenir 16 d'un coup est enfantin.

De toute façon, quand le produit sera terminé, il sera toujours possible de changer de méthode (c'est ce qu'écrit également Niallof, car le microcontrôleur est programmable 100000 fois !!.

disons que le équations des courbes permettent un traitement trés rapide par le micro. pour passer d'une courbe à l'autre, seuls les coef des polynomes changent. pour une polynomiale d'ordre 8 il n'y a que 9 termes par courbe. par contre je ne suis pas encore satisfait des allures de courbes. de toute façon, traditionnellement, c'est un tableau de valeurs qui est utilisé, sans doute qu'il y a sans doute une raison...  



une troisième piste consisterai à utiliser des segments de droites pour caractériser les courbes à ce moment là on a des équations simples mais un temps de traitement différent selon la zone de la courbe et selon le nombre de segment de définition.

Ca c'était le plan C (un de mes collègues m'avait soufflé la solution).

Cet après mid j'ai fait des test de rapidité.

Pour réaliser : q=q+1  j'ai mesuré 0.6us
Es tu sûr de ton coup pour le temps d’exécution de la polynomiale ??

oui oui, voici le code. tu peux faire un copier coller. je fais 10000 fois les deux calculs et je reviens au temps unitaire. tu peux mettre ton q=q+1 dans la boucle

int led = 13;
// regime moteur [tr/mn]
double x;
// y1 :retard entre l'étincelle et le top capteur
double y1;
// y1 :retard entre le début de charge de la bobine et le top capteur
double y2;
// temps et le temps de traitement
double temps;



void setup() {
// initialize the digital pin as an output.
pinMode(led, OUTPUT);
// config du port série
Serial.begin(9600);
x=333.0000;

}

void loop() {
temps = micros();
for (int i=1; i <= 10000; i++){
//et un essai avec 24 digits
y1=3.27124770502473 + x*(-0.00470054766560975+x*(0.00000291486604109577 + x*(- 0.000000000961445062745614+x*(0.000000000000173225871332+x*(- 0.000000000000000015926233+x*0.000000000000000000000582)))));

// y2 : retard entre le debut de charge et le top capteur
// avec une exponentielle
y2=57,604*pow(2.71828,-0.00042738*x);
}
temps = (micros()-temps)/10000.0;
Serial.print("temps de traitement des deux calculs :");
Serial.print(temps);
Serial.print(" us");
Serial.print (" regime moteur : ");
Serial.print (x);
Serial.print ("tr/mn etincelle/top capteur : ");
Serial.print (y1,4);
Serial.print ("ms debut de charge/top capteur : ");
Serial.print (y2,4);
Serial.println ("ms");

}

J'ai simplifié ton programme en virant l'affichage (source de problème, je l'ai vécu)
A la fin de ton programme, j'ai fait basculer la sortie LED au NL1 puis au NL2, c'est une astuce fournie par un collègue, de cette manière tu mesures réellement le temps du cycle.
Au scope j'obtiens une période (cycle complet de 10000 double calculs) de 4624us auquel je retranche par honnêteté la durée du pulse, on arrive donc a 4524us pour réaliser 10000 fois le cycle de calcul.
Le temps mis pour réaliser les deux calculs (Y1 et Y2) est donc de 0.45us : bravo pour la démonstration
Ajouter q=q+1 a présenté un temps négligeable (curieux cela contredit mes essai de cet après midi : j'ai aligné mon pas de la table de retard sur 3.5us en jouant avec cette astuce, mais arduino est parfois curieux, je le constate tous les jours)





int led = 13;
// regime moteur [tr/mn]
double x;
// y1 :retard entre l'étincelle et le top capteur
double y1;
// y1 :retard entre le début de charge de la bobine et le top capteur
double y2;
// temps et le temps de traitement
double temps;



void setup() {
// initialize the digital pin as an output.
pinMode(led, OUTPUT);
// config du port série
x=333.0000;

}

void loop() {
temps = micros();
for (int i=1; i <= 10000; i++){
//et un essai avec 24 digits
y1=3.27124770502473 + x*(-0.00470054766560975+x*(0.00000291486604109577 + x*(- 0.000000000961445062745614+x*(0.000000000000173225871332+x*(- 0.000000000000000015926233+x*0.000000000000000000000582)))));

// y2 : retard entre le debut de charge et le top capteur
// avec une exponentielle
y2=57,604*pow(2.71828,-0.00042738*x);
}

digitalWrite(led, HIGH); // met la sortie led. à l'état haut
delayMicroseconds (100);
digitalWrite(led, LOW); // met la sortie num. à l'état bas
}

Le logiciel avance :

- j'ai introduit une courbe de référence comportant 300 points et réduit le pas de calcul de l'application du retard à 3.5us (bientôt un relevé des 7 courbes que nous pourrons tester)
- je me suis également penché sur la phase de démarrage, j'y ai rencontré pas mal de difficultés (gestion de la première impulsion impossible par calcul de la période, chevauchement d'impulsions et plantage du logiciel.........)

J'ai du aborder 4 plages de fonctionnement pour le calcul du retard :

- premier cas : la moto est allumée depuis un temps inconnu et arrive  la première impulsion issue de la phase de kick
- deuxième cas : on est dans la phase de kick et de démarrage (forte disparité de fréquence : on passe de 1hz à 20Hz rapidement)
- troisième cas : le cas nominal, la moto fonctionne nominalement  entre son ralenti et 10000tr/mn
- quatrième cas : le calcul de la période amène une valeur incohérente (passage à 0 du compteur interne au microcontrôleur par exemple)

Et un petit oscillogramme de l'entrée et de la sortie pour illustrer la phase de démarrage :



Chaque impulsion est traitée convenablement en fonction du domaine de fréquence ou l'on se situe, aucune impulsion issue du rupteur n'est oubliée.
L'obtention de ce résultat a entraîné la mise en place d'un rapport cyclique constant de 50% sauf entre 0tr/mn et 800tr/mn ou la durée a été fixée à 30ms.

Un autre oscillogramme pour montrer la précision du décalage angulaire : signaux à 7500RPM


Jitter de 3.5us imperceptible, rapport cyclique 50%, retard angulaire 20°C.

Prochaine étape : présentation des 7 courbes que je proposerai à Jef pour essai.

Et voici les courbes qui seront testées en 2015, il s'agit des mesures réalisées sur la maquette de mise au point du logiciel et non ne courbes purement théoriques. :



La courbe 0 est la possibilité de se replacer sans aucune avance (comme s'il n'y avait que le rupteur et la bobine = montage d'origine).
Les autres courbes augmentent progressivement l'avance de phase à hauts et bas régimes.
A l'issu des tests de Jef nous pourrons réaliser une courbe idéale qui pourra être un mélange des courbes actuelles.
On remarquera la possibilité de se placer très proche du PMH durant la phase de démarrage ce qui devrait permettre d'améliorer la phase de kick (théoriquement plus de retour de kick et amélioration du taux de réussite de démarrage).
A hauts régimes on se rapprochera également du PMH ce qui devrait améliorer la consommation et la puissance du moteur.
La courbe 1 est la courbe de référence rentrée manuellement dans le programme, les autres sont le résultat de la multiplication de cette table par un coefficient ( 0 - 2 - 3 -4 -5 -6) .
Les pointillés rouge représentent la position du PMH (point mort haut = moment ou le piston est le plus haut dans le cylindre et donc le plus proche de la bougie).

Concernant l'énergie transmise par la bobine, j'obtiens cela :



A 7500RPM ou tr/mn l'énergie transmise par la bobine MZ (6 ohms - 13mH)  à la bougie est toujours suffisante (18mj à la place de 26mj à faible régime) ce qui permet de s'assurer que le moteur, à ce régime, ne sera pas limité par l'allumage.

Prochaine étape : amélioration de la gestion des Switchs : la gestion ne se fera qu'à l'allumage de la moto pour éviter que les vibrations ne  fassent sauter de courbe l'IGIMZ (c'est peu probable, mais c'est facile à éviter).