Retour d’expérience sur l’utilisation des liens

Michel94 · Décembre 16, 2021, 4:07

Bonjour à tous,

Le lien est une évolution majeure de l’IPX800 v5. Il facilite grandement la mise en œuvre de nos configurations.

Pourtant, nous avons tous constaté des comportements parfois étonnants de ces liens :

Les états des variables situées aux deux extrémités du lien peuvent être différents.
Inexplicablement, un lien ne peut pas être établi…

Bug ou spécificité ?

La documentation sur le comportement des liens n’est pas très détaillée.

Je propose, dans ce post, que nous partagions notre expérience sur ce sujet.

Pour initialiser le sujet, je vous livre mon analyse de ce nouveau moyen d’assembler les ressources. Il s’agit de ma propre interprétation, suite à ce que j’ai pu constater durant ces quelques dernières semaines. J’ai peut-être fait de grosses erreurs d’interprétation et n’hésitez pas à apporter la controverse. L’unique but est de parfaire la connaissance du produit et d’exploiter au mieux les nouvelles possibilités qu’il apporte.

Rappel :

Les ressources communiquent entre elles au moyen de leurs variables (variables d’entrée et variables de sortie). Pour activer ou modifier le comportement d’une ressource, il faut écrire des informations sur une de ses variables d’entrées. En retour, la ressource restitue le résultat son action en écrivant sur ses variables de sorties.
Sur les IPX800 v4 et v5, la communication entre deux variables est assurée par le moteur de règles. Ce moteur de règles assure l’écriture de valeurs dans les variables d’entrée des ressources lors de la détection d’événements. Les événements sont déclenchés suivant les variations d’états des différentes variables et suivant les consignes préalablement paramétrées dans des règles.

Le lien est une règle

Pour fonctionner, le lien utilise le moteur de règle. Lorsque l’on établit un lien entre une sortie (extrémité source du lien) et une entrée (extrémité destination du lien), on crée une règle simplifiée ayant les valeurs suivantes :

Evènement = variable de sortie située à l’extrémité source du lien
Action : Une des 5 actions disponibles dans le moteur de règles ; ON/OFF, ON, OFF, SWITCH, SET VAL. Par défaut, l’action ON/OFF est sélectionnée.
Variable modifiée = variable d’entrée située à l’extrémité destination du lien

Le lien n’est pas permanent

Le lien établi n’est donc pas un lien permanent, équivalent à un fil électrique connecté aux deux extrémités, mais un lien évènementiel, établi uniquement à chaque variation de l’extrémité source avec les limitations dépendantes de l’action sélectionnée. En absence de variation sur la variable source, la connexion source => destination est désactivée. Cela explique que, dans certains cas, les variables situées aux deux extrémités du lien puissent avoir des valeurs ou des états différents.

Le lien ne peut être établi qu’entre une entrée et une sortie

Une règle peut utiliser, dans la partie événement, indifféremment des sorties ou des entrées. Un lien lui, ne peut être établi qu’entre une sortie (source) et une entrée (destination). Par contre, il peut être crée aussi bien à partir de la source qu’à partir de la destination.

Sortie distribuée sur plusieurs liens

Sur une sortie source, il est possible de créer jusqu’à 8 liens. Dès la création d’un deuxième lien, le connecteur passe automatiquement en mode multi-liens et son aspect est modifié :

Il semble que, lors de la création de chaque destination supplémentaire, un couple action-variable soit ajouté à la règle déjà créée :

Dans cette hypothèse, l’ensemble des liens au départ d’une seule sortie n’utilise qu’une seule règle.

Réception de plusieurs liens sur une seule entrée

Sur une entrée destination, il est possible de recevoir jusqu’à 8 liens. Dès la création d’un deuxième lien, le connecteur passe automatiquement en mode multi-liens et son aspect est modifié :

Discussion

Sur le forum, plusieurs intervenants ont indiqué que, dans cette configuration, les liens étaient combinés entre eux avec la logique OU. On pourrait donc penser que la partie événement de la règle initiale serait modifiée et que les différentes sources seraient combinées entre elles avec l’opérateur OU :

Si l’on teste la configuration suivante :

et que l’on fait varier successivement les 2 variables IO a et IO b on obtient le résultat suivant :

