Presentation SpaRtzZii

[SpaRtzZii]

Bonjour a tous.

Je m'appel Quentin et je suis parmi vous depuis quelques temps pour mon nouveau projet de construction.
J'habite dans la région grenobloise.

Électricien de formation, j'ai réalisé des projets KNX pour des clients sur Megeve en Haute Savoie.
Au fur et a mesure des années, je me suis reconvertir en essayeur metteur en route sur des fours industriels.

Je touche a pas mal de domaine tel-que :
- Electricité
- Automatisme
- Réseau Informatique
- Système d'alarme
- Hydraulique / Pneumatique
- Travail du bois
- Thermique

Au fil des expérience dans l'automatisation du batiment, j'ai pu explorer différentes solutions telque le zigbee, HA, ...

Mais aucune ne rempli pleinement ce que je recherche. J'en reviens donc au KNX avec une solution d'automate industriel afin de pouvoir réaliser toutes sortes de logique.

Au plaisir de vous rencontrez au détour d'une discutions sur le forum.

[filou59]

Hello SpaRtzZii

Tu utilises quoi comme Automate WAGO ? Tu utilises Codesys 2/3 ou e!Cockpit ?

J'ai commencé a faire le ménage un peu dans mon projet ETS, je vais en profiter pour reprendre un peu mon programme WAGO et passer au nouveau plugin ETS avant d'ajouter qq fonction.
Je vais peu etre en profiter pour faire qq post/tuto sur le sujet.

Si ca te dis on pourra echanger

[SpaRtzZii]

Hello SpaRtzZii

Tu utilises quoi comme Automate WAGO ? Tu utilises Codesys 2/3 ou e!Cockpit ?

J'ai commencé a faire le ménage un peu dans mon projet ETS, je vais en profiter pour reprendre un peu mon programme WAGO et passer au nouveau plugin ETS avant d'ajouter qq fonction.
Je vais peu etre en profiter pour faire qq post/tuto sur le sujet.

Si ca te dis on pourra echanger

Salut Filou.
J'ai la version codesys 2.3. Je serais intéressé pour passer a la version 3, mais je ne la maîtrise pas, donc je fais déjà quelque chose de fonctionnels comme ça et on verra plus tard. 

Concernant ETS, je suis déjà passer avec le DCA, il fonctionne très bien pour le moment, si ce n'est qu'avec les licences cloud, quand internet est désactivé, le DCA aussi. Et il faut obligatoirement redémarrer ETS. 

Aucun problème pour échanger, j'aurai sûrement des questions sur la programmation de la carte Dali 647.

[filou59]

Tu as quoi comme automate du coup ?

Un 750-88X ?
Si c'est un 750-88X tu ne peux pas passer sur CDS 3.5
Si c'est un 750-820X tu peux y passer mais il faut passer par une licence SL a acheter chez Codesys, car Wago ne fourni de runtime que pour e!Cockpit, il se programme aussi sous CDS2.3
Si c'est un 750-810X tu peux y passer mais il faut passer par une licence SL a acheter chez Codesys, car Wago ne fourni de runtime que pour e!Cockpit
Si c'est un 750-821X tu peux y passer sans frais, la license est incluse pour CDS2.3 ou CDS3.5

Je suis en train de reprendre mon programme CDS (Faire un peu de ménage ^^) et je réorganise un peu mon projet ETS.

De mon coté :
-Migration e!Cockpit vers CDS 3.5 effectué déjà il y a qq temps.
-Sous CDS 3.5 il y a du nouveau concernant l'intégration du DALI et du SMI, il y a des petits add-ons qui simplifient certaines choses. il faut que je regarde comment ca fonctionne.
-Coté ETS je vais en profiter pour passer sur le nouveau DCA pour virer le plugin.

[SpaRtzZii]

Lors du choix de l'automate, j'ai choisi le 750-890 qui était un standard dans mon ancien travail.
Il gère l'ensemble de ce que j'ai besoin et ne manque pas de puissance ni de mémoire. Je suis actuellement autour des 50% d'usage du CPU.

