[gwion]

Je vais dire un truc très bête mais je ne les compte plus depuis longtemps...
Pour une carte qui va fonctionner hors de la vue de tout le monde, est-il vraiment utile de mettre à jour en permanence et en temps réel un affichage LCD ?

[paulfjujo]

Je vais dire un truc très bête mais je ne les compte plus depuis longtemps...
Pour une carte qui va fonctionner hors de la vue de tout le monde, est-il vraiment utile de mettre à jour en permanence et en temps réel un affichage LCD ?

c'est pas faux, mais en supposant qu'on puisse l'activer momentanement, la duree de traitement des datas à afficher
interviendra quand meme dans la duree de boucle ...
le seul avantage serait de moins consommer, user le lCD ..

quelques mesures de durée d'execution (Fosc=64MHz! 1cycle = 62.5nS )

duree d'exec. de 2 mesures INA1 et INA2 (sans afficher les mesures!)
SMT1 Nb Tics 5272 uS (avec recup de U induit,shunt,Alert,mA)
en optimisant :
duree d'exec. de 2 mesures INA1 et INA2
SMT1 Nb Tics 3848 uS avec seulement mesure de courant mA

duree d'exec. lecture MCP23017B AVEC affichage bits sur terminal YAT à 115200bds
ALRM= 1,PTNC =1,Radar=1,TCAR=1 ,TCAJ=1,Delai=0,ASbc=0,Butee=0
SMT1 Nb Tics 9948 uS .... la partie affichage sur terminal prend > 9mS !

Duree d'excution lect MCP23017-B via structure SANS affichage
SMT1 Nb Tics 428 uS


duree d'exec affichage 1 ligne sur LCD 'y compris le formatage prealable de la donnée à afficher)
SMT1 Nb Tics 18872 uS
donc LCD 4 lignes < 100mS

[gwion]

J'ajoute que je ne suis pas certain qu'un LCD soit l'idéal si la carte est dans un coffret au niveau du portail. Il va devoir supporter la température.

[Babar64]

Bonjour à tous,

Source du message #200 : Oui, sans MCP si le rajout du PORT D 8 bits et 3 bits Port E est suffisant

C'est possible, si on traite 4 entrées sur 2 ports en 2 paires analogiques soit A0 et A1 en entrées Ana (0v ;2,5v ; 5v)... Mais je dois refaire tout le PCB (!!!)
Si c'est vraiment une (bien) meilleure solution, notamment du point de vue codage et durée de boucle, je m'y collerais

Source du message #200 : à mon avis , la problématique soulevée sur la durée globale de la boucle principale , peut être levée (...) en remplaçant les diverses tempo de xmS (...)

Aucune idée des conséquences. Les temps pour le LCD dépendent je suppose de ce que l'on veut rafraichir. On peut envisager de supprimer l'affichage de position des vantaux et du taux duty en cours, pour ne garder que les mesurages INA... si ça joue vraiment sur la durée de boucle...
A+

[paulfjujo]

Bonjour à tous,

Source du message Oui, sans MCP si le rajout du PORT D 8 bits et 3 bits Port E est suffisant

C'est possible, si on traite 4 entrées sur 2 ports en 2 paires analogiques
soit A0 et A1 en entrées Ana (0v ;2,5v ; 5v)... Mais je dois refaire tout le PCB (!!!)
Si c'est vraiment une (bien) meilleure solution, notamment du point de vue codage et durée de boucle, je m'y collerais

Source du message à mon avis , la problématique soulevée sur la durée globale de la boucle principale ,
peut être levée (...) en remplaçant les diverses tempo de xmS (...)

Aucune idée des conséquences. Les temps pour le LCD dépendent je suppose de ce que l'on veut rafraichir.
On peut envisager de supprimer l'affichage de position des vantaux et du taux duty en cours,
pour ne garder que les mesurages INA... si ça joue vraiment sur la durée de boucle...
A+

si avec un 47K42 il faut utiliser 2 voies ana pour 4 entrees simili TOR , ça ne vaut pas le coup !
d'autant que via cette solution les entrees definies ne doievnt pas etre concomittentes.

le temps pour le LCD est evalué < 100mS quelque soit le contenu d'affichage 4 lignes.
on peut aussi jouer sur l'affichage alterné : rafraichir les lignes une par une ... à chaque tour de boucle
LCD rafraichit globalement en 4 tours..
necessiterait que 20mS du temps global boucle .

je dirai donc, laisser la config telle que prevue avec 18F27K42 + MCP

remarque:
MPLAB XC8 est bridé dans sa version gratuite ...
j'ai deja remaqué que dans certaines application XC8 prenait 2 à 8 fois plus de temps que pour la meme
appli compilée en MikroC 7.60 Pro
( mais qui était payante ! et n'existe plus ,car remplacée depuis par NECTO STudio en 2021...

je ne sais pas ,si en desinstallant completement MPLABX IDE,XC8 ...etc...
et en le re-installant, on pourait profiter
de l'essai 30jours en version NON bridée ...
ou est-ce qu'un Fantaspicien pourrait le recompiler avec une version non bridée pour en mesurer
les effets de reduction temps d'execution ..

L'organisation du programme doit pouvoir permettre une duree de boucle ,donc un temps de reactivité acceptable ...
Ne pas oublier qu'un contact sec connecté sur entre PIC doit passer un delai anti rebond de quelques mS , pour etre validé
Le PIC pouvant reagir sur quelques cycle de 62nS

La duréee de boucle n'est peut etre pas le point primordial sur lequel il faut s'attarder.

[Babar64]

(...) si avec un 47K42 il faut utiliser 2 voies ana pour 4 entrées simili TOR , ça ne vaut pas le coup ! (...) je dirai donc, laisser la config telle que prévue avec 18F27K42 + MCP (...) La durée de boucle n'est peut être pas le point primordial sur lequel il faut s'attarder.

OUF! 1) ça me libère de mes inquiétudes et 2) je garde les schéma et PCB actuels.