La colonne « Règle a OU b » a été obtenue de la même manière mais en supprimant les liens et en activant la règle IOa OU IOb.

On constate que le variable IO c ne réagit pas suivant une logique combinatoire OU mais suivant une logique événementielle où c’est la dernière variation sur un des liens qui conditionne le résultat.

La connexion de plusieurs liens sur une seule entrée est donc identique à la création de plusieurs règles indépendantes ayant la même variable destination.

Limitation sur les connexions multi-liens

Un lien ne peut avoir qu’une seule extrémité reliée à un connecteur en mode multi-lien

Réédité suite aux contributions de @cce66 et de @Jweb et la confirmation de @GCE

Si l’on tente de créer un lien et que cela provoquerait soit la création d’un lien qui aurait deux connexions multi-liens, soit la modification de liens existant en liens à deux connexions multi-liens, deux cas de peuvent ce produire :

nous avons le message « IHM, Invalid selection »

En glissant la souris sur le lien, nous avons le message « Already used »
Le lien n’est pas créé.
le lien souhaité est crée, mais des liens existant sont supprimés sans avertissement.
Ce problème fait l’objet d’un prochain correctif. La description détaillée de ce point est réalisée plus bas, dans ce fil, ainsi que la réponse de @GCE

En clair, la configuration suivante est interdite à cause du lien entre IOb et IOc :

Edit : suite aux contributions de @cce66 et de @Jweb et la confirmation de @GCE

Visualisation des variables raccordée à des liens dans les pages collections

Dans le menu Variable, il est possible de voir la collection d’une catégorie de variable.

Sur la page collection, il est possible d’afficher toutes les variables de la catégorie sur deux pages. La page « Virtual » affiche les variables indépendantes et la page « Système » affiche les variables dépendantes du système proprement dit, mais aussi les variables dépendantes des ressources. Deux pictogrammes symbolisent l’état de la connexion des accès. Le pictogramme de gauche symbolise l’accès écriture (accès in), celui de droite l’accès lecture (accès out). Le pictogramme indique qu’il n’y a aucun lien raccordé sur l’accès

Cette variable par exemple est connectée physiquement à l’entrée opto 4 en écriture. Son accès lecture n’est pas connecté

Le symbole indique la présence d’au moins un lien sur l’accès.

Cette variable est la variable d’entrée Start d’une ressource temporisateur et au moins un lien est raccordé sur son accès écriture.

Cette variable est la variable Output d’une ressource comparateur et au moins un lien est raccordé sur son accès lecture.

Problème avec la longueur du nom d’une input
Edit : Vu avec @patam, le problème évoqué n’est pas de conséquence sur les liens

Dans le Tuto Utilisation de la fonction MQTT sur l’IPX800 5,Patam remonte le problème suivant

[quote=« patam, post:4, topic:14502 »]
Le nom de l’input1 est trop long c’est pour ça que le input 1 ne fonctionne pas par les liens.
[/quote]

Personnellement, je n’ai, ni utilisé la fonction MQTT, ni rencontré par ailleurs ce problème.
@patam : pourriez vous le documenter ?

En espérant que ce post suscite de nombreuses remontées et que plus aucune zone d’ombre ne subsiste dans l’utilisation des liens…

Bonne soirée

fgtoul · Décembre 16, 2021, 4:29

Bonjour,
la règle énoncée par GCE est effectivement « c’est le dernier qui cause qui a raison ».

Les combinaisons logiques sont des demandes d’évolution.

bonne journée

patam · Décembre 16, 2021, 5:11

Bonjour,
J’ai refais des tests pour ce problème de longueur de nom, en fait si on crée un objet avec un nom juste assez long, les variables qui en découlent auront un nom encore plus long et dont le cadre apparaît en rouge.
Je n’ai pas réussi à reproduire le problème de création de lien car l’objet se valide quand même

Le nom est encadré en rouge, je n’aurais pas pu le nommer manuellement ainsi, j’aurais eu un message d’erreur, mais comme il est créé automatiquement ce n’est visiblement pas bloquant.
Mais donc où est vraiment la limite de caractère pour le nom?

Dans le tuto @Jweb explique le problème

Donc ma remarque n’était pas pertinente pour ce sujet mais plutôt pour la longueur des noms .

Michel94 · Décembre 16, 2021, 5:23

