Forum

Bonjour,

Peux-tu préciser tes besoins? Fournir un schéma de l'architecture souhaitée (même sommaire et gribouillé).

Dans un premier temps, regarde du côté du bus CAN et de la couche logicielle CANOpen.

Salut,
Il faut préciser ta pensée : "Temps réel" et "pas d'exigence de vitesse de bus" c'est plutôt antinomique...
Vu le nombre de périphériques envisagé je crois que de toutes façons quelque soit le système retenu, il faudra des switchs, répéteurs ou autres amplis de bus vu la charge.
Si la vitesse n'est pas un problème et si le coût de réalisation est un critère important, je pencherais pour un bon vieux RS485 et un protocole MODBUS, sénile mais toujours utilisé partout et facile à mettre en oeuvre. En plus il y a MODBUS-TCP/IP qui permet de franchir le pas avec des passerelles industrielles standard Ethernet RS485.
Le CAN est également relativement aisé à mettre en oeuvre, quoiqu'un peu plus compliqué. Côté PC, il y a des adaptateurs divers "pas trop cher" (définir la valeur d'un bras)...
A+

Bonjour,
Je ne sais pas d'où tu sors ces chiffres de 32 et surtout 64???
RS485 n'est pas un protocole donc il ne peut avoir de limitation en nombre logique mais éventuellement en nombre d'impédances connectées : c'est donc un problème de charge HW, selon le type de drivers utilisés (consulter les spécifications); dans le temps il y avait une limitation de facto qui n'est plus la même de nos jours. On peut utiliser des amplis, éclateurs ou des répéteurs.
La distance importe aussi beaucoup car si les esclaves sont très éloignés les uns des autres, une ligne unique peut être "brouillée" par des phénomènes d'écho multiples.
Pour le protocole MODBUS, la limitation logique est de 255 esclaves.
Pour la carte PC à 1500 bucks, ça semble un peu exagéré. Il y a des choses bien moins chères : http://www.lextronic.fr/P2623-module-can--usb-converter.html ou http://www.elektor.fr/nouvelles/convertisseur-usb-can-pour-connecter-aisement-un.10948.lynkx par exemple.
C'est quoi la "puissance requise" nécessaire ? Evidement, si on parle d'une carte qui fait toute la soupe, scan rapide et gestion automatique, ça peut aller loin. Autrement on peut gérer soi même la com, ça nécessite d'écrire du soft.
On ne peut avoir le beurre et l'argent du beurre...
A+

C'est totalement faux. Le protocole MODBUS code l'adresse de l'esclave sur un octet plein. Il y a 256 adresses possibles; 0 est réservé au "broadcast" (tout le monde, sans réponse : très très peu utilisé) et 248 à 255 sont réservés (non utilisables en théorie mais ou peut passer outre dans sa propre implémentation).
Se référer à la norme : http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf#page=8
Encore une fois, d'où viennent vos chiffres?
C'est quoi ce nouveau 127 en RS485???
A+

C'EST FAUX :

le MODBUS developpé par MODICON, actuellement schneider est un protocole de communication qui decris un myen de communication maitre esclave mais qui ne precise pas la façon excacte de ce qu'il faut faire.

une chose est sure POUR LA PPA94 :
la specification officiele declare que le maximun de protagoniste pouvant participer au reseau est de 32 MAXIMUM.

ça tombe bien car je developpe actuellement ^pour l'entreprise dans laquelle je bosse un tel systeme compatible avec celui de la RATP pour que nous puissions nous brancher dessus.

nous utilisons comme couche hardware le RS-485 mais il y a bien d'autres possibilités.
le probleme de la limitation ne vient pas exactement des resistance de terminaisons mais des resistances de polarisations du bus (si on veut etre vraiment precis).
le bus doit posseder a chacque extremité des deux fils une resistance de 120 ohms, puis quelquepart entre ces deux fils il ya la possibilité de placer 32 stations dont une suele peut etre maitre, l'etaged'entrées sortie rs-485 le plus fiable consiste a polariser en tension les lignes differentielles, la sensibilité de mouvement des signaux detectable est fixée a 200mV il faut prevoir au minimum cette tension autrement le bus ne fonctionnera pas.
cet etage est decrit dans le livre TRAITE DE L'ELECTRONIQUE justement edité par elektor pour la FRANCE, il ya toutes les explications et les calculs detaillés et meme des conseils sur l'immunité au bruit.

Dans le numeros precedent d'elektor il ya aussi un autre habituelement conatoné eux developpements d'amplis analogiques qui a publié un article sur ce bus ainsi que sur les probleems qu'il a rencontré, trés interessant.

a quelque chose prés ON PEUT DIRE QUE LE RS-45 est la couche hradware du bus can.
Le canamene quelques raffinementscomme le bit stuffing et la notion de niveaux dominants et recesifs evitant le court-circuit du bus.