La où je suis retissant au passage a CDS3.5 pour le moment c'est sur les librairies que j'utilise. Je ne sais pas comment le portage vas ce faire.

Je sais plus où j'ai lu l'information, mais une des refs de PFC200 (sûrement celle que tu as cité) inclus toutes les licences CDS même celle KNX.

Petite question variable, des fois je mets des blocs complets en variable globale afin de pouvoir utiliser l'écriture suivante entre chaque POU "nomdubloc.nomdelavariable". Mais cela doit utiliser plus de mémoire que si tu déclare simplement la variable que l'on veut transférer dans POU a l'autre ?

Exemple car pas le choix, les Fb KNX sont toujours déclaré en global afin d'éditer les XML. Du coup, dans mon POU éclairage, a l'entrée d'un Fbdimmer, je vais écrire directement "MX_XXX_NomduFB.lavariable" et vice versa pour le feedback car mon Fbdimmer est en global aussi.

[filou59]

Lors du choix de l'automate, j'ai choisi le 750-890 qui était un standard dans mon ancien travail.

Ah oui ok, c'est la gamme qui a remplacer les 88X suite a l'arret de le puce ou pénurie je sais plus. Je suis passé au PFC moi a ce moment là

La où je suis retissant au passage a CDS3.5 pour le moment c'est sur les librairies que j'utilise. Je ne sais pas comment le portage vas ce faire.

Normalement aucune crainte, toutes les lib WAGO sont passé sous e!Cockpit et maintenant sous CDS3.5
Je pense même qu'il ne doit plus y avoir de dev pour CDS2.3 ou alors c'est pas diffusé.

Je sais plus où j'ai lu l'information, mais une des refs de PFC200 (sûrement celle que tu as cité) inclus toutes les licences CDS même celle KNX.

Oui c'est ca en fait il faut eviter les PFC100 ou 200 de 1ere génération. 750-8x0x (750-810X = PFC100, 750-820X = PFC200)

Un PFC200 750-8212 : C'est le choix idéal, après il y aussi d'autre variante qui peuvent convenir.
Avec ce type de CPU, la licence runtime de Codesys est incluse dans l'automate, il n'y a pas de cout caché

Petite question variable, des fois je mets des blocs complets en variable globale

Ca c'est pas bien , c'est une mauvaise habitude.

Mais cela doit utiliser plus de mémoire que si tu déclare simplement la variable que l'on veut transférer dans POU a l'autre ?

Je sais pas si ca prend plus de mémoire, mais d'une manière générale en programmation (pas seulement niveau automate) on conseille en général de limiter la portée des variables afin d'éviter les erreurs.

Je ne déclare aucun FB en global, ce n'est pas necessaire.
J'ai un programme par exemple : P_KNX qui gère la borne KNX, dedans il y a tout les FB qui récupere ou envoie les info sur le bus. Ensuite je stocke dans une GVL les variables qui contiennent les résultats obtenu depuis le bus.

Il n'est pas nécessaire d'avoir les FB en global pour générer le XML qui permet d'exporter vers le DCA KNX.

Tu as dejà vue les exemple KNX que WAGO a fait ?

[SpaRtzZii]

Salut filou,
Je prend le temps de te répondre plus en détail demain.
C'est le rush en ce moment.

Côté automatisme, ce n'est pas ma formation comme à-peu-près tout ce que je fais dans la vie. J'apprends tout en autodidacte.

J'ai pris note de tes conseils et j'apporterai un correctif a mon PRG. Côté documentation, j'en est tourné un paquet, entre les exemples de Programme, les documentations de librairie, etc. Mais au début, je suis peux être passé trop rapidement sur celle de MES de la borne 753-646, pour tout avouer, je me suis aider d'un tuto déniché au fin fond de youtube où il déclarait les FbKNX de cette manière et j'ai gardé la méthode sans jamais me reposer la question.

