bascule t
ljanray
je dois réaliser une bascule T en language à contacts (fonction d'un
telerupteur une entrée, une sortie).
En fait je dois créer la fonction qui n'est pas dispo dans la lib. de
l'automate que j'utilise et je suis incapable de retranscrire la
fonction logique d'une bascule T en booléen.
Est ce que quelqu'un aurait un lien pour un modèle en language contact
ou txt svp.
Merci a vous.
Cordialement.
LJ
jjgoessens
problème typique.
la méthode la plus simple : le grafcet !!
la méthode la plus simple et la plus efficace c'est de le faire en
grafcet (4 étapes) et de transcrire ce grafcet en schema contact.
cela va donner 8 lignes de programme !
si tu ne sais le faire pas je te le ferai demain.
JJ
ljanray
>
> problème typique.
> la méthode la plus simple : le grafcet !!
> la méthode la plus simple et la plus efficace c'est de le faire en
> grafcet (4 étapes) et de transcrire ce grafcet en schema contact.
> cela va donner 8 lignes de programme !
> si tu ne sais le faire pas je te le ferai demain.
>
> JJ
Merci pour ta réponse,
j'essaye en grafcet, on verra bien, je te tiens au courant.
LJ
Adrien Gaudel
code qui donne ce genre de fonctionnement et uniquement avec des operations
binaires.
Il travail sur un mot complet et permet donc de créer en quelques lignes de
programme et en utilisant quelques mots memoire, 16 "télérupteurs" et 16
bits de front.
Je tacherais de penser à recopier ça demain pour le partager ici.
"ljanray" <ljanra...@free.fr> a écrit dans le message de news:
eho9d4$1f56$1...@talisker.lacave.net...
ljanray
Désolé, je n'ai pas reussi.
je suis preneur d'une réponse.
Cordialement.
LJ
cLx
>>> je dois réaliser une bascule T en language à contacts (fonction d'un
>>> telerupteur une entrée, une sortie).
>> problème typique.
>> la méthode la plus simple : le grafcet !!
>> la méthode la plus simple et la plus efficace c'est de le faire en
>> grafcet (4 étapes) et de transcrire ce grafcet en schema contact.
>> cela va donner 8 lignes de programme !
>> si tu ne sais le faire pas je te le ferai demain.
> je suis preneur d'une réponse.
> Cordialement.
Bonsoir
Un truc du genre, ça irait ?
http://clx.freeshell.org/gallery/Sch/chart.jpg
(ok, j'ai fait une lègére, usine a gaz, y'a surement moyen d'optimiser
ça, de plus j'ai pas testé)
Sinon, la solution grafget c'est tellement simple... :D
http://clx.freeshell.org/gallery/Sch/grafcet.jpg
--
cLx
Adrien Gaudel
"cLx" <clx@nos_pamchez.com> a écrit dans le message de news:
ehtj4l$ock$1...@gyptis.org...
>
> Bonsoir
>
> Un truc du genre, ça irait ?
> http://clx.freeshell.org/gallery/Sch/chart.jpg
> (ok, j'ai fait une lègére, usine a gaz, y'a surement moyen d'optimiser
> ça, de plus j'ai pas testé)
>
>
>
> Sinon, la solution grafget c'est tellement simple... :D
> http://clx.freeshell.org/gallery/Sch/grafcet.jpg
>
> --
> cLx
ça ne marchera jamais car tu ne peux pas avoir B2...
Pour créer un front montant (B2) il faut inverser les deux premiers segments
et là ça devrait marcher ;-)
PS : les TSX17 c'est largement depassé :-D
cLx
> ça ne marchera jamais car tu ne peux pas avoir B2...
> Pour créer un front montant (B2) il faut inverser les deux premiers segments
> et là ça devrait marcher ;-)
En haut, ça devrait aller, en tout cas quand j'avais essayais, ça
traitait toute la page sans mettre a jour les bits internes, si je me
rapelle bien. Par contre, je crois que j'ai commis un bug plus bas, je
me demande bien si ça ne s'éteindrait jamais en fait...
Ah ce serait si simple en VHDL!
> PS : les TSX17 c'est largement depassé :-D
Terrible, ça se voit si bien que je n'ai bossé que là dessus ? ;)
N'empêche que si on s'abstient bien de débrancher la terre, ça tient
le coup longtemps ces trucs :P
jjgoessens
Oh là là, je vois qu'il y en a qui s'improvisent "automaticiens" à la
légère ...
On peut bien sur le faire en logique combinatoire ... à condition
d'utiliser les outils : graphes d'état, tableaux de carnot.
Je l'ai déja fait en combinatoire, et avec seulement DEUX relais!
c'était en 1979!
Mais je trouve ces méthodes pas forcément efficaces (temps de
développement) pour les automates programmables,c'était bon pour faire
des logiques à relais, le bon vieux GRAFCET a encore des années devant lui.
bon voici ma solution, que je préfère, qui doit marcher si je j'ai pas
fait de fautes ...
c'est simple, linéaire, efficace, et ça marche.
http://cjoint.com/data/kCbotsvvC2.htm
je pense que la méthode de traduction grafcet => contact t'est connue.
sur chaque transition, on met à un le bit d'étape et à zero le bit de
l'étape précédete..
Important : ne pas oublier d'initialiser le grafcet au démarrage, il y a
toujours un bit d'initialisation dans un automate quelque part pour
faire cela.
Ne sachant pas comment est ton appli, ni que de genre d'automate tu
disposes, j'ai choisi les conventions suivantes :
source : BP (un Bouton Poussoir par exemple)
sortie : LAMPE (par exemple)
bits d'étape grafcet B0 à B3
bit d'init automate : INIT
à toi de les renommer correctement selon ton automate.
JJ
jjgoessens
>
> Bonsoir
>
> Un truc du genre, ça irait ?
> http://clx.freeshell.org/gallery/Sch/chart.jpg
> (ok, j'ai fait une lègére, usine a gaz, y'a surement moyen d'optimiser
> ça, de plus j'ai pas testé)
>
Désolé, mais je me sens OBLIGE de réagir !!
cela ne marchera jamais !
comme B1 suit l'entrée, B2 ne passera JAMAIS à 1!
ce n'est pas comme cela que l'on fait un front montant mais :
B1 I0.1 B2
-----!/!-! !--------( )---
I0.1 B1
-----! !------------( )---
mais la suite, excuse je ne comprends pas, si je suis bien, B3 va
simplement suivre B2 ??
si B2=1 alors B3=1
si B2=0 et B3=1 alors B3=0
ça sert à quoi?
rassures moi, tu n'est pas du tout automaticien ?
Si oui, dis moi ou tu travailles, au cas ou.. pas en Touraine, j'espère?
Conclusion:
-Pourquoi faire des trucs tordus, alors qu'il existe des OUTILS qui
fonctionnent de façon fiable ?
-Travailler avec METHODE c'est gagner du temps et de l'argent.
JJ
jjgoessens
http://cjoint.com/data/kCcVHLUAto.htm
j'avais simplement oublié l'étape active dans la condition de transition
vers l'étape suivante !!
JJ
cLx
> cela ne marchera jamais !
>
> comme B1 suit l'entrée, B2 ne passera JAMAIS à 1!
> ce n'est pas comme cela que l'on fait un front montant mais :
> B1 I0.1 B2
> -----!/!-! !--------( )---
> I0.1 B1
> -----! !------------( )---
>
> mais la suite, excuse je ne comprends pas, si je suis bien, B3 va
> simplement suivre B2 ??
Mon truc s'appuyait sur le fait que la page de ladder soit analysée
complètement, PUIS les sorties et bits internes sont mis a jour, puis
on attaque un second cycle, ce qui fait que dans ces conditions, sauf
erreur de ma part, nos deux détections de front montant donnent le
même résultat. (même s'il y a peut-être un autre problème en bas pour
la même raison, mais ce n'était qu'une idée comme ça...)
J'avais pas pensé à utiliser les bobines set et reset, en effet, c'est
beaucoup plus simple.
Et pour te rassurer, non, je ne bosse pas avec le langage a contact.
jjgoessens
J'ai compris que ta spécialité est l'écriture de programmes
informatiques. Un petit tour sur ton site m'a rassuré quand à ton sujet.
Un automate fait une image des entrées avant de scruter le programme,
mais tous les bits internes sont mis à jour en temps réel. il faut donc
écrire les bits dans le bon ordre pour que cela marche. en fin de
scrutation il met toutes ses sorties à jour.
cela pose d'ailleurs des questions : si on utilise une sortie dans des
conditions, l'automate utilise t-il la vraie valeur de la sortie
calculée lors de la scrutation précédente ou bien l'image en mémoire en
temps réel ? là c'est simple: cela dépend du matériel ! difficile donc
de prédire le comportement.
Le décalage du aux scrutations doit être utilisé avec grande prudence,
et à part pour faire des détections de front montant, cela reste à éviter.
D'ailleurs c'est justement cette notion de scrutation qui est la cause
de soucis de mise au point.
En automatisme, l'écriture intuitive est la pire chose qui existe !
malheureusement elle est pratiquée très souvent, même par des
"spécialistes" et aboutit toujours à des automatismes "buggés", au
comportement incertain, voire parfois dangereux. Sans doute les
automaticiens ont besoin de créer, ré-inventer la roue! dommage car les
outils existent et fonctionnent bien.
il m'est arrivé plusieurs de faire refaire complètement des programmes
écris de façon intuitive en les mettant sous forme de grafcet, le
résultat : cela marche du premier coup, et sans bugs !
aujourd'hui je m'occupe de projets industriels, et je constate que les
automaticiens ont toujours du mal à ne pas confondre : "a marché une
fois" et "marchera à tous les coups", je dois donc sans cesse me
rapprocher des automaticiens et m'assurer qu'ils travaillent dans les
règles de l'art pour aboutir à des solutions fiables.
grafcet, grafcet, et encore grafcet...
JJ
Adrien Gaudel
"jjgoessens" <jeanjacque...@wanadoo.fr> a écrit dans le message de
news: 4543263b$0$27379$ba4a...@news.orange.fr...
>
> grafcet, grafcet, et encore grafcet...
>
> JJ
Ouais enfin les grafcet faut pas non plus les mettre à toutes les sauces !
car suivant l'application ça peut être aussi grosse sources de bugs...
Programmes donc le fonctionnement d'un ensemble de convoyeurs pas-à-pas (par
exemple) en grafcet... en plus d'être inutilement lourd et difficile à
comprendre (et donc eventuellement à depanner), y'a de grande chance que le
fonctionnement ne soit pas celui attendu.
Alors qu'il est si simple de dire "si la cellule du tapis devant et la
cellule du tapis concerné alors j'arrête le tapis, sinon le tapis tourne"
(en y ajoutant si necessaire les autres conditions de marche ou d'arrêt) un
grafcet là-dedans, pourquoi faire ?
Chacun son truc, mais moi ce qui m'enerve c'est ceux qui font tout en
grafcet alors qu'il y'a des solutions plus simple.
Alors c'est sûr, comme tu dis les outils existent, mais il faut le utiliser
correctement... on utilise pas une pelteuse pour planter des patattes.
jjgoessens
oui et non
oui je suis d'accord, ne pas utiliser le grafcet pour faire ce qui peut
être fait simplement
non car souvent on sous-estime la difficulté et on commence en intuitif
..; et on fait une usine à gaz qui ne marche pas (ou mal).
donc avant d'agir, réfléchir et faire une analyse correcte, à partir du
moment ou il y a un cycle, c'est à dire ou le même jeu de combinaisons
d'entrée peut aboutir à des situations différentes, il y a un cycle, là
le grafcet est approprié, à partir du moment ou ce n'est pas le cas de
simples équations suffisent.
tu parles de grafcets qui buggent : c'est simple l'analyse est mal faite.
tu parles de grafcet difficilement lisible : là encore c'est l'auteur
qui est en cause, un bon commentaire n'est jamais superflu. Là je
m'élève en faux car un grafcet bien rédigé est très facilement lisible,
encore faut-il disposer du grafcet niv 1 ou 2 et non pas seulement de sa
traduction en contacts. et là encore faut-il bien le traduire et ne pas
faire de bidouilles qui ne sont pas dans le grafcet.
quand à la pelleteuse... aujourd'hui, il n'est plus nécessaire
d'optimiser comme on le faisait autrefois, on ne manque jamais de
performances mémoire ou vitesse. d'ailleurs ces programmes super
optimisés que nous faisions n'étaient en général lisibles que par
l'auteur, et encore, pas trop longtemps après...
Le matériel aujourd'hui n'est plus une barrière... enfin là d'accord ce
n'est pas un prétexte pour faire n'importe quoi quand même!
Dans le monde industriel, l'objectif c'est d'arriver au résultat, alors
chipoter sur 1000€ d'automate sur une machine à 1 million c'est idiot.
même si le programme écrit est lourd, l'essentiel est qu'il fonctionne à
coup sûr.
bref, tu sera sans doute d'accord avec moi, l'automatisme c'est avant
tout une affaire de rigueur.
toujours faire marcher sa tête avant ses mains!
JJ
lolo&lili&zozo
?
si c'est le cas, tu a la detection de front (montant ou descendant).
alors la, c'est trop simple le telerupteur (une ligne en contact si tu a la
fonction XOR dans l'automate)
sinon il te faut ajouter un bit interne pour avoir l'image de l'entree
precedente.
"jjgoessens" <jeanjacque...@wanadoo.fr> a écrit dans le message de
news: 45433f4b$0$5080$ba4a...@news.orange.fr...
ljanray
> Oups, voici la bonne version :
>
> http://cjoint.com/data/kCcVHLUAto.htm
>
> j'avais simplement oublié l'étape active dans la condition de transition
> vers l'étape suivante !!
>
> JJ
Bonsoir,
Merci de prendre du temps pour essayer de m'aider.
Malheureusement, ta solution ne fonctionne pas.
Je scannerai ce que j'avais fait avant, puisque mon gafcet etait
different du tiens, et que j'ai transformé en algebre de bool après.
http://www.jnetsys.com/golf/
Avec ta soluce, au depart nous avons init et bp/ donc conflit avec b2
qui set et allume direct la lampe.
Après l'init, a chaque etat de bp/ set b2 et set b0 reset b1 et b3 donc
lampe allumée.
A chaque etat de bp set b1 et b3 et reset b0 et b2 donc lampe allumée aussi.
Pour moi, c'est toujours un casse tete, je pense envoyer un mail a omron.
Bon, pour situer.
l'api est un omron cj1m et je developpe avec cx one qu'on vient de me
coller dans les pattes.
POur les applis simples j'ai l'habitude d'utiliser millenium de crouzet,
et pl7 pro pour les plus costauds.
J'ai toujours eu une fonction dispo bistable ou set/reset à une
entrée/une sortie.Mais avec cx one, pas trouvé.
Donc je dois la faire moi meme.
Je n'ai droit qu'a du ladder ou du texte.
Le but est de faire un stop sirene lors d'une alarme:
Entree contact sec simple, un voyant s'allume, la sirene gueule,
j'appuis sur un poussoir, je coupe que la sirene et j'allume le voyant
stop sirene, si je rappuis, j'eteinds le voyant stop sirene et la sirene
regueule.
Le tout sans toucher a l'etat de l'alarme qui lui sera controlé par un
bouton stop alarme qui coupera le voyant de l'alarme et la sirene si
l'alarme a disparue.
Voila en gros...
Merci et bonsoir.
LJ
jjgoessens
Bonsoir.
tu as du prendre la version ou j'avais oublié les bits de l'étape
précedente dans les conditions.
regardes la bonne (theoriquement) version.
JJ
ljanray
> Bonsoir.
>
> tu as du prendre la version ou j'avais oublié les bits de l'étape
> précedente dans les conditions.
>
> regardes la bonne (theoriquement) version.
>
> JJ
>
A voui...,C'etait pas la bonne, désolé, demain je teste celle ci.
Bonsoir
jjgoessens
Je suis sur de mon coup, cela DOIT marcher !!
(aie, j'engage mon honneur là !)
bon sinon, tu peux toujours utiliser une détection de front et mettre un
compteur binaire derrière, ainsi la sortie de poids faible changera à
chaque appui sur le bouton.
selon ton automate, ce ne sera pas forcement le mieux en temps
d'exécution, en effet il faut bien penser qu'un "petit" bloc sur l'ecran
peut en fait consommer pas mal de cpu, alors que la solution grafcet
consomme quasiment rien, que des opération sur des bits..
Un détail sur ton appli, tu ne veux pas réinitialiser ta sirène à l'état
marche à chaque apparition de défaut ?
JJ
Jacques GENIN
>> On peut bien sur le faire en logique combinatoire ... à condition
>> d'utiliser les outils : graphes d'état, tableaux de carnot.
Karnaugh, pas Carnot...
A+
JAG
ljanray
> Un détail sur ton appli, tu ne veux pas réinitialiser ta sirène à l'état
> marche à chaque apparition de défaut ?
>
> JJ
Non, la stop sirene doit coupé la sirène (sur un yacht de luxe, il ne
faut pas paniquer les gens du bord pendant des heures pour un pb mineur).
Mais il y a plusieurs girophares qui tournent tous le temps a plusieurs
endroits du bateau tant que toutes les alarmes activent ne sont pas off.
jjgoessens
JJ
Adrien Gaudel
"telerupteurs" en quelques instructions, le voici tel quel je l'ai utilisé
sur une de nos machines :
(C'est du "LIST" Siemens S7-300 mais ça peut se traduire dans d'autres
languages)
L "MIentrees" //chargement de l'image des
entrees, c'est là que se trouvent les "boutons"
L "MfrontBP" //chargment de la memoire pour fronts
XOW //"OU Exclusif" entre les deux mots
chargé
L "MIentrees" //image des entrees
T "MfrontBP" //->memoire pour fronts
UW //"ET" entre le resultat du OUexclusif
et l'image des entrées
T "FrontBP" //->fronts des boutons
L "BasculesBP" //memoire des bascules
INVI //Je ne me souviens plus de l'effet
exact de cette instruction, je crois que c'est le complement du mot
UW //"ET" mais je ne sais plus entre quoi
et quoi car je ne me souviens pas non plus si l'intstruction "INVI" affecte
l'accu2
T #Temp1 //memoire intermediaire 1 (mot
local)
L "FrontBP" // fronts
L "BasculesBP" // bascules
UW
INVI
T #temp2 //memoire intermediaire 2 (mot
local)
L "BasculesBP" //bascules
L #Temp1 //memoire intermediaire 1
OW
L #temp2 //memoire intermediaire 2
UW
T "BasculesBP" //bascules
Dans "FrontsBP" on recupere les fronts montant qui correspondent aux entrées
et dans "BasculesBP" les "telerupteurs"
Si ça vous interesse vraiment je regarderais le fonctionnement exact de
l'instruction "INVI"
traduit en S7-200 c'est encore plus court (je l'ai déjà fait pour une autre
machine)
"ljanray" <ljanra...@free.fr> a écrit dans le message de news:
eho4or$13vr$1...@talisker.lacave.net...