naturland:
Non non je veux changer le pupitre de commande par un PC+écran tactile, donc faire aussi un programme perso
Bonsoir
Ok
Dans ta reflexion actuelle un "arduino" interviendrait où/sur quoi ?
Maintenant l'arduino ne supporte peut être pas cette rapidité de traitement sur 10 bit ?
Bonjour,
il peut le faire 1000 fois
on peut donc envisager un tas de choses, après avoir réalisé en un 1er temps ce que tu souhaites
je pense même qu'on peut lire directement la roue et mettre gray au musée
ps : merci pour les photos, c'est une belle machine, ça donne envie de ... cintrer des tubes !
il n'y a qu'une chose qui mu turlupine sur ce type de machine c'est l'aspect sécurité. Si on touche à la commande il faudra bien savoir ce qu'on fait : si des fonctions de sécurité sont confiées à l'électrotechnique, il y aura un risque à les confier à l'arduino
Bonjour;
Pourquoi relayer le codeur gray au musée?
En tout cas, ce codeur (qu'il soit gray ou non) est un outils très performant et facilitant le travail.
Il est absolu, il ne perd pas sa position une fois la machine éteinte, donc pas de probléme de callage sur une position 0 à chaque fois que tu redémarre ta machine.
Je ne sais pas pourquoi on dit que le Gray est à mettre au musée?
Avec le code Gray les pas sont codés de telle sorte qu'en passant d'un pas à l'autre, il n'y a qu'un bit qui change A LA FOIS
0000, 0001, 0011, 0010, 0110, 0111, 0101 ...
Tandis qu'en binaire pur, ce n'est pas le cas
0000, 0001, 0010 (2 bits changent d'état), 0011, 0100 (3 bits changent d'états) ... ca peux poser des pb de transitions si tous les bits ne changent pas "exactement" d'états en même temps.
Mais dans ce cas présent, l'utile ou l'interêt est ce codeur absolu avec lecture en //.
Bonsoir,
Ne nous égarons pas.
La question et la seule (pour le moment en tous cas) est quoi prendre comme "interface" pour lire ce codeur via un PC.
Pour tout le reste c'est simple, c'est 8 relais à faire fonctionner... rien de plus
Mais tout le projet démarre par ce codeur, comment le lire.
-Via module programmable qui décode le gray pour en sortir une valeur analogique ?
http://controllino.biz/controllino/mega/
-Via une carte arduino qui accepte le 24V pour sortir une info exploitable ?
http://www.opto22.com/site/pr_details.aspx?cid=7&item=PB16K
https://www.antratek.com/ate-603
http://www.robotshop.com/en/elexol-8-channel-opto-i-o-board-3-24v-dc-ac.html
-Via une carte électronique PCI
http://www.iocontrol.de/pcie_dio.htm
JEANFRANLEC
Pour préciser après test en 24V
Les sorties sont de23.2V à 0.6V
Pour ce qui est de la "confiture", c'est pour cette raison que j'ai fait ce post pour savoir dans quelle direction me tourner car vouloir lire en direct le codeur serait l'idéal mais il faut bien une "carte" qui sache donner une valeur de 24v en "info-informatique" exploitable pour le programme, qui lui donnera à son tour une "info-informatique" vers une "carte" qui alimentera les relais en 24v.
Pour le code Gray c'est effectivement son intérêt, maintenant si autre chose existe j'écoute...
Mais la roue étant en Gray elle ne donnera que du Gray, je ne vois pas comment le lire autrement ? (ni l'interêt)
ARTOUSTE
Alors le cheminement est plus du ressort de mon père, étant programmeur c'est lui qui est en charge de cette tâche difficile.
La direction de l'arduino fut prise pour 3 raisons:
1-Il commence à bien maitriser le python et à déjà fait une table 3D avec ce langage et le trouve simple et efficace.
2-Avec de l'arduino on peut à moindre coût faire à peu près ce que l'on veut.
3-Le raspberry pourra être utilisé ce qui réduira la taille de cette partie électronique. (a verifier si il accepte l'écran tactile)
4-Tout ce petit monde est facilement upgradable.
De mon coté je prend plutôt le rôle de chargé d'affaire et prend en charge la partie intégration.
Donc pour moi je vois les choses d'une manière basique, je remplace un gros vieux pupitre obsolète par une petit système moderne (simpliste le cahier des charges!!!).
Sauf que ça ne se fait pas aussi simplement, car dans mon cahier des charges il y a un écran tactile IBM à gérer et ce fameux codeur absolu à lire.
Donc la direction actuelle (mais non figée) est un écran tactile IBM relié à son PC IBM avec le programme en python dedans, envoi et reçois les infos via arduino qui pilote des relais.
Au final concrètement il n'y a que le boitier cybelec qui sera remplacé (voir les relais par des DIN).
TRIMARCO232
Pour les sécurités ce n'est vraiment pas le problème.
La machine est très bien conçu au niveau de sa gestion hydraulique. c'est long à expliquer car le système hydraulique est assez complexe (si tu es dans les environs de Montpellier tu es le bienvenu pour regarder comment on cintre un tube !!!). Mais il n'y a qu'un seul risque, l'humain, celui de se trouver dans la zone de cintrage, la machine est incapable de te voir. Sinon risque machine zéro si on l'utilise normalement.
Même le bouton d'AU est géré par un relai qui coupe l'alimentation des pompes et vannes.
Ils travaillaient bien nos ancêtres simple, durable et efficace.
Il faudrait lire les docs un peu plus à fond, mais en première approche les cartes Controllino semblent intéressantes.
Elles te proposent des entrées/sorties de type industriel (24V, protection ESD, sorties de puissance, sorties sur relais, ...).
En environnement industriel, je pense que ce pourrait être un bon choix. Elles pourraient gérer tout ton interface avec la machine aussi bien la lecture du codeur et la conversion code Gray en angle que la commande des circuits de puissance de ta machine.
La mega possède même des interfaces RS485 et Ethernet qui seraient peut-être plus fiable comme interface avec ton PC.
Bonjour;
C'est clair, il y a un codeur absolu (gray ou non) il faut l'exploiter au mieux, c'est bien ce que j'avais écris.
Même si on est sur un forum arduino, je trouve très judicieuse l'idée de la carte PCI au moins pour interfacer le codeur au PC car finalement c'est aller DROIT AU BUT, du producteur (d'infos, le codeur) au consommateur (d'info, le PC).
Ensuite, si je peux me permettre mon avis, s'il fallait un automate tout fait, pour piloter le "gros hard" comme les relais, la lecture de l'AU et autres BP sur le pupitre, je choisirais le controllino. Et le PCI pour le codeur.
jeanfranlec,
ne le prends pas mal, mais le pci, c'est d'une lourdeur ... !
(et là ce n'est pas juste au futur et au conditionnel comme ma remarque concernant le gray)
Je ne le prends pas mal du tout. 
D'un coup d’œil rapide je voyais juste le fait que les infos allaient directement du codeur au PC.
naturland:
ARTOUSTE
Alors le cheminement est plus du ressort de mon père, étant programmeur c'est lui qui est en charge de cette tâche difficile.
...
Sauf que ça ne se fait pas aussi simplement, car dans mon cahier des charges il y a un écran tactile IBM à gérer et ce fameux codeur absolu à lire.
Bonsoir
OK
Pour transcoder du gray , il y a 2 ecoles principales avec chacunes leurs avantages et inconvenients
Quelle sont tes contraintes temporelles max entre lecture d'une position et l'action à suivre ?
en peu en marge ; qu'est ce qui a guidé ce choix de remplacer de l'A/B par de l'absolu ?
Je suppose que dans le cintrage "multiple" avec un seul degré de liberté (un seul encodeur) , les différentes étapes se suivent essentiellement en reprenant/recalant une reference relative 0 à chacune des nouvelles étapes ?
Tu va donc demander au programme de gestion de l'encodeur absolu de prendre à chaque debut de nouvelle etape comme reference sa position actuelle (entre 0 et 1023) ou tu a un moyen mécanique de repositionner formellement ton encodeur pour que 0 soit lu ou tu va prendre la valeur absolue lue 
comme 0 relatif ?
- calculer par soft la sortie linéaire fonction de l'entrée gray (- sur vitesse + sur occupation mémoire)
- présenter la sortie linéaire par simple indexage sur la valeur gray en entrée (+ sur vitesse - sur occupation mémoire)
dans ce projet on peut aussi considérer l'arduino comme une simple interface parallèle <-> série :
côté plieuse, en parallèle, le gray, les relais ...
côté PC, l'interface série (usb, rs485 ...)
la conversion du gray en unité lisible sera un jeu d'enfant en langage évolué sur le PC par le papa programmateur
trimarco232:
dans ce projet on peut aussi considérer l'arduino comme une simple interface parallèle <-> série :
côté plieuse, en parallèle, le gray, les relais ...
côté PC, l'interface série (usb, rs485 ...)la conversion du gray en unité lisible sera un jeu d'enfant en langage évolué sur le PC par le papa programmateur
bonjour trimarco
oui , mais quelque soit "l'endroit" ou le transcodage est realisé , les 2 solutions demeurent avec les mêmes "avantages/inconvénients" .
Il faudrait en savoir un peu plus sur les reelles contraintes temporelles , AMHA elles ne doivent pas être très élevées vu les techno employées (relais/hydraulique/... )
Les experts diraient que ce qui compte aussi c'est la fréquence d'échantillonnage au regard de la vitesse angulaire du cintrage.
Aprés, si il est connut que le systéme s'arrête mécaniquement avec un DELTA angle.
Par exemple tu veux cintrer 90° et tu sais qu'il faut à la machine, à partir du moment ou tu lui donne l'ordre d'arrêter le cintrage, 2° pour que l'arrêt soit effectif, alors tu arrête à 88°.
Pour revenir à la fréquence d'échantillonnage, forcément si tu a une vitesse angulaire de cintrage de X° par seconde et que tu fais une mesure toutes les 5 secondes, tes pas de résolutions ne pourront pas descendre en dessous de 5X.
C'est le théorème de shannon ça non?
D'où selon moi l'interêt de séparer la gestion mesure d'angle du reste.
Et compte tenu de la précision demandée (0,25° si je ne me trompe pas) et de la vitesse angulaire (je ne l'ai plus en tête) on devrait y arriver, ce n'est pas non plus de la trés haute précisionqui est recherchée il me semble.
Windows n'étant pas très déterministe en terme de temps de réponse, si tu ajoutes à ça du code interprété (n'oublions pas que l'application sera écrite en Python. Et aussi pour que la mise au point soit plus simple. Je pense qu'il serait préférable d'avoir la lecture de l'angle ET la commande de la machine dans l'arduino (Controllino) le PC se contentant d'envoyer des commandes haut niveau et suivant l'avancement des tâches.
oui , mais quelque soit "l'endroit" ou le transcodage est realisé , les 2 solutions demeurent avec les mêmes "avantages/inconvénients" .
Il faudrait en savoir un peu plus sur les reelles contraintes temporelles , AMHA elles ne doivent pas être très élevées vu les techno employées (relais/hydraulique/... )
Bonjour Artouste, et les autres !
tu as raison (comme toujours),
en lisant la suite tu comprendras où je veux en venir
Je pense qu'il serait préférable d'avoir la lecture de l'angle ET la commande de la machine dans l'arduino (Controllino) le PC se contentant d'envoyer des commandes haut niveau et suivant l'avancement des tâches.
Bonjour,
tout à fait d'accord (de la façon dont c'est formulé mais pas forcément de celle dont certains d'entre vous pourraient l'entendre) :
l'arduino n'a pas besoin d’interpréter l'angle, c'est le rôle de l'IHM :
avant le début du pliage, le PC dit à l'arduino que quand une certaine valeur est stabilisée sur ses entrées parallèles, l'arduino déclenche l'arrêt de tel ou tel relais
ainsi l'arduino peut réagir sans se casser la cpu, et dans un timing indépendant des errements de windows
Le créateur reste maitre de sa création, je donne juste un avis.
Cela me semble effectivement TOUT A FAIT logique de confier au PC les tâches de hauts niveaux.
C'est une évidence que c'est à ce niveau que l'Homme indiquera à la Machine quel angle il désire.
A un moment il faut tout de même comparer la consigne à la mesure, cela veut donc dire
CONSIGNE envoyée par la PC
MESURE faite par quelque chose à déterminer et qui fait débat ici (codeur + arduino, codeur + PCI ...), et peut-être traitement de la mesure pour affichage.
COMPARATEUR qui fait aussi débat ici (comparateur en soft, sur arduino, sur le PC ...).
TRAITEMENT de la comparaison (en tout ou rien, bon pas bon ...) si c'est OK on arrête de cintrer.
Sur PC, il y a des gens qui font avec Labview des mesures et actions pour des systèmes rapides donc ce n'est pas une histoire de PC ni windows (voir lunbuntu et autres autour de Linux) qui fait la rapidité du truc.
Par contre, la séparation BAS niveau HAUT niveau et choix du langage me semble être un trés bon argument pour déterminer qui fait quoi vis à vis de ce codeur.
fdufnews:
Windows n'étant pas très déterministe en terme de temps de réponse, si tu ajoutes à ça du code interprété (n'oublions pas que l'application sera écrite en Python. Et aussi pour que la mise au point soit plus simple. Je pense qu'il serait préférable d'avoir la lecture de l'angle ET la commande de la machine dans l'arduino (Controllino) le PC se contentant d'envoyer des commandes haut niveau et suivant l'avancement des tâches.
Bonsoir fdufnews
+1 avec ta réponse
Maintenant , AMHA "il est simplement urgent d'attendre" 
les réponses de naturland aux dernières questions posées ici ! 8)
Ouh ya, tout le monde se pose plein de questions.
Mais je ne sais pas vraiment ce que vous attendez comme réponses.
Je vais essayer de resituer la situation.
Pour ceux qui ne connaissent pas comment fonctionne une cintreuse vous pouvez vous donner une idée de la vitesse de cintrage sur ces vidéos
Mandrel pipe bender Curvatubi B.L.M. for sale - YouTube (A noter que sur cette vidéo le bras se balance un peu, du aux problemes hydraulique)
- YouTube (cette vidéo représente bien la vitesse réelle)
Voilà pour répondre sur la partie technique.
En ce qui concerne l’électronique, je ne sais pas trop quoi vous répondre ne voyant pas de question précise. N'hesitez pas à me poser des questions clairement, je tacherai de vous répondre avec photos ou vidéo si besoin.
Ma seule interrogation est quelle direction prendre pour piloter ceci.
Actuellement on part plutôt sur un controllino.
Mais j'ai plus l'habitude de voir sur les machines industrielle un PC avec carte qui pilote des "modules" de commande, d’où ma petite réticence http://www.mpi-elec.net/cablage-d-armoires-electriques.html , un arduino peut il concurrencer une installation "industrielle". Ma machine n'est ni super rapide ni super précis, donc ça devrait aller, mais je veux m'en assurer.
J'en demande à vos expériences, un arduino peut-il tenir la route sur une machine industrielle.
J'ai actuellement un "ordi" des années 80 donc depuis tout ceci à évoluer, un pc+controllino (ou autres...) peut surement faire l'affaire, mais ne connaissant pas les limites de l'arduino je me renseigne.
Bonjour:
Sur ce qu'on voit de mpi, se sont des photos d'armoires avec automates Indus (siemens) et leurs modules E/S. Controllino peux je pense, et dans cette application, remplacer Siemens tres avantageusement .
Utiliser le PC AUSSI c'est intelligent, surtout pour certaines taches I peu ca aussi la question PC a mon humble avis.
Tout à fait, et je suis habitué a voir ceci et les entreprise d'intégration d'automatisme ne travaille qu'avec ces produits.
Simplement par ce qu'il y ont un intérêt mais essentiellement parce qu’ils ne connaissent que cette manière de faire:
-Intégrer des systèmes étudiés et dédies à telle ou telle tâche. Peu de problème de compatibilité et un SAV.
-Se sont des produits évolutif, éprouvés et endurants.
Maintenant dans mon cas je n'aurais pas une machine qui tournera 24/24, elle demande peu de rapidité, performance et contrainte (du moins je trouve). Donc l'arduino peut devenir intéressant dans ce cas la.
Pour le moment j'en suis donc à:
1-Confirmer le choix de l'arduino/python
2-Confirmer si l'on peut (ou si c'est judicieux) de mélanger des interfaces (PCI / API etc...)
3-Choisir le ou les interfaces
Et seulement après ces étapes l'on commencera à faire mumuse avec les codes...
fdufnews et Trimarco232
D'accord avec vous c'était l'idée initial avoir un "module" qui interprète les entrées et les traite directement suivant les valeurs demandées avant le cycle.
A savoir quand même que plusieurs cycle différent pourront être executés à la suite sans intervention de l'homme et que le windows sera surement du linux.