Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - Pierre59

Pages: 1 ... 17 18 [19] 20 21 ... 23
271
Composants / M5stack
« le: août 04, 2018, 10:16:58 am »
Bonjour

Un ESP32 joliment emballé (M5stack), compatible Arduino, qui pourrait supporter facilement un gestionnaire de réseau et autres.

On doit même pouvoir trouver des versions avec le CAN.

Amicalement

Pierre

272
Présentez vous ! / Re : Hello world...
« le: juillet 22, 2018, 09:29:13 am »
Bonjour

Je me pose quelques questions sur ton schéma :

- je ne vois pas très bien de quoi il s'agit ni l'utilité, mais je dois être un peu obtus, est ce deux voies ou deux rails, sur quelles parties sont branchés les détecteurs de présence

- par principe je n'aime pas beaucoup les relais bistables, au démarrage ou après incident on ne sait plus trop dans quels états ils sont et cela ne marche plus. J'ai un ami qui on installé un BAL 3 feux avec des relais bistables selon un schéma paru dans LocoRevue, en cas d'incident il doit tout remettre en état à la main.

- je pense que l'Arduino peut très bien remplacer le (ou les) relais bistable(s) avec une variable booléenne, qui permet d'inhiber les détecteurs voulus, il faut un peut plus de programmation

Amicalement

Pierre


273
Débuter / Re : Tableau d'objet
« le: juillet 16, 2018, 01:55:19 pm »

Bonjour

Faut pas trop se polariser sur les pointeurs, certes c'est à la base de pas mal de choses en C et C++ (par exemple les tableaux, quand on écrit t[j] le compilateur voir cela comme *(t+j)  donc des pointeurs), mais bien qu'ayant enseigné le C et le C++ pendant de nombreuses années, j'utilise au minimum les pointeurs pour des problèmes de lisibilité des programmes.

L'utilisation de pointeurs sur les objets, c'est plutôt simple :

- pour la déclaration on met une étoile derrière le type, par exemple Led devient Led* (Led c'est un objet, Led* c'est un pointeur sur un objet)

- pour l'utilisation des objets au lieu de mettre objet.variable ou objet.fonction() on met objet->variable ou objet->fonction(), c'est à peu près tout (et on peut quasiment oublier les pointeurs).

Pierre

274
Débuter / Re : Tableau d'objet
« le: juillet 15, 2018, 10:09:14 am »
Bonjour

Le programme précédent avec 4 leds fonctionne très bien tel quel, mais si on veut le faire évoluer les choses vont se compliquer. Voici deux exemples entre autres qui vont poser problème :

Premier cas

Supposons que je veuille faire quelques traitements sur une led, par exemple la deuxième, comme on le recommande je vais utiliser une variable intermédiaire pour économiser des indiçages superflus, donc écrire quelque chose comme cela :

Led led=ledTab[1];

On a fait une copie sans trop s'en rendre compte, c'est "foutu" les leds du tableau ne seront pas modifiées si on modifie la copie.

Deuxième cas

Le programme précédent ayant l'air de fonctionner (et il fonctionne), en tant que "débutant" je m'enhardi en essayant de faire de l'héritage, de façon classique et comme dans les articles sur les objets de Locoduino, j'essaye de faire une LedBicouleur héritant de Led. Cela donne quelque chose comme cela :

class Led {
  protected: int mPin;
  public: Led(int inPin) : mPin(inPin) {}
  public: void display() { printf("%d ",mPin); }
};

class LedBicouleur : public Led {
  private: int mPin2; // deuxieme pin
  public: LedBicouleur(int inPin,int inPin2) : Led(inPin),mPin2(inPin2) {}
  public: void display() { printf("%d-%d ",mPin,mPin2);  }
};

Led ledTab[] = {
  Led(10),
  LedBicouleur(8,9),
  Led(3),
  Led(2)
};

int main(int argc, char **argv) {
  for (int i = 0; i < 4; i++) {
    ledTab[i].display();
   }
}

