Projet de boitier ECU pour le contrôle indépendant des blocages de différentiels avant et arrière sur HDJ80.

[clost]

Dernier message de la page précédente :

Waouh...
Combien de fils le connecteur ?

[olivier80]

C'est un 16 broches, avec 9 emplacements par rangée.

Photo connecteur ECU.png

Il ressemble beaucoup à un connecteur 16 broches utilisé pour les phares mais ce n'est pas exactement le même, celui des phares a 10 emplacements par rangée.

Je vais peut être pouvoir acheter une petite quantité, je viens de recevoir une réponse. Il y aurait des personnes intéressées par ce boitier custom ?

Je suis preneur aussi si quelqu'un peut vérifier sur 12S et 24S qu'on a tous le même connecteur. Le boitier se trouve à gauche de la pédale d'embrayage en haut. Photo si possible.

[profauto]

Bonjour,
J'ai un 12S (1992) et un 24 s (1996) . Ils ont les mêmes boîtiers....
Je les ai déjà intervertis pour faire des essais suite à une panne du bloc av.
Si cela peut t'aider.
Cdl

[olivier80]

Bonjour,
J'ai un 12S (1992) et un 24 s (1996) . Ils ont les mêmes boîtiers....
Je les ai déjà intervertis pour faire des essais suite à une panne du bloc av.
Si cela peut t'aider.
Cdl

Ok c'est bien ce que je pensais c'est déjà un bon point.

Il me reste à vérifier le connecteur, si on a bien tous le même. C'est une grosse galère pour en obtenir j'ai pas droit à l'erreur. Voir ma photo dans ce fil plus haut.

Une petite photo du connecteur coté boitier ECU me serait utile si quelqu'un a le courage d'aller y faire un tour.

[olivier80]

Je rencontre un soucis avec la carte Arduino Uno. Malgré un programme modérément complexe, ses 2 Ko de mémoire SRAM ne sont pas suffisant pour faire tourner le programme ladder OpenPLC. Alors qu'il tourne sans soucis dans le simulateur sur PC. Je pense que c'est à cause de la taille du runtime OpenPLC qui prend une bonne partie de la SRAM disponible.

Une solution serait de conserver cette carte et passer le programme en C, ce qui serait pénible pour s'y retrouver pour un programme de type automate programmable, étant donné que je préfèrerais que le programme soit ouvert et facile à comprendre et modifier.

L'autre solution que je vais essayer est de passer sur un processeur avec un peu plus de RAM. Peut être une Arduino Mega avec donc 8 Ko de SRAM, voir une carte à base de processeur ARM ce qui donnerait beaucoup plus de marge. Le prix du boitier ne devrait pas être impacté significativement.

PS : après test le programme fonctionne sur une Arduino Due (96 Ko de SRAM), mais c'est un peu too much, je vais tester sur Arduino Mega et peut être ESP32 si la compilation ne pose pas de problème.

La carte Arduino Due en cours de test :

Arduino Due.jpg

Le lab de test avec les deux platines Arduino Uno qui servent à simuler les moteurs de blocages de Diffs :

Simulation hardware.jpg

[Mikado80]

Alors la tu m'as perdu mais bravo quand même

[olivier80]

Alors la tu m'as perdu mais bravo quand même

Rien de compliqué :

La platine de gauche est une carte avec un processeur et un peu de mémoire, elle sert à faire tourner le programme de commande des blocages de diffs arrière et avant.

Les deux platines de droite sont chacune un simulateur hardware, dans lequel tourne un petit programme qui imite le fonctionnement de chaque moteur de blocage de différentiel. Cela permet de tester tranquillement au labo pour être certain que tout fonctionne avant de passer au prototype final. Par exemple cela m'a déjà permis de gagner probablement pas mal de temps pour diagnostiquer le problème de capacité mémoire qui s'est présenté. En voulant aller trop vite, on perd souvent pas mal de temps, voir même des fusées avec leurs passagers parfois

Les 5 leds représentent l'état du mécanisme moteur de blocage :

Led verte à droite : réception d'une commande moteur pour déverrouiller le blocage.
Led jaune à droite : réception d'une commande moteur pour verrouiller le blocage.
Led rouge au centre : verrouillage effectif du blocage (interrupteur de détection de verrouillage effectif sur le mécanisme réel).
Led verte à gauche: le mécanisme est sur la position attente de déverrouillage.
Led jaune à gauche: le mécanisme est sur la position attente de verrouillage.

Donc la grande carte de gauche envoi les informations de pilotage des mécanismes de blocage, et elle reçoit d'eux leur information de verrouillage effectif qui servira à deux choses :