Le cartes PC-can coutent une bras !!!
oui mais elektor en a publié plusieurs au fur et a mesure des années, il existe des composants qui prenent meme en charge la stack ou meiux, vous pouvez prendre un microcontroleur avec une stack gratuite et vous le connectez a votre pc via un circuit usb-rs232.

bon courage
fab

au dela de 32 stations sur un reseau modbus , il est obligatoire d'utiliser un repeteur.

toute tentative de passer outre, c'est a dire en bricolant !!!!! les inpedance se soldera par une baisse de l'immunité au bruit ce qui est innacceptable dans l'industrie.

professionnellement aucun organisme n'acceptera de certifier un reseau modbus qui ne respecte pas cette regla de base mais rien ne vous empeche de vous bricoler votre petit reseau a vous chez vous et pour vous mais cretainement pas dans l'industrie.

de plus lorsque que nos cartes sont certifiées elles doivent aussi etre soumise au des tests CEM, un reseau modbus 485 dont les impedances seraient bricolées ne resistera pas bien longtemps.

je rappelle aussi que bien que le modbus soit basé sur un tranfert 8 bits, la station receptrice doit regrouper certains champs pour obtenir des MOTS DE 16 bits .
comme par exemple le CRC en fin de tramme.

Pour en revenir au probleme PRINCIPAL de l'auteur du premier message :

je te conseillerai ceci :

pour la couche physique, si ton reseau fonctionne sur une courte distance choisis du 422.
si il est long passe sur du 485.
Si tu a du temps devant toi, achette toi un livre sur le bus can et forme toi sur le can-open autrement, definis toi meme ton propre protocole de communication en te basnt sur ce qui est fait en modbus.
Par rapport a du modbus le probleme principal est la detection de fin de transmition par la mise en free du bus.
si vous decidez de vous inspirer du modbus, je vous suggere d'eliminer cette spec dans le cadre de votre propre protocole mais surtout gardez le calcul de CRC.

Encore une fois vous mélangez tout... Vous amalgamez MODBUS et RS485 c'est une erreur.
MODBUS préconise un répéteur pour plus de 32 mais ce n'est pas obligatoire. Et tout le chapitre sur l'implémentation de MODBUS avec une couche physique RS485 ne fait que citer les recommandations de la norme RS485.
En aucun cas j'ai dit qu'il fallait "bidouiller" les impédances RS485. Il faut toujours respecter les caractéristiques du bus. Je dis simplement que ça dépend des caractéristiques de chaque station. Le 32 a été pris pour couvrir le cas le plus défavorable de stations qui seraient toutes à l'extrême de la norme RS485. Dans la réalité c'est très différent.
La remarque sur le 422 n'est pas cohérente. Le RS422 a les mêmes caractéristiques physiques que le RS485, mais il est utilisable en full duplex, ce qui est inutile dans le cas d'un protocole half duplex comme le MODBUS. Le seul avantage est que l'on n'a pas besoin de retournement TX/RX. Ce qui est assez facile à gérer dans un micro-contrôleur, contrairement à un appareil de "plus haut niveau" où l'on préfère utiliser un convertisseur à détection automatique...

PROMAINPour le modbus je ne vois pas trop l'utilité pour mais condition de travail...Cela est surtout se compliqué la vie, alors quand on peut faire simple ! Pour le CAN j'ai les normes ISO les docs etc.

Si le MODBUS est compliqué alors le CAN est super-compliqué. Le vieux MODBUS est basé sur une interface série standard, le CAN non. Le CAN est plus performant mais sa mise en oeuvre nécessite du hardware adéquat et une gestion d'arbitration de bus. Pratiquement tous les micro-contrôleurs d'une certaine taille ont au moins un port série, un port CAN est beaucoup plus rare...
Au départ, je préconisais MODBUS dans un simple souci de facilité de mise en oeuvre, jamais je n'aurais pensé que quelqu'un le trouve compliqué!

Mais pour le Modbus il faut des adaptateurs? Car si oui cela prend de la place, j'ai déjà choisi les microcontrôleurs (nxp LPC1769 ou microchip PIC32) passer par un simple RS485 est pas la méthode la plus simple?
Pour la vitesse je ne suis pas trop restreins si possible >250KB/s pour les 100 microcontrôleurs voila!
Et merci encore pour tout les conseils et informations.

Bonjour,

Tu n'as pas répondu à la question... Je demandais la quantité de données à transférer et non la vitesse du média souhaitée (qui n'a rien à voir avec la quantité max de données tranférables)

Exemple :
- tu as 100 µC
- chaque µC doit envoyer 10 octet toutes les 10ms

Débit = 100µC * 10 octets / 10ms = 100ko/s

