Messages

1276

Modélisation, Architectures logicielles et matérielles / Re : Re : Modélisation logicielle d'un réseau

« le: avril 16, 2015, 01:36:22 pm »

C'est la deuxième fois que tu dis "plus ou moins d'aiguillages par canton". J'aimerais que tu précises : tu "prolonges" les rails avec les contacts d'un relais ?
Parce que sinon, il faut bien détecter la présence des trains sur les aiguilles en carte B ?

Non, ce que je veux dire : mes cantons comprennent de 0 à N aiguilles. Comme je veux des cartes génériques pour pouvoir les faire fabriquer en série, elles sont indépendantes de la topologie d'un canton. C'est le logiciel qui fait le lien entre cantons et aiguillages et les manœuvre comme il faut. Par exemple voici ma gare terminus en pièce jointe. Chaque canton est d'une couleur différente :

A mon avis, en DCC, il y a quand même autre chose à gérer au niveau du canton : le sens de déplacement sur le canton.

La loco reçoit de la centrale DCC son sens de déplacement via les rails, indépendamment de la carte canton.
En gros, l'info n'existe plus dans les cartes.

Normalement si

A minima : tout est géré en carte D, en mémorisant les dernières demandes. Pourquoi pas ?

Tout à fait.

Il y a une limite du nombre de cartes par bus CAN ?

La limite est fixée par le transceiver. Le 2551 limite le nombre de nœuds à 112. Le Due a 2 CAN, autant les utiliser.

Les données, par contre, sont touffues et des erreurs peuvent être cachées. Du coup je suis en train de faire un langage pour spécifier la topologie du réseau, affecter les alimentations et les aiguillages, spécifier la longueur des cantons et le graphe de cantons et y accrocher des règles. Un compilateur vérifie la description et génère les structures de données correspondantes. C’est en chantier mais je peux vous en parler plus en détails.

Alors, là, c'est grandiose !!
C'est vrai qu'il "suffisait" de créer un nouveau langage avec un compilateur !!!!!!!
Ben voyons !!
Oui, je veux bien des détails.   

Ça vient

1277

Modélisation, Architectures logicielles et matérielles / Re : Architecture matérielle d'un réseau

« le: avril 16, 2015, 11:36:10 am »

Voici la mienne, en analogique donc :

1278

Modélisation, Architectures logicielles et matérielles / Re : Modélisation logicielle d'un réseau

« le: avril 16, 2015, 09:30:06 am »

Concernant ce qui doit être décentralisé sur les cantons, j’ai choisi de décentraliser la commande de la loco (je suis en analogique) et la détection de présence. La commande des aiguillages est compliquée à décentraliser sur les cantons car on peut avoir plus ou moins d’aiguillages par canton ce qui abouti à un code ou des données spécifiques dans chaque canton et un tas de problème de mantenance dans les mises à jour. Idem pour la signalisation.

Donc :

A) cartes de commande / détection de canton (pour moi une par canton mais il y a beaucoup de fonctions)
B) cartes de commande d’aiguillages
C) cartes de commande de signaux
D) carte de pilotage du réseau
E) carte TCO

Evidemment, en DCC, la carte A peut s’occuper de plusieurs cantons puisqu’elle a juste la détection à faire.

J’utilise 2 bus CAN, 1 pour la traction (cartes A), 1 pour les accessoires (B, C et E)
D doit donc avoir 2 contrôleurs CAN, c’est le cas de l’Arduino DUE.

Les cartes A reçoivent des commandes de D (vitesse de loco, sens de circulation, allumage/extinction des feux, affectation de convoi à un canton). Elle émettent à intervalles réguliers l’état d’occupation en pleine voie et en zone d’arrêt à destination de D. Elle émettent lorsqu’une machine passe d’un canton à l’autre la PWM et la composante intégrale de la loi de commande de manière à synchronise la  commande d’un canton à l’autre.

Les cartes B reçoivent les commandes de D (position des aiguilles) et émettent à destination de D la position effective lue via des fins de course.

Les cartes C reçoivent les commandes de D (signalisation)

La carte D connaît la topologie du réseau.

Elle reçoit de A l’état d’occupation en pleine voie et en zone d’arrêt et de B l’état des aiguillages. Elle reçoit également de E les commandes. Elle envoie à E les information de position des convois et des aiguillages.

