Forum 4x4

tristanlcf a écrit :voila avec quoi j ai commencé en automatisme le PB15


http://bmi56287.chez.com/id40.htm

Et moi j'ai commencé sur Schneider TSX 37, et je déteste faire des lignes de commandes...alors j'ai toujours fait sous-traiter

Epsilon1964 a écrit :Et moi j'ai commencé sur Schneider TSX 37, et je déteste faire des lignes de commandes...alors j'ai toujours fait sous-traiter

moi sa fait longtemps que j ai plus touché a cette daube depuis facile 93 apres j ai changé de metier

J'ai eu envie de toucher à l'arduino, en amateur, mais je manque de temps et me suis dis, le temps que je me forme il y aura autre chose de mieux, alors j'ai laissé tomber.

Par contre pour tout dépannage, j'ai conservé la méthode du Graphcet.

Epsilon1964 a écrit :J'ai eu envie de toucher à l'arduino, en amateur, mais je manque de temps et me suis dis, le temps que je me forme il y aura autre chose de mieux, alors j'ai laissé tomber.

Par contre pour tout dépannage, j'ai conservé la méthode du Graphcet.

Le Grafcet ce n'est qu'un Graphe Fonctionnel de Commande des Étapes et Transitions.

C'est donc un moyen simple (et donc puissant) de décrire un fonctionnement (attendus) d'un système.


Qu'en 2017, il faille encore se faire à la main un pseudo code C qui de toute façon sera compilé, c'est nulle.
(d'autant plus que des logiciels comme automgen fond très bien le travail grafcet vers compilable arduino).

Mais c'est la pratique des électroniciens informaticiens.


Les automaticiens ont développé depuis des lustres tout ce qui va bien : les réseaux de Pétri notamment.

Derrières les électroniciens et informaticiens rament pour réinventer la roue : le sysml dont diagramme état transition par exemple, ou stateflow sous matlab simulink.


Après, faut pas être idiot. Il faudra toujours bien une librairie adaptée à une cible physique. Donc un langage ligne de code pour gérer les parties "local" de matériel.

Mais pour juste décrire le comportement attendu "global", un langage graphique, état transition, c'est mieux.

Sauf que pour le moment, ce ne sont pas les automaticiens qui ont le dessus.

Chacun son boulot en fait.
L'automaticien décrit son grafcet et utilise les boites logiques de son logiciel.
Derrière c'est du code que le mec qui a pondu le logiciel a réalisé.

Comme windows /linux

Le lien que j'ai mis plus haut va vers un logiciel ou on travaille en graphique, le code arduino en découlant.

riga a écrit :Chacun son boulot en fait.
L'automaticien décrit son grafcet et utilise les boites logiques de son logiciel.

Voila.

riga a écrit : Derrière c'est du code que le mec qui a pondu le logiciel a réalisé.

riga a écrit : Le lien que j'ai mis plus haut va vers un logiciel ou on travaille en graphique, le code arduino en découlant.

il y a aussi ardubloc, scratch4arduino etc...

C'est graphique (coloré avec des gros rectangles), ce qui simplifie. Mais ce n'est pas encore avec des états et des étapes.
C'est une présentation visuelle autre du code pseudo C.

Or l'utilisateur lambda, ce qu'il souhaite c'est un fonctionnement global. Avoir à demander une lecture d'une entrée, il s'en fiche. (la fameuse transparence si chère aux informaticiens qui n'est rien d'autre que de l'opacité).

D'où que le grafcet décrivant les états de fonctionnement du système et les conditions de passage d'un état à un autre, c'est cela qu'il faut au niveau utilisateur.

Et des outils libres gratuits pour transformer grafcet en arduino code, je n'en connais pas. (à part tout faire à la main).

Si il faut pouvoir lire les états ne serait ce que pour le déboguage et pendant la construction de schéma.
Les briques sont pourtant claires, avec par exemple la grosse acccolade pour la fonction loop

riga a écrit :Si il faut pouvoir lire les états ne serait ce que pour le déboguage et pendant la construction de schéma.
Les briques sont pourtant claires, avec par exemple la grosse acccolade pour la fonction loop

Ouais mais ça c'est du code. Enfin du code coloré.

Pas un état.

En code, ta boucle loop , elle est exécutée "à chaque" cycle cpu. Tu écris dedans tant bien que mal le comportement attendu du système au court du temps utilisateur (et pas cpu).


En état transition, tu décris juste comment le système doit se comporter en utilisation. La boucle loop du cpu tu t'en fiche.

