Saccades moteur defender puma

[Imer]

Aujourd'hui le def fonctionnait mal c'était l'occasion de faire quelques enregistrements.
Pour la pédale malgré son remplacement ça ne résout pas le problème de saccades.
Sur toutes les pièces jointes les enregistrements ont été réalisés au moment ou le véhicule présentait des saccades.
Si besoin de précision dites moi...

[Normand 1400]

Voilà de la matière!

Avant tout, peux-tu me confirmer qu'on parle bien de la même chose :

• MAF : débit d'air à l'admission ;
  MAP : pression d'air admission ;
  FRP courbe jaune : consigne de pression de rampe ;
  FRP courbe bleue : pression effective dans la rampe ;
  VGT : position du potar d'accélérateur (confirmer notamment que 100% = pleine ouverture?) ;
  RPM : nombre de tours moteur par mn ;

Écran que tu as appelé essai 5 : là, il faut que tu commentes les différents paramètres, à quoi ils correspondent, car la variation de certaines grandeurs (notamment B+, qui est probablement la tension batterie) semble marquée.

Et que tu m'expliques aussi la différence entre les écrans 4 et 6 : ce qui a été mesuré et dans quel contexte (véhicule déconnant à chaque fois si j'ai bien compris) étant entendu que le 4 a bien meilleure gueule que le 6, même si certains paramètres semblent aussi changer sans raison valable sur cet écran...

Sur l'écran 4, préciser la définition du paramètre qu'on ne voit que partiellement, dont la valeur intermédiaire à t = 51,03 secondes est de 67 grammes/seconde.

Le logiciel d'acquisition te permet-il de superposer les différents écrans avec la même base temps? Je pose cette question car les bases temps sont différentes pour les trois écrans.

As-tu un suivi du temps d'ouverture des injecteurs (rapport cyclique de l'injection principale en particulier ou bien débit en millimètres cube par minute ou assimilé de cette injection)?

Enfin, il faudrait un enregistrement quand tout va bien.

Ma première impression est que la pression de rampe varie de manière inexpliquée, sans variation de charge et/ou de régime associée...

A suivre!

[Imer]

Je vais essayer de faire un maximum d'essais.

]MAF : débit d'air à l'admission ;
MAP : pression d'air admission ;
FRP courbe jaune : consigne de pression de rampe ;
FRP courbe bleue : pression effective dans la rampe ;
FRP courbe rose: tension capteur pression de rampe;
VGT : position du turbo;
RPM : nombre de tours moteur par mn ;

Sur l'écran essai 5:
Temp culasse,
Tension batterie,
Position pédale accel,
Temp gasoil,
Fuel pw (je vais regarder le logiciel de mémoire je me souviens pas),
Sync: synchronisation entre capteur CKP et CMP.


Alors effectivement le véhicule ne fonctionnait pas correctement lors des essais. Mais il m'a été difficile de trouver une route bien plate et sans défauts pour stabiliser au mieux le moteur.

Sur l'écran 4, la valeur intermédiaire à t = 51,03 secondes est de 67 grammes/seconde: valeur théorique (ou de consigne?) du capteur MAF.

Le logiciel d'acquisition te permet-il de superposer les différents écrans avec la même base temps?

Malheureusement je n'ai pas trouvé cette fonction (a vérifier).

As-tu un suivi du temps d'ouverture des injecteurs (rapport cyclique de l'injection principale en particulier ou bien débit en millimètres cube par minute ou assimilé de cette injection)?

J'ai une valeur de correction il me semble (encore une fois je vais vérifier mais il y a de mémoire une valeur par cylindre).

Enfin, il faudrait un enregistrement quand tout va bien.
(Je dois en avoir je transfère une fois le pc en main)

[Normand 1400]

Petit point de détail : peux-tu potasser la fonction qui permet de citer (quote), ça rendra la lecture plus aisée!

Bon, c'est plus clair. Le logiciel m'a l'air d'avoir toutes les ressources nécessaires, on devrait donc y arriver...

Toujours dans l'hypothèse d'une dérive aléatoire de la pression de rampe, il faut repasser par la case « fondamentaux » d'un mazout pour comprendre la logique que je tente de suivre à partir des premiers éléments qui tendent à apparaître.

L'objectif d'un système d'injection est d'instaurer un certain synchronisme entre la quantité de gas oil injectée et la vitesse de descente du piston (du moteur) : c'est en effet de là (de la progressivité et de la durée de la combustion du mélange air/gas oil) que l'on tire du couple (surtout) et des watts.

Sur les injections mécaniques, le piston de pompe et le piston du moteur étaient synchronisés via la courroie de distribution. Cela permettait au piston de pompe d'injection d'accompagner très longtemps la descente du piston moteur, le tout à pression d'injection constante, car elle était déterminée par le tarage des injecteurs.

