DETECTION ET PROTECTION CONTRE LES COURT-CIRCUITS

[laurentr]

Bonjour

J'ai procédé à la suite de mes tests.

J'ai rencontré quelques "surprises inattendues" qu'il a fallu traiter étape par étape.

La plus grosse d entre elle est que dans ma loop() une condition switch(ETAT), qui constitue exclusivement le corps du code, itère selon la valeur d une variable, ne fonctionnait pas!

J ai découvert le "truc" en insérant des Serial.print() régulier dans les étapes du code pour voir les enchainements.
Ceux ci ne se réalisaient pas! Le switch étant inopérant!!!

Autre subtilité une variable dont la valeur ne se conservait pas... et la suspicion d'un WATCHDOG actif sur le CPU de test.
Apres un re flashage des fuses... cela c'est passé beaucoup mieux! ( merci BLINK!)

Autre "surprise du chef" et oui on en va pas s'arrêter en si bon chemin, en utilisation en courant continu sur le pilotage du moteur connecté sur l'ACS712 la lecture fait apparaitre même de façon extrêmement temporaire un PIC au démarrage du moteur (INRUSH CURRENT) qui peut alors déclencher les conditions de bascule de façon "abusive" et "erronée" car ce pic n'est que transitoire lors du démarrage du moteur. Je pense que l' on pourrait avoir exactement le même comportement en source d'alim DCC. (tests a venir)

En revanche la hauteur de celui ci m'a fortement surpris. (proche de 1A!!)

J'utilise le moteur d'une carte de TEST ESU permettant de connecter des décodeurs DCC pour leur programmation.
La carte dispose d'un petit moteur équipé d'un volant d inertie.

La consommation de ce moteur à vide est très faible en étant proche de 50mA sous 12V environ.


Je suis repassé à des if(ETAT ==xx) ce qui a permis de bien enchainer les éléments ce que curieusement le switch() ne réalisait pas.

Je n'ai pas compris l'origine de ce symptôme

Pour augmenter la consommation du moteur je pose doucement mon doigt dur le coté du volant afin de générer un effort qui fait monter la consommation.

Celle ci fait varier les mA et une fois atteint le seuil de bascule... cette fois cela commute si toutes les conditions sont bien remplies.

le "RESET EXTERNE" est confié à un bouton poussoir sur un PIN en INPUT_PULLUP via un attachinterrupt(digitalpintointerrup(broche ID),fonction_reset,FALLING) qui joue merveilleusement bien son rôle

Comme la tension n'est pas un modèle de stabilité absolu les fluctuations sur les retours de analoguRead() de la broche provenant de l'AC712 sont "écrêtés par la bas" pour nettoyer le "bruit" Pour memo l'ACS712 a un bruit de l'ordre de 20mV (source datasheet)

De même, la moyenne de l'échantillon de mesure (100 mesures successives prenant chacune ~24us ) est également "écrasée" pour les plus faibles variations qui en mv sur la lecture se traduise dans la mise à l'échelle par des mA imaginaires.

Ces petits ajustements fait j'obtiens à ce stade de réalisation des conditions de tests valides et des résultats en accord avec l'objectif donné.

D'autres tests vont suivre mais ceux ci caractérisent une étape importante de franchie.

Ltr

[Etienne66]

L'appel de courant au démarrage peut être du au volant d'inertie ainsi qu'à la partie capacitive ou inductive du circuit
qui peut amplifier les transitions.
Il conviendra aussi de faire des tests avec des locos équippées de réserves de courant qui vont aussi pomper du jus au démarrage.

[laurentr]

C'est "au menu des tests" à réaliser afin aussi de se prémunir de tout aléas, voir d ajuster des valeurs dans le code (timing/seuils...)

Ce n'est finalement pas si "trivial" que cela en à l'air!

Ltr

[laurentr]

Une solution "simple" consiste à réaliser un échantillonnage de mesures sur un plus grand nombre d'itérations ce qui allonge la durée au détriment de la réactivité.

J'ai personnellement préféré une mesure brève des échantillons de référence.

Voici la trame mise en œuvre:

1/mesures:
on effectue un échantillonnage sur 100 mesures consécutives via analogRead() afin de vérifier si la valeur moyenne > seuil
passage en 2/ si dépassement sinon on reste en 1/

2/ on inverse immédiatement la distribution des pôles J/K, on note le temps T0 de référence, on calcul le temps de fin max et on passe au point 3/

3/ on temporise légèrement grâce au temps de référence comme base et le temps écoulé avec une comparaison du temps de fin max avec micros() (via boucle while() , pas de delay()!! )  comme l'avait suggéré Etienne.
J'ai mis ici 30ms.
Puis, on mesure s'il y a un pic de conso > seuil au delà d'une durée de référence ici mise à 30ms également.

Ces deux valeurs peuvent encore faire l'objet d'ajustements.

Si temps maxi dépassé on passe en 4/
Sinon on repasse en 1/

4/ ou coupe pour protéger


Une interruption externe permet de sortir de 4/ pour repasser vers 1/ et inverse également la distribution des pôles J/K.

Dans chaque étape des leds témoins indique les statuts.

Les premiers tests sont encourageants et répondent comme attendus.
Le pic de courant du moteur de test lorsqu'il est connecté et avec son démarrage sont bien vus par 1/ et font passer en 2/ puis 3/ avant de revenir vers 1/

Il faudrait sortir l'oscillo pour mesurer le temps du pic avec ce moteur et avec d'autres pour voir si une tendance peut être dégagée et optimiser les valeurs, idem avec une rame loco en charge d'une rame "lourde" et ou" haut le pieds".
En effet l'effort à produire au démarrage d'un convoi étant diffèrent les timings et valeurs peuvent nécessiter d'être revues/ajustées.

Pour la charge des "grosses capas" si les choses sont bien faites leur courant de charge est limité. (IL DOIT L'ETRE) Toutefois dans le cas de multiples charges à réaliser en parallèle les unes des autres ces courants s'additionnent et donc leurs pics d'appels même transitoires.

Ltr.