(
avec le code C like arduino, un "front montant", tu dois le gérer toi même, à coup d'interruption.... bonjour l'usine à gaz. 0 intérêt pour l'utilisateur.
avec du code C like arduino, tu dois coder la lecture des entrées pour pouvoir comparer etc).
le graFcet, décrit le Fonctionnement attendu du système sans se soucier du reste. Si j'appuie sur le bouton et que avant, alors il faut mettre en rotation le moteur.
Le point de vue du graFcet est plus Fonctionnement utilisateur que "comment je fais durant un cycle loop cpu" pour avoir le comportement utilisateur que je veux.
)

Tu peux tout faire en code. Tu peux réécrire proprement en respect du grafcet. C'est juste hyper chiant.

Comme tu peux transformer le grafcet en langage ladder (ou pret post si tu veux). Mais c'est juste hyper chiant.

Et dans les 2 cas, code arduino C like ou ladder, ce n'est pas facilement lisible. Ou c'est vraiment moins facilement lisible.

La preuve, Tristan, qui n'est pas un manchot, dans son code avec un loop et 2 loop void et je ne sais combien de if, il n'a pas trouvé le if qui comparait l'iud lu de sa carte avec la valeur attendue.



Le deboguage s'est autre chose encore.

Avec un langage état transition, l'état, tu le constates sur le fonctionnement du système puisque tu as écrit en fonction de ce fonctionnement.

Et, au même titre que tu va faire des println sur un terminal virtuel, qui est affiché à l'écran, avec du code arduino, tu peux le faire avec du grafcet.

Et surtout, dans la plupart des logiciels permettant de programmer en langage état transition, tu as un mode avec remonté des infos qui te permettent de voir, sur ton graph qui est actif ou pas (étapes en couleurs, etc).


Tout ça pour dire que le grafcet c'est mieux. Mais que ce n'est pas (encore) le monde de l'arduino.

voila ou les retrouve les élèves , dans les forums d'électronique le mec est en terminal S-SI , il gère rien . Entre ca et les portes de poulailles automatique ou les mecs ne connaissent pas un fin de course. (je ne blâme n'y les profs , n'y les élèves ).

Bonjour / Bonsoir,

M'étant inscrit très récemment, je me permet de vous faire un petit "TOPO" sur le contexte de ma requête : je suis un élève de terminale S-SI (Sciences de l'Ingénieur), et cette année a débuté avec un projet bien définit.
Le nom du projet est le "Codeur Scott"; il consiste à communiquer (en mer lors d'une panne ou d'un silence radio) avec les navires alentours grâce à des signaux lumineux issus d'un projecteur, en utilisant le code Morse.

Mon groupe et moi avons définit le système dans cet ordre:
- Un clavier Alphanumérique va acquérir une information. (Ex: l'utilisateur appuie une fois sur la touche 2, ou bien 2 fois sur la touche 3)
- La carte électronique à microcontrôleur va traiter cet information reçue depuis le clavier pour la "transformer" en une lettre. (Par exemple, "Appuyer une fois sur 2" correspond à la lettre A, "Appuyer deux fois sur 3" correspond à la lettre "E", etc.)
- L'afficheur LCD va ensuite afficher le message que l'utilisateur veut communiquer.

En effet, cette expérience préliminaire doit d'abord être effectuée avant de l'essayer sur le système "réel".

Maintenant voilà l'issue de ma requête:
Ayant construit un modèle numérique de ce système sur ISIS (proteus), je dois maintenant programmer sous Flowcode un algorithme permettant au Microcontrôleur de convertir les informations acquises en un message bien clair.
Seulement, mes recherches n'ayant rien données, je n'ai rien trouvé qui puisse m'aider à créer ce programme.

Toutes les infos dont je dispose sont que je dois, à l'intérieur de ce programme, créer une boucle qui permettra au microcontrôleur de recevoir et de traiter chaque information, pour ensuite la communiquer à l'Afficheur. Je dois également faire appel à des "Routines", mais je n'ai aucune idée de comment les utiliser.

J'espère trouver de l'aide sur ce topic afin de réussir à créer un algorithme tel que celui-ci sous Flowcode.

(PS: le Microcontrôleur utilisé est un E-block : le PIC 16F876; l'Afficheur LCD est de dimension 16x2 (8 colonnes et 2 lignes); le clavier Alphanumérique est un clavier classique 12 touches (de 0 à 9 avec * et #)

Je vous remercie d'avoir pris le temps de lire. Bien cordialement,

Thomas.

La c'est du pic.
Faut qu'il achète le bouquin.
Je sais pas si les mecs en sti electronique travaillent la dessus, peut etre est il dans une branche spécialisée ?
Au moins sa requête est bien écrite