La carte D connaît donc l’état global du réseau :
- convois présent, position de chaque convoi ;
- suivi des convois de canton en canton ;
- position des aiguilles.

Elle gère :
- affectation d’un poste de conduite à un convoi ;
- allumage/extinction des feux ;
- anti-collision ;
- positionnement des aiguillages ;
- gestion de la signalisation ;
- mémorisation des caractéristiques de loi de commande de chaque locomotive et envoi de ces caractéristiques aux cantons en fonction du suivi de convois.

Elle exécute :
Les commandes des postes de conduite;
Les commandes du TCO.

Dans les deux cas il y a filtrage : le fait qu’une commande d’un poste de conduite demande à entrer dans un canton occupé par un autre convoi est mis attente. De même le changement de position d’un aiguillage venant du TCO ou d’un poste de conduite alors que cet aiguillage est affecté à un autre convoi est mis en attente ou interdit.

Par la dessus, on peut mettre une circulation automatique en substituant un automate à un poste de conduite.

La carte E gère le TCO : changement de position d’aiguillage, réservation d’un itinéraire, affectation d’un convoi à un poste de conduite. Elle envoie ces ordres à D et reçoit de D le positionnement des convois et les positions des aiguilles.

La logique de fonctionnement n’est pas trop compliquée, il faut juste bien la spécifier et la vérifier.

Les données, par contre, sont touffues et des erreurs peuvent être cachées. Du coup je suis en train de faire un langage pour spécifier la topologie du réseau, affecter les alimentations et les aiguillages, spécifier la longueur des cantons et le graphe de cantons et y accrocher des règles. Un compilateur vérifie la description et génère les structures de données correspondantes. C’est en chantier mais je peux vous en parler plus en détails.

1279

Bibliothèques / Re : Bibliothèque CommandInterpreter

« le: avril 14, 2015, 12:18:33 pm »

Pas mal ta paravirtualisation ;-)

Mais tu ne peux pas allumer une vrai LED :-) Trêve de plaisanterie, je n'opposerais pas les deux solutions. Ta solution permet de développer et débugguer confortablement mais si ton modèle n'est pas conforme à la réalité, tu passes à côté de certaines choses. Ma solution permet juste de doter une application d'une interface pour interagir via la ligne série.

1280

Bibliothèques / Bibliothèque CommandInterpreter

« le: avril 14, 2015, 10:20:05 am »

Bonjour,

Je ne sais pas si vous êtes comme moi mais lors de la mise au point de programmes un peu plus compliqués que le basique, je reflashe pas mal l'Arduino. Par ailleurs, pour configurer une application, valeurs par défaut de variables, configuration en EEPROM, ... c'est assez pénible.

Il m'est donc venu à l'idée d'utiliser une interface ligne de commande qui tournerait sur l'Arduino. Il y en a qui existent mais pas forcément comme je veux. J'ai donc fait la mienne.

L'idée est d'avoir sur l'Arduino une interface en ligne de commande qui gère la communication sur la ligne série, attend des commandes et les exécute. Les commandes sont à coder sous forme de fonction et peuvent avoir des arguments. La bibliothèque gère également un historique de 8 commandes pour ne pas avoir à les retaper et deux commandes internes : hist qui permet d'afficher l'historique des commandes et help qui affiche l'aide. Le tampon d'entrée est de 20 caractères et la saisie au delà de ce tampon est gérée.

Côté logiciel sur le PC/Mac, il faut un logiciel de terminal plus sérieux que celui inclus dans l'IDE Arduino, j'aime beaucoup CoolTerm qui est multiplateforme : http://freeware.the-meiers.org mais, Guillaume va râler, il n'est pas libre. Sinon il y a minicom et un tas d'autres.
Les paramètres de connexion sont la vitesse qui dépend du Serial.begin() de votre appli, 8 bits de données, pas de parité, 1 bit de stop, pas de contrôle de flot. Comme ceci :



Il faut également ne pas avoir d'écho local et prendre en charge le backspace



La bibliothèque est ici : https://git.framasoft.org/Koryphon/CommandInterpreter/repository/archive.zip. Une fois décompressée, on obtient un dossier CommandInterpreter.git. Enlever le .git et placer le dossier dans libraries.

