Carte de commande de servo-moteurs

Bonjour,

La suite des opérations concernant les actionneurs d'aiguille au moyen de servo-moteurs.
(le début est ici: https://le-forum-du-n.1fr1.net/t18147-utilisation-des-servo-moteurs)

Cette carte double-face est une conseption personnelle que je vais faire fabriquer cet été. Elle permet de commander 6 servo-moteurs et est connectée au système via une bus CAN. Elle comporte un PIC 18F46K80, un transceiver CAN, la quincaillerie (transistors, résistances, capas, leds, connecteurs) qui va autour.

11 exemplaires seront installés sur le réseau : 7 pour les aiguilles, 4 pour les signaux. Elle met en œuvre :
- une fonction d'allumage/extinction des servos individuellement
- la commande en elle-même,
- les interrupteurs de fin de course.

Côté composants :


Côté soudures :


Je viens de publier un article complet : http://modelleisenbahn.triskell.org/spip.php?article36

Je suis en train de déboguer le logiciel

Bonsoir Jlb,

Je suis très impressionné par tous ces développements, c'est du très beau travail.

Je ne connais pas les PICs pratiquant l'AVR. Est-ce que le PIC 18F46K80 permet de générer la PWM à l'aide des timers de manière indépendante ?

Bon dimanche.

Bonsoir SavignyExpress

Merci pour tes compliments

En fait le programme la gère via des sorties numériques. À partir d'une interruption  toutes les 3,33 ms (environ), je multiplexe la gestion des servos (un par slot de 3,33 ms et 6 slots). La sortie correspondante est mise à 1, un second timer est armé et génère une interruption au bout du temps correspondant à la durée à l'état haut de la PWM du servo. La routine d'interruption remet la sortie à 0.

Bonsoir

Le logiciel commence à fonctionner. J'ai 7 vitesses possibles dans chaque sens (indépendamment car j'ai remarqué que pour les signaux mécaniques la vitesse de fonctionnement n'est pas la même selon le sens du mouvement). Pour bien enfoncer les fin de course, le logiciel continue le mouvement au delà de la détection. Le délai après détection du fin de course s'adapte en fonction de la vitesse pour tenir compte de l'inertie du moteur. Une fois la position atteinte, la PWM est coupée pour que le moteur ne grogne pas (l'élasticité des fins de course fait que l'électronique du servo laisse le moteur en route pour contrer)

Il me reste à généraliser pour les 6 servos (l'architecture est déjà en place mais il faut que je câble encore des trucs sur la breadboard) et à ajouter la messagerie (les consignes sont actuellement envoyées en écrivant directement en mémoire via le bus CAN) et la partie sécuritaire pour détecter les pannes de servos et de fins de course.

Une vidéo :

Bonsoir,

Je touche au but.

Je viens de terminer le logiciel à 90%. La messagerie CAN est en place, la généralisation à 6 servos est faite et testée à 85% (je n'ai que 5 servos disponibles, il faut que j'en monte un demain pour terminer les tests). Pour l'instant je pilote la carte directement au clavier de mon Mac (je vais d'ailleurs écrire un script de test complet pour tester les cartes quand je les monterai).

Au repos (servos allumés, PWM éteinte) la carte consomme environ 80mA (90mA avec un servo de plus).
Si tous les servos sont en mouvement ça monte à 400mA environ x 11 cartes = 4,4A
Je me pose la question de ne permettre que 2 ou 3 mouvements simultanés pour limiter la consommation.

Une petite vidéo où les 5 servos tournent simultanément dans un sens puis dans l'autre :

Bonjour,

Le logiciel est presque fini. Il ne me reste plus qu'à lire l'adresse CAN sur les DIP switches.
La séquence d'allumage est opérationnelle et j'ai implémenté ce dont je parlais hier : limiter le nombre de servos en mouvement simultanément pour limiter la consommation, c'est un paramètre réglable. Une petite vidéo :

Bonjour,

J'ai publié sur mon blog un descriptif du logiciel pour la partie commande des servos, la partie messagerie CAN va suivre. Dès que j'ai nettoyé le code et vérifié son fonctionnement sur la carte de production, je le mets à disposition ainsi que les gerbers de la carte.

C'est par ici : http://modelleisenbahn.triskell.org/spip.php?article40

En résumé, le logiciel multiplexe dans le temps les PWM des servos comme ceci :



et chaque servo est géré au moyen d'une machine d'états (automate + code exécuté lors du franchissement des transitions) :

Hello Jlb,

Je suis aussi un adepte des machines d'états pour la conception de systèmes embarqués. Celle que tu présentes pour la commande de servos est bien documentée. Comment l'as-tu testée ?

Un tout grand bravo.

Merci SavignyExpress

J'avoue ne pas avoir vérifié cette machine d'états exhaustivement car les entrées sont en nombre réduit et la machine reste simple. J'ai testé son fonctionnement in-situ en envoyant via le bus CAN des commandes permettant le franchissement de toutes les transitions.

Pour des choses plus compliquées, j'utilise Uppaal (normalement c'est pour des automates temporisés mais rien n'empêche de l'utiliser sans temps), http://www.uppaal.org ou Spin, http://spinroot.com/