Au passage, tu installation est totalement gérer en KNX avec le wago pour la logique, ou tu utilises ton automate pour l'ensemble de tes actionneurs ? (VR, Éclairage, ...)

[filou59]

Je n'ai pas de module logique donc oui si il y a des choses qui ne sont pas traitable directement/nativement en KNX ca passe par l'automate.

Mes VR sont en SMI via le WAGO, je recois les ordres depuis des BP KNX , voir la station météo.
Ensuite pour la partie gestion des apports solaire faut que je la re-travail dans l'automate pour gérer la protection en fonction de la T° Amb, T° Ext/P Solaire (Iradiation...).

Eclairage : J'ai du TOR , du Dali et un variateur KNX, le TOR c'est des sorties digital qui attaque des relais, les ordre arrivent depuis le bus KNX
Le DALI : C'est sur l'automate, c'est commandé sur le bus KNX
Ensuite j'ai de la mesure de puissance, 750-494, là je pense que j'enverrais les valeurs de mesure directement sur une base de donnée depuis l'automate (via MQTT,NodeRED, InfluxDB) , c'est une reflexion que je suis en train de regarder

La partie Linky : J'ai le choix de passer par l'automate, par un module Hager via le KNX, via un ESP, ou via un PC directement , j'ai pas encore arrêté mon choix.
Comme j'ai 2 compteur a linky (1xConso + 1xProd PV) il me faut une solution x2

Faut que je test aussi du EnOcean, j'ai une passerelle EnOcean KNX que je n'arrive pas a apparait avec des prises Connecté NodoOn, normalement ca devrait être possible avec le WAGO, pour cette partie il faut une carte serie 750-652 (de mémoire) et une interface RS232 / EnOcean Thermokon.

[SpaRtzZii]

La où je suis retissant au passage a CDS3.5 pour le moment c'est sur les librairies que j'utilise. Je ne sais pas comment le portage vas ce faire.

Normalement aucune crainte, toutes les lib WAGO sont passé sous e!Cockpit et maintenant sous CDS3.5
Je pense même qu'il ne doit plus y avoir de dev pour CDS2.3 ou alors c'est pas diffusé.

J'utilise des librairies développé avec mon travail pour la régulation de température des fours. 
Ces librairies n'ont pas encore était porter sur CDS3.5.

Petite question variable, des fois je mets des blocs complets en variable globale

Ca c'est pas bien   , c'est une mauvaise habitude.

Je suis en cours de correction. Comme je les dit hier, j'apprends tout de manières autodidacte sans toujours avoir les bonnes pratiques.

Je n'ai pas de module logique donc oui si il y a des choses qui ne sont pas traitable directement/nativement en KNX ca passe par l'automate.

Mes VR sont en SMI via le WAGO, je recois les ordres depuis des BP KNX , voir la station météo.
Ensuite pour la partie gestion des apports solaire faut que je la re-travail dans l'automate pour gérer la protection en fonction de la T° Amb, T° Ext/P Solaire (Iradiation...).

Eclairage : J'ai du TOR , du Dali et un variateur KNX, le TOR c'est des sorties digital qui attaque des relais, les ordre arrivent depuis le bus KNX
Le DALI : C'est sur l'automate, c'est commandé sur le bus KNX
Ensuite j'ai de la mesure de puissance, 750-494, là je pense que j'enverrais les valeurs de mesure directement sur une base de donnée depuis l'automate (via MQTT,NodeRED, InfluxDB) , c'est une reflexion que je suis en train de regarder

La partie Linky : J'ai le choix de passer par l'automate, par un module Hager via le KNX, via un ESP, ou via un PC directement , j'ai pas encore arrêté mon choix.
Comme j'ai 2 compteur a linky (1xConso + 1xProd PV) il me faut une solution x2

