Réseau de terrain (stage)

[Matheux56]

Bonjour,

Lors de mon stage, je dois choisir un moyen de communication pour effecteur des essais d'effort sur les pots d'échappement des véhicules. J'ai le choix entre du CANopen, RS485, Ethercat, DeviceNet et Profibus-DP. les essais seront fait par le moyen de moteur linéaire. Le problème c'est que j'ai du mal a me décider sur le moyen de communication et le pourquoi de ce choix.

En effet Ethercat est le plus rapide mais est très coûteux et demande un système d'exploitation en temps réel car Windows seul ne suffit pas pour gérer les I/O si j'ai bien compris.

Profibus-DP est à exclure car je n'ai pas ce genre de configuration sur le controlleur

DeviceNet est assez compliqué à mettre en oeuvre d'après ce que j'ai vu.

Il ne me reste plus que Ethercat, RS485 et CANopen.

Pour moi, le plus adapté serait le CANopen car déjà c'est un bus fait pour l'industrie automobile, de plus il demande moins de câble que les autres et à une fonction de détection d'erreur permanente. Il est aussi plus robuste dans un environnement perturbé grâce à son signal différentiel CAN-H et CAN-L (de même pour la RS485 si j'ai bien compris). Il permet aussi la sauvegarde de donnée en cas de problème grâce à sa mémoire si j'ai bien compris aussi..

Voilà, j'ai essayé de faire au mieux dans mon étude comparatif en cherchant partout sur internet mais je bloque un peu et j'aimerais votre aide sur les avantages/inconvénient de chacun et ce qui serait le mieux.

Merci d'avance pour vos réponse.
-----

[lou_ibmix_xi]

Avantages / inconvénients c'est lorsqu'il reste plusieurs candidats qui répondent tous à tes spécifications. Or tu n'en donne pas beaucoup, on a compris que ça doit tourner sans OS (1 spec), maintenant il faut les autres, débit max, taille des messages, type bus (plusieurs périph sur un même tuyau, alors attention au collisions qui rendent difficile le déterminisme des com), ou type étoilé... etc...

De plus je ne suis pas sûr que tu compare ce qui est comparable: le RS485 c'est juste un type de tuyau (la couche physique), alors que de mémoire CANOpen est un protocole (une manière de discuter) qui peut donc s'adapter à plusieurs type de liaison, même si la liaison privilégiée est le CAN.

[Matheux56]

Merci pour ta réponse rapide !

Le problème c'est que je n'ai pas plus d'infos sur le projet, je dois me débrouiller avec juste le thème du sujet.. C'est pour cela que je n'arrive pas du tout à avancer..

Je vois ce que tu veux dire, la RS485 est plus un type de liaison que l'on peut associer avec avec moyen de communication type Profibus par exemple.

J'aurais juste un moteur à piloter donc je suppose que ça sera plutôt un type bus..

[Matheux56]

Ah j'ai oublié de dire que le contrôle se fera à partir du PC avec une commande numérique.

[A voir en vidéo sur Futura]

[Matheux56]

Parce que sinon tout ce qui est Max speed, tranfert node, Message time, Max nodes tout ça je les ai noté dans mon tableau comparatif, mais j'ai l'impression que ça me sert à rien au vu des infos que j'ai..

[Matheux56]

Mais bon d'après ce que je vois le CANopen est conçu pour les réseaux de contrôle/commande industriels orientés sur le contrôle de moteur mais il y a aussi d'autres domaines. Ce qui rentre pas mal dans ce que je veux faire.

[lou_ibmix_xi]

J'aurais juste un moteur à piloter donc je suppose que ça sera plutôt un type bus..

Là je ne comprends pas. Un moteur se pilote par courant continu (pour un moteur à CC), en monophasé, en triphasé, ou avec un pilotage électronique pour les brushless...
Peut-être on t'impose un moteur avec son contrôleur, alors il faut se baser sur ce que nécessite ce contrôleur. Mais ce n'est pas forcément aussi évolué qu'un vrai bus. Par exemple beaucoup de contrôleur de moteur brushless se pilote par un signal PWM.
Mais j'imagine que c'est nu moteur pas-à-pas, sans vraiment connaître cette techno, à mon avis mon raisonnement est identique.

Une piste: le projet arduino, tu as une foultitude de module tout fait pour contrôler des moteurs pas-à-pas (matériel et logiciel), tu auras déjà le côté "moteur", reste pour toi à faire le côté liaison PC/arduino, le moins cher / plus simple étant à mon avis d'utiliser la liaison série (une interface USB/série coutant pinuts). La question est de savoir si le logiciel de pilotage côté PC existe déjà, ou si il est spécifié, car ça peut imposer le choix du protocole et/ou du type de liaison à utiliser. Si ce n'est pas le cas, utilise un protocole simple textuel sur liaison série, ça te permet de pouvoir vérifier la partie arduino+ moteur avec un logiciel type hyperterminal. Puis quand ça marche tu peux faire une belle IHM en python ou autre langage de haut niveau pour faire une jolie interface pour les utilisateurs.

[Matheux56]

