Utiliser les fonctionnaltés de l'IHM ou programmer dans l'API

[Gigi]

Bonsoir
Je remarque que les IHm possèdent de plus en plus de fonctionalités qui permettent de se simplifier l'écriture des programmes dans l'API,mais lors de la documentation du projet cela devient compliquer de s'y retrouver, alors est-il plus judicieux de programmer dans l'APi ou d'utiliser ces fameuses fonctionnalités.
Etant de la vieille école je préfère limiter cette utilisation particulièrement les bits mis à 1 au lieu de momentanné, certains changement de pages qui rendent complexes le lien entre situation de la PO et la page affichée etc;
Qu'en pensez vous ?
A+

[itasoft]

slts,
si on prens l'exemple des recettes, on peut les traiter dans l'automate mais c'est plus simple de le faire sur le IHM avec l'onbjet "Recettes"

[Gigi]

Ce que tu appelles « recette » c’est bien un ensemble de données spécifique à un fonctionnement de la machine.

On agit donc sur le fonctionnement de la machine.

Je ne parle ici évidemment pas des tracés de courbes ou calculs pour l’utilisateur qui restent évidemment très utile.

Donc on accepte une dépendance à l’IHM et cela devient un couple indissociable (API+IHM) en cas de soucis il faut ensuite trouver un IHM complètement identique et pouvoir récupérer son programme.

Si on extrapole la même machine peut avoir un contrôle quasi à 100% API (IHM utilisé comme les anciens pupitres câblés ou presque) ou hybride en exploitant toutes les fonctionnalités de l’IHM.


Merci pour ta réponse

[itasoft]

Ce que tu appelles « recettes » c’est bien un ensemble de données spécifique à un fonctionnement de la machine. OUI
-----------
Slts,
Disons que habituellement le traitement du process se fait dans l’automate mais certaines fonctionnalités de IHM peuvent être utilisées pour traiter une partie du process , l’exemple des recettes, mais c’est aux choix de chacun

[LaurentCK]

Perso, lorsque j'ai à programmer des recettes (jeux de paramètres spécifiques à une production particulière), je les stocke dans autant de bloc de données que de recette. Au moment d'un changement de production (ou changement de format), le bloc de la recette à activer est recopiée intégralement dans un bloc de donnée de travail (qui a alors exactement la même structure que les blocs de données de recette).

Par contre, si le client veut sauvegarder ses recettes sur une carte SD par exemple et les réinjecter, ça oblige à programmer une recopie depuis chacun des blocs de données de l'automate vers une carte SD par exemple, ce que je rechigne à faire... alors que cette fonctionnalité de sauvegarde/réinjection est toute faite si on utilise les fonctions recettes de l'IHM...

[sinced]

Les recettes sur IHM facilitent la tache pour le developpement.

On peut effectivement etre content de le gerer dans le code mais le probleme dans le code c'est que ca demande beaucoup d'ecriture et de manipulation de donnees.

Apres je ne vois pas trop le probleme de dependance. Si les machines savent fonctionner sans IHM alors l'IHM ne sert a rien. Mais tant qu'il est la il est plutot interessant de tout faire pour qu'il soit sauvegarde et qu'en cas de panne il soit restaure.

Je vois plutot ton sujet sur un autre angle. Y'en a qui developpe la logique de la machine sur l'IHM (meme si beaucoup de constructeurs donnent des avertissements en disant que ces logiciels ne sont pas prevu pour du traitement et piloter les machines). Certains mettent des E/S deportees et l'IHM vient lire les data et avec les fonctions et scripts qui tournent arrivent a piloter le process. C'est totalement deconseille, peu maintenable et nul

[Jambe]

Il faut un peu dé-sacraliser le truc, d’expérience on a « peur » de l’IHM parce que le jour où il plante on perd la conduite de l’installation mais il fait parti d’une pièce par mis tant d’autre et donc la possibilité qu’il tombe en panne n’est pas plus ou moins élevée qu’elle ne le serai pour un autre capteur voire même de l’automate.

L’intérêt justement de l’IHM est justement de pouvoir faire du parametrage sans avoir besoin de venir connecter une console ni d’être automaticien, refaire une génération et tout ce que ça implique.

Si c’est juste pour faire office d’afficheur, bof bof.

Dernier point: rappelons que IHM c’est pour Interface Homme Machine, bien sûr je vous apprend rien, mais il y a encore quelque années, une façade d’armoire avec des boutons et des voyants on appelais ça un IHM

[Jambe]

Et j’oubliais:

Donc on accepte une dépendance à l’IHM et cela devient un couple indissociable (API+IHM) en cas de soucis il faut ensuite trouver un IHM complètement identique et pouvoir récupérer son programme.

Si l’IHM devient quelque chose d’indispensable à la conduite, on le catégorise comme étant un équipement critique, on en garde (un ou plusieurs) en stock, déjà programmé, prêt à être mis en service ainsi que le personnel compétent quand l’installation est en service.

[Gigi]

J'allais envoyer ce message et d'autres réponses sont apparues dans l’intervalle, je l'envoie quand même.

Ma question portait plutôt sur la documentation du projet.

Surtout que je me retrouve souvent à gérer du bit impulsionnel, ou maintenu,de la transmission de poids fort ou poids faible en premier,et selon le modèle cela peut être très différent.

En effet je vois assez facilement comment on pourrait fournir un programme au client sans trop de surprise mais si trop de subtilités sont gérées par l'IHM on en arrive à des programmes simples ,c'est bien mais toute l’intelligence est dans l'IHM et c'est quand même lui qui est le plus exposé en production donc à mon avis celui qui sera à changer plus rapidement(cela reste à prouver).

Donc si tu dois le changer et qu'il n'existe plus de modèle équivalent tu pourrais avoir à finalement tout reprogrammer car pas de "moulinette" .

Et si c'est l'automate que tu changes en premier l’interaction avec l' "IHM" n'est pas garantie.

J'en suis resté à l'époque ou l'automate gère tout et l'IHM la gestion des pages ,modes de marche ,visuels mais pas d'intervention directe sur une sortie .

Sinon je prends un modèle "PROFACE" par exemple et il est vendu complet "Automate+IHM" et ça fait le job pour les petites machines.

Pour les systèmes à multiples "IHM" qui nécessite des "recettes" et la multiplication des programmes ça à l'air évident que ce vous me dites est pertinent.

En tous cas merci pour vos réponses.