Idem pour les injecteurs pompes, à part qu'il était plus compliqué de moduler pression et durée d'injection, qui était figée par la pression fixe d'ouverture des dits injecteurs, soit environ 2 000 bars, ce qui a provoqué leur disparition progressive lorsque les rampes communes ont pu taper des pressions de service elles aussi très élevées. Pressions que l'on n'utilise qu'aux très fortes charges et vitesses du moteur, pour des raisons que je vais survoler ci-après.

Avec l'électronique appliquée aux rampes communes, le support mécanique de la synchronisation n'existe plus et doit être recréé par calcul parce que :

à temps d'ouverture identique, la quantité de combustible injectée dépend très fortement de la pression de rampe. En d'autres termes, si la pression de rampe est fixe et surtout très élevée, l'ouverture de l'injecteur devra être extrêmement courte sinon on injectera trop de combustible. Donc la combustion sera elle aussi très courte, mais surtout violente. Il faut donc baisser fortement la pression de rampe pour des charges et des régimes moteurs faibles afin de maintenir la pression de combustion le plus longtemps possible lors de la course motrice descendante du piston ;

les séquences d'injection peuvent être gérées avec une souplesse infinie : pré-injection, puis une ou ou plusieurs injections principales, voire post injection pour purger le FAP.

Bref, tout peut être géré avec une souplesse incroyable et de manière totalement désynchronisée (dans une certaine mesure, évidemment ) des cycles propres au moteur.

Ainsi, je me répète, pour obtenir un faible débit tout en gardant une durée d'injection suffisamment longue afin de maintenir la pression de combustion le plus longtemps possible sur le piston, il faut réduire la pression de rampe et, du même coup, jouer sur le point d'avance des différentes injections et sur le temps d'ouverture des injecteurs.

C'est là où les algorithmes, la précision et la rapidité de l'électronique prennent tout leur sens. Les puristes feront remarquer que de baisser la pression de rampe altère la qualité de la pulvérisation, donc augmente la pollution... Bah oui, c'est la limite de ces beaux systèmes : l'idéal serait d'avoir un injecteur alimenté par une rampe à 2 000 bars mais dont le débit dépendrait d'un autre paramètre que son temps d'ouverture...

C'est ce que je trouvais génial avec l'injection mécanique : lorsqu'il fallait injecter fort et vite, le panache injecté changeait méchamment de tronche car on forçait la même quantité de combustible à passer dans le même trou, mais en beaucoup moins de temps! Formulé autrement, la seule chose qui changeait entre accélérateur en grand à 1800 tours et accélérateur en grand à 4 000 tours, c'était le point d'avance, et encore...

Aujourd'hui, on va changer la pression de rampe, le temps d'injection, voire injecter plusieurs fois pour mieux accompagner la descente du piston (les injecteurs piezos font ça très bien) bref, c'est un autre monde, très compliqué et aussi très ... fragile.

Si quelque chose débloque au niveau des pressions, le fonctionnement même de l'injection est complètement perturbé car la cartographie d'injection se décale progressivement de l'état du moteur : tu peux avoir trop d'avance pour la charge réelle du moteur et la quantité de gas oil injecté, ce qui provoque des saccades, ou des fumées, ou des cognements.

Bref, ça devient n'importe quoi.

Je voudrais donc vérifier les paramètres calculés par le micro contrôleur gérant l'injection et notamment ceux-ci : degrés d'avance, pression de rampe (on a), mais aussi durée d'ouverture des injecteurs.

Le hic, c'est que ces paramètres sont le cœur du système et c'est eux qu'on décortique quand on veut faire de la rétro ingénierie (en politiquement incorrect, ça veut dire qu'il faut faire ça pour trafiquer une carto d'injection dans le but de vitaminer les moteurs) ; donc ces guignols de constructeurs et d'équipementiers ne les rendent pas facilement accessibles, comme si cela pouvait arrêter un technicien expérimenté et déterminé...

Bref si tu peux nous trouver ça (degrés d'avance à la pré-injection et à l'injection principale) ainsi que le temps d'ouverture, ce sera le paradis car cela permettra de mesurer les variations de l'avance à l'injection, car je subodore que c'est sans doute cela qui met le bazar dans ton moteur.

Si tu trouves ça dans ton logiciel, l'étape suivante consistera à charger le moteur selon des cycles qu'on va imaginer ensemble et à voir comment le calculateur réagit.

N'oublie pas non plus de confirmer que 100% au capteur d’accélérateur correspond bien à l'ouverture en grand et non au contraire. Même question pour le paramètre VGT (position turbo).

En résumé pour l'instant, on observe, on réfléchit et, surtout, on arrête de changer des pièces!

[Imer]

Alors voici de nouveaux essais.

Pour la légende:
- en orange G DMD: avance
- balance cylindre 1234 en vert bleu mauve et jaune
- VFDES en cm3 quantité de gasoil demandée

Pour l'accélérateur 100% demande maximum, 0% ralenti idem pour le turbo.

