Voir les contributions
106
Composants / Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« le: juillet 09, 2020, 03:20:55 pm »
Bonjour,
Je reviens sur ce sujet pour le compléter d'un retour d'expérience plus approfondi. (et en profiter pour glisser une question... bête de bête j'en ai peur)
D'abord le REX sur les CJMCU-3216. En condensé : totalement positif... mais.
Totalement positif car du point de vue du capteur la fiabilité/reproductibilité est sans faille. Réellement.
Les problèmes, car il faut le dire il y en a, proviennent du bus I2C. Parasitages et amplification des problèmes (je crois... je n'affirme pas) du fait de l'usage de multiplexeurs I2C "TCA9548", indispensables de mon point de vue pour profiter réellement de l'intérêt de ces capteurs CJMCU-3216, c'est à dire en en faisant un large usage.
Ces problèmes ont-ils une solution ?
Ne pouvant parler que de mon expérience, il ne m'est pas possible de donner une réponse absolue car elle sera probablement propre à chaque configuration du réseau.
Je peux néanmoins dire qu'il est possible de parvenir à un fonctionnement parfait moyennant un bon filtrage. Dans son principe, celui qui fonctionne pour moi devrait pouvoir s'adapter avec profit.
Avant de le détailler, je dois probablement préciser que j'ai choisi une logique de gestion par canton, en analogique donc. Un détecteur situé à chaque frontière de canton commande :
- l'application du courant traction spécifique au convoi concerné sur le canton C+1 dès détection d'un convoi, qu'il soit poussé ou tiré ;
- l'extinction du courant traction sur le canton (devenu) n-1 dès que la totalité du convoi à franchi le détecteur (extinction légèrement temporisée).
Par ailleurs, et fort d'une expérimentation concluante, je pense tripler le nombre de détecteurs de façon à avoir en amont de chaque détecteur frontière un autre détecteur, pour ralenti final et arrêt au signal.
C'est l'ensemble de ces détecteurs, ou plutôt je le redis, des transmissions de données, qui demande à être filtré. D'abord par l'installation de condensateurs sur chaque alimentation canton, par précaution mais avec un effet pas vraiment vérifié.
Et essentiellement par un indispensable filtrage logiciel, en trois points.
Suivant l'occupation des cantons par les convois, une fonction en boucle scanne chaque canton (toutes les 25ms dans mon cas) à la recherche d'une éventuelle détection : un train T sur un canton C entraînera la surveillance du détecteur frontière entre le canton C et le canton C+1 pour CE train.
Une première détection (par seuil "haut" réglé chez moi à 200) étant censée mettre un canton donné sous tension (et l'affecter à un convoi précis), cette détection est-elle réelle ?
- dans tous les cas, une fonction de "switch" vers le canton suivant est appelée ;
- une variable booléenne "switched" enregistre ce fait.
- faute de pouvoir décider de la réalité de la détection, la fonction de switch rejette la détection mais enregistre dans une variable booléenne "IRDtoFilter[train]" le fait que le détecteur D a, pour le train N, été vu "détectant" et le met sous surveillance.
A la loop suivante, de deux choses l'une : soit le train est en pleine voie. Il n'y a donc pas de seconde (fausse) détection (cas heureusement jamais rencontré) et il faut donc le concrétiser en annulant la surveillance du détecteur fautif :
=> par exemple en tête de la fonction en loop :
et à la fin de la fonction en loop :
- soit le train est SUR un détecteur et, dans ce cas deux loop, consécutives passeront toutes deux par la fonction de switch qui est alors chargée de faire le ménage :
- troisième patch de filtrage :
il arrive aussi qu'un canal I2C, aléatoire, se bloque sur une valeur... également aléatoire.
Pour pallier ce problème, chaque "loop" reset un des détecteurs, à tour de rôle :
A noter que le seul paramétrage "proxSensor.setMode(PS)" m'a finalement paru nécessaire et utile.
A l'usage donc, une fois ce filtrage OK :
- toute vraie seconde détection au dessus d'un seuil "HAUT" applique le courant traction du train N au canton C+1 et initialise une temporisation liée à ce détecteur ;
- ensuite, toute détection au dessus d'un seuil "BAS" (20 dans mon cas), réinitialise une temporisation qui signale ce détecteur comme "actif" ,
- à l'extinction de cette temporisation, cad le convoi passé, le courant traction est coupé sur le canton "arrière" qui est libéré pour un autre convoi.
De cette façon, et même convoi à l'arrêt avec un attelage en surplomb du détecteur, LE CONVOI RESTE VU ET AFFECTE AUX DEUX CANTONS encadrants. Ceci a comme avantages :
- de pouvoir repartir dans les deux sens, que la motrice ait été en poussé ou en tiré
- de conserver en permanence un feu de fin de convoi (convoi roulant s'entend ! on parle ici d'analogique).
(Accessoirement et avec un code un peu boosté, cette logique marche également pour un convoi trop long pour un canton et qui occupe donc simultanément trois cantons)
Maintenant la question.
Ce site m'a apporté et m'apporte beaucoup. Un apport absolument essentiel. J'ai lu, je lis beaucoup... mais je ne comprends pas tout !
Notamment sur cette question car elle est en rapport :
J'ai lu beaucoup de choses sur la rétrosignalisation. Je me demande... ces détecteurs 3216, ou d'autres car ils ne font en fait rien d'autre (mais avec quelques fameux avantages) que ce que font des barrières infra-rouge, n'est ce pas de la rétrosignalisation ? pour bien moins cher, bien moins compliqué que des détecteurs de consommation dont l'exploitation me semble finalement plus limitée ? C'est ça qui m'intrigue. Mais de que j'ai lu à propos des détecteurs de consommation, je m'en suis fait l'idée (éronnée ??) qu'ils étaient associés aux réseaux exploités en digital. Bien que je ne vois pas pourquoi. Il y a en tous cas une donnée qui m'échappe gravement et avant de me lancer dans un réseau digne de ce nom j'aimerais tirer ça au clair. Si quelqu'un peut m'y aider...
Je reviens sur ce sujet pour le compléter d'un retour d'expérience plus approfondi. (et en profiter pour glisser une question... bête de bête j'en ai peur)
D'abord le REX sur les CJMCU-3216. En condensé : totalement positif... mais.
Totalement positif car du point de vue du capteur la fiabilité/reproductibilité est sans faille. Réellement.
Les problèmes, car il faut le dire il y en a, proviennent du bus I2C. Parasitages et amplification des problèmes (je crois... je n'affirme pas) du fait de l'usage de multiplexeurs I2C "TCA9548", indispensables de mon point de vue pour profiter réellement de l'intérêt de ces capteurs CJMCU-3216, c'est à dire en en faisant un large usage.
Ces problèmes ont-ils une solution ?
Ne pouvant parler que de mon expérience, il ne m'est pas possible de donner une réponse absolue car elle sera probablement propre à chaque configuration du réseau.
Je peux néanmoins dire qu'il est possible de parvenir à un fonctionnement parfait moyennant un bon filtrage. Dans son principe, celui qui fonctionne pour moi devrait pouvoir s'adapter avec profit.
Avant de le détailler, je dois probablement préciser que j'ai choisi une logique de gestion par canton, en analogique donc. Un détecteur situé à chaque frontière de canton commande :
- l'application du courant traction spécifique au convoi concerné sur le canton C+1 dès détection d'un convoi, qu'il soit poussé ou tiré ;
- l'extinction du courant traction sur le canton (devenu) n-1 dès que la totalité du convoi à franchi le détecteur (extinction légèrement temporisée).
Par ailleurs, et fort d'une expérimentation concluante, je pense tripler le nombre de détecteurs de façon à avoir en amont de chaque détecteur frontière un autre détecteur, pour ralenti final et arrêt au signal.
C'est l'ensemble de ces détecteurs, ou plutôt je le redis, des transmissions de données, qui demande à être filtré. D'abord par l'installation de condensateurs sur chaque alimentation canton, par précaution mais avec un effet pas vraiment vérifié.
Et essentiellement par un indispensable filtrage logiciel, en trois points.
Suivant l'occupation des cantons par les convois, une fonction en boucle scanne chaque canton (toutes les 25ms dans mon cas) à la recherche d'une éventuelle détection : un train T sur un canton C entraînera la surveillance du détecteur frontière entre le canton C et le canton C+1 pour CE train.
Une première détection (par seuil "haut" réglé chez moi à 200) étant censée mettre un canton donné sous tension (et l'affecter à un convoi précis), cette détection est-elle réelle ?
- dans tous les cas, une fonction de "switch" vers le canton suivant est appelée ;
- une variable booléenne "switched" enregistre ce fait.
- faute de pouvoir décider de la réalité de la détection, la fonction de switch rejette la détection mais enregistre dans une variable booléenne "IRDtoFilter[train]" le fait que le détecteur D a, pour le train N, été vu "détectant" et le met sous surveillance.
A la loop suivante, de deux choses l'une : soit le train est en pleine voie. Il n'y a donc pas de seconde (fausse) détection (cas heureusement jamais rencontré) et il faut donc le concrétiser en annulant la surveillance du détecteur fautif :
=> par exemple en tête de la fonction en loop :
Code: [Sélectionner]
switched[train] = false ;et à la fin de la fonction en loop :
Code: [Sélectionner]
for (byte i(0) ; i < TRAINS; ++i)
{ if (switched[i] == false) // pas de switch pour le train i dans la boucle => une éventuelle fausse détection doit être effacée
{ if (IRDtoFilter[train] == frontIRD[train] ) // frontIRD : numéro du détecteur de sortie du canton, compte tenu des positions d'aiguille et du sens de circulation
{ firstDetection[i][IRDtoFilter[i]] = true ; // la prochaine détection sera à nouveau vue comme étant la première
IRDtoFilter[i] = 222 ; // aucun détecteur 222 ! signifie qu'il n'y a aucun détecteur à surveiller...
}
}
}- soit le train est SUR un détecteur et, dans ce cas deux loop, consécutives passeront toutes deux par la fonction de switch qui est alors chargée de faire le ménage :
Code: [Sélectionner]
void switch_to_section(byte train, byte currentSection, byte newSection, byte wichIsCutIRD)
{ // filtrage des fausses détections : second test : si 1er passage, mise sous surveillance du détecteur responsable et sortie de la fonction / premier test : si en seconde lecture ce détecteur est < seuil, il a été filtré et redevient vierge pour action à la seconde détection.
switched[train] = true ;
if (wichIsCutIRD != IRDtoFilter[train] && proxSensor.getProximity() < proxThreshold)
{ firstDetection[train][IRDtoFilter[train]] = true ;
IRDtoFilter[train] = wichIsCutIRD ;
}
if (firstDetection[train][wichIsCutIRD] == true)
{ IRDtoFilter[train] = wichIsCutIRD ;
firstDetection[train][wichIsCutIRD] = false ;
firstDetection[train][IRDtoFilter[train]] = false ;
return ;
}
// suit la fonction de switch en elle-même
}- troisième patch de filtrage :
il arrive aussi qu'un canal I2C, aléatoire, se bloque sur une valeur... également aléatoire.
Pour pallier ce problème, chaque "loop" reset un des détecteurs, à tour de rôle :
Code: [Sélectionner]
reset = (reset +1)%NbDeDetecteurs ;
tcaselect(reset) ;
proxSensor.init() ;
proxSensor.setMode(PS);
A noter que le seul paramétrage "proxSensor.setMode(PS)" m'a finalement paru nécessaire et utile.
A l'usage donc, une fois ce filtrage OK :
- toute vraie seconde détection au dessus d'un seuil "HAUT" applique le courant traction du train N au canton C+1 et initialise une temporisation liée à ce détecteur ;
- ensuite, toute détection au dessus d'un seuil "BAS" (20 dans mon cas), réinitialise une temporisation qui signale ce détecteur comme "actif" ,
- à l'extinction de cette temporisation, cad le convoi passé, le courant traction est coupé sur le canton "arrière" qui est libéré pour un autre convoi.
De cette façon, et même convoi à l'arrêt avec un attelage en surplomb du détecteur, LE CONVOI RESTE VU ET AFFECTE AUX DEUX CANTONS encadrants. Ceci a comme avantages :
- de pouvoir repartir dans les deux sens, que la motrice ait été en poussé ou en tiré
- de conserver en permanence un feu de fin de convoi (convoi roulant s'entend ! on parle ici d'analogique).
(Accessoirement et avec un code un peu boosté, cette logique marche également pour un convoi trop long pour un canton et qui occupe donc simultanément trois cantons)
Maintenant la question.
Ce site m'a apporté et m'apporte beaucoup. Un apport absolument essentiel. J'ai lu, je lis beaucoup... mais je ne comprends pas tout !
Notamment sur cette question car elle est en rapport :
J'ai lu beaucoup de choses sur la rétrosignalisation. Je me demande... ces détecteurs 3216, ou d'autres car ils ne font en fait rien d'autre (mais avec quelques fameux avantages) que ce que font des barrières infra-rouge, n'est ce pas de la rétrosignalisation ? pour bien moins cher, bien moins compliqué que des détecteurs de consommation dont l'exploitation me semble finalement plus limitée ? C'est ça qui m'intrigue. Mais de que j'ai lu à propos des détecteurs de consommation, je m'en suis fait l'idée (éronnée ??) qu'ils étaient associés aux réseaux exploités en digital. Bien que je ne vois pas pourquoi. Il y a en tous cas une donnée qui m'échappe gravement et avant de me lancer dans un réseau digne de ce nom j'aimerais tirer ça au clair. Si quelqu'un peut m'y aider...