- attendre que l'arrière soit effectivement verrouillé avant de lancer le verrouillage du blocage avant.
- faire clignoter les voyant du combiné d'instrument lorsqu'un blocage est en attente de verrouillage.

Ensuite, pour le programme qui sera en ladder (schéma à contact), quelques connaissances en électricité et en logique de base devrait suffirent à comprendre son fonctionnement

Voici le programme, qui subira probablement une modification pour passer l'entrée analogique speed en entrée numérique, le signal speed en provenance du combiné d'instrument étant probablement un signal carré qui varie juste en fréquence, au rythme de 4 impulsions par tour du capteur sur la boite. J'étais resté en analogique pour le moment car j'avais un problème avec la librairie Oscat qui fournit le module qui va bien pour mesurer une fréquence et / ou un rapport cyclique, problème résolu aujourd'hui par l'auteur du logiciel OpenPLC qui a trouvé le bug en moins d'une journée.

Si quelqu'un a ce capteur ça m’intéresserait d'avoir le nombre de dents de son pignon, ainsi que le nombre de dents coté boite, pour calculer son rapport de transmission. J'ai cherché cette info en vain. Je sais juste qu'il envoi 4 impulsions par tour.

programme ECU blocages copyrighted.png

[clost]

Rien de compliqué :

[docxl]

Expliqué clairement comme ça, en effet, ça a l'air "simple" !!!
Mais pour moi ça reste de la magie !

[olivier80]

Ce n'est pas de la magie, c'est juste l'utilisation de processeurs qui profitent de plusieurs dizaines d'années de développement et qui arrivent aujourd'hui à une maturité, une complexité et une puissance difficilement imaginable.

Je me souviens avoir étudié un peu en détail le fonctionnement à bas niveau du processeur AVR (qui est un petit processeur Risc 8 bits célèbre optimisé pour le C, utilisé sur les platines Arduino entre autres) pour deux projets dont le programme décodeur PWM du projet Arducopter. On a du optimiser au maximum un programme en C de quelques dizaines de lignes pour éviter de passer à la programmation en langage machine afin de tirer le maximum du processeur en terme de respect du timing des entrées. Rester en C était un impératif pour que le programme opensource soit compréhensible et accessible. Deux mois de boulot environ de mémoire, à deux personnes. Dans des cas critiques comme celui-ci, ou l'on est tenu par des impératifs de performance, de coût et de langage de développement, c'est pas toujours simple, il faut parfois descendre dans les arcanes du processeur jusqu'à tenir compte du nombre de cycles d'horloge pour chaque instruction.

Mais pour beaucoup de projets, heureusement, les langages de développement modernes, comme le C et les langages métiers comme le ladder, grafcet et autres, ainsi que la puissance démesurée des processeurs, permettent de programmer sans ce soucier de leurs arcanes complexes. Si on ajoute à cela des petites platines toutes faites à faible coût comme la famille Arduino et similaires, on obtient quelque chose d'abordable pour toute personne curieuse pas trop fâchée avec la logique et les mathématiques !

Cela m'a toujours attiré, plus que la magie ou la cartomancie

[olivier80]

Pour revenir aux cartes Arduino Uno et au programme ladder que j'essaie d'y faire tourner il semblerait que le bug que j'ai rencontré soit du non pas à une capacité mémoire insuffisante de la carte mais à un bug dans le l'éditeur OpenPLC, qui j'espère va être corrigé sous peu suite à mon rapport.

Ce serait bien non seulement pour ce projet mais aussi peut être d'autres petits projets pour automobile nécessitant une plateforme low cost et ouverte facilement programmable en ladder.

Il existe bien quelques petits automates programmables disponibles pour ce type de projet, mais soit leur coût soit leur manque d'ouverture (en terme de matériel et logiciel de programmation) font que cela nuirait à la pérennité ou même la faisabilité des projets.

Edit : bonne nouvelle le programme ladder OpenPLC tourne sur une carte ESP32.

La famille de cartes ESP32 sont des cartes faible coût de petite dimension, équipées d'un processeur 32 bits LX6 très rapide (horloge 240 MHz), souvent à deux cœurs, d'un module Wifi et du Bluetooth. Moins connues que Arduino mais très attractives pour des projets qui ne nécessitent pas un grand nombre d'entrées sorties physiques et de la puissance. Les quantités de mémoire RAM (520 Ko) et FLASH (4 Mo) sont très élevées ce qui permet de faire tourner des programmes complexes. Le module Wifi permet de faire par exemple un serveur Web pour du diagnostique et ou configuration depuis un smartphone
Avec un écosystème moins large que Arduino, elles s'adressent probablement plutôt à des utilisateurs ayant un minimum d'expérience en électronique.