Je n'ai pas toutes les fonctions possibles avec le logiciel ni toutes les valeurs du calculateur.

Qu'est ce que tu en penses ?

[Normand 1400]

Les courbes sont difficiles à interpréter parce qu'elles ne restituent pas toutes le même état à l'instant t... Dit autrement, il doit être possible de dérouler l'intégralité de l'enregistrement des différents paramètres sur le même intervalle de temps.

C'est le principe de base de ces outils.

De plus, l'affichage un peu « raboté » ne rend pas toujours facile la lecture des paramètres.

On va donc prendre le problème autrement, cela te guidera pour gérer différemment l'outil.

A ce stade, voici ce qui me semble curieux, sachant que tous les écrans ne concordent pas ce qui ne permet pas de valider nettement l'hypothèse d'un dysfonctionnement léger du moteur par manque d'avance faible charge :

tout d'abord, la tension batterie semble un peu trop fluctuante (presque 1 volt de crête à crête, c'est beaucoup sur un véhicule moderne). Attention, il s'agit de la tension batterie vue par le calculateur, qui peut — et ce sera un point à vérifier, mais qui nécessite un oscilloscope — être différente de la tension réelle.

Ce premier point peut signifier plusieurs choses :

• soit le régulateur de l'alternateur est fatigué ;
  soit il y a une masse intermittente qui fait chuter la tension générale du véhicule de manière aléatoire et excessive ;
  soit la tension générale est en réalité parfaitement régulée, auquel cas c'est l'étage de filtrage du calculateur qui commence à dériver (condensateur vieillissant).

Quoi qu'il en soit, la conversion des grandeurs analogiques (tensions) en valeurs numériques sur lesquelles portent les calculs peut être affectée et donc fausser les résultats, donc produire un effet perceptible à certains stades critiques du fonctionnement du moteur.

Mais on verra ça ultérieurement ; pour l'instant, l'important est de réunir sur une seule et même base temps les paramètres à analyser.

Toujours sur cette question du filtrage, je trouve, d'une manière générale, que certains écrans rapportent des courbes relativement propres (tracés lisses) alors que d'autres font apparaître des résultats parasités (tracés en dents de scie). Un véhicule est un univers très bruité d'un point de vue radioélectrique mais je trouve quand même ces fluctuations un peu trop marquées. Si des électroniciens expérimentés (LØLØ, Bisnouk) connaissant les calculateurs de Land pouvaient discuter ce point, ce serait un plus indiscutable!

Un des écrans d'hier (le n°6) montre que la pression de rampe est bizarrement corrélée avec la charge du moteur : augmentation de la consigne à suralimentation et régime quasiment constants. Sachant que cette pression augmente avec la charge et avec le régime, il faut donc que la position de la pédale d'accélérateur et, soit la charge du turbo, soit la pression dans le collecteur d'admission, puissent être analysées en simultané sur le même intervalle de temps.

Dans les écrans d'aujourd'hui (le 2), la demande en gasoil baisse ponctuellement de manière inexpliquée également. Là encore, ce n'est pas normal et pour comprendre l'origine du phénomène, il faudra corréler ce paramètre avec les précédents.

Concernant les paramètres turbo et accélérateur, quelque chose ne va pas non plus par rapport à tes indications. Sur l'écran 6 d'hier, on relève une bonne corrélation entre l'action du turbo et l'augmentation de pression, à part que la pression dans le collecteur d'admission augmente quand VGTpos baisse...

Cela correspond au fonctionnement exactement inverse de celui que tu rapportes :

Pour l'accélérateur 100% demande maximum, 0% ralenti idem pour le turbo.

Donc soit ta doc est erronée, soit quelque chose est branché à l'envers.

En résumé, l'idéal serait de disposer, sur le même intervalle de temps, moteur en défaut puis moteur en fonctionnement normal, des paramètres suivants :

• tension batterie ;
  potentiomètre accélérateur ;
  pression à l'admission ou actionneur turbo ou volume d'air admis (tes différents écrans montrent que les trois paramètres sont correctement corrélés, bien qu'il reste à tirer au clair cette histoire de pourcentage inversé au turbo, donc on peut se contenter de l'analyse d'un seul d'entre eux) ;
  pression de rampe ;
  demande de gas oil ;
  avance à l'injection ;
  régime moteur.

Remarque : j'imagine que le logiciel peut fournir des exports en .csv. Cela permettrait de composer les graphes à la demande sur la durée de notre choix.

Concernant la demande de gas oil, tu peux l'avoir cylindre par cylindre?

Désolé de pinailler ainsi, mais cette phase de collecte des données est vraiment capitale...

Et pour une fois qu'on a un gentil membre qui dispose d'un outil sérieux, ça vaut vraiment le coup de pousser les feux!

[bisnouk]

