Maurice

Avatar de l’utilisateur
F1OAT
Electrolab::Membre
Messages : 93
Enregistré le : 04 mars 2017, 19:28
Contact :

Re: Maurice

Messagepar F1OAT » 11 déc. 2018, 20:11

Bas vient de nous donner des infos sur le groupe Machinekit : https://groups.google.com/forum/#!topic ... BYgBSnwieQ
Donc, ça serait plutôt EtherCat la bonne option.
Le module HAL est ici : https://github.com/sittner/linuxcnc-ethercat

Sinon, le projet https://github.com/rene-dev/stmbl semble très intéressant : un drive open source qui semble faire du DC.
2 kw, ça doit suffire pour les moteurs Fanuc d'origine.
Avatar de l’utilisateur
F1OAT
Electrolab::Membre
Messages : 93
Enregistré le : 04 mars 2017, 19:28
Contact :

Re: Maurice

Messagepar F1OAT » 11 déc. 2018, 20:15

fabrice a écrit :Autre question, j'ai largement entendu que si on fait du RT non critique (et pas de certification) on prends un noyau linux sinon tous sauf linux. Pour un centre d'usinage, critique ça veut dire quoi ?


Oui, la question se pose.
LinuxCNC et Machinekit s'en sortent bien, avec soit du RTAI, soit du RT-PREEMPT.
Jamais vu de pb sur mes machines, et c'est utilisé commercialement par Tormach sur des machines de prod.
Avatar de l’utilisateur
fabrice
Electrolab::Référent
Messages : 94
Enregistré le : 17 sept. 2017, 00:34
Contact :

Re: Maurice

Messagepar fabrice » 11 déc. 2018, 20:29

Je me demande ce que pourrait apporter un os plus simple comme riot.
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1592
Enregistré le : 01 mars 2017, 20:46
Contact :

Re: Maurice

Messagepar Flax » 12 déc. 2018, 09:58

fabrice a écrit :Autre question, j'ai largement entendu que si on fait du RT non critique (et pas de certification) on prends un noyau linux sinon tous sauf linux. Pour un centre d'usinage, critique ça veut dire quoi ?

F1OAT a écrit :Oui, la question se pose.


"RT non critique" c'est une oxymore, non ? Effectivement il faudrait poser la question plus clairement et définir "critique".
Mais peut-être que j'enfonce des portes ouvertes et que je suis à côté de la plaque parce que je n'ai pas compris la question ?

Bon, essayons quand-même : Si on parle de Linux "standard" type desktop, évidemment qu'il ne faut pas l'utiliser pour cette application, vu que ce n'est PAS un OS temps-réel. Après il y a les branches RT, comme RTLinux, Xenomai et cie, et là je ne saurais pas juger de la pertinence de ces implémentations RT en elles-mêmes, je ne les connais pas, je ne les ai pas utilisées. Mais le peu que j'en ai vu me donne quand-même l'impression que ce sont des bricolages pour rendre temps-réel un OS qui n'a pas été prévu pour ça à la base. Si on tient à mettre un OS pour le contrôle, il faut un "vrai" OS temps réel, genre VDK, VxWorks, RTOS ... Là, normalement j'enfonce vraiment une porte ouverte :0

Je ne connais pas l'état de l'art dans les machines d'usinage, mais j'aurais tendance à penser que le contrôle des axes devrait être de toutes façons et à tout prix contrôlé par un système temps-réel dur - quitte à avoir de la supervision moins contrainte - et donc que se poser la question sous la forme "est-ce que ça va suffisamment vite / latence suffisamment faible" est déjà se tromper de voie parce qu'on part sur un système qui n'est pas temps-réel. Mais encore une fois, peut-être ai-je mal compris ? :-/J'ai l'impression de me tromper sur le niveau - au sens fonctionnel - au sujet duquel on parle.

Concernant les histoires de certification, je pense que le problème est à prendre dans l'autre sens : ce n'est pas Linux qui n'est pas certifié / certifiable et donc "mauvais". Ce sont les autres OS, quand ils sont commerciaux et poussés par une boîte qui doit les vendre (cher), qui le sont. Quand on doit certifier un système, on ne va pas exclure Linux parce qu'il est "mauvais", mais parce que la certification de l'OS serait une tâche supplémentaire à ajouter au développement. Alors que Green Hills et cie ont des OS temps réel clé-en-main avec tous les petits macarons kivonbien pour rassurer les organismes de certification (et le prix stratosphérique qui va avec). Exemple en ce moment dans l'automobile avec l'ISO-26262 et Autosar : si le système doit être conforme, il faut que tous les éléments de la chaîne le soient. Donc on va prendre les composants / compilateurs / OS qui sont conformes (jusqu'à aller parfois dans des extrémités délirantes), ce qui ne veut pas dire que ceux qui ne sont pas conformes sont mauvais, ça veut juste dire qu'ils ne peuvent pas être choisis. Le fait de devoir être conforme à une norme ne dit intrinsèquement rien sur la qualité de la norme à tenir, et donc sur la qualité du système final. Ça dit juste que ça doit être conforme :mrgreen:
Avatar de l’utilisateur
f4grx
Messages : 881
Enregistré le : 26 sept. 2016, 13:58