Bonsoir patam,
effectivement, moi aussi, j’ai eu ce problème sur des variables dépendantes d’un objet.
Par défaut, le nom d’une variable dépendante d’une ressource est [nom ressource]nom de la variable.
Il existe une limite (non documentée) dans le nom des variables et des ressources.
Lorsque l’on modifie le nom des ressources, la limite n’est pas atteinte mais celle de la combinaison [nom ressource]nom de la variables l’est.
Du coup, lorsque l’on édite la variable il y a problème…

Il faut,

soit modifier le nom de la variable, mais dans ce cas, on ne règle pas le problème du nom des autres variables de la ressource qui doivent aussi déborder
soit réduire le nom de la ressource.

@gce : pourrions nous avoir une alerte quand la longueur du nom de la ressource fait déborder les noms des variables dépendantes ?

cce66 · Décembre 16, 2021, 5:56

Bonjour @Michel94
Je pense qu’en entrée on peut mettre aussi plusieurs liens mais que cela dépend des objets qu’on lie, ici j’ai lié avec l’entrée digitale 1, l’entrée digitale 2 et un suscribe MQTT,

Par contre si j’ajoutes un io virtuelle à l’entrée cmd 1 du relais 1 il le merge et le sub + l’entrée digitale sont basculées sur l’IO virtuelle et après l’affichage devient

Michel94 · Décembre 17, 2021, 6:51

Bonjour cce66,

Bien sur, il est possible de mettre plusieurs liens sur une entrée.

La nature des ressources sources n’apporte pas de limitation. Il suffit juste que le lien, que nous désirons créer, ne pointe pas sur une sortie déjà utilisée par un autre lien. Dans ce cas, nous aurions un lien avec des connecteurs en mode multi-liens aux deux extrémités, ce qui n’est pas autorisé.

Si j’ai bien compris, l’opération que vous avez réalisé est l’insertion d’une variable virtuelle entre les ressources sources (suscribe et entrée digitale) et la commande du relais.
Le schéma est devenu

Il ne s’agit pas d’un « merge » entre les entrées existantes et la variable virtuelle mais d’une insertion d’une variable IO virtuelle dans le schéma qui, à mon avis, n’apporte pas de nouvelle possibilités.

A propos des variables, il faut distinguer les variables systèmes des variables virtuelles.

Les variables systèmes sont les variables propres au système ([IPX]clock par exemple), ou les variables créées par le système au moment de la création de ressources. Ces variables sont dépendantes de la ressource et ne sont accessible par les liens qu’en accès lecture (extrémité source du lien) ou qu’en accès écriture (extrémité destination du lien).
les variables virtuelle sont des variables indépendantes créées par la fonction ajout. Ces variables sont accessibles aussi bien en lecture qu’en écriture. En fait, c’est une ressource particulière, contenant une seule variable, accessible en entrée et en sortie. Pour déterminer le sens d’un lien entre deux variables virtuelles, il faut choisir le côté droit si l’on désire que la variable sur laquelle on crée le lien soit la variable source, ou le coté gauche si la variable doit être la destination.

Merci pour ce retour d’expérience.
Bonne journée

Michel94 · Décembre 17, 2021, 7:32

Bonjour fgtoul,

Je viens de faire une recherche sur le IPX800V5_manuel_5.4.0.pdf et sa version en ligne, seul document, à ma connaissance, mis à la disposition des utilisateurs, et je ne trouve pas de trace de cette règle.

Existe-t-il d’autres documents que nous pourrions consulter ?

Bonne journée

grocrabe · Décembre 17, 2021, 9:14

Bonjour Michel94,

seuls les documents publiés sont validés.

Les infos que nous donnons et qui ne sont pas dans ces documents viennent d’échanges avec le BE.

Bonne journée

cce66 · Décembre 17, 2021, 12:07

Bonjour @Michel94,

Effectivement j’ai écrit « cela dépend des objets » j’eusse du écrire « cela semble dépendre des objets » car j’ai pas tout testé c’était une réponse à ci-dessus (mais qui sembles limité aux IO virtuelles)

Je ne sais pas si cela fera l’objet d’une évolution future mais je trouves que cela pourrais être une évolution intéressante (après cela peut se faire avec un scénario je crois)