tout d'abord, la tension batterie semble un peu trop fluctuante (presque 1 volt de crête à crête, c'est beaucoup sur un véhicule moderne).

Je viens de parcourir le thread et j'avoue que moi aussi je trouve ces variations anormales. La production des tensions d'alimentation dans un véhicule n'est pas particulièrement de la haute technologie comme on pourrait avoir dans la hifi ou l'informatique. Tout au plus, on a un Alternateur / Diode de redressement / condensateur de lissage / régulateur de tension basique qui commande l'excitation de l'alternateur / batterie

La forme de la tension d'alimentation ne devrait pas présenter des variations proches du volt crête pour un tension moyenne de 13V, on est quand même pas loin de 10% d'ondulation parasite. Si l'ECU rapporte ça, cela veut dire qu'il est lui aussi alimenté par cette tension. Et donc, par voie de conséquence, tous les organes de contrôle et de commande aussi.
Il n'est pas absurde de penser que, par exemple, la tension d'asservissement de la pression de la pompe puisse aussi connaitre des petites oscillations liées aux oscillations de la tension d'alimentation du circuit de commande.

Comme le fait remarquer très justement notre expert Normand 1440, les moteurs modernes sont tellement affutés qu'une infime modification des conditions normales de fonctionnement perturbe tout le fonctionnement du système.

Il serait judicieux de procéder à la mesure équivalente de la tension sur un autre véhicule (sans anomalie connue) afin déjà d'isoler cette problématique de tension.
- si la tension du second est parfaite... ça oriente les recherches
- si la tension du second est identique... ça permet de dire que le (ou les) problème(s) est (sont) ailleurs !

Tu pourrais aussi isoler électriquement (ou mécaniquement) l'alternateur et faire un test routier uniquement alimenté par la batterie et aussi mesurer ta courbe de variation de la tension...

Bref, oriente déjà tes recherches là dessus, il faut remonter le mal de la source et l’alimentation est la source commune à tous les systèmes.

[Normand 1400]

Tu pourrais aussi isoler électriquement (ou mécaniquement) l'alternateur et faire un test routier uniquement alimenté par la batterie et aussi mesurer ta courbe de variation de la tension...

C'est ce que j'aurais fait sans oscillo...

A part qu'on aurait une alimentation en 12 volts, voire moins, ce qui est également susceptible de perturber le fonctionnement de l'électronique.

Bisnouk, à ton avis :

• ces cartes (le calculateur) comportent-elles une alimentation à découpage ou bien pompent-elles directement sur le circuit électrique général avec, par exemple, deux pauvres condensateurs de filtrage?
  
  comportent-elles plusieurs convertisseurs analogique/numérique (CAN) gérant chacun une entrée?
  
  le binaire qui sort du CAN est encodé sur combien de bits?
  
  sais-tu de quel type de CAN il peut s'agir?

Concernant ce point :

Il n'est pas absurde de penser que, par exemple, la tension d'asservissement de la pression de la pompe puisse aussi connaitre des petites oscillations liées aux oscillations de la tension d'alimentation du circuit de commande.

je pense que le fonctionnement de la pompe haute pression n'est pas affecté. En revanche, la mesure de la pression de rampe — qui détermine la régulation — peut l'être si le CAN qui la mesure doit faire face à des variations de tension.

Car si tu regardes les courbes, il me semble la pression de consigne dérive un peu trop. Or elle résulte d'un calcul, dont les paramètres sont issus de la numérisation de la tension délivrée par le capteur de pression...

Autre point : je n'ai rien d'un expert ; je m'intéresse, c'est tout...

Comme je trouve que notre forum manquait un peu de fond sur cette question de la gestion électronique des fonctions de base d'un moteur, j'ai sauté sur l'occasion!

Et pour la suite, car j'espère qu'il y en aura une , question à Imer : as-tu les moyens de repérer les fichiers de matrices (la carto, quoi) et de les lire?

Le fichier que je voudrais analyser est celui contenant les données de l'avance en fonction de la charge et du régime moteur ; les autres ne contiennent en principe que les éléments permettant les corrections température(s) et pression turbo, si le croisement pression turbo/position du potentiomètre d'accélérateur n'a pas déjà été suffisamment approché dans le premier fichier.

[bisnouk]

A part qu'on aurait une alimentation en 12 volts, voire moins, ce qui est également susceptible de perturber le fonctionnement de l'électronique.

L'expérience m'a souvent montré qu'il vaut mieux une tension basse (quoique en théorie toujours dans la marge de fonctionnement) mais stable plutôt qu'une tension nominale mais parasitée

ces cartes (le calculateur) comportent-elles une alimentation à découpage ou bien pompent-elles directement sur le circuit électrique général avec, par exemple, deux pauvres condensateurs de filtrage?