A+

[Babar64]

Bonjour,

Pour une carte qui va fonctionner hors de la vue de tout le monde, est-il vraiment utile de mettre à jour en permanence et en temps réel un affichage LCD ?

L'implantation sur carte du LCD a 2 utilités : 1) Faciliter les réglages sur site, 2) indiquer l'état et la circonstance de la survenue d'une anomalie (par exemple quelle surcharge subie par quel moteur).

Je ne suis pas certain qu'un LCD soit l'idéal si la carte est dans un coffret au niveau du portail. Il va devoir supporter la température

Pas faux! Mais l'armoire électrique de commande est protégée sous abri, et les batteries étant incluses, elle dispose d'une ventilation statique (finement grillagée : couleuvre oblige!).
Mais effectivement, à des températures sous abri à plus de 50°C, on serait mal... le LCD, et nous avec
A+

[Babar64]

LO à tous,
Je fais le point au niveau du schéma, avec la version V10.0.0.
Le document complet n'étant pas bien lisible, je l'ai éclaté.

V10.0.0 Complet :

(V10.0.0) Schéma COMPLET.pdf

V10.0.0 Eclaté :

DETAILS - Moteur+Chargeur+Périphériques+Maison.pdf

Note :
Sur cette version, seule une connectique a été ajoutée pour un arrêt moteur d'urgence par coup de poing : On m'a indiqué que ce dispositif serait désormais obligatoire...
Bien que n'ayant pas pu vérifier la véracité de cette info, je pense que ça tient quand même du bon sens de l'inclure.

Vos avis et remarques sur cette base hardware seraient bienvenus avant de reprendre l'étude du soft
A+ à tous

[Babar64]

Je reviens sur une remarque faite par Paul dans son post #190 à laquelle je n'avais pas répondu :

Source du message Certaines mesures / paramètres INA pourront être éliminés pour simplifier : mesure de puissance, mesure de tension induit , détection ALERTE (puisqu'on est en hardware)

OK pour les mesure de puissance et mesure de tension induit, mais pas pour la détection ALERTE qui reste à être reprise au PIC (Alert_inPC0 pin11) pour des affichages (LCD et LEDS).
A+

[paulfjujo]

oops Je reviens sur une remarque faite par Paul dans son post #190 à laquelle je n'avais pas répondu :

Source du message Certaines mesures / paramètres INA pourront être éliminés pour simplifier : mesure de puissance, mesure de tension induit , détection ALERTE (puisqu'on est en hardware)

OK pour les mesure de puissance et mesure de tension induit, mais pas pour la détection ALERTE qui reste à être reprise au PIC (Alert_inPC0 pin11) pour des affichages (LCD et LEDS).
A+

les 2 mesures ina1 ina2 initiales prenant la plupart des infos dispo dans l'INA prenaient 5.27mS
en ne recuperant que la mesure mA -> < 3.5mS

lire le flag Alerte (registre interne INA) n'est pas utile ,puisque ALERT est traité au niveau hardware,
sortie harw ALERT INA -> sur input RC0 du PIC
Pin RC0 traitée via interruption , pour annuler les consignes %PWM et monter le flag ALERT_STATUS

Code : Tout sélectionner



void __interrupt(irq(IRQ_IOC), high_priority) IOC_ISR(void) {
    unsigned char i;
    const char *p2 = "ALERT\r\n";
    if ((IOCCF & 0x01) == 1) // RC0
    {  //message sur terminal YAT
        for (i = 0; i < 7; i++) {
            while (!U1TXIF) {
            };
            U1TXB = *(p2 + i);
        }
        Led_Rouge = 0; // allume led
        ALERTE_STATUS = 1;
        k1_PWM = 0;
        k2_PWM = 0;
        IBT2_Enable=0;
        IOCCF = 0x00;
    }
 

Arret d'urgence aussi sur ALERT INA ...donc -> RC0 -> flag ALERTE_STATUS

Question: comment connaitre l'origine de cette ALERT
quel vantail ?
il faudra peut etre mémoriser les derniers mesures de courant INA1 et INA2 à l'instant de l'ALERT
ou figer les mesures sur LCD (ne plus les rafraichir)
ou est-ce utile ?
voir l'etat des vantails suffisant pour diagnostiquer la cause

Arret sur courant superieur en mode vitesse Lente .. ou seuil courant vitesse rapide sur l'un ou sur l'autre
detectées en polling (dans la boucle principale)
ne plus rafraichir les mesures INA pour garder les dernieres mesures de courant ,restant affichées sur le LCD