En fait j’avais le premier schéma effectif donc pour moi le « Cmd Relais 1 » pouvait être déclenché ou par un évenement MQTT « Suscribe » ou par l’action du « Digital Input 3 » puis j’ai inséré pour tester une IO virtuelle qui s’est donc insérée à droite des deux autres entrées, je pensais qu’elle resterait là et en fait elle a absorbé le « suscribe » et le « digital input 3 » en entrées et sa sortie est venue en entrée du « cmd Relais 1 » en affichant un message comme quoi cela allait mergé les entrées mais je pense que cela vient du fait que le « subcribe » pointait sur plusieurs entrées MQTT (pour tester aussi)

Et je refais la même manip avec une IO vierge aussi et là il reste ! J’ai du merder quelque part !

Et j’ai pas encore saisi je crois la partie sur les io virtuelles (quand et pourquoi les utiliser par exemple)

Michel94 · Décembre 17, 2021, 3:25

cce66,

je viens de reproduire le problème :

je crée une première configuration à partir de l’entrée Cmd Relais 6 :

Séparément, je crée une deuxième configuration

Je tente d’ajouter IO b à l’entrée de cmd relais 6 à partir du relais 6

J’ai le message m’indiquant que l’entrée sera partagée avec lien IOB-IOC

Ce qui est fait :

Cette action a simplement supprimés les liens existants avec l’input 6 et l’IO a sans aucun avertissement et a mis en oeuvre la nouvelle configuration
Le nouveau schéma est :

Si je fait la même opération à partir de Edit suite au message de Jweb :[l’entrée IOb] remplacé par : la sortie de IOb, le « merge » proposé est celui que nous souhaitons !

[mais, au final, le résultat est le même.] Edit suite au message de Jweb : dans ce cas l’opération est bien réalisée

Il me semble que vous avez mis le doigt sur un bon gros bug ! En principe, en l’état actuel, l’action aurait dû être annulée avec un message d’avertissement !

@GCE :Je ne sais pas déposer un ticket Est que quelqu’un peut s’en charger !

Jweb · Décembre 18, 2021, 12:56

Je vais alors me permettre de revenir sur certains passages

Après avoir refait vos tests, celui-ci n’est pas possible… en effet IO b entrée doit être connectée à un objet présentant une sortie, or le Relay cmd 6 ne présente qu’une entrée…

Je souhaiterais compléter les choses que vous avez listé en début de ce fil:
1.

Certains objets ne présentent qu’une entrée
Certains objets ne présentent qu’une sortie
Certains ont entrées et sorties.
Qd on établie un lien, il faut regarder à partir de où il est établit et vers quelle type de destination.

En reprenant ce dernier principe, revenons sur votre 1er test:

Nous avons ici un connecteur 2-1

Ici nous avons un connecteur 1-1

Lorsque vous essayez de merger les 2 figures par la sortie du connecteur que ce passe t il ? (c’est un merge de 2 connecteurs)
=> voulez merger un connecteur 2-1 par la sortie 1 avec un connecteur 1-1 on obtient alors un connecteur 1-2
vous êtes alors avertis de l’opération par la popup:

A comprendre : la sortie IOb sera liée aux entrées IOc / relay cmd 6
D’où la figure obtenue du point de vue de l’IOb:

Maintenant si on regarde du point de vue du relais cmd 6 :

si on le fait par la sortie IOb on obtient bien:
merge2

Que fait-on lors de cette opération?

Nous allons merger 2 connecteurs par l’entrée
un connecteur 1-1 (IOb-IOc)
un connecteur 2-1

Le résultat doit donc etre un 3-1

Vue depuis la sortie du connecteur: (cad le relais)

Vue depuis l’IOb:

Michel94 · Décembre 18, 2021, 7:58

Merci Jweb pour ce retour très détaillé.

Je poursuis la controverse
Le but est toujours de comprendre le fonctionnement des liens.

Dans mon message précédent, j’ai fait deux erreurs :

une erreur de rédaction : j’ai écris :

au lieu de « Si je fait la même opération à partir de la sortie IOb, ». Mais c’est bien à partir de la sortie IOb que l’opération a été réalisée

et une erreur d’interprétation, en ne vérifiant pas le résultat à partir du relais.

En conclusion : dans ce cas, comme vous l’indiquez, l’opération est bien réalisée. Un lien est ajouté entre IOb et Cmd Relais 6. Nous avons bien le schéma suivant :