J'ai inclus deux exemples : un interpréteur avec 3 commandes pour lire, écrire et avoir la taille de l'EEPROM, un interpréteur pour changer et afficher l'état de la led 13.

En résumé, il faut :

• Instancier un objet de type CommandInterpreter avec comme argument de constructeur la ligne série utilisée
• Instancier un objet de type Command pour chaque commande avec 3 arguments : le nom de la commande, la fonction à appeler, une chaîne d'aide
• écrire pour chaque commande une fonction à appeler. Ces fonctions prennent 2 arguments : une référence vers un CommandInterpreter (ce qui permet de récupérer la ligne série employée et chaque argument), un byte qui est le nombre d'arguments
• dans setup, ajouter les commandes à l'interpréteur via la méthode addCommand
• dans loop, appeler CommandInterpreter::update() pour que l'interaction avec l'utilisateur se fasse

On a alors un moniteur qui fonctionne en « tâche de fond » pourvu qu'il n'y ait aucun appel à des delay longs dans le programme.

Avec les flèches haut / bas, on peut se balader dans l'historique, une fois une entrée de l'historique sélectionnée elle peut bien entendu être éditée. L'historique ne stocke pas une nouvelle commande si la précédente est identique.

1281

Vos projets / Re : Simulation daylight

« le: avril 14, 2015, 08:37:48 am »

Le comportement n'est pas du tout le même entre alimentation en tension continue et alimentation en PWM

En tension continue, il faut que ça passe le seuil de 3 DEL en série (elles sont montées comme ça) pour que ça éclaire. Ça doit effectivement faire dans les 8V.

En PWM, le seuil est passé au premier cran et tu as donc un éclairage 1/256e du temps

Effectivement l'Arduino Due est sympa de ce point de vue

1282

Vos projets / Re : Simulation daylight

« le: avril 14, 2015, 07:41:12 am »

Bonjour,

J'avais noté cette manque de finesse dans la gradation pour les faibles valeurs de PWM et j'ai reprogrammé le timer 1 pour avoir une PWM 16 bits au lieu de 8 bits sur les 2 broches 9 et 10. On se retrouve avec 65536 pas au lieu de 256, ce qui résout le problème.

Mais je n'ai que 2 rubans.

Ceci dit en utilisant un Mega, il y a un paquet de timers 16 bits et donc un paquet de PWM 16 bits.

Il y a un exemple de code ici : http://www.ofrecordings.com/2014/03/16/how-to-set-up-16-bit-pwm-with-an-arduino-uno-atmega328/

1283

Vos projets / Re : Simulation daylight

« le: avril 12, 2015, 05:42:23 pm »

Oui, Patrick a travaillé là dessus :

http://jurasecondairen.blogspot.fr/2012/11/jour-et-nuit.html

Même si je pense que le matin, c'est blanc pur à l'aube avant que le soleil se lève puis plus chaud au levé du soleil.

À moduler pour simuler un temps nuageux avec des couleurs plus froides

Et puis ses propres goûts

1284

Présentez vous ! / Re : Bonjour de Class66240

« le: avril 11, 2015, 08:25:05 am »

Bonjour et bienvenue sur le forum.

N'hésite pas à nous exposer en détails ton projet 

1285

Infos et bonnes affaires / Re : Du WiFi à 6,95$ chez Sparkfun

« le: avril 10, 2015, 09:57:55 am »