Oui c'est exactement ça, on m’impose un moteur et son contrôleur :

http://shop.linmot.com/E/ag7000.e12/...1250-ec-uc.htm pour le controlleur

https://www.yumpu.com/en/document/vi...ies-p01-48x360 pour le moteur (P01-48x360)

Le problème c'est que le contrôleur peut communiquer de diverse façon comme je l'ai décrit dans mon premier post.. Donc au vu du peu d'info, je pense faire une étude comparative et en discuter avec mon tuteur mais même là, faire des comparaisons avec aucunes informations (et je pense pas en avoir plus) ça reste galère..

[lou_ibmix_xi]

Le problème c'est que le contrôleur peut communiquer de diverse façon comme je l'ai décrit dans mon premier post.. Donc au vu du peu d'info, je pense faire une étude comparative et en discuter avec mon tuteur mais même là, faire des comparaisons avec aucunes informations (et je pense pas en avoir plus) ça reste galère..

Effectivement, ce contrôleur accepte tout ça, donc retour au point de départ...
Tu dis que c'est un PC qui doit contrôler ce bousin, du coup je regarderai:
- ce qui est fournit comme SDK/bibliothèque/outils avec le contrôleur moteur
- le coût des différentes interfaces pour PC

Le 1er point tu vérifies si ce qui est fourni te permet d'attaquer toutes les interfaces du contrôleur, si ce n'est pas le cas, tu peux éliminer (attention tout de même, si par exemple tu n'as pas d'API pour attaquer du RS485, qui n'est qu'une liaison série, ce n'est pas forcément rédhibitoire _SI_ le protocole est textuel, pas trop alambiqué)

2ème point, ETHERNET tu en trouveras sur tous les PC, j'ai peur qu'EtherCAT nécessite une interface spécifique (probablement cher) et la couche logicielle qui va bien.

Attention tout de même, le besoin peut également imposer l'interface: débit, temps-réel (qui dépends également de la topologie du réseau: ETHERNET en point à point pour du "temps réel" OK, sinon c'est mort il faut EtherCAT)

Tiens nous au courant.

[Matheux56]

C'est exactement ça ^^ !

Avec le contrôleur est fournit un logiciel linmot talk qui permet l'interfaçage avec une RS232, ça c'est ok je communique avec.

Maintenant pour ce qui est du pilotage, en effet avec EtherCAT j'ai vu qu'il fallait un système en temps réel plus tout ce qui va avec, donc niveau prix c'est pas trop ça ^^.

Maintenant je me tâte à faire avec du ETHERNET, mais comparé avec l'EtherCAT, je ne sais pas trop de quoi j'ai besoin..

Par contre qu'est ce que tu appelles du point par point ? je vois ça partout mais je comprends pas grand chose a tout cela ^^

[lou_ibmix_xi]

C'est exactement ça ^^ !

Tu me rassures, je connais encore mon métier

Avec le contrôleur est fournit un logiciel linmot talk qui permet l'interfaçage avec une RS232, ça c'est ok je communique avec.

J'imagine qu'il ne suffit pas ?

Maintenant pour ce qui est du pilotage, en effet avec EtherCAT j'ai vu qu'il fallait un système en temps réel plus tout ce qui va avec, donc niveau prix c'est pas trop ça ^^.

Maintenant je me tâte à faire avec du ETHERNET, mais comparé avec l'EtherCAT, je ne sais pas trop de quoi j'ai besoin..

Par contre qu'est ce que tu appelles du point par point ? je vois ça partout mais je comprends pas grand chose a tout cela ^^

Je vais préciser, EtherCAT (de mémoire) c'est nécessaire pour faire de la communication temps-réels sur un réseau câblé "type ethernet" classique, où souvent sur un même câble passent des paquets pour plusieurs communications différentes (pensent au câble reliant 2 switchs par exemple). Du coup à cause des collisions de paquets, tu ne peux garantir l'instant de réception d'un paquet.

Ce problème ne se pose plus si ton PC est relié directement au contrôleur, il ne peut plus y avoir de collision, tu as une communication temps-réel.

Mais attention, c'est orthogonale avec un système temps réels, i.e. un système qui réponds à un stimuli en un temps borné et quantifié, par exemple un système anti collision doit arrêter le bousin en moins de X ms à la détection de l'obstacle.

Pour finir, un système temps réel n'a pas forcément besoin de moyen de comm temps-réels (sauf si c'est un tuyau de stimuli ou réponse). L'inverse et vrai également, mais probablement plus rare, le seul exemple qui me vienne est la synchro par réseau.

Pour hiérachiser, ethernet sera probablement plus "rapide" que tes liaisons séries / canOPEN (mais ce n'est pas forcément très pertinent si les autres débits suffisent)
Par contre Ethernet est probablement plus compliquer à mettre en oeuvre qu'en liaison série (je ne saurais pas dire pour canOpen), seul la doc de la bibliothèque fournie avec le contrôleur peut te guider à ce niveau.

[Matheux56]

Coucou et merci pour ton aide

J'imagine qu'il ne suffit pas ?

Comment ça ? Je pense peut-être que je mélange des choses pourtant qui était clair dans ma tête x)