Faut que je test aussi du EnOcean, j'ai une passerelle EnOcean KNX que je n'arrive pas a apparait avec des prises Connecté NodoOn, normalement ca devrait être possible avec le WAGO, pour cette partie il faut une carte serie 750-652 (de mémoire) et une interface RS232 / EnOcean Thermokon.

Pour le moment, je n'en suis pas encore a des fonction aussi poussé, en ce moment je travail déjà à obtenir un hard totalement débugguer et les fonctions de base fonctionnel. 
Ex: contrôler les VR avec retour d'information lié au temps et contrôle de position depuis la station météo.

Pour la variation, tout est en DALI chez moi et passe par l'automate. 
Pour de la variation simple, je suis partie sur les module Yuled YL-2303AC déjà cité sur le forum. Ils remplissent très bien leurs fonctions pour beaucoup moins chère qu'un variateur KNX. Et par la même occasion, le prix de la carte DALI est vite "amorti".

Pour la consommation, j'ai fais le choix de partir sur un projet francais, j'ai choisi le Serveur WES V2. Seule problème, l'intégration HA, ne semble pas des plus facile et le nombre d'entrée courant est limité a 4. Ils doivent sortir une extension avec 12 pinces.

Pour le EnOcean, je laisse tombé ce protocole et je préfère partir sur du Zigbee devenu plus courant.
D'ailleurs il existe une librairie MQTT pour wago, qui permet de communiquer avec ces appareils. Il me semble qu'elle est réservé pour les PFC100 et 200.

[filou59]

J'utilise des librairies développé avec mon travail pour la régulation de température des fours. 
Ces librairies n'ont pas encore était porter sur CDS3.5.

Si c'est des lib CDS2.5 a porter en 3.5 c'est normalement assez facile.

Après niveau Lib, je te conseille :
Les Lib Wago
Les 2 ou 3 Lib OSCAT

Avec ca on fait je pense pas mal de chose.

Pour le EnOcean, je laisse tombé ce protocole et je préfère partir sur du Zigbee devenu plus courant.

L'intérêt du EnOcean, c'est quand on a pas prévu le coup et que l'on veut un détecteur ou capteur sans fil et sans pile.

D'ailleurs il existe une librairie MQTT pour wago, qui permet de communiquer avec ces appareils. Il me semble qu'elle est réservé pour les PFC100 et 200.

Oui j'ai pas encore essayé, c'est dans ma TODO list, en fait il y a une partie ou l'on déclare le serveur dans l'interface d'admin du PFC
Et ensuite une lib qui permet de faire le reste.
A noter que de prime a abord on peut penser que c'est pour faire du MQTT dans du cloud, mais que c'est bien sur possible de rester en local, il doit d'ailleurs y avoir des video YTB qui montre ce cas de figure. (WAGO Benelux il me semble)

Donc cette solution avec CDS 3.5 est totalement gratuite

Sinon sur le store Codesys il existe des dev qui eux sont payant pour CDS3.5, qui là ne sont pas réservé exclusiment au matériel WAGO.

[SpaRtzZii]

C'est la merde !

J'ai apporté les modifications à mon programme pour ne plus que les FBs soit déclarer en Variable Global.
Depuis, impossible d'éditer un SYM_XML correct ... Je suis vanné, 4 heures que je cherche sans réponse.



2 nouveauté, il ajoute le nom du PRG sous codesys ce qui n'était pas le cas avant. Pour mon cas, KNX1 ou KNX2.
Autre problème, il croise les variables des cartes. Je me retrouve donc avec les DPT de la seconde carte sur la première carte.

Ci-joint la manière dont je configure l'édition du fichier SYM_XML.


Bien sûr, j'ai regarder en long, en large et en travers, les FB ne sont pas déclaré en doublon.

EDIT: En relissant mon message, je me suis demander si le bug ne venait pas du faite que j'avais des numéros d'Index identique à la carte 1 malgré que les block soit en M2_XXX.
Mais non, ce n'est pas le problème.

