Presentation SpaRtzZii

[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.