=> dans ce cas, certaines solutions sont inadaptées, comme celles basées sur du CAN car le CAN, même si la vitesse du bus maximum est de 1 Mb/s (mb = mégabit, à ne pas confondre avec mB = mégaByte), offre un débit net max théorique d'env. 70-75ko/s...

Donc je réitère ma question : quelle est la quantité de donnée à transférer?

Je vois très bien ce que tu veux dire... une architecture maître / esclave... On avance...

Mais serait-ce trop demander que d'avoir des chiffres? Je ne suis toujours pas en mesure de t'aider efficacement, n'ayant pas encore toutes les données!!!

Pour les micros que je propose j'ai la board de Philips avec le LPC1769 le nom de la board est LPCXpresso et coute seulement 20euro, bien sur avec plain de documentation, Library et exemple sur les moyens de communication.
Pour les chiffres... Je me demande pourquoi cette question, j'ais pas de restriction de communication de donnée ni de vitesse (moi qui choisi). La seule restriction est de pouvoir piloter 100 microcontrôleur en broadcaste et séparément. Donc que se soi le nombre de Octet par trame ou la vitesse, je la déciderai en fonction du protocole de communication choisie.
Sachant que je parlerais aux microcontrôleurs les un après les autres je me fiche de la vitesse et du nombre de octet par trame car cela n’est pas la problématique.
Les mesures le bus choisi devrait faire 15 à 20m max (plutôt court) moins de 5cm de distance entre le microcontrôleur et le bus. Vitesse >250KB/s
« Exemple :
- tu as 100 µC
- chaque µC doit envoyer 10 octet toutes les 10ms

Débit = 100µC * 10 octets / 10ms = 100ko/s »
Exemple hors sujet car le PC choisi de passer d’un microcontrôleur a l’autre et non se fixé a une base de temps comme dans l’exemple car chaque microcontrôleur métra plus ou moins de temps suivant le système qu’il pilote.
Mais si on doit faire un rapprochement je dirai environ 50Ko/s est déjà bien.
J’espère vous avoir donner le plus de renseignements possible et que sa colle a votre attente.
Merci encore de participé activement avec moi a mon projet.

Oui a loblick mais 1KO/s est la pire des situations et de plus dans mon projets la vitesse est pas un atout majeur car je ne pilote pas des moteur etc... Plus oui des 'températures"

Si on a du can ou RS485 les bus seront chainés et si on a du ethernet se sera en étoile.. Pour les KB/s dans mon système cela a pas d'importance il faut pas que je dépasse 3 a 4 heure pour mais test mais j’espère en être loin, sans trop de difficulté et quelque soi le moyen de communication. Dans les meilleures conditions possible le chois du bus en fonction de la vitesse a plus de sans tu ne crois pas? J’ai besoin d'idée pour me décidé puis j'optimiserais le système en fonction.

@ Fabrice : Je partage ton avis mais PROMAIN n'est pas obligé d'expliquer le but de son réseau...

On s'en fout qu'il commande des moteurs, lise des températures ou même centralise le nombre de cacahouètes qu'une armée d'éléphants roses a mangées dans la dernière heure (chaque éléphant rose étant associé à un µC, cela va de soi)

@ PROMAIN : il faut que tu nous donnes des données concrètes :
- le nombre de données qui doivent transiter par le réseau par unité de temps
- la position relative des nœuds (distance et géométrie)
- coût souhaité

Si tes nœuds sont tous à la queuleuleue, un réseau en étoile sera peu adapté économiquement, car câblage plus chère qu'un réseau chaîné.
A l'inverse, si les nœuds sont très dispersés dans l'espace, un réseau en étoile sera très adapté!!!

Fabrice, tout comme moi, a des idées et de l'expérience, mais manque de matière première!!!

sans les info demandées je ne peut te conseiller.
bon courage

Bonjour a tous (oui cela fais un petit moment),

Je reviens ver vous car le projet a avancé! On compte utiliser une connexion Ethernet et modifier le protocole TCP/IP pour plus avoir à utiliser de switch. Si il y en a qui on des informations sur la norme de câblage ethernet comme nombre d'esclave max sur une ligne, tout les esclaves connecté ensembles en ligne et le maitre en croisé, résistance de bous de ligne,... Je suis preneur
S’il y a des idées sur le changement de protocole ou petite astuce pour le détourner je suis aussi preneur !

En tout cas merci encore pour toute l’aide que vous m’avez déjà apporté !

C'était faisable, dans le temps, avec la liaison en câble coaxial 50 ohms , gros ou fin. ...... Nostalgie !

L'éthernet 10, 100 et 1000Base-T utilisant des paires torsadées est toujours en point à point. Les specs se trouvent facilement. Je pense qu'il faudrait d'abord approfondir les bases et étudier l'existant. Là, ça part un peu dans tous les sens.