[filou59]

Hello
Si j'ai bien compris tu as 2 bornes KNX ?
Si c'est le cas il faut bien spécifier le N° de la borne dans Codesys :

1. Que ce soit dans la FB Master ou dans les FB de tes DPT, le numero de la carte qui va dans la variable peut être omis pour la 1ere carte car c'est la valeur par defaut, mais a partir du moment ou l'on a plus d'une carte, il est préférable de renseigner le numéro même pour la carte 1
   Le Numero de la carte 1 , 2 ... c'est l'ordre dans laquelle les cartes sont pluggés, c'est une numérotation de carte virtuelle de même famille.1=1ere Carte KNX2=2nd Carte KNX (peut importe l'emlacement sur le bus WAGO)
   
2. Ensuite il faut bien définir un nom de FB pour tes DPT M1_001_NomdetonFB, M2_001_NomdetonFB , M1 etant pour la Carte 1, M2 pour la carte 2...
   
3. Assure toi que les case soit bien cocher dans l'export pour chacun des prg voulu
   

Ensuite sous ETS, dans le DCA il ne faut pas oublier de définir le N° de module. (Module Index).
Quand on defini 1 pour la 1ere carte on ne voit que les FB defini pour la carte 1
Quand on defini 2 pour la 2nd carte on ne voit que les FB defini pour la carte 2

Je viens de faire un essai et ca fonctionne correctement pour ma part. Assure toi que tu as bien tout mis correctement tu as du passé a coté d'un truc.

PS : Pourquoi 2 cartes ? Tu as 2 bus ? Tu dépasses les capacité d'une carte ?

Sinon envoi moi ton projet CDS je regarderais.

Voici une capture d'un test que j'ai fait a l'arrache a partir dun sample de wago que j'ai modifié pour avoir 2 carte ds des prg différent :

[SpaRtzZii]

Merci de la réponse.

J'ai bien repris l'ensemble des points cités, ce sont des règles que j'ai bien comprises et assimilées depuis le début.
L'erreur se produit uniquement sur les 3 derniers Fb du groupe KNX2. Il sont présents dans ETS sur la carte 1 mais aussi 2.

Pourtant le bKNX_Master de chaque bloc est bien réglé sur 2 (pour la carte 2) et le nom attribué en M2_121_Rain.

EDIT: La programmation n'a pas changé, j'ai juste décalé les Fb des variables global au POU concerné.
Ils ont gardé leurs numéros et appellations.

Comme veux tu procéder pour jeter un œil a mon programme ?

EDIT2 : Si je les adresse en bKNX_Master 3 avec un nom "M3_XXX_NomdetonFB". Lors de l'importe ETS, ils disparaissent de la carte 2 mais reste toujours visible sur la carte 1 avec le nom suivant : "KNX_2.M3_121Pluie".
Le bug ce produit sur toutes les lignes après 21 dans mon PRG.

EDIT 3 :
Si je supprime totalement les DPT_Switch, FbDPT_Value_Temp ou FbDPT_Value_2_Count et qu'a la place je créer une autre fonction sur la même adresse, le bug disparait.
C'est un grand mystère !

[filou59]

Tu peux le mettre sur un Google Drive ou zipper sur le forum comme tu veux

[SpaRtzZii]

MP envoyé,

Je fais des édit de mon précédent message en même temps que tu as écrit le tiens.
Tu as peut-être des informations utile dans l'edit3.

[filou59]

J'ai regardé ton programme.

1: Il y a une raison précise pour laquelle tu utilises les anciennes lib DALI ?
2: J'ai coompilé et j'ai importé ca me semble correct.
Quand tu importes ton fichier de Codesys dans le DCA, tu dois repondre a la question si tu veux fusionner (Merge) ou si tu veux ecraser (Overwri...)
Si a un moment tu as "merdé" avec les Numero de carte, tu as des objets de la 2 qui ont du se retrouver sur la une et vice versa.
Du coup le seul moyen de s'en sortir c'est de faire un import et de repondre non.

