[Resolu] Pseudo miltiplexeur

[spheris]

Bonjour et bonne année à tous.
J'ai une question d'ordre générale.

J''ai un automate avec 8 relais no en sortie.
Je dois piloter 40 petits ventilateurs de pc en 12vdc pour une maquette pour un projet à grande échelle de traitement d'air
Je n'ai aucune contrainte de temps.
Mon idée première est de fabriquer un genre de multiplexeur 8 entrées et 40sortie relais comme ceci:
Je recois un code 8bits des relais de l'automate que je convertis en sortie active sur tel ou tel relais.
Un exemple:
1 en decimal soit 00000001(1relai allumé sur automate) allume le relais R1 (premier relai des 40 en sortie)
2 decimal ou 00000010 (2eme relai allumé sur automate) eteind le relai R1 etc...
Je maitrise la programmation picaxe pour ce genre de projet.
Pensez vous que 4 picaxes soient appropriés pour cette application ou existe -t-il un système déjà tout fait?
Merci pour votre réponse.

 

[spheris]

Un petit schéma vaut mieux qu'un long discours.
J'ai oublié de préciser que je maitrise le programme automate sur un petit millenium crouzet que j'avais en stock.

Sans vouloir trop rentrer dans le détail, je vous passe toute la partie régulation de l'automate en fonction des sondes d'entrée. Voilà pourquoi le besoin nécessaire de cet automate.

 

[MGU]

Bonjour,
Je ne comprends pas bien la question.
Un octet, ça fait 256 combinaisons.
40 ventilateurs, si il faut les commander individuellement, il faut 5 octets
On peut lire 5 fois un octet en entrée et commander les ventilos par bloc de 8, (avec 5 x 74HC 595 ?)
Alors, on fait quoi?
MM

 

[Technoman]

Bonsoir,

Pour ce projet, je pense que l'utilisation de l'automate Crouzet avec des sorties relais n'est pas la plus appropriée.

Selon la consommation de vos ventilateurs, avec des circuits tels que :

• Utilisation d'un seul Picaxe (08M2, ...) :
  Avec 5 registre à décalage de type 74HC595, comme proposé par MGU (8 mA maxi par sortie)
  5 x registres à décalage de puissance comme le TPIC6C595N (Texas Instruments) (100 mA maxi en continu par sortie)
  Une combinaison 74HC595 + ULN2803 (500 mA maxi par sortie).
  Il existe de nombreuses cartes toutes faites (breakout board) avec ces deux circuits intégrés.
  Un autre exemple : https://www.electronics-lab.com/project/72-channels-serial-parallel-driver-board-using-74hc595-uln2803/
  Pour une consommation importante, 5 x cartes 74HC595 + 3 x cartes avec sorties à 16 relais. Voir sur le Net.
  
  
• Utilisation d'un seul Picaxe avec davantage de sorties (18M2, ...) : 8 sorties + 5 strobes (verrouillages) + 1 clear (RAZ)
  5 x latchs de type 74HC574 (35 mA maxi par sortie)
  5 x latchs de type MIC5801 ou équivalent (500 mA maxi par sortie).
  Pour une consommation importante, 5 x 74HC574 + 3 x cartes avec sorties à 16 relais.
  

 

[MGU]

On pourrait peut être aussi utiliser 5 PCF8574 en I2C, avec des amplis ULN derrière.
MM

 

[spheris]

MGU, Technoman,
Merci pour vos réponses.
A) pour l'automate, comme je le disais, il est la source de régulation des ventilations en amont en fonction des sondes, je ne peux pas l'enlever, et dois faire malheureusement avec.
B) L'idée de registres à décalage est excellente.
J'ai donc pensé à un schéma comme ceci. Bien entendu adapter le nombre de picaxe pour le nombre de sortie.
Pensez-vous qu'il faille mettre une opto isolation? et si oui à quel étage?
Les relais sont-ils nécessaires ou je peux piloter les ventilos directement avec les ULN?

 

[spheris]

MGU,
Pour répondre à votre première réponse, l'automate envoi bien 1octet soit comme vous l'avez dit 256 combinaisons.
40 appareils à piloter avec chacun une marche et un arrêt, cela fait 80 commandes de pilotage. les 256 combinaisons couvrent largement mon besoin.
L'idée de départ était que les 8 broches de sortie de l'automate sont reliées sur les 8 picaxes (sortie relais 1 sur tous les C.0 des picaxe, relais 2 sur tous les C.1 etc...), et en fonction de l'octet reçu, ils activent telle ou telle sortie par un:

read pinC, b1
if b1 = &00000100 then high B.2
if b1 = &00001000 then low B.2


C'était sans connaitre l'existence de registre à décalage.
Encore merci pour cette précieuse info.

 

[Technoman]

La fréquence de changement du code 8 bits sera probablement faible. Les relais ont des contacts présentant des rebonds que les circuits logiques, beaucoup plus rapides, vont "voir" : selon la configuration, un filtrage RC sera peut être nécessaire et/ou avec du code.

L'utilisation d'optocoupleurs ne me parait pas nécessaire, les relais isolent de la partie automate : 12V commuté par des transistors collecteur ouvert alimente les ventilateurs et du 5V pour alimenter les Picaxes.

 

[MGU]

40 appareils à piloter avec chacun une marche et un arrêt, cela fait 80 commandes de pilotage. les 256 combinaisons couvrent largement mon besoin.

Bonjour,
Ben non, ou alors, j'ai rien compris...
Si la position de chaque bit d'UN octet correspond à la position ON/OFF d'UN ventilo, il faut un octet pour 8 ventilos. Les 8 positions ON/OFF font 259 combinaisons
Donc, si il faut UN octet pour UN groupe de 8 ventilos, pour 40ventilos, il faut 5 octets.
MM

 

[spheris]

MGU,
Excusez moi je me suis mal exprimé. Ce n'est pas la position du bit qui fait le déclenchement de tel ou tel ventilo, c'est la valeur de l'octet qui fait office d'adresse pour pointer le ventilo et son état.

Exemple:
Pour le transcrire en décimal si je n'ai qu'un seul octet :
1 allume le 1er ventilo soit l'octet 00000001
2 arrête le premier ventilo soit l'octet 00000010
3 allume le 2eme ventilo soit soit l'octet 00000011
4 arrête le 2eme ventilo soit l'octet 00000100
Etc... soit 80 combinaisons pour 40 ventilos.
les 8 broches pinC recoivent le code de l'octet et allume le B.x correspondant.

Technoman,
Dans mon premier message, je signifiais que je n'ai aucune contrainte de temps. Toutefois ,vous avez raison, un flitre RC sera le bienvenue à l'entrée du picaxe.

 

[MGU]

Ok, donc l'octet sortant de l’automate contient deux infos, l'adresse du ventilo (son n°) et son état ON/OFF.
On divise l'octet par 2, le reste (0 ou 1) est l'état, le quotient est le n° du ventilo.
Je verrais un codage simple:
10 => arrêt du ventilo 1
11=> marche du ventilo 1
10001 => marche du ventilo %1000= 8

Je verrais bien des PCF, le codage des shiftout n'est pas prévu sur la série M
MM

 

[Technoman]

La combinaison Picaxe (18M2, ...) + PCF + ULN (ces 2 circuits sont disponibles en cartes breakout) est une solution élégante. Le Picaxe échantillonnerait les 8 sorties relais dont un pôle est relié à une résistance de Pull-down (tirage à GND) OU de Pull-up (tirage à +5V), puis filtrage RC ou avec du code. Une table ou un algorithme de calcul donnerait la correspondance entre le code 8 bits délivré par l'automate, le PCF concerné (plage de codes) et la sortie ventilateur activée/désactivée.

 

[MGU]