Interfaçage et le pilotage sont deux choses différentes non ? Interfaçage via la RS232 permet de relier le variateur/contrôleur au PC mais ne permet pas un pilotage de moteur en numérique ?

Donc pour moi cette interfaçage suffit largement.

Ce problème ne se pose plus si ton PC est relié directement au contrôleur, il ne peut plus y avoir de collision, tu as une communication temps-réel.

Bah avec la RS232 c'est le cas alors. Mais on peut parler seulement comme tu l'as dis de communication temps réel mais pas pour le système globale comportant la boucle fermée avec le moteur est tout le blabla si j'ai bien compris ce que tu as dit !

[Matheux56]

AAAAH ! à moins que j'ai mal compris et que avec le RS232 on peut configurer le variateur et le piloter ?

Si c'est le cas alors je ne vois pas sur quoi m'appuyer pour dire si ça suffit ou non .. Car a part que la RS232 peut aller jusqu'a 115K et quelques baud/s comment puis-je savoir si ça peut convenir xD ..

[Matheux56]

Sachant que la transmission de donnée ce fait sur 8 bits + 1 start + 1stop > On se retouve à 10. Donc on envoie un bit à 11,5 Kbauds soit une fréquence de 11500 Hz..

Même avec ça, je peux rien faire au vu du manque de donnée je sens ^^.

[lou_ibmix_xi]

Comment ça ? Je pense peut-être que je mélange des choses pourtant qui était clair dans ma tête x)

Si tu arrives à faire faire à ton moteur ce qu'il doit faire pour le vrai projet, au travers de l'interface fournie, c'est déjà un bon début:
- tu sauras que c'est faisable en RS232
- tu peux peut-être "scripter" les commandes pour automatiser, directement depuis ce programme, alors ton projet est fini (sauf si tu veux une "vraie" interface, mais c'est cosmétique)
- si une bibliothèque est fournie, l'enchaînement des commandes devrais pouvoir facilement se "traduire" en une suite d'appels de fonctions.

AAAAH ! à moins que j'ai mal compris et que avec le RS232 on peut configurer le variateur et le piloter ?

Si c'est le cas alors je ne vois pas sur quoi m'appuyer pour dire si ça suffit ou non .. Car a part que la RS232 peut aller jusqu'a 115K et quelques baud/s comment puis-je savoir si ça peut convenir xD ..

C'est comme ça que je le comprennais, mais il n'y a que la documentation de ton contrôleur qui peut y répondre.

Mais comme tu dis, le "tuyau" RS232 est peut-être trop limité en débit pour pouvoir faire tout ce dont tu as besoin.

[Matheux56]

En effet, en discutant on m'a dit que la RS232 est pas fait pour ça (rapidité).

J'aurais un grosse question a te poser.

le variateur est un servo-drive donc un servo-contrôleur, qu'est ce que ça signifie ? Qu'il est intelligent et que je peux faire un rebouclage dessus ?

De plus, comme c'est un Ethercat-drive, je suppose qu'avec mon pc je peux directement le relier aux variateur et piloter le moteur en Ethercat ?

On m'a dit qu'il fallait un carte intel au niveau du Pc pour pouvoir gérer en tant que maître. Quand je regarde dans mes cartes j'ai une Intel dual band wireless-AC 7265 et realtek pcie gbe family controller #2 donc je suppose que ma carte réseau et la realteck donc je suis baisé xD ?

[lou_ibmix_xi]

En effet, en discutant on m'a dit que la RS232 est pas fait pour ça (rapidité).

J'aurais un grosse question a te poser.

le variateur est un servo-drive donc un servo-contrôleur, qu'est ce que ça signifie ? Qu'il est intelligent et que je peux faire un rebouclage dessus ?

De plus, comme c'est un Ethercat-drive, je suppose qu'avec mon pc je peux directement le relier aux variateur et piloter le moteur en Ethercat ?

On m'a dit qu'il fallait un carte intel au niveau du Pc pour pouvoir gérer en tant que maître. Quand je regarde dans mes cartes j'ai une Intel dual band wireless-AC 7265 et realtek pcie gbe family controller #2 donc je suppose que ma carte réseau et la realteck donc je suis baisé xD ?

Tes questions sont trop pointues pour moi, je n'ai jamais bossé avec ce type de matériel...
Mais à mon avis EtherCAT n'est PAS compatible avec Ethernet, il te faudrait un contrôleur EtherCAT côté PC, qui est probablement hors de prix.
Mais si le port ETHERNET du contrôleur te permet de faire tout ce que tu veux, c'est à priori bon.

On m'a dit qu'il fallait un carte intel au niveau du Pc pour pouvoir gérer en tant que maître. Quand je regarde dans mes cartes j'ai une Intel dual band wireless-AC 7265 et realtek pcie gbe family controller #2 donc je suppose que ma carte réseau et la realteck donc je suis baisé xD ?

Je ne vois pas de raison sur ethernet classique, sauf si on t'impose un MTU > 1500 (jumbo frames), c'est vrai que pas tout les contrôleurs ethernet ne le permettent (et les intel le permettent en général)