Pour des systèmes simples (ie 1 seul automate), c'est un peu la bombe atomique pour écraser une mouche mais c'est très efficace dès qu'on a plusieurs automates concurrents qui se synchronisent (le cas où on ne comprend plus ce qui se passe )

Bonjour,

Suite et fin de la description de cette carte sur mon blog : http://modelleisenbahn.triskell.org/spip.php?article41

avec la messagerie CAN et les commandes comprises par le logiciel de la carte.

Voici un résumé des commandes :

jlb a écrit:

Bonsoir,

Je touche au but.

Je viens de terminer le logiciel à 90%.........

Une des grandes lois de l'informatique:

Il faut 10% du temps pour écrire 90% du code.

Et 90% du temps pour écrire le reste et le débugger !  

Très sympa.
Pourquoi couper les fils des servos ? L'ordre des fils sur la carte à l'air bon, mettre de pin faciliterait grandement le remplacement d'un servo grillé !
Le montage est chouette en tout cas.
Ton CAN, il permet de communiquer avec quoi ?

CleoN a écrit:

jlb a écrit:

Bonsoir,

Je touche au but.

Je viens de terminer le logiciel à 90%.........

Une des grandes lois de l'informatique:

Il faut 10% du temps pour écrire 90% du code.

Et 90% du temps pour écrire le reste et le débugger !  

Et 45% du temps pour écrire le reste et le débugger, et 45% à la machine à café pour "se calmer les nerfs", "reprendre de la niak" et, si la machine est publique, comparer ses malheurs à ceux des autres !

Bravo,
et bon courage pour les 10 % restant.

Wapata a écrit:

Très sympa.

Merci

Citation :

Pourquoi couper les fils des servos ? L'ordre des fils sur la carte à l'air bon, mettre de pin faciliterait grandement le remplacement d'un servo grillé !

Oui ça permettrait de le remplacer plus facilement mais je veux limiter la longueur de fil. Les servos n'étant pas piloté en différentiel, il sont sensibles au bruit si le fil est trop long. De plus, il aurait fallu que je bobine le fil ce qui le rend encore plus sensible au bruit. Donc j'ai préféré raccourcir au mini. 3 soudures, c'est pas le bout du monde

Citation :

Ton CAN, il permet de communiquer avec quoi ?

C'est une conception faite avec 2 copains. 3 bus CAN sont utilisés : 1 pour la traction (une alim par canton), 1 pour les accessoires (aiguilles, dételleurs, signalisation, éclairage, etc), 1 pour les postes de conduite (comporte aussi l'alim avec un branchement à chaud).

À l'intersection de ces 3 bus, on a un gestionnaire central : une carte avec un ARM7TDMI à 60MHz. Il y a une description succincte ici : http://modelleisenbahn.triskell.org/spip.php?article11

Ça offres les possibilités du numérique mais avec des locos analogiques. C'est comparable au système de Pegase informatique mais je pense que la partie traction est plus sophistiquée et puis on fait ce que l'on veut.

CleoN a écrit:

Il faut 10% du temps pour écrire 90% du code.

Et 90% du temps pour écrire le reste et le débugger !  

Je compte le debug dans les 90%

Jicébé a écrit:

Bravo,
et bon courage pour les 10 % restant.

Merci Jicébé

Bonjour,

Les cartes sont arrivées ! Ya plus qu'à souder  

Tes cartes ont une bonne tete !

On peux savoir chez qui tu les a fait graver ?

Elles ont été gravées chez Eurocircuits. J'ai mis quelques explications ici : http://modelleisenbahn.triskell.org/spip.php?article42

Elle font 96x55mm. Pour 16 exemplaires (standard pool), ça m'a coûté 150€ environ port compris

Envisages tu de faire une adaptation vers une norme dcc tout public ?
Car matériellement, ton montage est dans les plus économique !

Bonsoir,

Je ne bricole pas dans le DCC, donc non. Il serait sans doute moins économique en DCC car comme il n'existe pas de transceiver DCC intégré, il faudrait le faire en circuits discret, ce qui prendrait plus de place. Par ailleurs, il ne me semble pas qu'un décodeur d'accessoire puisse être maître de bus (mais je peux me tromper, ceci dit je n'ai pas vu d'arbitrage donc à priori seul la centrale est maître de bus). Du coup la détection d'erreur et l'émission périodique de l'état des servos ne serait pas exploitable. Par ailleurs, le bus DCC a un débit pire cas très faible, environ 10kbits d'après ce que j'ai vu. En supposant que le DCC soit multi-maîtres, si 10 cartes comme celles ci rapportent l'état des servos (100 bits de message environ) toutes les 100ms, ça sature le bus.

(je suis pas très fan du DCC, je trouve que le protocole est raté )

Pour des choses pas trop chères, je pense qu'il faut regarder du côté des cartes de Tam Valley : http://www.tamvalleydepot.com/products/quadservodecoder.html
http://www.tamvalleydepot.com/products/octopusservodriver.html