Alors que dans le cas précédent, en tentant d’ajouter le lien à partir de l’entrée du Cmd Relais 6, le lien est bien ajouté mais les liens existants( input 6 vers Cmd Relais 6) et (IOa vers cmd Relais 6) sont supprimés.

Nous avons le schéma suivant :

Il semblerait que, si nous ajoutons un lien à une entrée et que ce lien provient d’une sortie déjà connectée à un autre lien, les liens existant sur cette entrée sont supprimés sans aucun avertissement.

Par contre, si nous ajoutons un lien sur une sortie, ce lien est crée, quelle que soit
l’occupation de l’entrée destinataire du lien (dans la limite bien sûr de 8 liens).

Nous progressons…

Michel94 · Décembre 18, 2021, 4:40

Il y a deux types de ressources :

Les variables virtuelles qui ne contiennent qu’une seule variable qui est accessible en entrée par le côté gauche (écriture) mais également en sortie par le côté droit (lecture).
Les autres ressources qui contiennent des variables spécialisées soit en entrée (écriture), soit en sortie (lecture).

Le fait que les variables virtuelles soient indifféremment accessibles en sortie ou en entrée peut, éventuellement, être source de problème.

J’ai donc repris les mêmes tests en utilisant des interfaces au lieu de IO virtuels.
Le schéma initial devient :

On note que nous n’avons pas accès à tous les connecteurs : nous ne pouvons pas modifier les connecteurs des sorties de input 6 et input 7 qui sont reliés à la même entrée de CMD relais 6

Pour réaliser le schéma

Option 1 : raccorder la sortie de l’input 8 à l’entrée de Cmd Relais 6 à partir de l’input 8.
L’opération semble avoir réussie vue des entrées,

mais le lien input 8 => Cmd relais 7 a été supprimé.

Le schéma de la configuration obtenue est :

Option 2 : raccorder l’entrée de Cmd Relais 6 à la sortie de l’input 8 à partir de Cmd Relais 6.

Ça commence mal !

En effet !

Le schéma de la configuration obtenue est :

Conclusion des deux tests, avec ou sans variable virtuelle : si l’on crée un lien dont une extrémité doit être raccordée à une entrée ou une sortie qui est elle même déjà raccordée à plusieurs autres liens, il y a un risque que des liens existants soient supprimés, et ceci, sans aucun avertissement.

Edit : j’ai reproduit le même test en n’utilisant que des IO virtuelles et refait également le test des configs initiale avec un mélange d’IO virtuelles, d’entrée et de cmd relais. Les résultat sont identiques dans les 3 cas et conforme avec ceux obtenus avec uniquement les Digital input et les Cmd relais.

Il serait sympa, qu’à ce moment du fil, @GCE intervienne !

Michel94 · Décembre 19, 2021, 6:16

Bonjour,
Après avoir refait les tests, j’arrive à la conclusion suivante, qui peut, bien sûr, faire l’objet de controverse.

Le postulat indiqué dans Limitation sur les connexions multi-liens semble être vrai. :
Actuellement, un lien ne peut avoir qu’une seule extrémité reliée à un connecteur en mode multi-liens.

Un connecteur peut prendre 3 états :

Simple :
Multi-destinations :
Multi-sources :

Sur une entrée et une sortie libre, le premier lien crée utilise un connecteur simple aux deux extrémités.

Connecteur multi-destinations
Lorsque l’on ajoute un deuxième lien à une sortie, le connecteur de cette sortie devient multi-destination. Tous les liens de cette sortie sont désormais sous le contrôle de ce connecteur. La signalétique se propage à toutes les entrées situées aux extrémités des liens utilisant ce connecteur.

Dans ce cas, il n’est possible de créer un lien supplémentaire qu’à partir de la sortie associée au connecteur multi-destinations. L’accès aux entrées associés à ce type de connecteur est désactivé. Il n’est donc pas possible de créer de nouveau lien à partir de ces entrées.

Ex : on note sur les entrées des collecteurs ouverts 2 et 3 :

la signalétique indiquant leur appartenance à un connecteur multi-destination
l’absence de signe + permettant de créer de nouveau lien