Pas sûr. Le SoC est fait par Espressif Systems (https://espressif.com https://espressif.com/en/products/esp8266/) et le firmware également (http://bbs.espressif.com). Sparkfun n'est qu'une des multiples sociétés qui produisent des breakout boards. Je ne vois pas Sparkfun améliorer le firmware de son côté. Si tu vas sur le GitHub de Sparkfun (https://github.com/sparkfun) tu y trouveras surtout les fichiers de production de leurs cartes mais très peu de soft contrairement à Adafruit (https://github.com/adafruit) qui a produit quantité de bibliothèques.

1286

Infos et bonnes affaires / Re : Du WiFi à 6,95$ chez Sparkfun

« le: avril 08, 2015, 02:40:22 pm »

J'en ai un mais je n'ai pas encore eu le temps de l'essayer C'est au programme. De mémoire il peut être utilisé comme point d'accès. La connexion est via la ligne série et utilise des commandes AT pour la configuration. Des infos ici :

http://www.electrodragon.com/w/Wi07c

Il y a un essai dans la revue OpenSilicium de janvier/février. Voici la conclusion :

Que penser finalement de ce module très économique ? Il apparaît clairement qu'il n'est pas question de d'intégrer celui-ci dans l'état dans un quelconque produit final et la question de savoir s'il ou non l'ajouter à un projet existant dépendra complètement de l'aspect critique de la réalisation. Le firmware est bien entendu la cause de tous les problèmes avec un manque de documentation évident, des comportements et messages incohérents, des traductions approximatives, etc
...

En résumé SoC ok mais firmware pourri.

Le bluetooth c'est pas mal non plus

1287

Bibliothèques / Re : Bibliothèque SlowMotionServo

« le: mars 27, 2015, 10:49:11 am »

J'ai vérifié hier soir que l'on pouvait calculer des fonctions sinus en flottant pour 8 servos sans que le mouvement en soit affecté. J'avais un peu peur qu'au niveau calcul ça ne passe pas mais en fait c'est bon

Une fois les valeurs min et max définies via setMin, setMax ou setMinMax pour définir les deux valeurs extrêmes d'un coup. Ces valeurs sont en micro-secondes. La position à atteindre via goTo s'exprime avec un nombre flottant de 0.0 à 1.0

La vitesse (setSpeed, setMinToMaxSpeed et setMaxToMinSpeed) s'exprime aussi avec un nombre flottant. Par défaut la vitesse est de 1.0 (hier c'était 0.0001 mais maintenant je divise par 10000 ce qui est passé à setSpeed, c'est plus sympa d'être autour de 1). On peut descendre en dessous.

1288

Bibliothèques / Bibliothèque SlowMotionServo

« le: mars 26, 2015, 06:16:57 pm »

Bonjour à tous,

En me replongeant dans le travail que j'avais effectué pour piloter 8 servo-moteurs, voir la série d'articles sur mon blog, j'ai voulu remettre les choses à plat.

En effet, quand on pilote un servo-moteur pour bouger les aiguilles d'un aiguillage, on se moque un peu de la manière dont le mouvement est effectué, du moment qu'il est lent. J'avais donc fait un mouvement linéaire sans phase d'accélération ou de décélération. Donc le plus basique possible.

Voulant maintenant manœuvrer des portes de remise, je voulais un mouvement réglable en vitesse, mais aussi que la position angulaire suive une trajectoire qui ne soit pas forcément une droite. Je veux par exemple que la porte vienne en butée puis rebondisse et s'arrête progressivement.

je me suis demandé si il n'existait pas une bibliothèque pour effectuer des mouvements lents sur les servo-moteurs et je n'ai absolument rien trouvé.

J'en ai donc fait une.

On peut donc pour chaque servo :

• définir les positions minimum et maximum ;
• régler la vitesse indépendamment dans chaque sens de déplacement ;
• définir une trajectoire quelconque sous la forme d'une courbe mathématique ;

3 trajectoires sont disponibles toutes faites :
- linéaire
- accélération puis décélération en sinus
- accélération en sinus, rebond sur la butée et décélération en 1/temps

Pour l'instant j'ai un prototype qui tourne mais il faut que je finisse de monter une remise pour montrer le mouvement des portes Il faut également que je vérifie que l'Arduino arrive à calculer des fonctions complexes pour 8 servos sans que le mouvement en pâtisse.

Je me servirai de cette bibliothèque pour mettre à jour le logiciel pour piloter 8 servo-moteurs.

Elle disponible via le gestionnaire de bibliothèques de l’IDE

1289

Présentez vous ! / Re : Présentation bern 69

« le: mars 26, 2015, 05:36:17 pm »

Bonjour et bienvenue Bernard

Je pratique également l'échelle N et l'analogique. Mais je ne suis pas encore à la retraite

1290

Vos projets / Re : Commande d'itinéraires par arduino

« le: mars 15, 2015, 10:21:20 am »

Bonjour Denis

Utiliser des différences de tension pour communiquer des consignes aux Arduino me semble extrêmement bizarre. Ce genre de système est prévu pour de l'électronique classique. Avec les Arduino tu as d'autres moyen de communication autrement plus souples et plus simples.