Le dcc est un peut comme le midi. Bridé par sa souche.
Mais si, les décodeurs peuvent communiquer dans les deux sens, c'est relativement récent et permet d'identifier les convois... si on réalise des cantons.
A titre personnel, je pense que le réseau dcc doit être aménagé de la même façon qu'un réseau analogique pour dévoiler sa puissance. Mais ce n'est pas ce qui est enseigné.

J'avais déjà vu Tam Valley. Et leurs produits sont bluffants.

Bonne continuation en tout cas ! Je retourne explorer ton site internet.

Wapata a écrit:

Mais si, les décodeurs peuvent communiquer dans les deux sens, c'est relativement récent et permet d'identifier les convois... si on réalise des cantons.

C'est la centrale qui initie la communication en faisant une requête de lecture ?

Citation :

Bonne continuation en tout cas ! Je retourne explorer ton site internet.

Merci ! il n'y a pas grand chose pour l'instant mais j'enrichis régulièrement

Pour les décodeurs de trains, ils ne renvoient que leur identifiant. Il y a un break dans le signal qui leur permet d'envoyer leur paquet.
Pour le reste (accessoires, boutons, interrupteurs), on doit passer par un bus distinct. Le RS88 ou le ProfiNet et là... Ben heu je sais plus trop, c'est totalement bi-directionnel je pense. Les infos sont envoyées, tous les équipements lisent l'info, et sil il sont intéressés par l'info, il font une action en conséquence.

Ces deux technologies sont là pour pallier aux limitations du DCC en lui même en terme de retours d'infos. Dans l'absolu, absolument rien ne t’empêche de faire de la signalisation, et de la rétro signalisation avec ces bus et piloter tes trains en analogique.
Il existe même des montages pour piloter les trains analogiques en pulsé à partir de l'ordinateur (mais là, je n'ai plus de lien, je parle d'une époque ou le port parallèle était roi).
Et enfin, entre nous, il est possible aussi d'utiliser les décodeurs de trains en statique pour piloter des cantons via l'ordi. Le tout est de savoir si il est plus économique d'équiper les cantons, ou le park de locos (et cela ne gèrera que la vitesse des locos, en pas leurs équipements).

Si tu le souhaite, nous pourrions en parler en MP, pour que nous puissions ne pas perdre le fil de discussion de ta carte de commande.

Pas de soucis pour le fil, je suis au bout . Je présenterai la carte montée mais ensuite ça bascule sur le montage sur le réseau et donc dans le fil idoine.

Citation :

Il existe même des montages pour piloter les trains analogiques en pulsé à partir de l'ordinateur (mais là, je n'ai plus de lien, je parle d'une époque ou le port parallèle était roi).
Et enfin, entre nous, il est possible aussi d'utiliser les décodeurs de trains en statique pour piloter des cantons via l'ordi. Le tout est de savoir si il est plus économique d'équiper les cantons, ou le park de locos (et cela ne gèrera que la vitesse des locos, en pas leurs équipements).

En fait nous avons choisi cette solution avec mes deux copains. Mais nous n'utilisons pas de décodeurs de locos. D'ailleurs, je ne suis pas sûr que ça marche bien étant donné qu'il n'y a aucune raison que que les PWM des décodeurs soit synchro. Par conséquent lorsque la loco passe d'un canton à l'autre et qu'elle prend le courant sur 2 décodeurs, elle va voir une PWM qui est la superpositions des PWM de deux décodeurs. Elle va donc faire un petit bond.

Donc nous avons développé des cartes ad-hoc. Chaque carte pilote 4 cantons. Sur chaque canton on a :
- détection de présence en pleine voie et zone d'arrêt dans les deux sens de circulation (on détecte une résistance de 80kΩ environ
- mesure du courant
- détection de sur-courant
- détection de fusible grillé
- mesure de la vitesse (FCEM)
- alimentation par une PWM à 32kHz
- asservissement PID de vitesse
- synchronisation des PWM
- collaboration du pilotage de cantons adjacents pour la partie intégrale de l'asservissement
- paramétrage des locos (vitesses maxi, delai avant la mesure de vitesse, ...)

Le tout géré par un PIC 26K80 à 64MHz et l'électronique qui va bien.

Pas de PC pour gérer tout ça. On utilise une carte ARM pour le logiciel de gestion.

grosso-modo ça nous coûte 25€ par canton. J'ai 24 cantons sur mon réseau.

Et bien sûr pas de fonction annexe sur les locos.

Au niveau câblage, c'est comparable au numérique, on passe le bus et les alims. Ça offre des fonctions similaires et on sait ce qui tourne dessous

C'est dans des moments comme ça que je regrette d'être nul en math et de ne pas avoir fait électronique à l'école. Tout ceci me laisse sur le bas côté, à reproduire des schémas existants ou à tripatouiller un Arduino.

Avoir son système, que l'on connais sur le bout des doigts, ça vaut tout les montages du monde !

Pour la superposition des signaux pulsés... Il faudrait que je teste, la remarque est intéressante.