Connecteur multi-sources
Lorsque l’on ajoute un deuxième lien à une entrée, le connecteur de cette entrée devient multi-sources. Tous les liens de cette entrée sont désormais sous le contrôle de ce connecteur. La signalétique se propage à toutes les sorties situées aux extrémités des liens utilisant ce connecteur.

Dans ce cas, il n’est possible de créer un lien supplémentaire qu’à partir de l’entrée associée au connecteur multi-destinations. L’accès aux sorties associés à ce type de connecteur est désactivé. Il n’est donc pas possible de créer de nouveau lien à partir de ces sorties.

Création des liens
La création d’un lien est opérée en trois étapes :

La sélection d’une entrée ou d’une sortie sur une ressource donnée. Dans ce cas, seules les entrées ou sorties autorisées sont sélectionnables et autorisent la création d’un connecteur ou l’ajout d’un lien dans un connecteur.
La sélection du type de ressource (choix de la tuile) puis de l’entrée ou de la sortie constituant l’autre extrémité du lien.
La validation qui déclenche la création du lien

Si l’étape 1 est parfaitement maitrisée (seules les entrées et sorties autorisées sont accessibles), les entrées ou sorties proposées dans l’étape 2 n’intègrent pas les contraintes liées aux types de connecteurs. La sélection porte uniquement sur la nature de l’accès (entrée ou sortie) en fonction de la nature de l’accès choisi lors de l’étape 1.
Il est donc possible de valider un lien non conforme, dont l’entrée et la sortie appartiendraient déjà à deux connecteurs multi-liens ou dont la création génèrerait un nouveau connecteur multi-liens, provoquant ainsi une configuration non conforme.

Dans ce cas, on note deux comportements :

Refus de la création du lien en indiquant que l’accès est déjà occupé. (comportement normal)
Création du lien sur l’accès déterminé à l’étape 2 (via la tuile) mais suppression, sans avertissement, du lien existant sur l’accès déterminé à l’étape 1. Si cet accès est sous la dépendance d’un connecteur multi-liens, ce sont tous les liens de ce connecteur qui sont supprimés. (Bug)

Il serait utile à tous que GCE nous éclaire sur le sujet !

Bonne soirée

Jeremy_GCE · Décembre 20, 2021, 9:39

Bonjour @Michel94,

Vous avez tout à fait raison sur l’analyse des liens.

En effet, il n’y a que deux cas pour merger une entrée ou une sortie à un connecteur multiple.

Premier cas, cette entrée/sortie est linkée à rien dans ce cas pas de soucis. Cela va venir créer un connecteur multiple ou ajouter cette entrée/sortie sur le connecteur multiple déjà créé. Attention, les connecteurs multiples entrées et sorties ne sont pas gérés.
Deuxième cas, et c’est ici que le bug apparaît, nous voulons connecter une entrée/sortie déjà linké avec un connecteur simple à un connecteur multiple. Actuellement, nous avons un pop-up qui montre le simple lien, puis nous avons une suppression de l’ancien lien multiple, et un merge vers le lien simple (qui devient un lien multiple). Cependant, dans le cas où nous voudrions ajouter cette entrée/sortie (connecteur simple) vers le connecteur multiple nous ne pouvons pas.

Pour pallier ce problème, nous allons ajouter une modale permettant de faire le choix entre passer le lien simple en lien multiple (comportement actuel) ou supprimer le lien simple et ajouter l’entrée/sortie dans le lien multiple. Nous allons également ajouter une modale de warning permettant d’avertir l’utilisateur que le lien (simple ou multiple) sera supprimé.

Merci, pour vos retours !

Bonne fête à tous

Michel94 · Décembre 24, 2021, 5:03

Bonjour,
Merci pour votre réponse. L’utilisation de modales pour informer et activer l’action souhaitée semble être bien adaptée.

J’ai une réserve sur la proposition : Dans le cas d’un lien multiple, seule la possibilité de supprimer l’ensemble des liens est proposée. Est-il possible de ne supprimer que la « branche du lien » posant problème ?

Le conflit se produit dans les cas suivants :

L’objectif est d’informer l’utilisateur des modifications apportées, de préserver au maximum les liens existants et de ne supprimer que les liens posant problèmes.

Bonne fêtes

cce66 · Décembre 24, 2021, 5:42

Bonjour,
L’idéal serait d’avoir une fenêtre d’édition des liens un peu comme celle -ci :

Bonnes fêtes à tous !