Je n'ai pas de donnée sur la structure interne mais je doute qu'il y ai des alimentations à découpage alors que la tension d'entrée est déjà en 12V. Il y a plus de chance qu'il y ai un régulateur 5V (directement à partir du 12V) pour alimenter la partie électronique numérique et l'utilisation directe du 12V pour établir la référence de tension pour les comparaisons (capteur de pression, de température....)

comportent-elles plusieurs convertisseurs analogique/numérique (CAN) gérant chacun une entrée?

A lire la doc du TD4, chaque organe a son propre capteur intégrant un CAN et c'est information digitale qui est remontée à l'ECU par le bus ECM. Donc chaque capteur se base sur le 12 V général pour faire sa référence.

le binaire qui sort du CAN est encodé sur combien de bits?

Aucune idée mais très souvent sur 10 à 12 bits soit 1024 à 4096 valeurs possibles

Je ne suis pas un spécialiste de la gestion moteur et si le problème ne vient pas d'un capteur, du 12V, d'une mauvaise masse ou du faisceau électrique, ça sera inaccessible d'aller plus dans le détail de l'ECU.

[Imer]

Voici les enregistrements du jour. Le def a plutôt bien fonctionné, il a déconné seulement sur un enregistrement que j'ai nommé PB4 mais c'était moins qu'hier.
Les autres sont à titre de comparaison, les capteurs sont dans l'ordre demandé seul le MAP est en volt au début puis en kpa (erreur de choix).

Sinon, je n'ai pas accès aux autres paramètres mais j'ai fait des captures d'écran de la liste des capteurs à dispo, en pj également.
S'il faut je peux encore réaliser d'autres essais avec différents paramètres en tout cas merci de votre aide!

Les enregistrement sont faits juste après le passage de la 4e jusqu'à atteindre un régime stabilisé.

Je n'arrive pas à joindre les fichiers en .csv, savez vous comment faire (le pc me dit extension incorrecte) ?

[bisnouk]

Faut dire que ça va pas être simple... rien que la description de la partie charge de la batterie fait intervenir tellement de paramètres... 'tain, c'est qu'une voiture !

Jusque là, c'est classique... quoique l'alternateur débrayable, c'est déjà pas mal...

Mais là, franchement....

[Normand 1400]

Ça se précise : il y aurait bien un problème avec le calcul de l'avance à l'injection.

Alors que la pression de rampe et la quantité de carburant à fournir varient de manière logique, tout en étant bien corrélées d'ailleurs, l'avance reste désespérément constante...

En prime, bien qu'il s'agisse de valeurs calculées, on trouve des points aberrants où l'avance varie de 10° pendant quelques millisecondes, ce qui n'a aucun sens mécanique et encore moins électronique (au sens électronique numérique) car un tel résultat aurait dû, d'emblée, être éliminé par l'algorithme...

Bref, l'a pas l'air tip top, comme calculateur. Je rejoins Bisnouk sur le regard critique qu'il porte sur la manière dont est gérée une toute bête opération de recharge d'une batterie et de stabilisation de la tension régnant dans un circuit électrique ; j'ai de plus en plus l'impression qu'une poignée d'allumés, enivrés par les possibilités sans limites de l'électronique et la fascination que cette discipline exerce sur le commun des mortels, qui n'y comprend d'ailleurs que couic, se fait plaisir à inventer des montages toujours plus sophistiqués — et souvent assez farfelus — en perdant de vue l'essentiel : il se passe quoi quand tout ce petit monde commence à vieillir et quand ils se loupent, ce qui arrive malgré tout de temps en temps?

Autre bizarrerie, la fourchette des valeurs d'avance restituée par le logiciel est très large (elle était bien plus resserrée sur l'écran E1 du 19 février) ce qui signifie que la courbe d'avance peut se développer d'une manière plus normale...

Pour l'heure, il va falloir secouer un peu ton moteur dans divers sens pour voir s'il se passe enfin quelque chose en matière de gestion du point d'avance.

Mais avant de commencer quelques essais, pour régler un dernier problème d'interprétation et surtout pour être bien confort dans la lecture, pourrais-tu nous sortir un écran avec les paramètres suivants, car j'ai vraiment du mal avec l'inversion du paramètre VGTPOS!

Voici les paramètres qui me siéraient bien pour, un peu mieux encore, mais tu as déjà bien géré le coup, caler l'écran de travail :

• APP
  MAP, directement en KPa si possible
  VGTDC
  VGTPOS
  VGT_F

Sachant que pour le reste, tu as vraiment organisé l'écran de contrôle aux petits oignons et qu'une fois le paramètre turbo bien choisi (en fait je cherche juste, dans ta dernière série d'écrans, à remplacer VGTPOS par un paramètre donnant la lecture directe de la pression turbo) on pourra passer aux tests.

Concernant les sorties au format csv, je ne peux pas te répondre, cela dépend des formats d'exportation supportés par ton logiciel. Le csv est un format très courant (comme le txt d'ailleurs) ; plus basique, je ne vois que le raw, mais si tel a été le choix des concepteurs du logiciel, c'est vraiment du genre mesquin, car pouvoir faire des calculs sur les valeurs brutes, c'est quand même la moindre des choses en matière de diagnostic numérique un peu plus travaillé...