Pas contre en temps normal quand on fait des MAJ on repond en gnl oui.

Tu peux très bien ajouter 2 autres carte a ton projet pour faire un essai aussi.

J'ai 132 Objets sur la carte 1 et 117 sur la 2, je me suis pas amusé a compter, mais tous les M1 sont sur la 1 et tous les M2 sur la 2.

Voilà une capture de la fin des 2 DCA : Tu connais mieux ton programme que moi , est que tu penses qu'il manque des choses ?
   

[SpaRtzZii]

J'ai regardé ton programme.

1: Il y a une raison précise pour laquelle tu utilises les anciennes lib DALI ?
2: J'ai coompilé et j'ai importé ca me semble correct.
Quand tu importes ton fichier de Codesys dans le DCA, tu dois repondre a la question si tu veux fusionner (Merge) ou si tu veux ecraser (Overwri...)
Si a un moment tu as "merdé" avec les Numero de carte, tu as des objets de la 2 qui ont du se retrouver sur la une et vice versa.
Du coup le seul moyen de s'en sortir c'est de faire un import et de repondre non.

Pas contre en temps normal quand on fait des MAJ on repond en gnl oui.

Tu peux très bien ajouter 2 autres carte a ton projet pour faire un essai aussi.

J'ai 132 Objets sur la carte 1 et 117 sur la 2, je me suis pas amusé a compter, mais tous les M1 sont sur la 1 et tous les M2 sur la 2.

Voilà une capture de la fin des 2 DCA : Tu connais mieux ton programme que moi , est que tu penses qu'il manque des choses ?

Concernant la Lib Dali02, je l'utilise car quand j'ai approvisionné le matériel y'a 3 ans en arrière, je me suis tromper de référence de carte au moment de la commande. Du coup pour le moment, j'utilise celle-ci. 
Je viens de recommander une carte 750-647, mais je n'est pas encore pris le temps de la mettre en service pour remplacer l'ancienne. 

C'est vraiment bizarre, car chez moi ETS génère constamment le bug peux importe le choix d'importation. 
Si j'ajoute 2 nouvelle cartes 646 a mon projet et que je réimporte le fichier, le bug continue d'être présent.

Pourrais tu me fournir le fichier SYM_XML que tu as généré afin d'identifier si cela viens de la génération du fichier par mon codesys 2.3 ou de ETS ?

[filou59]

Je t'ai mis un dossier Partagé sur mon drive, le fichier est dessus. Si besoin normalement tu pourras y glisser des fichiers dedans.

[filou59]

QQ 1er petits conseil en vrac :

Sous Codesys 2.3, pour faciliter le travail a plusieurs, le changement de PC, ou pour eviter les prb lors des MAJ, il faut envisager de travailler avec une copie des lib dans un sous dossier que tu mets dans ton projet
D:\TonProjetCodesys\Projet v1.pro
D:\TonProjetCodesys\Libs\ Là dedans du y met toutes les lib que tu utilises dans ton projet.
Dans les options du projet, dans répertoire, tu définis ce dossier libs sur la 1er ligne : Projet\Bibliotheque.

L'avantage :
Tu peux travailler avec ce projet sur n'importe quel PC et n'importe quel version de Codesys sans que celui-ci ne te demande de re-compiler le projet.
Car un des inconvenient avec CDS2.3, c'est que si tu fais une MAJ de Codesys ou des lib WAGO et bien tu te retrouves avec des lib différentes qui t'oblige du coup a recompiler le prg.
Quand on est tout seul et qu'on est un particulier, c'est pas grave, mais c'est une astuce vachement interessante quand on est pluisieurs ou quand on a un prg identique sur plusieurs machine.

Ou tout simplement : tu as ton prg qui tourne depuis plusieurs année, tu reinstall Codesys tu fais pas gaffe a la version ou tu choppes une nouvelle version entre temps et du coup tu as plus les meme lib, avec potentiellement une lib qui pourrait casser la compatibilité.