Comme je tiens à pouvoir facilement exécuter les programmes, c'est écrit en C++ standard (pas spécialement pour l'Arduino), donc il me faut adapter les entrées/sorties et avoir une fonction main à la place du setup(), en plus j'ai changé les uint8_t en int (pour la lisibilité). J'ai du passer aussi la variable mPin de Led de private à protected (pour l'héritage).

La classe LedBicouleur hérite de la classe Led, elle rajoute une variable pour la deuxième pin, un constructeur comme il faut et une nouvelle méthode display() pour afficher les deux pins.

Dans le tableau de leds j'ai changé une Led en LedBicouleur. On exécute, cela donne :

10 8 3 2

Grosse déception, les deux pins de la LedBicouleur ne sont pas affichées  :(

En tant qu'informaticien le tableau de leds me pose un problème une LedBicouleur prend plus de place qu'une Led (un entier de plus), le compilateur n'a que deux possibilités, soit il tronque la LedBicouleur à la taille de Led, soit il alloue de la place pour 4 LedBicouleur. Après vérifications (sizeof) il me semble que le compilateur tronque.

Bilan

La BONNE solution pour éviter ces problèmes (et d'autres) c'est d'utiliser systématiquement des pointeurs sur les objets quand on veut les manipuler. Voila ce que cela donne :

class Led {
  protected: int mPin; float x;
  public: Led(int inPin) : mPin(inPin) {}
  public: virtual void display() { printf("%d ",mPin); }
};

class LedBicouleur : public Led {
  private: int mPin2; double x,y,z; // deuxieme pin
  public: LedBicouleur(int inPin,int inPin2) : Led(inPin),mPin2(inPin2) {}
  public: virtual void display() { printf("%d-%d ",mPin,mPin2);  }
};

Led* ledTab[] = {
  new Led(10),
  new LedBicouleur(8,9),
  new Led(3),
  new Led(2)
};

int main(int argc, char **argv) {
  for (int i = 0; i < 4; i++) {
    ledTab[i]->display();
   }
}

Cela affiche :

10 8-9 3 2

Les deux objets n'ont pas été modifiés (à part l'ajout de "virtual" à la méthode display() (nécessaires pour le polymorphisme)
Le tableau de Leds à été transformé en tableau de pointeurs de Leds, et le programme de test (main()) à été modifié en conséquence.

Amicalement

Pierre

275
Débuter / Re : Tableau d'objet
« le: juillet 10, 2018, 05:56:46 pm »
Bonjour

Il me semble que le constructeur pas défaut n'est pas ajouté par le compilateur si un autre constructeur est fourni. Chaque constructeur fourni doit alors initialiser les variables.

Pierre

276
Débuter / Re : Tableau d'objet
« le: juillet 10, 2018, 04:55:00 pm »
Désolé,mes messages se sont un peu télescopés avec celui de Jean-Luc.

Pierre

277
Débuter / Re : Tableau d'objet
« le: juillet 10, 2018, 04:52:30 pm »
Bonjour

Voila la version avec des pointeurs de leds :

#include <stdio.h>
#include <iostream>

class Led {
public:
int n;
Led(int x) { n=x; }
};

Led *l1=new Led(1),*l2=new Led(2),*l3=new Led(3);
Led* ls[]={l1,l2,l3};

int main(int argc, char **argv) { int i;
for (i=0; i<3; i++) {
printf("%d ",ls[i]->n); //std::cout<<ls[i]->n<<" ";
}
printf("\n"); //std::cout<<<<l2->n"\n";
l2->n=0;
printf("%d\n",l2->n); //std::cout<<"\n";
for (i=0; i<3; i++) {
printf("%d ",ls[i]->n); //std::cout<<ls[i]->n<<" ";
}
printf("\n"); //std::cout<<"\n";
return 0;
}

et le résultat :

1 2 3
0
1 0 3

Le numéro de la led2 à bien été modifié aussi dans le tableau de leds.

Pierre

278
Débuter / Re : Tableau d'objet
« le: juillet 10, 2018, 04:44:02 pm »
Bonjour

Il faut se méfier des manipulations avec des objets, le programme suivant est une adaptation du programme, présenté ci-dessus, manipulant des leds :

#include <stdio.h>
#include <iostream>

class Led {
public:
int n;
Led(int x) { n=x; }
};

Led l1(1),l2(2),l3(3);
Led ls[]={l1,l2,l3};

int main(int argc, char **argv) { int i;
for (i=0; i<3; i++) {
printf("%d ",ls[i].n); //std::cout<<ls[i].n<<" ";
}
printf("\n"); //std::cout<<<<l2.n"\n";
l2.n=0;
printf("%d\n",l2.n); //std::cout<<"\n";
for (i=0; i<3; i++) {
printf("%d ",ls[i].n); //std::cout<<ls[i].n<<" ";
}
printf("\n"); //std::cout<<"\n";
return 0;
}

On a une classe Led avec juste une variable entière qui est un numéro de led.
On déclare 3 leds l1,l2,l3 puis un tableau de 3 leds ls.

Dans le main :
- on affiche le tableau de leds avec une boucle
- on modifie le numéro de la led2 en le mettant à 0 et on l'affiche (pour vérification)
- on réaffiche le tableau de leds

Voila le résultat :

1 2 3
0
1 2 3

Bizarre le tableau n'a pas changé (notamment la led2)  :(

C'est normal quand le tableau est créé une copie des leds est faite, donc si on modifie la led2 sa copie elle n'est pas modifiée.
C'est très pernicieux et cela peut créer des bugs difficiles à trouver.

Pour éviter ces problèmes il vaut mieux utiliser des pointeurs sur les objets. C'est d'ailleurs la bonne façon de faire, pour profiter de l'héritage et du polymorphisme.

Amicalement

Pierre


279
Bonjour

Dans la réalité les circuits de voie détectent une variation de courant (suite à un court-circuit provoqué par les roues+essieux métalliques
C'est pas malheureusement pas possible sur nos réseaux en deux rails, il faut donc avoir recours à grande variété de circuits électrique ou électroniques.

Le gestionnaire doit travailler différemment avec les occupations et les libérations. L’occupation, en tête de train est la plus importante. Elle détermine les signaux et le suivi des trains en fonction du sens de circulation. Si un train est en pousse, il faut évidemment que le premier wagon ou voiture soit « vu » par le détecteur.
Voila les actions que fait le gestionnaire lors de l'occupation d'une zone  :
- aubiner les signaux 
- mettre à jour le suivi des trains, avec affichage éventuel sur TCO, mise à jour du cabsignal et commutation des sources en analogique
- affichage de l'état de la zone sur le TCO

La libération sert seulement à confirmer qu’il n’y a plus de convoi sur une zone (à mon avis), notamment pour protéger les convois suivant en cas de perte de wagon.
Voila les actions que fait le gestionnaire lors de l'occupation d'une zone  :
- destruction d'iitinéraires, en transit rigide la libération de la dernière zone détruit l'itinéraire
- mettre à jour le suivi des trains, avec affichage éventuel sur TCO et commutation des sources en analogique   
- affichage de l'état de la zone sur le TCO

Pour la "perte de wagons" voir le paragraphe suivant.

Une libération de la zone « n » qui n’arrive pas (par exemple quand le convoi occupe la zone n+2) est une anomalie, à condition que la longueur du convoi soit toujours inférieure à la longueur des zones (dans les zones d’aiguilles, ça peut être n+3 ou plus évidemment).
Je pense que l'on parle ici des ruptures d'attelage. Une solution simple est de mettre un compteur de zones pour chaque train avec une valeur maximum qui permet de détecter l'anomalie. Comme les zones d'aiguilles sont en général beaucoup plus courtes que les autres on pourrait gérer le compteur en tenant compte de la "pseudo longueur" des zones.

Une solution plus sophistiquée et de gérer une liste des zones pour chaque train, quand une zone se libère on vérifie que cette zone est bien la dernière de la liste. Mais on peut aussi maintenir artificiellement l'occupation de la zone "leurrant" ainsi le gestionnaire, permettant de pouvoir faire circuler des trains dont seuls le premier et le dernier véhicule sont détectés (pas d'essieux graphités pour les véhicules intermédiaires) sans que le gestionnaire ne perde le suivit des trains.

Mais cette solution a des limites, si on veut faire des manoeuvres sur le réseau, par exemple un dételage de locomotive, c'est équivalent à une rupture d'attelages mais voulue! Il faut alors utiliser des itinéraires en mode manoeuvre pour palier ce problème.

Mais la meilleure solution reste le graphitage de tous les essieux des véhicules.

Le plus important est comment est fait le traitement des occupations et libérations par le gestionnaire, qui doit être indépendant de la technique de détection.
Tout à fait et contrairement à Denis je pense que cette discussion a sa place ici car la façon dont on détecte les occupation/libérations dépend aussi de que l'on en fait avec (cela peut aller d'un gestionnaire à une simple manoeuvre de passage à niveau).

Pierre

280
Les schémas de détection des trains par consommation de courant sont assez anciens anciens et datent pour la plupart d'avant l'Arduino. Avec l'Arduino on peut mettre moins de composants électroniques en compensant par plus de logiciel. L'Aduino pouvant facilement faire du filtrage des signaux reçus et de la temporisation à la libération.

J'ai déja proposé un montage qui va dans ce sens et que j'utilise sur mon réseau, voir http://forum.locoduino.org/index.php?topic=329.0 ou l'image ci dessous. Ce montage peut aller jusqu'a une sensibilité de 1mA détectant facilement les essieux graphités.

Quelques remarques sur des discussions connexes du forum qui me semblent importantes :

- pour une sécurité maximum (de la part du gestionnaire) tous les véhicules doivent consommer un peu de courant (moteurs, éclairages, feux de fin de convoi, graphitage des essieux, …)

- si le delais de libération est fait numériquement il peut être précis, permettant d'avoir des temps de parcours de zones tout aussi précis  (normalement l'occupation est immédiate).

Pierre

281
Discussions ouvertes / Re : protection des aiguilles en gare
« le: février 18, 2018, 11:38:40 am »
Bonjour

Concernant les itinéraires, outre la référence donnée par Dominique ( http://www.locoduino.org/spip.php?article172), la discussion sur le forum ("Modélisation logicielle d'un réseau - le système de Jean-Luc") est aussi intéressante  (voir notamment la réponse n° 64 sur la recherche récursive d'itinéraires).

Cordialement

Pierre

282
Les réseaux / Re : Projet de réseau Jean-Claude74
« le: février 09, 2018, 02:18:06 pm »
Bonjour

Personnellement j'utilise sur mon réseau (une bonne trentaine de zones et d'aiguilles) depuis plusieurs années un gestionnaire de réseau entièrement fait maison.

Ce gestionnaire, écrit en Java, permet la circulation de trains en automatique et en manuel (en analogique ou en digital) avec itinéraires et TCO sur l'écran de l'ordinateur, ceci avec une sécurité totale dans la circulation des trains. Des Arduinos assurent la gestion des zones, des aiguilles, des signaux, ...

Ce gestionnaire à été décrit complètement dans une version en C++ (Gestionnaire de réseau en C++) pour Arduino. Cette description étant une bonne base pour aborder tous les problèmes qui se posent dans l'écriture d'un gestionnaire.

Suite à mes articles sur la construction de TCOs en Processing j'ai développé une nouvelle version de mon gestionnaire en Processing qui automatise le plus possible l'écriture du gestionnaire de réseau. Cette version est en cours de publication.

Donc ce que tu veux faire est tout à fait possible et on t'aidera, n'hésite pas à poser des questions..

Cordialement

Pierre








283
Vos projets / Re : TCO en processing
« le: septembre 25, 2017, 04:22:43 pm »
Bonjour

Ce ne sont pas des erreurs, mais des avertissements, qui n'empêchent pas le programme de tourner.

Les erreurs sont sur un fond rouge, les avertissements sur un fond orange.

Cordialement

Pierre

284
Vos projets / Re : Essai manette DCC++ en C++
« le: juillet 12, 2017, 07:02:25 pm »
Bonjour

Juste une précision :

- QT c'est une bibliothèque graphique pour C++

- Processing est fait pour développer du graphique

Mon expérience de C++ et du graphique en Java m'incitent à dire que ce n'est pas si simple que cela dans ces langages. Processing est plus adapté quand on manque d'expérience en graphique. Mais de toute façon le graphique ce n'est pas si simple que cela.

Pierre

285
Bonjour

Voici la forme des trames DCC (concernant l'adresse, la vitesse et la direction) pour les décodeurs multifonctions.

Il y a deux possibilités d'adresses (courte et longue) : 

0AAAAAAA 7 bits d'adresse

11AAAAAA AAAAAAAA 14 bits d'adresse

Et deux possibilités de vitesse (crans) et direction (sens) :

01DcCCCC 4 ou 5 bits (14 ou 28 crans) suivant l'utilisation de "c"

00111111 DCCCCCCC 7 bits (128 crans)

le bit "D" est la direction


Ce qui donne les 4 trames possibles :   

0AAAAAAA 01DcCCCC XXXXXXXX adresse courte 14/28 crans

0AAAAAAA 00111111 DCCCCCCC XXXXXXXX adresse courte 128 crans

11AAAAAA AAAAAAAA 01DcCCCC XXXXXXXX adresse longue 14/28 crans

11AAAAAA AAAAAAAA 00111111 DCCCCCCC XXXXXXXX adresse longue 128 crans

le dernier octet contient une "checksum" (ou-exclusif des octets précédents)

on voit bien les 4 emplacements possibles pour le bit de direction (en gras)

Pierre

Pages: 1 ... 17 18 [19] 20 21 ... 23