S'il est possible de faire une copie d'écran des extensions proposées pour les exports, envoie toujours. On trouvera peut-être notre bonheur (dbf, xls, on peut rêver)!

Dernier point : peux-tu me dire quelle est la longueur maximale d'enregistrement supportée par le système (au moins 150 secondes si j'ai bien lu les divers écrans, ce qui est déjà excellent)?

[Imer]

Je suis également impressionné par la complexité du système...
Je vais réaliser un essai de permutation de batterie avec un autre véhicule pour voir (par curiosité).

Le logiciel me permet d'enregistrer quelques minutes de roulage, j'ai essayé hier environ 10min avec différents régimes et vitesses mais il a planté au moment de la sauvegarde. Je pense que 3-5 min ne poseront pas de souci.

Est ce qu'il est trop tôt pour envisager un problème de gestion du calculateur (un programme interne qui fait que le véhicule peut mal se comporter sous certaines charges moteur et régime) ?

Ce que j'ai du mal à comprendre c'est pourquoi ça se ressent surtout en 4. Aujourd'hui pour traverser une agglomération c'est soit en 3e un peu haut en régime je trouve ou en 4 mais c'est de la loterie...

Sinon j'ai les enregistrements plus longs sur quelques minutes en format .csv : ralenti 1,2,3,4 stabilisation puis arrêt, mais, sur le forum je n'arrive pas à les placer en pj.

Concernant l'avance, je l'ai vu varier de cette manière au changement de vitesse.

Je réalise de nouveaux enregistrements et vous tiens au courant.

[Normand 1400]

Concernant l'alimentation électrique, ça me laisse tout aussi perplexe...

Perso, j'aurais posé le problème en termes de longévité et de maintenance de la batterie : le fait de gérer plus finement a-t-il un réel impact sur sa longévité? J'avoue que j'ai un doute...

Quant à limiter l'évaporation, vérifier régulièrement le niveau de l'électrolyte fait partie de la maintenance normale, non?

Bon je sais bien que l'idée, dans ce monde d'intellos, est de ne plus mettre les pattes dedans, mais quand on voit ce que cela implique en termes de débauche technologique, on peut légitimement s'interroger sur l'intérêt de l'approche.

En d'autres termes, on sait ce qu'on a (un système électronique bien plus complexe) mais sait-on vraiment ce qu'on gagne au bout du bout? Pas sûr.

Et une chose est certaine : avec un tel discours (je n'ai pas dit dogme ) sur l'intérêt de chiader ce pauvre circuit, je me serais attendu à une régulation à +/- 0,3%. Quand on voit ce que mesure le calculateur, ça laisse effectivement perplexe! Mais seul un oscillo objectiverait le doute...

3 minutes d'enregistrement? C'est le Nirvana!

Par contre, l'idéal serait que tu fasses la manip avec une autre personne et que l'instant précis où tu ressens les saccades (35 secondes, 125 secondes etc.) soit bien précisé par rapport à la base temps de l'enregistrement...

Pour les csv, tu peux me les passer en messagerie privée. Je remettrai les extraits si je parviens à les exploiter.

Quant à ta question sur un problème de calculateur, je commence effectivement à me poser la question en ces termes, mais avec une réserve : il s'agit de l'avance calculée. Comme nous sommes en passe de consolider l'hypothèse que tous les capteurs et actuateurs fonctionnent correctement (reste à voir cette histoire de dérive de pression de rampe, mais tes derniers écrans ne l'ont pas reproduite) on peut effectivement supposer que le calcul se fait mal, mais là, une seule hypothèse semble tenir : entrants incorrects.

Car soit le microcontrôleur ne parvient pas à pointer sur les cartos, ce qui est peu probable, car sinon tout serait en rade, soit le fichier lui-même est vérolé et du coup, il cale l'avance à 0. Un microcontrôleur n'est pas un ordinateur, plus précisément il ne contient pas d'interface homme/machine dont la vocation est de donner l'alerte. Et il ne réagit pas s'il ne trouve pas de données, il prend en compte la valeur NULL et enchaîne sur l'instruction suivante.

L'hypothèse du fichier vérolé est peut-être confirmée par ce que tu expliquais en début de ton message : avec la carto poussant les watts sur le moteur, le phénomène serait plus marqué. On peut légitimement se demander si le fichier gérant l'avance n'a pas pris un shoot sur les deux cartos et si la vérole n'est pas apparue durant les transferts...

Une carto vitaminée rendrait une défaillance de l'avance beaucoup plus sensible, ceci expliquerait aussi cela, c'est du moins mon hypothèse du moment.