Ce dernier cas, je l'ai eu il y a pas si longtemps que ca, et c'est parfois chiant a comprendre d'ou ca vient, WAGO (DE) avait tout simplement uniformiser le nom de certaines variable en appliquant une convention de nommage sur des bloc ou variable, mais comme la lib que j'utilisais de chez WAGO (France) n'avait pas été mise a jour, cela ne fonctionnait plus. La compatibilité avait été cassé et comme ils n'avaient pas changé le nom de leur lib, et que les messages d'erreur de Codesys 2 n'etaient pas très parlant c'était compliqué a cerner.
Je réouvrais mon programme 5ans après avec une install toute fraiche de Codesys.
En utilisant le principe des libs dans le dossier du projet, on ne rencontre pas ce probleme.

---

Convention de Nommage :
Je vais essayer de te retrouver ca il est judicieux d'adopter une convention de nommage pour le nom des variables. 
On peut trouver des exemple chez Codesys, WAGO, ou chez d'autres, il y aussi PLCOpen qui a éditer des guide PDF qui explique les bonnes pratique.

Je te conseille celui-ci : https://plcopen.org/downloads/plcopen-co...version-10

La partie Naming Rules, parle de ca.
Après on peut adapter leur recommandation, c'est pas évident d'avoir le truc ultime, j'ai fait un mix de plusieurs technique utilisé par WAGO/PLCOpen et de ce que qq fournisseur dans des programme que j'ai rencontré.
Faut que je retrouve mon fichier, si ca tintesse j'ai fait un tableau sous Excell

Le but de cette convention c'est que n'importe qui soit capable de savoir de quel type est une variable dans n'importe quel programme. peu importe que ce soit le concepteur ou qq d'autre sans avoir besoin d'aller voir la partie déclarative.

Un exemple qu'on peut retrouver dans un Sample de Wago : 

Code :

        sStatusMaster        : STRING;
        xProgModeOn            : BOOL;
        wCountFbDPT            : WORD;

Bon là c'est facile c'est la partie déclaration, mais la 1ere lettre des variable défini le type. 
On sait ce que c'est

Moi j'introduit en plus la notion de Local ou Global.

Code :

        sL_StatusMaster        : STRING;
        xL_ProgModeOn            : BOOL;
        wL_CountFbDPT            : WORD;

gx_Vacance

J'adopte le même principe avec le type de variable, suivi de "L" pour "Local", ou "G" pour global.

[filou59]

Tu utilises quel version de Codesys ?
Moi j'ai la 2.3.9.68

Je sais pas si c'est la derniere que Wago propose, mais on doit pas etre loin je pense.

[SpaRtzZii]

Bonjour Filou,

Déjà un grand merci pour tes test et tout ces explications.
J'ai pris note pour les librairies et je le ferai quand j'aurai réussi à débuguer mon système.

Côté variable, je comprends mieux cette forme d'écriture que l'on retrouve de partout dans les librairies WAGO.
J'ai copié dernièrement ce principe sans en comprendre l'utilité ni pourquoi c'était comme ça ...

Test de ce matin. Le bug est toujours présent même avec ton fichier SYM_XML.
Je commence a penser que le bug provient de ETS6.2.2 (v7302) et le DCA.
Je vais tenter de tout réinstaller.

Peux-tu tester mon fichier SYM_XML ? Histoire de m'assurer que chez toi il fonctionne et que ce soit bien ETS en cause.
Je les ajouté au répertoire partagé.

Concernant la version Codesys, je ne suis pas sur la dernière version.
CDS 2.3.9.61
Sait-tu ou je peux trouver la MAJ ?

[filou59]

On a la meme version d'ETS
DCA : 1.0.0.8
WAGO TP1 Module 753-646 : v1.1 (Dispo dans le Catalogue En ligne ETS Allemand)