Re: Maurice

Messagepar f4grx » 12 déc. 2018, 16:35

fabrice: NuttX arrive a répondre en quelques centaines de ns si on s'y prend vraiment bien, la dizaine de microseconde est beaucoup plus facilement atteignable.

-USB, je pense que niveau temps réel, c'est totalement dans les choux.

-CANOpen est bien foutu mais plutot avec des controleurs hardware plus proche de la machine (carte fpga pcie?), parce que via USB je pense pas que ca tienne la route.

EtherCAT:
Pour l'ouverture, apparemment c'est: IEC 61158, IEC 61784, ISO 15745, SEMI E54.20
Reste a vérifier que les docs sont accessibles, mais a priori, faut raquer:
https://www.evs.ee/products/iso-15745-1-2003
https://webstore.iec.ch/publication/25404&preview=1
L'avantage est évident: ethernet, sans bus "bizarre" nécessitant des adaptateurs.

Niveau doc c'est les mêmes problèmes: il faut payer pour la doc CANOpen CiA 402 (moteurs), mais on trouve des drafts complets, et le protocole de base (CIA 301) est dispo. Malgré tout, les fabricants de drives CANopen fournissent des déclinaisons spécifiques de la doc pour leurs machines, exemple festo:
https://www.festo.com/net/SupportPortal ... 2085f1.pdf
C'est souvent suffisant.

stmbl a l'air très très sexy.
Avatar de l’utilisateur
F1OAT
Electrolab::Membre
Messages : 93
Enregistré le : 04 mars 2017, 19:28
Contact :

Re: Maurice

Messagepar F1OAT » 12 déc. 2018, 21:44

J'ai étudié la doc EtherCAT https://www.schneider-electric.com/en/d ... 113868-EN/
Je crois qu'il y a les infos nécessaires pour les registres.

Pour le paramétrage du drive, il faut utiliser Twincat 2 https://www.beckhoff.com/english.asp?do ... catdow.htm
Et un fichier XML https://www.schneider-electric.com/en/d ... _XML_file/
En principe, Twincat détecte les devices présents sur le bus, et je pense que c'est après que l'on charge le XML.
Sans device, je n'ai pas trouvé comment forcer le chargement (pour se faire la main avec les paramètres).

Ici un tuto sur EtherCAT : https://www.ethercat.org/pdf/english/Et ... n_0905.pdf
En gros, ça ressemble à MODBUS : des registres à lire/écrire.
Ca reprend aussi les concepts de CANopen pour les différents types de commandes.

EtherCAT semble plutôt répandu dans le monde LinuxCNC/Machinekit.
J'ai vu des posts sur la connexion avec du Lexium 05, mais personne en Lexium 32.

On pourrait aussi attaquer nos modules d'I/O en EtherCAT : il faut juste remplacer le module MODBUS par un EtherCAT.
Avatar de l’utilisateur
Flax
Electrolab::CA
Messages : 1592
Enregistré le : 01 mars 2017, 20:46
Contact :

Re: Maurice

Messagepar Flax » 13 déc. 2018, 11:54

