Ok je test et je vous ferais un retour. Et comme le mentionne @mamatdv je n’ai pas pris le temps non plus de faire remonter car je pensais être le seul. Et comme j’avais pris le parti d’installer du câble normal rigide 1.5 (en cas de reconversion a une installe classique) et pas du câble RJ45 je pensais que le souci venait essentiellement de là.
Le temps de commutation est de 32ms voir photo entre le moment ou on appui (en jaune), le debounce du BP et l’activation du relais (en bleu ). ça correspond aux mesures que nous avions fait à l’époque.
Si vous avez des ratés c’est peut etre lié à un problème de masse.
SI vous avez un bruit de masse qui se balade dans votre câblage alors le zéro volt n’est pas suffisamment clean pour être détecté. Idéalement il faudrait faire un petit montage avec un transistor ou un opto pour contourner les câblages en 1.5mm2 et/ou les boucles de masses.
ah une piste !!
Si vous avez les valeurs des seuils haut et bas des trigger des pic16 sous le coude je les veux bien !
je me mettrai en config labo et je sonderai directement sur le micro contrôleur.
Une chose est sûr, c’est que la résistance de pull-up de 10k et celle de 1k juste avant la sortie font un pont diviseur de tension, donc la tension sur l’entrée du pic ne descendra jamais au dessous de 0.33V.
Perso je suis en RJ45.
La X8R Connect serait moins sensible au perturbation ?
Les entrées ont un hardware différent et le traitement est beaucoup plus optimisé car le micro est 16 fois plus rapide que celui d’un X8R classique.
@AlexDomo
Refaire des filtres passe-bas en entrée ne résoud pas systématiquement les soucis et modifie les temps d’acquisition du système.
Faire un montage trigger ou une commutation par opto devrait améliorer…vous semblez maîtriser l’électronique donc ca devrait être assez simple à faire.
Cependant, normalement, avec un câblage adapté il n’y a pas besoin de rajouter d’électronique.
Il y a donc forcément un élément déclencheur propre à votre installation et celle des 3/4 autres utilisateurs ayant des symptômes similaires.
Des x-8r anciennes générations, x24d et x4vr déployées dans des installations, il y en a des dizaines de milliers. Si il y avait un défaut vraiment avéré, il y aurait des centaines de messages sur le forum et sur la help desk.
Un truc simple:
Révisez vos câblages, blindages à la terre, séparation terre / masse des alim 12v etc…
Et ne pas oublier de bien éloigner les câbles de puissance des câbles courant faible.
On a vite fait de passer à côté d’un câble mal connecté ou d’une masse oublié, ou du câble d’alim du four qui croise un câble rj. Ça arrive au plus confirmé d’entre nous et j’en parle en connaissance de cause
De notre côté, aujourd’hui, on a pas forcément détecté de problème, mis à part des commutations erratiques liés à des inters de très mauvaise qualité et pourtant d’une marque bien connue.
Je vais terminer les tests demain avec Kevin…histoire d’aller au bout du sujet.
Merci en tout cas d’avoir pris le temps de faire des tests. De mon côté je sais que mes câblages ne sont clairement pas optimisé. D’ailleurs mon tableau est en photo dans le wiki dans les exemples à ne pas reproduire . Je vais prendre le temps de refaire certains câblages. Au final ce n’est pas non plus catastrophique et avec le temps je finis par ne plus m’en rendre compte. C’est madame qui me fait remarquer le soucis de temps à autre.
Peut-être mettre tout simplement un coup de bombe nettoyant contacts WD-40 Specialist l’oxydation du contact à la longue doit provoquer ce genre de parasite
Bonjour l’équipe @GCE,
Tout d’abord merci d’avoir pris le temps de faire des mesures sur ce sujet qui visiblement rassemble maintenant quelques utilisateurs. Merci également pour les petites pistes données à ceux-ci notamment celles des optocoupleurs. Pour infos j’ai conçu un boîtier sur cette techno mais je ne pense pas que je puisse le partager ici.
Je souhaite tout de même vous faire une petite remarque bienveillante envers vos produits. En effet vous dites vous mêmes que les systèmes sont relativement sensible au cheminement des câbles dans les cloisons, notamment lorsque l’on s’approche des câbles de puissance. En lien avec ceci je pense qu’il serait bien de rendre plus robuste vos produits sur ce point afin qu’il ne ressorte qu’une chose de la bouche de 100% de vos clients envers leurs proches :
" => Prend les produits GCE, c’est super simple à mettre en place, peu importe ton installation existante, tu branches et sa fonctionne, c’est fiable à toutes épreuves leurs trucs !"
Vous êtes une bonne boîte française et vous soutiens à ce titre. N’oubliez pas qu’il suffit de quelques clients mécontent pour pourrir une réputation d’où ma remarque bienveillante alors ne le prenez vraiment pas mal.
Bonne continuation aux équipes !
Bon j’ai passé ma soirée à faire tout un tas de test :
1. Affectation des sondes :
- Jaune :Sonde aux bornes du poussoir
- Violet : Sonde aux bornes de la broche du microcontrôleur
- Bleu : Excitation du relai (directement sur la puce) (désolé pour la faute de frappe dans les captures)
- Vert : Bus
2. Avoir un front descendant le plus propre possible :
Test avec poussoir Legrand Celiane :
C’est plutôt pas mal, ce sont de bons interrupteurs.
On voit bien l’effet du filtre en violet.
Une division = 50us soit 1/20000 de seconde.
Test avec un contact franc sans parasite ni rebond :
Là on ne peut pas faire mieux même rajoutant de l’électronique optocoupleur ou autre, c’est le filtre du module qui fait son job, c’est très propre et largement assez rapide pour le microcontrôleur.
On voit bien l’effet du diviseur de tension 1k/10k, on a environ 330mV sur la broche du PIC16 alors qu’aux bornes du module on a bien 0V.
330mV c’est dans les spec pour le nivaux bas donc ok.
Une division = 50us soit 1/20 000 de seconde.
Test mise à la masse de l’entrée du microcontrôleur :
Nécessite le démontage du module.
Là on bypass le filtre avec un contact franc sans parasite ni rebond.
On force également l’entrée à 0V.
On ne pourra pas être plus rapide et plus bas en tension : le top !
Sur cette capture la trace est bleu et non violette.
Une division = 200ns soit 1 / 5 000 0000 de seconde (250 fois plus rapide que la capture précédente).
3. On regarde ce qu’il se passe sur le relai et le bus
Test avec un contact franc sans parasite ni rebond :
Délai de 80ms pour l’excitation du relai, le bus envoi les données quelques millisecondes plus tard.
Une division = 10ms soit 1/100 de seconde.
Test mise à la masse de l’entrée du microcontrôleur
Délai de 80ms pour l’excitation du relai, le bus envoi les données quelques millisecondes plus tard.
Une division = 10ms soit 1/100 de seconde. (j’ai enlevé la trace jaune qui ne sert à rien ici)
Si j’ai fait une mauvaise manip, n’hésitez pas à me le signaler pour que je corrige la méthode.
4. Conclusion :
Même en optimisant au maximum la propreté, la rapidité du front descendant et la tension du nivaux bas, j’ai toujours ce délai de 80ms.
Vous parvenez à descende à 32ms dans votre capture d’oscillo, la mesure que vous faites est bien faite avec un X8R et pas avec l’IPX800V4 ?
En effet quand je fais des tests avec l’IPX j’arrive même à descendre à 15/20ms.
En partant du principe que vous faites votre mesure avec le X8R, soit :
- Je m’y prends mal pour faire mes mesures
- Nous n’avons pas le même firmware
- Nous n’avons pas la même révision du hardware (le mien est de 2019)
En tous cas c’est vraiment cool que vous preniez le temps de regarder, c’est aussi pour ça que j’ai acheté vos produit, il y a un suivi à long terme !
Bonjour @Neuvidor
Je suis bien d’accord avec vous et c’est justement pour ça qu’on a changé les entrées et le filtrage sur la nouvelle génération d’extensions.
Une autre entreprise aurait simplement dit: il faut acheter le nouveau modèle ! Hier on a quand même pris le temps de faire des tests afin de voir si on a une solution.
Concernant la réputation de l’entreprise, je suis bien conscient des enjeux. Nous sommes relativement transparent sur les réussites et parfois les ratés qu’il peut y avoir.
Les clients mécontents en général le sont pour une bonne raison et je partage la plupart du temps leurs avis étant moi même consommateur.
Je les appelle, on discute du soucis et on trouve dans 99% des cas des solutions. Les produits ont tous des petits défauts. C’est pour ça qu’on travaille activement pour les améliorer et faire en sorte que les nouveaux soit plus fiables et plus fonctionnels que les précédents.
@AlexDomo
Si vous regardez notre capture d’oscillo vous verrez que nous avons pris un inter classique. On voit nettement les rebonds de l’inter et du contact du relais 32ms plus tard.
Le firmware dans le x-8r est le 1.10.
Rapprochez vous de la help desk pour vérifier la version de votre firmware.
Je voulais éliminer le doute sur d’éventuelles entrées mal câblés, du coup là on voit que c’est une entrée hyper clean !!
Il est possible pour vous de regarder sur le X24D ?
En effet j’ai fait le test avec le X8R pour qu’on parle de la même chose mais mes poussoirs de lumières sont tous câblés sur le x24D et le problème est similaire à la milliseconde près.
Je vais prendre attache avec la helpdesk pour qu’on vérifie les versions de firmware.
Bonjour,
On aura peut etre pas le temps de refaire des tests sur le X-24D aujourd’hui. De plus c’est différent car le temps de réponse du X24D est lié à l’anti-collision donc proportionnel au traffic du bus.
Un exemple si vous avez une trame qui passe au moment ou le X-24D veut parler, il va forcément avoir un délai d’attente lié à l’anti-collision.
A voir avec @Kevin_GCE sur la helpdesk.
Merci !
J’ai fait une demande à la helpdesk.
Il manque la trace du bus, sur votre capture, on ne sait pas si la trame est envoyé au même moment que la commutation ou 80ms après l’appui.
En tout cas, sur l’IPX, le bus réagit en moins de 20ms, il est donc bien possible d’avoir un délai d’émission sur le bus inférieur à 80ms.
La gestion anticollision n’explique donc pas le comportement du bus sur X8R et X24D …
En tout cas sur mes tests pas de collision c’est sûr, le module est seul sur le bus
Bonjour,
Je ne veux pas rentrer dans un débat d’expert sur le forum mais le bus réagit de façon asynchrone par rapport au trafic.
Laissez nous un peu de temp pour regarder en détail.
CDT,
Bonjour @AlexDomo
On a travaillé avec @Kevin_GCE toute la journée sur ce sujet.
Finalement il a fallut recoder une grande partie des acquisitions de la x24D et refaire le debounce pour pouvoir tomber à 30ms entre appui et envoi de la trame.
A priori ça marche sauf que ça nécessite une mise a jour de la v4. En effet, on doit aussi faire des modifs coté IPX800 V4 pour que le bus EBX fonctionne correctement.
Comme quoi meme une modification qui semble mineure peut entrainer beaucoup de travail.
On fera une béta V4 la semaine prochaine histoire de voir si ça améliore ou pas. Sachant qu’il y a un risque majeur de régression pour les autres utilisateurs on passera par la helpdesk pour publier la bêta, faire la maj de la X24D et faire des tests sur votre installation.
J’en ai profité pour aussi regarder la X-4VR et, malheureusement, il n’est pas possible d’améliorer les temps de réaction du firmware. Le programme du X4VR étant assez lourd, le hardware est vraiment trop juste en terme de vitesse.
Bon week-end
Bravo les gars vous êtes au top, merci beaucoup pour le travail effectué !
Tant pis pour le X4VR, c’est un peu moins gênant, en général on les manipule moins souvent.
Au moins vous avez regardé et c’est cool…
J’attends avec impatience que la helpdesk me contact pour tester !!!
Problème de non détection sur appuis bref de l’extension X8R résolu après mise à jour du firmware
J’ai mitraillé le module avec un générateur de fonction, il envoyait 10 impulsions de 32ms par seconde.
Maintenant le relai est excité entre 0 et 32ms après l’appui, le bus communique environ 3ms après.
Si l’appui dure plus de 32ms aucun risque de non détection !
Une des captures avec un délai hyper court (1ms/div) :
Voici les traces avec la persistance de oscilloscope activée (5ms/div):
Bravo @gce de maintenir aussi longtemps vos produits, d’être à l’écoute de vos clients et de les respecter ! Bravo bravo bravo