Je viens d'essayer avec ton SYM_XML que tu as mis ce matin j'ai le même résultat qu'avec ma compilation 132/117
Tous les M1 dans le Module TP1 N°1, tous les M2 dans le Module TP1 N°2

Vérifie la version de ton TP1 dans ton catalogue et celui du DCA.

Entre tous tes essais ton PC tu l'as rebooté ? Redemarré ETS même si j'y crois pas trop.

En plus le DCA a l'air de bien fonctionner, si tu changes le Module Index alors que tu as déjà fait un import il te prévient et averti que la liste va être effacé lors du prochain import.

Sait-tu ou je peux trouver la MAJ ?

Oui

[SpaRtzZii]

Quand cela arrive, j'applique toujours la philosophie "dans le doute, reboot"

Dans mon projet de test créer ce matin. J'ai importé la carte TP depuis le catalogue en ligne allemand. Donc en théorie la dernière version.
Sur la version de test, j'ai tester de changé les numéro d'index, mais quand je reviens a la 1, il garde constamment ces 3 variables foireuses.

J'ai cherché sur le site Codesys et je trouve rien hormis cds3.5.
Et sur le site wago, il faut faire une demande. Sauf que j'aurai rien avant la semaine prochaine. Et puis en temps que t'elle, je suis pas un professionnel, alors est-ce qu'il vont bien vouloir me l'a donner ...

Édit: tu as les target wago pour CDS3.5.19 ?

[filou59]

Ca ne doit pas venir de Codesys puisque ton fichier génére un fichier XML qui semble bon vue que ca marche chez moi.

Parfois sous Codesys, quand il y a eu de grosse modif (ou certains type de modif) on peut faire un Clean All pour refaire une compilation en partant de 0, par contre on ne fait pas ca souvent, car du coup ca fait faire un Download complet (et non un Donwload Online) et on perd les variables modifié ... , on repars comme après avoir fait un Reset (Chaud ou Froid, je sais jamais lequel, celui qui remet a 0 les variable ^^ )

Tu peux voir dans le catalogue le N° de version
Pour le DCA, tu vas dessus, et dans le menu du DCA tu as About... , tu auras le N° de version

Pour Codesys 3.5 oui j'ai tout, mais là c'est plus simple tu peux les récupérer ici : https://www.supportwago.fr/index.php , c'est maintenu par Wago France et c'est en accès libre contrairement a celui ci https://downloadcenter.wago.com/wago/software qui est maintenu par le coté Allemand et qui lui necessite un compte pro

Pour Codesys 3.5, Wago conseille vivement d'attendre la validation de leur coté des target et donc la mise a disposition des target/bibliotheque avant d'utiliser les nouvelle version dispo chez Codesys car il peut y avoir des prb de compatibilité.
Exemple :
Actuellement Codesys est a la 3.5.20.30, il y a eu 4 version depuis Mars sur la 3.5.20
Pour le moment Wago est a la 3.5.19.70, C'est la dernière en version 3.5.19

Ca dépend surtout du degré de changement coté Codesys je pense, mais il y a eu il y a qq mois des gros changement qui apparemment posaient problème.
Sinon si tu en as l'occasion essaie de trouver un 750-8212 sur LBC , il y en a parfois a des prix très abordable.

Je t'ai mis a disposition ma version Codesys 2 mais encore une fois ton fichier a l'air d'être bon.

Tu peux me faire un export de ton projet ETS avec le problème sur tes carte que j'y jette un coup d'oeil.

[SpaRtzZii]

Bonsoir Filou,

Me voilà soulagé et encore mille mercis pour ton aide.
Il s'agissait bel est bien d'un bug du DCA dans ETS. J'avais le DCA en 1.0.0.6 au lieu de 1.0.0.8.

J'ai fait la MAJ et un reboot d'ETS et tout est rentré dans l'ordre.
Je vais pouvoir reprendre ma programmation.