C'est pour cette raison qu'on va devoir imaginer un protocole de charge du moteur qui permette d'identifier si oui ou non il manque des lignes dans le fichier.

D'où ma question d'hier sur son identification et sa lecture sur un ordi indépendant, l'objectif étant de vérifier sa complétude et son intégrité.

Mais cela aura quand même ses limites, car je ne suis pas motoriste : je sais que sur la plupart des moteurs, on avait une rupture dans le diagramme de l'avance à faible charge vers 1800/2000 t/mn ce qui me laisse penser qu'on est pile poil dans la zone sensible. Mais cette information date pas mal et donc je ne sais pas ce qu'il en est avec les moteurs d'aujourd'hui, surtout que la préinjection joue un rôle majeur sur l'amélioration de l'inflammation, ce qui permet de moduler l'avance encore différemment.

Mais une valeur quasiment nulle, ça m'interpelle vraiment. L'idéal serait de diagnostiquer un moteur fonctionnant parfaitement, mais...

Ça se complique un peu, mais bon, c'est sympa d'essayer de comprendre!

[bisnouk]

Car soit le microcontrôleur ne parvient pas à pointer sur les cartos, ce qui est peu probable, car sinon tout serait en rade, soit le fichier lui-même est vérolé et du coup, il cale l'avance à 0. Un microcontrôleur n'est pas un ordinateur, plus précisément il ne contient pas d'interface homme/machine dont la vocation est de donner l'alerte. Et il ne réagit pas s'il ne trouve pas de données, il prend en compte la valeur NULL et enchaîne sur l'instruction suivante.

Je ne suis pas tout à fait d'accord avec ton résumé sur le microcontrôleur, on peut très bien écrire le programme du microcontrôleur en prévoyant la génération d'anomalie. C'est d'ailleurs bien ce qui se passe quand un code erreur est généré par l'ECU. Un microcontrôleur est de ce point de vue identique à n'importe quel microprocesseur présent dans un ordinateur.

Je ne penche pas pour un bug logiciel car il serait généralisé. Le dysfonctionnement, s'il est d'origine logicielle ce qui n'est pas encore prouvé, sera plutôt lié à un défaut des paramètres d'entrée (capteurs...) ou de sortie (actuateurs...) ou de conformation... et là, ton raisonnement sur une table vérolée se tient. Ne connaissant pas la procédure de cartographie du Puma, est il possible de réinjecter toutes les tables par défaut de sa cartographie.

[Normand 1400]

Je ne suis pas tout à fait d'accord avec ton résumé sur le microcontrôleur, on peut très bien écrire le programme du microcontrôleur en prévoyant la génération d'anomalie. C'est d'ailleurs bien ce qui se passe quand un code erreur est généré par l'ECU. Un microcontrôleur est de ce point de vue identique à n'importe quel microprocesseur présent dans un ordinateur.

Tu as raison...

Je voulais simplement exprimer le fait qu'il ne s'agit pas d'une IHM au sens commun du terme puisque l'homme n'intervient pas instantanément dans le déroulement du programme, ne serait-ce qu'en raison d'un arrêt pur et simple de son exécution et de l'attente d'un ordre, exprimée via une demande s'affichant sur un écran.

A tout te dire, ça me rappelle les programmes de calcul d'ouvrages en Fortran qu'on passait d'abord à la compil', la descente du bac à cartes (40 000 cartes étaient courantes) dans la salle de calcul, l'attente des résultats qui sortaient sur des listings de ouf quand les trous de guidage ne foiraient pas tout...

L'arrivée des premières calculatrices programmables (je me souviens des HP 11C ) puis, après, les premiers mini puis micro-ordinateurs avec un écran et un clavier, bref des bécanes avec qui on pouvait « causer », ça a vraiment été une révolution pour les has been dont je fais partie!

Du coup, si vraiment l'hypothèse tient, on ne sait pas ce qui se passe (il n'y a pas de code défaut) et on va passer un certain temps à explorer des pistes.

Comme avant, quoi...

[Imer]

Voici les captures d'écran du jour. Je ne peux toujours pas poster les fichiers en csv.
L'essai d'une autre batterie ne change rien.

Par contre je ne comprends pas la lecture du paramètre VGTDC en %, pourquoi ces pics ?

[Normand 1400]

De plus en plus captivant!

Tout d'abord, je vais certainement invalider la piste de l'avance et des fichiers vérolés.

J'ai ressorti toutes mes docs : la demi douzaine de fiches d'essai que j'ai sur les pompes mécaniques les plus diverses montre que la courbe d'avance ne se développe jamais en dessous de 900 t/mn pompe, c'est à dire 1800 t/mn moteur. De même, l'avance faible charge se rajoute toujours à l'avance principale ; autrement dit, le complément d'avance faible charge (AFC) est, en moyenne, lui aussi mis en place au-delà de 1800 t/mn.