Pour traiter des octets, je préfère le 20M2 (j'aime pas le 18M)
MM

 

[MGU]

D'après la doc, les sorties PCF sont capables de 20mA.
Avec les relais statiques: https://www.gotronic.fr/art-module-a-4-relais-statiques-ssr01-31503.htm
Il en faudrait 10...
Plus besoin d'ULN
MM

 

[Technoman]

Le 20M2 est celui qui présente le meilleur rapport nombre E/S / prix. J'évoquais à minima le 18M2 car le 08M2 n'a pas le nombre d'entrées nécessaire.
Les actionneurs sont des ventilateurs de PC 12V avec une consommation sans doute faible (xxx mA?) ; L'interface de puissance avce des ULN fera sans doute très bien l'affaire. Les relais statiques sont adaptés pour commuter des charges sur le secteur 230V.

 

[PieM]

Bonjour à tous,
Je prends un peu le train en marche, et j'ai dû rater un wagon... Je ne comprends pas ce que l'API sort comme info. dire qui a 256 positions est effectivement une erreur car chaque ventilo doit être adressé individuellement sans changer l'état des autres.
Donc l'API doit envoyer sur un octet, le numero du ventilateur, et son état, a chaque changement d'état. Bien d'accord avec Michel en #11. Est ce bien OK pour sphéris pour l'automate?

 

[spheris]

Piem,
Je ne suis pas allé si loin dans mon simple raisonnement.
Je me suis fais un plan mémoire ultra simple sur mon octet de 255 combinaisons.
1 : j'allume le ventilo 1
2: j'arrete le ventilo 1
3 : j'allume le ventilo 2
4 j'eteinds le ventilo 3 etc...
L'octet reçu est simplement une adresse de mon plan mémoire.
2 adresses pour un ventilo : 1 qui l'allume, une qui l'eteind.
C'est le picaxe programmé qui effectue ce que je veux dans le plan (eteindre ou allumer tel ou tel)

ainsi si le picaxe recoit respectivement 7,9,13,8 à 5 secondes d'intervalles par exemple, veut dire Ventillo 5ON,v6on, v8on, v5off.
Remarque :
c'est vrai que pour des raisons d'optimisation du code, j'aurais pu dire :
1 allume V1,
2 allume V2

51 eteind V1
52 eteind V2 etc


TEchnoman, entièrement d'accord avec vous.
Par convention, pour mon stock personnel et pour tous mes projets, le 20M2 est de loin le plus pratique et le moins limité pour toutes mes applications. je n'utilise que celui là depuis le début.

 

[PieM]

2 adresses pour un ventilo : 1 qui l'allume, une qui l'eteind.

Ce qui revient à dire: une adresse par ventilo sur 6 bits + 1 bit d'état.
Sinon je ne comprends pas comment seront adressés les expandeurs PCF sans complication inutile.
Quel est le rôle de l'automate en dehors de gérer ces ventilos ?
Mettre des ventilateurs de PC pour une maquette est un peu luxueux. Visualiser par de simples leds serait plus économique.
A moins que l'automate soit strictement nécessaire, une solution directe Picaxe serait beaucoup plus simple.
Une réalisation ancienne avec gestion de plus de 40 aiguillages d'un réseau ferré avait été discutée ici : Réseau

 

[MGU]

Bonjour,
Je ne connais rien aux automates. Mais je suppose qu'il donne le numéro du ventilo concerné.
On prend ce n°, on le multiplie par 2, et on ajoute 0 pour "OFF" et 1 pour "ON"
Suivant ce principe, je suppose que les 40 ventilos sont connectés aux sorties de 5 PCF, par groupe de 8
Si le n° du ventilo est 22, il faut retrouver le PCF concerné et la sortie concernée.
Voici un embryon de code

; Décodage adresses et commandes pour 40 ventilo
; Chaque ventilo a un n° de 0 à 39
; Ls ventilos sont reliés par grouge de 8 à 5 PCF adresés de 0 à 4
; Le n° du ventilo est complété d'un bit de commande (poids faible)
; Les 8 bits du code en entrées // sont scannés par un boucle infinie
; L'octet généré par l'automate est lu sur les entrées C
; Lorsqu'il est détecté une modif du code entrée, le nouveau code est lu et traité
; Les ventilos, numéroté de 0 à 39 sont commandés par 5 PCF
; 0 à 7 => PCF0 ;8 à 15=> PCF1; 16 à 23 +> PCF 2 ; 24 à 31 => PCF3 ; 32 à 39 => PCF4

symbol etat=bit0        ;0=OFF; 1=ON
symbol code=b1    ;        ;code en mémoire
symbol leccode=b2        ;code automate scanné sur les entrées C
symbol numvent=b3        ;numéro du ventilo
symbol numPCF=b4        ;numéro du PCF concerné
ymbol NventPCF=b5        ;numéro du vent dans le PCF concerné
dirsC= %0                 ;toutes les entrées C en entrées
    code=pinsC            ;ancien code mémorisé, ici on lit les entrées
    do                     ;scan des entrées C
        leccode=pinsC
    loop while code=leccode
    code=leccode    ;Le code a changé...
    etat=code//2    ; bit poind faible=état (OFF ou ON)
    numvent=code/2    ;n° du ventilo de 0 à 39, Suite avec ex numvent=22 
    ;****************
    numPCF= numvent/8    ;donne le n° du PCF concerné de 0 à 4 Ex:22/8= 2
    NventPCF=numPCF * 8  ; calcul intermédiare Ex: 2 x 8 =16
    NventPCF=numvent-NventPCF ; n° du vent dans le PCF concerné Ex: 22-16=6
    ; C'est le bit n°6 du PCF2 qui est concerné => Y a plus qu'à....

MM

 

[PieM]

Oui Michel, c'est effectivement le plus logique mais l'ami sphéris veut sortir 80 octets sur ses relais qui sont des output de son API!. On pourrait considérer que les octets pairs sont une mise à l'arrêt et inversement pour les impairs. Je ne comprends toujours pas pourquoi il faudrait doubler les octets en sortie.

 

[MGU]

Oui Michel, c'est effectivement le plus logique mais l'ami sphéris veut sortir 80 octets sur ses relais qui sont des output de son API!. On pourrait considérer que les octets pairs sont une mise à l'arrêt et inversement pour les impairs. Je ne comprends toujours pas pourquoi il faudrait doubler les octets en sortie.

On ne sait pas tout...
Pour compléter ma réponse précédente, je pense que faudrait en mémoire une image des 5 octets de configurations PCF, en RAM, ou autre, pour modifier le bit concerné et renvoyer l'octet modifié.
Setbit et clearbit ne sont pas dispo sur les M2. Si on est pas à 2 euros près, il y a le 20X2, sinon, on se débrouille...
Il y a encore un peu de travail....pour l'ami sphéris.
MM

 

[PieM]

C'est effectivement ce qui avait été fait pour la gestion réseau ferré, avec une écriture en eprom pour garder l'état en cas de coupure de courant.
Mais difficile de donner des avis sur quelque chose de parcellaire...

 

[MGU]

J'ai continué sur la même idée, je sais pas si ça servira...

; Décodage adresses et commandes pour 40 ventilo
; Chaque ventilo a un n° de 1 à 40
; Ls ventilos sont reliés par grouge de 8 à 5 PCF adresés de 0 à 4
; Le n° du ventilo est complété d'un bit de commande (poids faible)
; Les 8 bits du code en entrées // sont scannés par un boucle infinie
; L'octet généré par l'automate est lu sur les entrées C
; Lorsqu'il est détecté une modif du code entrée, le nouveau code est lu et traité
; Les ventilos, numéroté de 0 à 39 sont commandés par 5 PCF
; 0 à 7 => PCF0 ;8 à 15=> PCF1; 16 à 23 +> PCF 2 ; 24 à 31 => PCF3 ; 32 à 39 => PCF4
; La config des octets PCF est mémorisé en EEPROM, octets 0 à 4
;pilotage 40 ventilos par PCF MM 08/01/23
#picaxe 20X2
symbol etat=bit0        ;0=OFF; 1=ON
symbol code=b1    ;        ;code en mémoire
symbol leccode=b2        ;code automate scanné sur les entrées C
symbol numvent=b3        ;numéro du ventilo
symbol numPCF=b4        ;numéro du PCF concerné
symbol NventPCF=b5    ;numéro du vent dans le PCF concerné
symbol octPCF=b6        ;octet PCF en mémo EEPROM
symbol adPCF=b7        ;adresse I2C des PCF 0 à 4
    dirsC= %0             ;toutes les entrées C en entrées
    code=pinsC            ;ancien code mémorisé, ici on lit les entrées
    do
        do                     ;scan des entrées C
           pause 1000    ;temps de modification code
            leccode=pinsC
        loop while code=leccode
        code=leccode    ;Le code a changé...
        etat=code//2    ; bit poind faible=état (OFF ou ON)
        numvent=code/2    ;n° du ventilo de 0 à 39, Suite avec ex numvent=22
        ;****************
        numPCF= numvent/8    ;donne le n° du PCF concerné de 0 à 4 Ex:22/8= 2
        NventPCF=numPCF * 8  ; calcul intermédiare Ex: 2 x 8 =16
        NventPCF=numvent-NventPCF ; n° du vent dans le PCF concerné Ex: 22-16=6
        ; C'est le bit n°6 du PCF2 qui est concerné => Y a plus qu'à....
        read numPCF, octPCF        ; lecture de l'octet PCF concerné
        If etat=1 then
            setbit octPCF,NventPCF        ; on met à 1 le bitn°6 de l'octet octPCF
            else clearbit octPCF,NventPCF    ; on met à 0
        endif
        write numPCF,octPCF
        lookup numPCF,(%01000000,%01000010,%01000100,%01000110,%01001000),adPCF ; adresses PCF de 0 à 4
        hi2csetup i2cmaster, adPCF, i2cslow, i2cbyte
        hi2cout (octPCF)    ;envoi nouvel octet dans PCF
    loop

On peut toujours en discuter.
MM

 

[PieM]

Michel, ton programme est logique et parfait, mais le problème va se situer en amont!
Comme le disais Technoman fort justement, l'utilisation d'un automate n'est pas appropriée.
Je serais curieux de voir le Grafcet lié à ce projet.
Si on suppose que tous les ventilateurs doivent être mis en marche, ou à l'arrêt, dans un cycle de scrutation de l'API , 40 combinaisons de 8 relais vont être envoyés sur les sorties TOR en quelques ms! Et l'utilisation de mémoires internes pour comparer état futur /état actuel pour n'activer que les sorties concernées, ne changera rien.
C'est donc la destruction assurée des sorties de l'automate.
Quant à vouloir utiliser deux adresses pour donner un ordre marche / arrêt c'est utiliser, pour commander une lampe, un interrupteur pour allumer et un autre pour éteindre.

Si il y a un impératif de passer par un automate, alors il faut utiliser des modules d'extention pour disposer de 40 sorties sur relais.
De plus si ce projet prend une dimension d'application industrielle, l'association API+Picaxe ne sera jamais conforme aux critères de sécurité et de sureté de fonctionnement.

 

[MGU]

Bonjour,
Mon programme répond à la remarque #10: un octet pour la fonction "ON", un autre pour "OFF". Avec un petite adaptation pour un décodage simple, les ventilos sont numérotés de 0 à 39 (et non 1 à 40)
100 => ventilo 10 OFF
101 => ventilo 10 ON
Les commandes se font une à une (pas de contrainte de temps), avec un délai pour tenir compte du temps d'action des relais (ajout d'une pause en sortie de boucle)
Pour le reste, je ne connais rien à la programmation des API, ce que je propose n'est peut être pas réalisable. J'ai seulement essayé de finaliser ce que j'avais commencé....pour voir.
MM

 

