LOCODUINO
Parlons Arduino => Vos projets => Discussion démarrée par: laurentr le février 07, 2024, 02:55:02 pm
-
Bonjour
Ce sujet important est souvent abordé en filigrane mais n'a jamais encore fait l'objet d'une section dédiée.
Consacrons nous y.
Traditionnellement il est d usage de mesurer la consommation et en cas de dépassement d un seuil fixé de procéder à une coupure de l alimentation, ce qui met fin au court circuit ou à la surcharge.
Historiquement des fusibles à plomb, calibrés assuraient ce rôle.
D autre solutions existe aussi comme des lampes ballaste.
La solution "ultime" repose toujours sur un temps de réaction le plus bref possible ce qui assure l'efficacité de la protection.
Un disjoncteur mécanique actionne des contacts d une position fermée assurant la continuité à une position ouverte qui coupe la continuité!.
C est ce que réalise un relais
Les temps de bascules sont de l'ordre de quelques milli secondes. (ms) à quelques dizaines de ms.
Si ceci est mécaniquement rapide c'est électriquement ( et donc électroniquement) long voir très long.
En effet nos microprocesseurs travaillent à des vitesses beaucoup plus rapide. Les composants électroniques aussi.
Autant alors optimiser le tout dans une mise en œuvre visant une efficacité optimale que nous allons pouvoir développer dans ce post.
Ltr
-
Voici le schéma de base ( partiel) que nous allons utiliser pour nous affranchir de la présence de relais.
Ils seront ici remplacés par de transistor MSOFET canal N. ( des canal P pourraient produire un résultat analogue)
Nous utiliserons un "driver MOS" qui pilotera la commutation rapide des transistors MOS.
Lors d'un CC, un changement d état aura lieu sur une broche RST_PINx que traitera un CPU qui procèdera alors à une commutation/bascule.
Voici un schéma qui illustre cette mise en œuvre.
-
Lors d un CC cela signifie que COMx qui est alimenté par la source avec un pole J ou K rencontre le pole opposé K ou J respectivement.
On détecte alors ce CC au niveau du pont diviseur pilotant la gate du NMOS dans la ligne de l opto coupleur.
La magie opère et les états respectifs des entrées sorties sont alors alignées afin que les pole soient de nouveau alignés.
Un petit mécanisme devra verrouillé la 1ere interruption survenue pour éviter une double bascule que pousserait la seconde qui ne résoudrait alors pas le problème initial.
Le schéma ne présente que 50/100 des composants de commutations pour la gestion d'une boucle mais reste suffisant pour un simple disjoncteur de protection.
Ltr
-
Très intéressant, vivement la suite !
Christophe
-
Hello
La suite est ce que l'on veut en écrire à présent pour décliner ceci en réalisation.
Puissances à commuter, nombre de composants... utilisation en disjoncteur global, commutateur.( LOOP etc)...
Exemple un composant" tout en un" comme le TLP3553 va bien aider mais il est limite en tension (20V) et ampérage( 3A)
https://www.mouser.fr/datasheet/2/408/TLP3553_datasheet_en_20200325-1108741.pdf (https://www.mouser.fr/datasheet/2/408/TLP3553_datasheet_en_20200325-1108741.pdf)
Les drivers MOS VOM1271 et TLP3906 nécessiteront plus de composants mais laisseront le choix de leur dimensionnement.
https://www.mouser.fr/pdfDocs/vom1271.pdf (https://www.mouser.fr/pdfDocs/vom1271.pdf)
https://www.mouser.fr/datasheet/2/408/TLP3906_datasheet_en_20191222-1916273.pdf (https://www.mouser.fr/datasheet/2/408/TLP3906_datasheet_en_20191222-1916273.pdf)
Pour bien comprendre les mécanismes opérants il ne faut pas hésiter à écrire les tables de vérité des états auprès de chaque item.
Subtilité pour ne NMOS à DEPLETION
Prendre pour exemple le BSS139.
Lorsque sa GATE est à 0V il est passant et inversement des que l on quitte le 0V il se bloque au delà de 1V (en gros).
Les résistances du pont diviseur sont à dimensionner en conséquence.
Si on veut rester sous 2 W par exemple il faut tabler sur 100r, ( une SMD en 2512 fait parfaitement le job) si on réduit leur valeur on augmentera la dissipation à conduire , question de compromis donc.
Ltr
-
Bonsoir
Dans le cadre de la gestion du traitement en mode LOOP avec le montage décrit précédemment le code suivant doit pouvoir tourner.
Il faut savoir que le moment ou les interruptions vont se produire lors du chevauchement des roues par dessus les coupures des rails des sections fixe et commutable, ne sont pas identiques.
Il y en aura toujours une qui arrivera quelques tantièmes de secondes plus tôt que l'autre.( même avec des coupure bien parallèles, et encore plus vrai avec des coupures en quinconce!)
Afin d'éviter un double changement qui conduirait de fait à n'en produire aucun (ordre et contre ordre quasi immédiat) il faut neutraliser les effets de l'interruption arrivant en seconde position puisque la bascule est (déjà) en cours pour aligner les polarités des sections.
On rejette l utilisation de detachinterrupt() qui prendrait trop de temps en lui préférant une variable stockée ( bool) dans un registre (ca va très vite ainsi) et qui sera considérée dans les operations à mener.
Lors du changement des états de pin de commande on désactive aussi toute autre interruption pour garder une séquence de commutation rapide et groupée.
Si une temporisation est requise (temps de commutation des états au niveau CPU et de réaction de l'électronique) on utilisera une boucle while() pour incrémenter une valeur jusqu'à un seuil défini avant de conclure!
Voici la trame d'un code pouvant mener ces opérations.
Cela vous semble t il "convenable"?
#include <Arduino.h>
/*
DCC ADVANCED AUTO LOOP REVERSER: V1.0
Author: Laurent ROEKENS LTR
Version 1.0.0
Date rev: 07/02/2024: initial release design for MOSFET BACK TO BACK DESIGN
Specially designed for MEGATINY x06 (806,1606,816,1616,826,1626,3226 CPU Parts)
SWAP PIN NAMES OF ANY AVRx CPU. ( ex AVR Serie0 (NANO_EVERY), AVR Dx, ...)
*/
//VARIABLES:
#if !defined(PIN_PA1)
#define PIN_PA1 2
#endif
#if !defined(PIN_PA2)
#define PIN_PA2 3
#endif
#if !defined(PIN_PC0)
#define PIN_PC0 10
#endif
#if !defined(PIN_PC1)
#define PIN_PC0 11
#endif
#if !defined(PIN_PC2)
#define PIN_PC0 12
#endif
#if !defined(PIN_PC3)
#define PIN_PC0 13
#endif
#define TOGGLE GPIOR0 //use global register GPRIOR0 to store value for faster speed reaction
#define CHANGING GPIOR1 //same for CHANGING state value
#define CDE_SET1 PIN_PC0
#define CDE_SET2 PIN_PC1
#define CDE_SET3 PIN_PC2
#define CDE_SET4 PIN_PC3
#define RST_PIN_1 PIN_PA1
#define RST_PIN_2 PIN_PA2
#define CDE_SET1_SET_ON PORTC.OUTSET = PIN0_bm //faster than PORTC.OUT |= PIN0_bm
#define CDE_SET1_SET_OFF PORTC.OUTCLR = PIN0_bm //faster than PORTC.OUT &= ~PIN0_bm
#define CDE_SET2_SET_ON PORTC.OUTSET = PIN1_bm //faster than PORTC.OUT |= PIN1_bm
#define CDE_SET2_SET_OFF PORTC.OUTCLR = PIN1_bm //faster than PORTC.OUT &= ~PIN1_bm
#define CDE_SET3_SET_ON PORTC.OUTSET = PIN2_bm //faster than PORTC.OUT |= PIN2_bm
#define CDE_SET3_SET_OFF PORTC.OUTCLR = PIN2_bm //faster than PORTC.OUT &= ~PIN2_bm
#define CDE_SET4_SET_ON PORTC.OUTSET = PIN3_bm //faster than PORTC.OUT |= PIN3_bm
#define CDE_SET4_SET_OFF PORTC.OUTCLR = PIN3_bm //faster than PORTC.OUT &= ~PIN3_bm
void toggle_state();
void toggle_state()
{
if(CHANGING == true) //no new change till current one is not over so lock it beacause change is in progress
{
return;
}
if(CHANGING == false)
{
TOGGLE = !TOGGLE;
CHANGING = true;
}
}
///////////////////////////////
//SETUP
///////////////////////////////
void setup()
{
pinMode(CDE_SET1, OUTPUT);
pinMode(CDE_SET2, OUTPUT);
pinMode(CDE_SET3, OUTPUT);
pinMode(CDE_SET4, OUTPUT);
pinMode(RST_PIN_1, INPUT);
pinMode(RST_PIN_2, INPUT);
//init STATE:
TOGGLE = false; //init state NORMAL
CHANGING = false; //no change in progress
//NORMAL MODE: SET STATES FOR EACH DRIVING PINS:
CDE_SET1_SET_ON;
CDE_SET2_SET_OFF;
CDE_SET3_SET_OFF;
CDE_SET4_SET_ON;
attachInterrupt(digitalPinToInterrupt(RST_PIN_1),toggle_state,FALLING); //ANY STATE DOWN DETECTED ON RST_PIN WILL SWAP STATE
attachInterrupt(digitalPinToInterrupt(RST_PIN_2),toggle_state,FALLING); //ANY STATE DOWN DETECTED ON RST_PIN WILL SWAP STATE
}
void tempo() //tempo 10us
{
uint16_t i = 0;
//@20Mhz ==> 1 cycle = 0.000 000 050 sec = 50ns (50 nano seconds)
// 200 cycle give 10us
//need adjustements may be
while(i < 200)
{
i++;
}
}
////////////////////////////////
//LOOP
////////////////////////////////
void loop(){
switch(TOGGLE)
{
case false:
if(CHANGING == true)
{
noInterrupts(); //stop any new interrup if any
//SET ALL PINS OFF:
//CDE_SET1_SET_OFF; //ALREADY OFF
CDE_SET2_SET_OFF;
CDE_SET3_SET_OFF;
//CDE_SET4_SET_OFF; //ALREADY OFF
// tempo();
//SET NEW STATE:
CDE_SET1_SET_ON;
//CDE_SET2_SET_OFF; //ALREADY DONE
//CDE_SET3_SET_OFF; //ALREADY DONE
CDE_SET4_SET_ON;
CHANGING = false;
// tempo();
interrupts(); // inerrupt are now allowed
}
break;
case true:
if(CHANGING == true)
{
noInterrupts();
//SET ALL PINS OFF:
CDE_SET1_SET_OFF;
//CDE_SET2_SET_OFF; //ALREADY OFF
//CDE_SET3_SET_OFF; //ALREADY OFF
CDE_SET4_SET_OFF;
// tempo();
//SET NEW STATE:
//CDE_SET1_SET_OFF; //ALREADY OFF
CDE_SET2_SET_ON;
CDE_SET3_SET_ON;
//CDE_SET4_SET_OFF; //ALREADY OFF
CHANGING = false;
// tempo();
interrupts();
}
break;
}
}
Ltr
-
Dans le cas d'une simple coupure comme disjoncteur on ne pilote alors que 2 sorties CDE_SETx qui agiront comme un interrupteur.
Nous avons notre disjoncteur DCC ultra rapide et sans relais!
Je pense qu'il sera toujours préférable de confier la gestion des ces opérations de commutation à un "petit" CPU dédié exclusivement pour des questions d'efficacité et de priorisation.
Le réarmement se fera par un commande externe.
Ltr
-
Pour illustrer une version "FAST LOOP REVERSER" simple, rapide et compact voici une implémentation possible dans l'esprit "LK200".
Ltr
-
Très intéressant, vivement la suite !
Christophe
Je crois que c'est un montage dans ce style qui devrait te convenir.
Il gère nativement l'inversion de façon autonome.
Si on le désire, il rapporte à l'extérieur la position, qui peut être basculée/réinitialisée de façon externe ou localement en manuel.
Des indicateurs lumineux formalisent ces informations.
La compacité du montage et les composants mis en œuvre assureront 2.5A sans encombre voir plus.
Qu'en penses tu?
Ltr
La conso cote boucle est monitorée à l'aide de l'ACS712 et si elle dépasse un seuil sur un intervalle de temps donné on peut mettre en protection
-
Bonjour Laurent,
En effet ce montage m'intéresse beaucoup pour les satellites autonomes et c'est pour cela que je te disais que j'avais hâte d'en savoir plus, en particulier les différents composants retenus et le schéma électronique.
Pour le code, j'ai regardé ce que tu avais proposé mais je dois avouer que je suis complètement paumé. C'est assez spécifique au hard que tu utilises (MegaTiny ?) et rien ne compile chez moi.
A plus donc pour de nouveaux avancements.
Christophe.
-
Bonsoir
Voici les éléments.
J ai retenu ici un MEGATINY à 14 broches.( x4) ( utilisez MEGATINYCORE https://github.com/SpenceKonde/megaTinyCore (https://github.com/SpenceKonde/megaTinyCore))
Il couvre bien nos besoins, dispo et économique. Selon la taille du code produit on pourra mieux cibler les versions mais toutes sont éligibles.
Attention c'est expérimental à ce stade même si un certain degrés d'optimise reste de mise! :)
On se bornera avec les composants ici présents à ne pas dépasser 2.5A ( le montage peut encaisser plus)
Laurent.
-
Le layout
-
Christophe
Sur le montage tu as le OFF global avec les 4 commandes PIN_SETx @ "0" ce qui produit la coupure recherchée.
Sinon on a "l'auto sense" sur la sortie par rapport à l'entrée. et on active alors 2 des 4 sorties selon la direction recherchée.
Ltr
-
Rm: dans l'exemple de code fourni pour illustrer plus haut qui était prévu pour un MEGATINY x6 à 20 broches les ports sont différents.
Il faut donc remplacer les 4 port B du x6 part des port C sur le x4 qui ne dispose pas de port B sur son hardware.
Ltr
-
Bonsoir
Je devrais recevoir le montage exposé ci dessus en début de semaine prochaine ce qui permettra de le tester et le valider. ( il est repris sur le module de protection et d inversion des satellites autonomes V2 en approche modulaire).
En attendant j'ai repris la trame du code de celui ci.
"BETTER, (REALLY) FASTER, STRONGER & ATOMIC!" ont été la trame directive.
Par itérations successives qui permettront quelques tests intermédiaires je suis arrivé au niveau "atomic" des traitements. C'est à dire à un niveau de traitement unitaire le plus élémentaire afin de gagner en vélocité de traitement pour favoriser la réaction la plus rapide en cas de détection de court circuit.
A titre d exemple si une solution à base de l'utilisation de la fonction attachdigitalinterrupt() peut très bien fonctionner, celle ci est en fait "très longue" pour s'exécuter et il y a plus "efficace" à condition de coder cela autrement via l'utilisation des ISR du hardware. (à l'aide des vecteurs d'interruption)
A ce sujet je vous renvoie vers les très bonnes explications données par Spence KONDE à qui l'on doit les librairies DXCORE, MEGATINYCORE
DXCORE:
https://github.com/SpenceKonde/DxCore (https://github.com/SpenceKonde/DxCore)
MEGATINY CORE:
https://github.com/SpenceKonde/megaTinyCore (https://github.com/SpenceKonde/megaTinyCore)
et plus spécifiquement ces rubriques:
https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/Ref_PinInterrupts.md (https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/Ref_PinInterrupts.md)
et
https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/Ref_Interrupts.md (https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/Ref_Interrupts.md)
Ces optimisations permettent également une économie importante de ressources et permettent même de traiter sur les CPU avec de plus faibles ressources.
Verdict très bientôt donc...
Ltr
-
Bonjour
Fraichement reçu à l instant, il me reste quelques ajouts de composants à faire ( connecteurs, OPTO MOS) avant d entamer les tests en fin de semaine...
Ltr
-
J'ai un doute sur ton shéma.
Tu génères le +5v à partir du DCC, mais quand il y a un court-circuit le DCC tombe à 0 donc le 5V aussi.
-
Etienne
Il y a une "subtilité".
En effet le 5V provient bien du DCC mais du DCC coté BOOSTER/CENTRALE, partie qui n'est en principe pas coupée lors de la bascule du montage car pris en amont. Le temps de bascule du montage est en effet plus petit que celui coté centrale. (source d alim DCC)
Le montage n'est privé d'alim que si la centrale coupe et donc qu'il y a pas de besoin/possibilité de de surveiller ou d inverser.
C était un choix, mais il pourrait aussi être modifié pour une alim externe.
Dans le montage l'ACS712 prend aussi une mesure cote "boucle" qui n'inclue pas la propre conso du montage.
Le reste est encore à éprouver naturellement. Le code compile. A tester donc avec tous les assemblages finalisés.
Ltr
-
Bonjour
Premier tests:
Programmation du montage: petit écueil il faut pour cela "démonter" la résistance reliée au port UDPI pour pouvoir programmer le chip.( sinon message d erreur! Et prog impossible.)
Je devrai ajouter un "bridge" pour éviter ce genre de manip à l'avenir pour la phase injection.
En fait le port UDPI est utilisé non pas de façon exclusive pour la programmation mais comme GPIO d'usage général en mode RUN. (c'était un choix d attribution de broches qui pourrait être résolu par la sélection d'un CPU avec plus d IO et garder le port UDPI de façon exclusive)
Aussi ceci a pour conséquence aussi qu'en écrivant les fuses du CPU il faut alors disposer d'un programmateur à "haute tension" pour le "debriker" si on a flaché les fuses pour passer la broche UDPI en GPIO. 8)
En version finale tout ceci ne sera pas nécessaire puisque tout le travail en amont de mise au point aura été réalisé.
On a la possibilité d'en fabriquer un soit même pour un cout assez modique en suivant les info disponibles ici:
http://www.technoblogy.com/show?48MP (http://www.technoblogy.com/show?48MP)
L'autre alternative est d'utiliser des programmateurs disposant de cette option d'injection du 12V en mode "récupération".
A priori un PICKIT4 fait le job.
N'en disposant pas (je suis équipé entre autre d'un ATMEL-ICE) et après quelques recherches je suis tombé sur "le produit qui va bien" pour m'aider dans cette phase de trouble shoot.
Un "debriker" autonome.
Plusieurs versions du produit existent. L'une est exclusive aux MEGATINY, autre supporte les AVR Dx et les MEGATINY.
Version MEGATINY
https://www.tindie.com/products/microprogrammers/attiny-updi-high-voltage-fuse-repair-programmer/?pt=ac_prod_search#product-description (https://www.tindie.com/products/microprogrammers/attiny-updi-high-voltage-fuse-repair-programmer/?pt=ac_prod_search#product-description)
Version AVR Dx et MEGATINY:
https://www.tindie.com/products/microprogrammers/dual-mode-high-voltage-updi-fuse-repair-programmer/ (https://www.tindie.com/products/microprogrammers/dual-mode-high-voltage-updi-fuse-repair-programmer/)
Je suis donc en attente de la réception de ce précieux outils de mise au point. En attendant je vais utilisé un autre carte pour tester. Seule sera indisponible temporairement la notification externe de CC.
A noter que le site propose différents petites cartes bien utiles. (dont des cartes de tests de CPU, des programmateurs, ...)
J ai par exemple utilisé avec bonheur cette carte de programmation autonome:
https://www.tindie.com/products/microprogrammers/avr-updi-standalone-mass-production-programmer-v2/ (https://www.tindie.com/products/microprogrammers/avr-updi-standalone-mass-production-programmer-v2/)
En gros on y injecte le code compilé de la puce que l'on veut programmer, on configure quelques options depuis un menu (flash des fuses par exemple) et ensuite plus besoin de PC. On relie ce programmateur autonome au chip en question et la pression d'un bouton fera la reste avec un affichage visuel sur led du résultat produit.
Bon voila... la suite très bientôt :)
-
Etienne
Il y a une "subtilité".
En effet le 5V provient bien du DCC mais du DCC coté BOOSTER/CENTRALE, partie qui n'est en principe pas coupée lors de la bascule du montage car pris en amont. Le temps de bascule du montage est en effet plus petit que celui coté centrale. (source d alim DCC)
Le montage n'est privé d'alim que si la centrale coupe et donc qu'il y a pas de besoin/possibilité de de surveiller ou d inverser.
C était un choix, mais il pourrait aussi être modifié pour une alim externe.
Dans le montage l'ACS712 prend aussi une mesure cote "boucle" qui n'inclue pas la propre conso du montage.
Le reste est encore à éprouver naturellement. Le code compile. A tester donc avec tous les assemblages finalisés.
Ltr
Je ne parle pas du moment où ça bascule, mais du moment où on a le court-circuit.
U = R * I
R = 0 -> U = 0
Ta centrale ne produit plus de volts ou presque au moment du court-circuit. Tu auras un petit voltage résiduel dù à
la résistance des fils mais si tu es proche de la voie et loin de la centrale il en reste encore moins dans ton circuit.
-
Bonjour
Mes tests se sont poursuivis avec des succes et quelques "déconvenues".
Outre une petite erreur de codage finalement corrigée j'ai pu valider les éléments suivants:
bascule des optonmos selon une commande issue de du CPU
traitement visuel de l'info sur les leds.
maintenant les conditions de déclanchement sont à revoir.
J avais pensé utilisé les interruptions matérielles liées aux pins ( A1 A2 A3) mais à l usage... il y a trop de rebonds. Et je pense qu'il faut un bon petit "debonce" dans la boucle dont la valeur va être à trouver (peut être autours de quelques dizaines de uS? je prends vos avis!)
AttacheInterupt() sera donc de mise!
Laurent
-
Quand un cc est détecté tu inverse la polarité des rails et il faut lancer un timer.
A cause des condensateurs le détecteur va continuer à afficher le cc (il faut que tu mesures ce temps de retour à 0)
et il ne faut pas réinverser la polarité pendant ce temps.
Après ce temps si le cc existe toujours il faut déclencher la protection sinon on stoppe le timer après un certain temps.
Mais tant que le timer tourne on n'inverse pas la polarité.
Tu peux mettre le reset du timer à 1 seconde. On n'a pas besoin de plus rapide pour une boucle de retournement.
-
Bonjour Etienne
A quel type de "timer" pense tu? :
un comparo avec un seuil sur micros()- xxx >seuil de bascule avec une boucle while() par exemple
ou un timer hardware ( type TIMERB) dont on surveille le CNT au niveau du seuil et dont le start est fait par la confirmation post debounce de l interruption de bascule de la condition?
D'autres propositions?
Ltr
-
2 boucles while avec 2 valeurs de temps :
on attend que le cc revienne à 0 ou qu'on atteigne T1
si on atteint T1 avant que ça revienne à 0 c'est un vrai cc donc on coupe
sinon deuxième while jusqu'à T2 et on remet tout à 0
-
Chronologie :
0 court-circuit
1er while
Ta tu inverses donc plus de cc (ou pas)
Tb les condos sont déchargés si pas de cc -> la 1ère boucle while se termine si pas de cc
T1 la 1ère boucle while se termine avec cc donc on coupe
2ème while
T2 on reset
Donc réaction rapide pour boucle de retournement et temps de réaction T1 pour les vrais cc.
-
Bonjour Etienne
J'avais la trame suivante en tête:
a/CC
b/ détection CC sur broche d'interruption par bascule de son état (selon le montage en entrée soit RISING soit FAILLING)
c/ ISR avec bascule d une variable xx= z d'un GPIOR ( ultra rapide)
d/ exploitation de cette variable dans la loop du programme principal : if(variable ==z)
Debounce de cette variable par confirmation sur un delais antirebond via lecteur valeur de brcohe et lock du process (if ((PORTx.IN & 0bxxxxxxxx) = 0bxxxxxxxx)) ( on pourrait voir la pour mettre un timer hardware typeB et compter jusau à un evaleur du CNT qui nous donne un delais à exploiter)
transformation de cette variable en xx=y si OK sinon après un delais recheck des conditions sur les broches d interruption par un if ((PORTx.IN & 0bxxxxxxxx) = 0bxxxxxxxx)
e/ dans la loop exploitaiton de la variable xx = y avec les actions de bascule (toogle en entrée puis application des valeurs sur les broches) puis purge du statut de cette variable xx= z qui est le mode run usuel.
Voila un peu à quoi cela pourrait resembler:
void loop()
{
if(STATE == PROTECTION_MODE)
{
CIRCUIT_BREAKER_OPEN();
LED_NRM_OFF;
LED_REV_OFF;
LED_CC_ON;
}
if(STATE == CC_DETECTED)
{
//WE DEBOUNCE HERE CC STATE
// 1/ CHECK PORT STATUS:
// FIRST STATUS CHANGE TAKE IN COUNT ONLY TO SET LOCKER
noInterrupts();
if(((PORTA.IN & 0b00000110) == 0b00000110) && (LOCK_CHANGE == false)) //PIN PA1 or PA2 IN @ HIGH STATE DUE TO CC
{
//DEBOUNCE
LOCK_CHANGE = true;
interrupts();
lastDebounceTimeinus = micros();
}
//DISCARD ANY BOUNCE IF CHANGE YET IN PROGRESS AFTER FIRST CHANGE: SO ANY NEW CC INTERUPT WILL BE IGNORED TILL CHANGE IS NOT OVER
if(((PORTA.IN & 0b00000110) == 0b00000000) && (LOCK_CHANGE == true)) //PIN PA1 or PA2 or both IN LOW STATE
{
//CANCEL ANY BOUNCE EFFECT
STATE = CC_DETECTED;
}
if(LOCK_CHANGE == true)
{
if(micros() - lastDebounceTimeinus > debounceDelayinus)
{
noInterrupts();
//DEBOUNCE DONE SO NEED TO UPDATE STATUS TO CONFIRM IT
LOCK_CHANGE = false; //RELEASE LOCKER
STATE = CC_CONFIRMED; //UPDATE STATUS FOR NEXT STEP
interrupts();
return;
}
else if(micros() - lastDebounceTimeinus < debounceDelayinus)
{
//NO CHHANGE YET
STATE = CC_DETECTED;
}
}
else if(LOCK_CHANGE == false)
{
if((micros() - lastDebounceTimeinus > debounceDelaytimeoutinus))
{
noInterrupts();
LOCK_CHANGE = false; //RELEASE LOCKER
STATE = NORMAL_RUN_MODE; // SWAP IN NORMAL RUN MODE
interrupts();
return;
}
else
{
STATE = CC_DETECTED;
}
}
Surement encore très perfectible...
Laurent
-
attention deux erreurs de syntaxe non détectées par le compilateur:
STATE == CC_DETECTED
au lieu de
STATE = CC_DETECTED
2 fois
-
Merci Etienne
Je travaillais dessus en y apportant quelques modif également et je les avais corrigé entre temps.
J'ai donc actualisé le code aussi en quelques points. (dans la trame if STATE == CC_DETECTED) correspondant à timing avant rebascule.
Mais tout n'est pas encore finalisé J y travaille et toute aide comme la tienne est appréciée et bienvenue
Encore merci
Ltr
-
Bonjour
J'ai reçu mon "DEBRIKER".
Il n'y a plus qu'à le mettre en œuvre!
Ltr
-
Bonjour
Utilisé avec bonheur et simplicité hier soir!
Remarquable, simple et efficace!
Un outils très utile finalement.
Laurent.
-
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
-
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.
-
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
-
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.