Certes, il s'agit de pompes mécaniques, mais une loi d'injection reste une loi d'injection, l'électronique est « juste » plus rapide et capable de gérer des dizaines de paramètres auxiliaires...

Mis sous forme cartographique, on obtient ceci :

L'autre point est que l'avance fixe (l'équivalent du calage au comparateur ou à la pige) est donnée par la position du capteur de point mort haut. Lequel n'est pas au point mort haut, mais précisément au point d'avance fixe. Ce détail figure peut-être dans la doc ; si une âme charitable peut nous éclairer là-dessus...

En d'autres termes, la valeur de l'avance restituée par les écrans est le complément à l'avance fixe ; il résulte de ce qui précède qu'il est normal que ce complément soit voisin de 0 sur les écrans, car le moteur n'atteint pas ce régime.

Concernant les pics de la valeur d'avance calculée, un examen plus précis des graphes montre que le calculateur augmente très fortement l'avance à chaque tendance haussière de la pression de rampe : une forte valeur d'avance est sélectionnée dès que la dérivée de la courbe de pression passe de 0 à une valeur positive. J'en déduis que le microcontrôleur laisse le moteur effectuer une petite dizaine de tours avec cette avance puis, constatant que la charge ne varie pas plus que ça, réduit l'avance. Tout cela se joue en quelques dizaines de microsecondes (une éternité pour l'électronique, mais un instant pour la mécanique) mais vu l'échelle adoptée par le logiciel d'interface, cela donne un pic apparemment incohérent.

J'ai retrouvé des algos similaires dans la gestion du cliquetis sur les calculateurs essence Bosch ; c'est déroutant comme approche pour un mécanicien mais parfaitement cohérent si on y réfléchit de plus près. Formulé autrement, on est pile poil sur la frontière séparant la mécanique de l'électronique : on joue sur la rapidité de calcul pour ajuster progressivement les valeurs.

D'un point de vue code informatique, ça doit s'apparenter à une boucle du genre (les « go to subroutine» de ma jeunesse ) :

tant que le paramètre machin n'a pas évolué de telle et telle manière, incrémenter de telle valeur la tension de l'actuateur bidule ;
dès que la valeur tartemuche est atteinte, fermer la boucle.

Ça se tient sacrément, tout ça!

Bref, je crois qu'on fait fausse route, surtout qu'au regard de ce que tu viens de trouver, je pense qu'on peut pour l'instant laisser la question de l'avance de côté.

Je n'ai pas la moindre idée de ce à quoi correspond mécaniquement le paramètre VGTDC. Que mesure-t-il physiquement, je n'en sais fichtrement rien non plus!

Mais c'est là que nos amis qui ont la doc vont se faire un plaisir de nous répondre!

L'idéal serait également de savoir de quel type de capteur il s'agit (résistif, inductif, effet Hall, piézoélectrique, etc.) car ça va aider à identifier son point faible.

Il restera à trouver la manière dont il est exploité et quel est l'actuateur dont le régime est corrigé par le microcontrôleur, mais il y a manifestement une corrélation entre le point du chronogramme que tu as repéré lors des saccades et les variations de ce paramètre.

Cette fois, je crois qu'on tient le lien...

Je ne serai pas surpris que le calculateur modifie une des consignes passée aux injecteurs. Mais laquelle? Peut-être la préinjection? Une chose est sûre, c'est un paramètre secondaire puisqu'il ne provoque que des saccades que toi seul perçoit, si j'ai bien lu le début de ton inter.

Il y donc un nouveau travail documentaire à effectuer, mais on commence vraiment à bien voir la puissance de ces outils de diagnostic.

Concernant la tension générale, ton essai montre que les variations de tension (si tant est qu'elles existent vraiment et là, je me répète, seule une mesure à l'oscillo le confirmerait) ne perturbent aucunement le calculateur.

Les graphes que tu as postés hier préparaient cette conclusion...

[Imer]

Le paramètre VGTDC serait la position de la géométrie variable du turbo en cycle de fonctionnement.

[Imer]

[/quote]

Je ne serai pas surpris que le calculateur modifie une des consignes passée aux injecteurs. Mais laquelle? Peut-être la préinjection? Une chose est sûre, c'est un paramètre secondaire puisqu'il ne provoque que des saccades que toi seul perçoit, si j'ai bien lu le début de ton inter.

Effectivement si je reviens sur mes saccades, ça se produit principalement en 4 sur une légère charge. Je ressens que le def commence à devenir hésitant puis si je reste dans les mêmes conditions de conduite l'ensemble du véhicule se met à bouger. C'est vraiment vers 1700tr/min 50km/h 4e vitesse. Si je roule en 6e à 90km/h au même régime aucun problème.

Autre chose quand l'accélération devient rugueuse et un peu imprécise, j'ai l'impression sur les enregistrements que ce même paramètre VGTDC est aussi instable.

Je ne veux pas parasiter votre réflexion avec mon sentiment peut être erroné....