Merci pour le lien vers le tuto EtherCAT, je ne connaissais pas le fonctionnement de ce protocole (à part de loin dans le brouillard), et c'est différent de ce que je pensais.
En fait, si je pige bien, c'est du Ethernet "classique", mais avec des trames "génériques" envoyées régulièrement de façon synchrone, de façon à avoir de la reproductibilité, et le contenu est rempli "à la volée". Donc on a une latence commune à tout le monde, ce qui est plus facile à gérer que des latences qui ne font que ce qu'elles veulent.
CANOpen c'est le même principe en CAN ?
En supposant que les deux fonctionnent sur le même principe, effectivement EtherCAT est préférable : plus de bande passante (x100 avec du CAN 1Mbits, sachant qu'en général on est plutôt sur du 500kbits), par contre interface plus chère (HW : pas les mêmes transcievers ni les mêmes câbles), et potentiellement plus de charge CPU, quoique les contrôleurs dédiés doivent permettre de rendre le protocole transparent, et donc de ne pas se soucier des histoires de gestion de la stack IP ? (je ne sais pas si ce que je dis est clair ... c'est pas très clair dans ma tête, j'avoue :aille2: )
En tous cas, avec des cycles à 276µs (~3kHz) on peut presque faire de la régulation moteur en direct :langue3:

Ai jeté un oeil à stmbl, attention le power-module est donné pour 1.5kW, pas 2kW : https://www.infineon.com/dgdl/iram256-2 ... d9dafb185f
Bon, c'est ce qui est donné dans le texte d'intro de la datasheet, donc il faut voir si on arrive pas à en tirer plus si on met la dissipation ad-hoc. Maaaais c'est à vérifier :) Après, si 1.5kW suffit ...
Avatar de l’utilisateur
F1OAT
Electrolab::Membre
Messages : 93
Enregistré le : 04 mars 2017, 19:28
Contact :

Re: Maurice

Messagepar F1OAT » 13 déc. 2018, 21:38

Oui, c'est ce que j'ai compris aussi.
Il y a des contrôleurs slave hardware qui gèrent l'insertion des datas dans la trame qui passe.
Et du DMA pour gérer l'échange des registres avec la RAM du CPU.

Ici un shield Arduino : https://www.bausano.net/en/hardware/eth ... sycat.html
Et le chip LAN9252 : https://www.microchip.com/wwwproducts/en/LAN9252
Avatar de l’utilisateur
fabrice
Electrolab::Référent
Messages : 94
Enregistré le : 17 sept. 2017, 00:34
Contact :

Re: Maurice

Messagepar fabrice » 13 déc. 2018, 23:34

Si j'ai bien compris avec ce type de servo drive, grosso modo

* on transforme le gcode en une séquence de positions
* que l'on convertit en instructions servo ethercat
* puis on les envoie via un driver kernel ethercat et un phy ethernet pc standard, les slaves ethercat recevant les instructions dans l'ordre de la chaîne ethercat
* et le servo drive se débrouille tout seul en mode position

Il faut donc essentiellement un tuning correct des servos pour que les axes soit synchro et gérer la synchro avec la broche ...

Mais dans ce cas LinuxCnc ne fait plus grand chose ???
Peut on changer le mode du servo drive à la volé ? En tournage il y a des opérations simples, tel un déplacement entre deux positions avec une vitesse consigne, et des opérations complexes en coordonnée cylindrique.

Ça fonctionne comme cela un centre d'usinage de nos jours ? Ou c'est une interpolation bas niveau de courbe de Bézier à nD avec rétroaction sur la position et la vitesse des axes ?
Avatar de l’utilisateur
fabrice
Electrolab::Référent
Messages : 94
Enregistré le : 17 sept. 2017, 00:34
Contact :

Re: Maurice

Messagepar fabrice » 14 déc. 2018, 00:44

En cherchant j'ai trouvé cette thèse faîte à l'ENS Cachan en 2013 : Commande numérique ouverte : interpolation optimisée pour l’usinage 5 axes grande vitesse des surfaces complexes

( par ouvert il faut comprendre, open de open software )

* http://lurpa.ens-paris-saclay.fr/versio ... 5970149354
* posting.php?mode=reply&f=7&t=48el.archives-ouvertes.fr/tel-00913943
* http://lurpa.ens-paris-saclay.fr/versio ... ZYZYZYZYZY

En gros ils ont hacké un centre d'usinage Mikron 5 axes en remplaçant une partie de la commande siemens 840D par un contrôleur temps réel dSPACE et des variateurs universels analogiques Siemens SimoDrive 611U ( à l'origine 611D numérique ).

Tout l’intérêt des variateurs universels 611U réside dans le fait qu’ils sont pilotés par un signal analogique ±10V. Suivant le paramétrage interne du variateur, ce signal de commande peut être pris comme une consigne de vitesse ou comme une consigne de courant. Cela permet au variateur de réaliser soit de la boucle de courant uniquement, soit les deux boucles courant et vitesse. Évidemment, l’ensemble des gains et des filtres sont paramétrables dans le variateur, mais la structure d’asservissement est figée (correcteur PID). Pour l’implémentation actuelle, le signal de commande fournit la consigne de vitesse et les deux boucles d’asservissement sont réalisées par le variateur, mais un pilotage en courant pourrait être réalisé notamment pour implémenter le contrôle par anticipation en accélération dans la commande.


Donc c'est de l'asservissement chiadé en numérique.

Retourner vers « Mecanique »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 1 invité