[PieM]

C'est à l'automate de n'activer des sorties que si l'état a changé. C'est en ce sens que je parle de travailler avec des mémoires internes sur l'API. Le picaxe ne devrait faire que lire les nouveaux états pour mettre à jour les PCF. Sinon, les relais sont HS au bout de 10mn.
Vouloir faire du numérique avec des relais est une hérésie, indépendamment du timing à mettre en oeuvre, ce qui n'est pas le fonctionnement normal d'un API.

 

[spheris]

Merci à tous pour vos réponses et pour le bout de code qui m'a appris pas mal de choses.

PieM, MGU,
Pour des raisons commerciales, je dois malheureusement utiliser ce que le client m'impose. Je suis entièrement d'accord avec vous, je me passerai bien de leur automate.
Sauf que pour la maquette de démo, ils veulent voir une API avec écran bleu, ça rassure sur le plan industriel (chose idiote mais là n'est pas le sujet).
pour la maquette un API et une carte picaxe fera l'affaire.
Pour le projet final si signature, un API avec 40 sorties sera effectivement achetée.

Pour vous en dire un peu plus, la maquette a été réalisée pour un hopital.
Tout le système de ventilation (pression, depression en salle d'opération etc...) vous feront très vite comprendre qu'il il y a quelques euros en jeu et que le prix de la maquette sera dérisoire par rapport au projet.

Concernant les commandes de groupes de ventilos, c'est tout l'intêret d'adresser sur 255 combinaisons.
Je peux soit les démarrer un par un, ou pour l'adresse 163 par exemple, je peux démarrer les 10 premiers et le 23eme.
l'adresse 167 les démarre tous et 168 les arrête tous.
l'adresse 170 demarre tous les pairs, etc... de multiples options sont possibles.
ce sera codé en dur dans les picaxes avec une option sur la carte de modifier avec des petits switches ou simplement en reinjectant par le port programmation.

En tous cas, j'ai de quoi pas mal avancer avec tout ce que vous m'avez présenté.
Un grand merci à vous tous.

 

[MGU]

il y a quelques euros en jeu et que le prix de la maquette sera dérisoire par rapport au projet.

Il est vrai que jusqu'à présent, ça n'a pas couté grand chose...
MM