Discussion :

[Jay M]

Bonjour à vous 2

J'ai fait des essais dans Processing, ça ne doit pas être pour moi! Je ne suis pas arrivé à "cerner" l'événement d'un clic sur une aiguille tout en déduisant quel est la direction active.

voici quelques modifications à apporter au programme Processing

je vais essayer de les expliquer et je pense qu'ensuite @JP les choses seront plus simples pour vous

dans PERSO_10-2-1
il faut déclarer une variable globale qui va représenter notre port série de discussion avec l'arduino. On met donc au début

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
// LE PORT SERIE
import processing.serial.*;
Serial arduinoSerial;      // The serial port

il faut ensuite trouver le bon port. Généralement un Arduino va toujours se déclarer au même endroit, donc on peut câbler cela en dur dans le setup et donc on ajoute dans le setup()

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
  // List all the available serial ports:
  printArray(Serial.list());
  // Open whatever port is the one you're using - here Serial.list()[1]
  arduinoSerial = new Serial(this, Serial.list()[1], 115200);

la première commande affiche dans la console de processing tous les ports séries détectés. Sur mon mac avec mon Arduino Mega branché ça affiche
[0] "/dev/cu.Bluetooth-Incoming-Port"
[1] "/dev/cu.usbmodem1401"
[2] "/dev/tty.Bluetooth-Incoming-Port"
[3] "/dev/tty.usbmodem1401"

et je sais que mon MEGA est sur "/dev/cu.usbmodem1401" qui est l'entrée N° 1 donc dans le code à la ligne suivante j'écris en dur quelle entrée de la liste choisir, ici la 1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 arduinoSerial = new Serial(this, Serial.list()[1], 115200);

et j'ouvre la connexion à 115200 bauds.

Pour tester ce qu'il se passe, on va charger dans l'arduino un petit programme tout simple qui renvoie sur la ligne série ce qu'il reçoit. une sorte d'echo. Installez donc ceci dans votre Arduino Mega:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
void setup() {
  Serial.begin(115200);
}
 
void loop() {
  int r;
  if ((r = Serial.read()) != -1) { // si on a reçu un octet
    Serial.write((byte) r); // on le renvoie
  }
}

ATTENTION DE NE PAS OUVRIR LA CONSOLE ARDUINO (car sinon le programme processing ne va pas pouvoir s'y connecter).

Voilà avec cela on est paré, notre programme processing sait théoriquement parler à notre Arduino mais ne sait pas encore écouter ce qui vient de l'Arduino. On rajoute donc dans PERSO_10_2_1 à la fin un petit bout de code qui écoute ce qui arrive sur le port série et l'imprime dans la console série de Processing

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
// GESTION DU RETOUR DE L'ARDUINO
 
void serialEvent(Serial aPort) {
  // read what the Arduino sent us back
  while (aPort.available() > 0) print((char) aPort.read());
}

Ensuite bien sûr il faut pouvoir définir ces messages, donc associer à un Pavé un message et l'envoyer si nécessaire.

dans l'onglet Pavé

Pour cela on va modifier la classe Pave dont héritent tous les pavés en rajoutant une variable d'instance de type String et en l'initialisant à vide dans le constructueur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
abstract class Pave {
  Forme[] formes; // les formes
  int couleur=GRIS; // couleur (par defaut) pour le pave
  int taille=1; // taile du pave (1 par defaut)
  ArrayList<Forme> retraits=new ArrayList<Forme>(); // les retraits
  String messageArduino;

  Pave(Forme... fs) { 
    formes=fs;
    messageArduino = "";
  } // constructeur

Par la magie de l'héritage, tous les pavés sont maintenant porteur d'un message. Il faut pouvoir définir ce message donc on rajoute une méthode à la classe Pavé pour cela:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
  // message à émettre 
  void definirMessage(String m)
  {
    messageArduino = m;
  }

et il faut bien sûr avoir une méthode généraliste d'émission de message. Donc on rajoute aussi une méthode d'envoi de ce message

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
  void emettreMessage()
  {
    if (messageArduino != "") {
      arduinoSerial.write(messageArduino);
      arduinoSerial.write('\n'); // on envoie un marqueur de fin de commande
    }
  }

(Ici on ne va pas faire très propre et on va dire que la classe Pavé dépend d'une variable globale existante arduinoSerial qui représente le port série. Dans une bonne approche objet, on aurait une variable de classe (variable statique) qu'on définirait pour porter ce port série)

On y est presque maintenant. il nous reste à dire que lorsque l'on clique sur un pavé, il faut émettre son message. Donc on va modifier la fonction mouseClicked() pour cela, au lieu de juste envoyer le message manoeuvrer au pavé, on va ensuite lui envoyer l'order de communiquer avec l'Arduino:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
void mouseClicked() { 
  int l, c; 
  ; 
  Pave p;                              
  l=(mouseY-BORDURE)/TAILLE_CASE/(int)ZOOM; // calcul de la ligne
  c=(mouseX-BORDURE)/TAILLE_CASE/(int)ZOOM; // calcul de la colonne
  if (l<0 || l>=LIGNES || c<0 || c>=COLONNES) return; // pas dans tco  
  p=tco.paves[c][l]; // obtension du pave
  if (p!=null) {
    p.manoeuvrer(mouseButton==RIGHT); // manoeuvre des aiguilles et signaux
    p.emettreMessage(); // on emet un message si nécessaire
  }
}

Enfin il faut bien sûr associer des messages au pavés. Cela se fait dans l'onglet TCO. par exemple pour nos pavés de type Cercle qui sont nos boutons, on peut faire la déclaration de la fonction construire() comme cela:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
  void construire() { // PERSO 10 complet
    //==============================================================================    
    Pave p; // variable qui nous permet de travailler avec nos nouveaux pavés

    p = new PaveCercle();
    p.definirMessage("C1V1");
    ajouter(p);
    ajouter(new PaveTexte("C1\nV1", 2, NOIR, 0, 0)); // texte, taille texte, couleur, ∆x, ∆y
    espacer(1);

    p = new PaveCercle();
    p.definirMessage("C2V1");
    ajouter(p);
    ajouter(new PaveTexte("C2\nV1", 2, NOIR, 0, 0)); // texte, taille texte, couleur, ∆x, ∆y
    espacer(1);

    p = new PaveCercle();
    p.definirMessage("C3V1");
    ajouter(p);
    ajouter(new PaveTexte("C3\nV1", 2, NOIR, 0, 0)); // texte, taille texte, couleur, ∆x, ∆y

    alaligne();        // Ligne 2 
...

je déclare une variable p qui sera un pavé et avec new je lui associe un pavé. j'appelle ensuite sur cette instance la méthode de définition de son message

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

p.definirMessage("C1V1");

et enfin on l'ajoute comme avant au TCO. On fait la même chose pour les autres.


Voilà. on y est.

si vous compilez et lancez le programme processing, en cliquant sur les "boutons" de la première ligne, un message sera envoyé à l'arduino sur son port série. Comme l'Arduino a un programme qui fait écho, c'est renvoyé au programme Processing qui va l'afficher dans sa console puisque l'on a mis la fonction serialEvent()

dans l'onglet Pavé
Mais on ne va pas s'arrêter là. Comme le dit @JP il faut pouvoir distinguer les états et donc pour cela il faut pouvoir éventuellement modifier le message qui est émis en fonction de l'état du Pavé. Comme tous les pavés héritent de la classe Pave, il ont tous un message et une méthode d'émission. Mais en programmation orientée objet, les sous-classes peuvent se permettre de surcharger certaines méthodes et de faire ce qu'elles souhaitent. On va donc par exemple modifier ma classe PaveCercle pour lui rajouter sa propre méthode emettreMessage() en disant par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
  void emettreMessage()
  {
    if (messageArduino != "") {
      arduinoSerial.write(messageArduino);
      if (couleur == #0000FF) { // couleur non appui
        arduinoSerial.write(" is OFF");
      } else {
        arduinoSerial.write(" is ON");
      }
      arduinoSerial.write('\n');
    }
  }

Quand le bouton est clické, la méthode emettreMessage() est appelée mais par le biais de l'héritage le code exécuté correspond à celui le plus bas dans la hiérarchie d'héritage, donc ici mon code spécifique et pas le code généraliste de la classe mère. Ce code ici est simpliste, je regarde la couleur du bouton, si c'est celle par défaut je rajoute "is OFF" au message envoyé à l'Arduino, sinon je rajoute "is ON".

Voilà en lançant le code modifié ainsi, l'affichage sera celui ci

et dans la console Processing quand on clique sur les boutons on voit bien les ports disponibles, puis ce que nous renvoie l'Arduino:

[0] "/dev/cu.Bluetooth-Incoming-Port"
[1] "/dev/cu.usbmodem1401"
[2] "/dev/tty.Bluetooth-Incoming-Port"
[3] "/dev/tty.usbmodem1401"
C1V1 is ON
C2V1 is ON
C3V1 is ON
C1V1 is OFF
C2V1 is OFF
C3V1 is OFF

Le principe donc serait d'associer un message à tous les pavés contenant un aiguillage en faisant comme ci dessus avec definirMessage(). si on ne modifie pas la méthode héritée emettreMessage() alors on aura celle par défaut et le pavé émettra toujours le même message à chaque fois qu'il est appuyé. si côté Arduino on sait traiter cette alternance (bascule) alors il n'y a rien de plus à faire.

ci joint le fichier ZIP avec toutes les modifications indiquées
PERSO_10_2_1.zip

Si on voulait envoyer un message particulier en fonction de la position de l'aiguillage alors il faudrait pour chaque classe qui représente des aiguilles rajouter une méthode emettreMessage() qui va faire un peu ce que j'ai fait avec les couleurs, regarder si mon état à changé et décider quel message envoyer à l'arduino dans ce cas.

Tel que c'est codé un pavé contient une liste de formes et la fonction manœuvrer() réordonne les formes et certains pavés spécifiques par exemple PaveAiguilleTriple vont avoir le propre méthode manoeuvrer(). il n'y a pas de façon simple (comme je l'ai fait avec mes couleurs) de savoir dans quel état on est. Une option serait de rajouter aux pavés une variable d'instance de type entier qui représente l'état dans lequel on est et dans la fonction manoeuvrer() si on n'a que deux états on alterne entre 0 et 1 mais si on est dans une aiguilles triple alors on alternera entre 0,1,2 par exemple. cet état serait alors utilisé pour émettre le bon message, un peu comme je l'ai fait avec la couleur.

[Jsiorat]

Bonsoir,

Je savais que vous étiez un maître en la matière ! Si personne ne vous l'a dit, je suis prêt à le crier sur tous les toits de France !

Je me suis attelé à inclure vos réflexions. Ça fonctionne au petit quart de poil !

j'ai quand une question qui me tarabuste !
J'ai copié et modifié le fichier TCO.pde pour en faire TCO_G.pde (G pour Gare) et TCO_T.pde (T pour triage)
Je pense alléger le TCO.pde en sortant les interfaces nécessaires Gare et Triage et les afficher au moyen de boutons

Pensez-vous que ce soit faisable ? avec des TCO tco = new TCO_G; ou TCO tco = new TCO_T; ...
si oui, comment modifier les fichiers ?

Merci pour vos réflexions.
Jacques

[jpbbricole]

Bonsoir Jay M

Merci pour tes explications, mais comme je disais dans mon post #279:

... Je ne suis pas arrivé à "cerner" l'événement d'un clic sur une aiguille (ça c'est bon) tout en déduisant quel est la direction active.
Pour la transmission vers l'Arduino, c'est ok.

Le principe donc serait d'associer un message à tous les pavés contenant un aiguillage en faisant comme ci dessus avec definirMessage(). si on ne modifie pas la méthode héritée emettreMessage() alors on aura celle par défaut et le pavé émettra toujours le même message à chaque fois qu'il est appuyé. si côté Arduino on sait traiter cette alternance (bascule) alors il n'y a rien de plus à faire.

En fait, si pour un clic sur une aiguille, le programme Processing (PP) ne fournit pas la position G ou D de celle-ci, ça ne répond pas vraiment à ma question. Je voulais éviter l'alternance (bascule). Dans ce cas il est beaucoup plus simple, de prendre dans void mouseClicked(), les variables l et c qui donnent le pavé cliqué et comme il n'y a qu'une chose à manipuler dans ce pavé, on envoie l et c à l'Arduino, on modifie la structure des aiguilles ainsi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	//Nom,  paveL  paveC          TCO,       Position,  Moteur G,  Moteur D,    Led G, LED D   -1 = port inutilise
	{"G1",  15,      7,        tcoIndexGare, aigPosNull,    200,       201,       208,   209},

Ainsi, l'Arduino recevrai PAV=15,7, effectue l'opération et répondrai PAV=15,7,G si l'aiguille est à gauche ou PAV=15,7,- si l'opération ne s'est pas bien terminée. Ainsi PP peut mettre à jour les pavés.
Cette même "mécanique" peut être adaptée pour les boutons.

Cette façon de procéder ne nécessite que quelques lignes supplémentaires dans l'onglet PERSO...

Jacques, passes-moi la dernière version de ton programme avec les boutons, je t'en fais la démonstration

Cordialement
jpbbricole

[Jay M]

@JP bien sûr c’est faisable comme cela.

Vous déléguez à l’arduino la tâche de gérer le message et ne passez que le clic sur un pavé.

Droite et gauche ce n’est qu’un début. Ensuite vous allez avoir les feux, les boutons, les cantons, et puis il y a des pavés avec 3 aiguillages, d’autres types de pavés que je n’ai pas trop regardés, d’autres idées de pavés (comme le bouton que Jacques souhaitait), des interactions potentielles entre pavés...

L’autre choix est de distribuer cette logique dans le programme Processing, où on a plus de mémoire et de puissance de calcul, dans les pavés eux même qui seraient responsables d’envoyer les bons ordres de plus "bas niveau" à l’arduino (qui aurait moins d’intelligence mais serait en charge des ordres "électriques" et de la remontée d’information sur l’état du réseau). A mon avis c’est plus évolutif car on n’a pas à toucher le code arduino si on change l’interface, mais demande un peu de travail abstrait/conceptuel en amont, un peu comme l’auteur de Locoduino a fait en créant son approche avec des classes et sous classes pour peindre le réseau. Le code que je donnais ci dessous n’était là que pour donner des pistes en approche objet.

En informatique il y a toujours plusieurs solutions et pas forcément une meilleure ou plus mauvaise qu’une autre. Il y a toujours des plus et des moins. Au final c’est celui qui code et fait le boulot qui décide et comme vous vous impliquez beaucoup sur le code de Jacques, faites comme ça vous paraît le plus simple pour vous.

[jpbbricole]

Bonsoir Jay M

L’autre choix est de distribuer cette logique dans le programme Processing, où on a plus de mémoire et de puissance de calcul, dans les pavés eux même qui seraient responsables d’envoyer les bons ordres de plus "bas niveau" à l’arduino (qui aurait moins d’intelligence mais serait en charge des ordres "électriques" et de la remontée d’information sur l’état du réseau). A mon avis c’est plus évolutif car on n’a pas à toucher le code arduino ...

Ok, tout à fait d'accord avec ça. Il me semblait que le programme ne partait pas dan ce sens.
Donc, j'attend les spécifications de ce que recevrai l'Arduino et ce qu'il devra répondre.

Cordialement
jpbbricole

[Jsiorat]

Bonsoir ...

Est-ce que ceci te convient ?

je t'envoie le code complet ?

Mon TCO.docx

[Jay M]

Donc, j'attend les spécifications de ce que recevrai l'Arduino et ce qu'il devra répondre.

Comme je vous l'ai dit,

Au final c’est celui qui code et fait le boulot qui décide et comme vous vous impliquez beaucoup sur le code de Jacques, faites comme ça vous paraît le plus simple pour vous.

==> c'est vous qui développez la solution complète pour Jacques, donc je vous laisse faire à votre convenance.

S'il y a des points de blocage ou des explorations ponctuelles comme le bouton, je peux contribuer à ce genre de choses, mais à vous de décider ce qui vous intéresse ou pas pour votre solution.

[Jay M]

j'ai quand une question qui me tarabuste !
J'ai copié et modifié le fichier TCO.pde pour en faire TCO_G.pde (G pour Gare) et TCO_T.pde (T pour triage)
Je pense alléger le TCO.pde en sortant les interfaces nécessaires Gare et Triage et les afficher au moyen de boutons

Pensez-vous que ce soit faisable ? avec des TCO tco = new TCO_G; ou TCO tco = new TCO_T;

Quand on fait des new, il faut des classes, pas juste un fichier qui porte un nom particulier. Ici la classe s'appelle

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
class TCO {
...

On peut instancier plusieurs fois la classe TCO, mais comme sa méthode construire() est à l'intérieur c'est pas simple d'avoir des looks différents. il faut modifier le constructeur pour qu'il soit vide

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
  TCO() {
  } // constructeur

et et enlever la code de construire() de la classe TCO.

C'est dans le setup() principal, une fois créé le tco, que vous le construisez

tco=new TCO(); // le tco
construireTCO();

la fonction construireTCO() étant une fonction à écrire qui fait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
void construireTCO()
{ // PERSO 10 complet
  //==============================================================================    
  Pave p; // variable qui nous permet de travailler avec nos nouveaux pavés

  p = new PaveCercle();
  p.definirMessage("C1V1");
  tco.ajouter(p);
  tco.ajouter(new PaveTexte("C1\nV1", 2, NOIR, 0, 0)); // texte, taille texte, couleur, ∆x, ∆y
  tco.espacer(1);

  p = new PaveCercle();
  p.definirMessage("C2V1");
  tco.ajouter(p);
  tco.ajouter(new PaveTexte("C2\nV1", 2, NOIR, 0, 0)); // texte, taille texte, couleur, ∆x, ∆y
  tco.espacer(1);

  p = new PaveCercle();
  p.definirMessage("C3V1");
  tco.ajouter(p);
  tco.ajouter(new PaveTexte("C3\nV1", 2, NOIR, 0, 0)); // texte, taille texte, couleur, ∆x, ∆y

  tco.alaligne();        // Ligne 2 
  tco.alaligne();        // Voie 3 en haut ; Ligne 3
  tco.espacer(1); 
  tco.ajouter(new PaveArc90Grand(1).symetrie()); 
  tco.ajouter(new PaveDroit()); 
...
}

une fois cela fait vous pourriez avoir plusieurs instances de la classe TCO,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
tco1=new TCO();
tco2=new TCO();
tco3=new TCO();

et bien sûr il faudra une fonction spécifique pour ajouter tous les pavés pertinent dans chacun de ces TCO.


MAIS.... à quoi ça va bien pouvoir vous servir est la question...

C'est compliqué car une instance de TCO ne gère pas la fenêtre dans laquelle il se dessine. C'est celle de l'applet en cours d'exécution... La taille de cette fenêtre est calculé pour un seul TCO dans la fonction settings()

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void settings() {
  size(COLONNES*TAILLE_CASE*ZOOM+BORDURE+BORDURE, // taille de la fenetre
    LIGNES*TAILLE_CASE*ZOOM+BORDURE+BORDURE, 
    P2D); // mode graphique 2D
}

Vous ne pouvez pas non plus avoir 3 programmes séparés que vous lancez en même temps car ils ne peuvent pas partager le port série.

il faudrait donc repenser le code pour

- soit gérer du multi-fenêtrage et associer un TCO particulier à une fenêtre. pas insurmontable mais du boulot.

- soit modifier la taille de la fenêtre unique et avoir des zones bien spécifiques pour chaque TCO. cette seconde option est la plus simple si votre écran est grand, mais dans ce cas pourquoi s'embêter autant dessiner dans une très grande fenêtre les TCO séparés graphiquement mais comme étant dans un seul TCO...


à mon avis le plus simple est de tout conserver dans une même fenêtre

PS: si dans la méthode dessiner() du TCO vous commentez les lignes en rouge ci dessous

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
  void dessiner() { 
    int l, c; 
    Pave p;
    translate(BORDURE, BORDURE); // decalage pour la bordure
    //for (l=0; l<LIGNES; l++) for (c=0; c<COLONNES; c++) { // dessin de la grille
    //  stroke(NOIR); 
    //  noFill(); // bordure noire 1 pixel, pas de remplissage
    //  rect(c*TAILLE_CASE*ZOOM, l*TAILLE_CASE*ZOOM, TAILLE_CASE*ZOOM, TAILLE_CASE*ZOOM); // dessin d'un carre vide
    //}

....

alors les pavés sont dessinés sans contours. Je trouve que ça fait plus joli et si vous mettez des réseaux bien séparés visuellement vous aurez l'impression d'avoir plusieurs "trucs" différents dans la fenêtre

[Jsiorat]

Bonjour à toutes et tous,

résultat final du dessin du TCO de mon réseau

les petits carrés rouges sont les feux de zone d'arrêt.
les petits carrés verts sont les feux de présignalisation

MERCI A JAY, sans lui, je ne serais jamais arrivé à ce résultat !

[jpbbricole]

Bonjour à tous

Voilà une semaine qui démarre fort!!!

Mon principal but est que la représentation du TCO PP soit l'exacte reflet du "circuit Arduino" et vice-versa. c'est pourquoi les commandes reçues de PP doivent âtre quittancées par l'Arduino afin de mettre à jour le graphisme et

S'il y a des points de blocage ou des explorations ponctuelles comme le bouton, je peux contribuer à ce genre de choses, mais à vous de décider ce qui vous intéresse ou pas pour votre solution.

c'est là que je bloque, je ne sait pas faire ou du moins je n'ai pas eu le temps d'étudier.

Voilà comment je vois la chose, en cas de clic sur un pavé, selon ses coordonnées L et C, dans une table dans PP (dont je m'occupe), on en déduit une commande à envoyer à l'Arduino. L'Arduino exécute puis quittance en retour avec les coordonnées L et C, suivi d'un code, à définir, qui peut être G ou D afin de mettre à jour le pavé concerné. Pour exemple, PP envoie PP=12,5,BP=C1_V2 et Arduino répond AR>12,5,G.
Ainsi, que les commandes émanent de PP ou directement de l'Arduino via le moniteur, sur un autre port Serial, ou d'un bp, PP est toujours le reflet de la situation.
L'avantage de la table dans le PP, c'est que c'est plus facile à tenir à jour. Il n'est pas nécessaire de retélécharger de programme dans l'Arduino, sauf en cas de création d'une nouvelle commande.

A votre avis?

Cordialement
jpbbricole

[Jsiorat]

Bonjour JP,

PERSO_10.zip

Ci-joint le code complet.
Il te reste à associer le code Arduino sur les boutons bleus

Une remarque à prendre en compte ...
- au lancement la gare est programmée. par les commandes C1_V1, C2_V2 et C3_V3
si on clique sur d'autres boutons, C2_V3 par exemple et encore sur C3_V1 ...
il devient nécessaire de réinitialiser la gare avant que le C3_V1 soit effectif pour que les aiguillages
soient bien tous en conformité et simuler le clic sur les pavés concernés

Ce qui veut dire que, dès que l'on clique sur l'un des boutons de la gare, il faut la réinitialisée.
je ne sais pas si je suis clair dans mon explication.

Courage, on y est presque !

Jacques

[Jay M]

Bonjour

Jacques - très cool le nouveau dessin !

JP, tant que l’arduino n’utilise pas les coordonnées du pavé pour prendre des décisions ça peut le faire mais difficile de s’en passer à mon avis pour les commandes multiples que mentionne Jacques. C’est ennuyeux car ça oblige de connaître les pavés dans le programme arduino. Sinon il faut donner un nom aux pavés, nom qui sera connu et identique dans l’arduino.

Le PP envoie "(12,5)BP=C1_V2\n" (facile d’analyser "(x,y)commande\n").
L’arduino répond "(x,y)commande\n") de manière symétrique et dans ce cas le PP met a jour le Pavé en x,y avec l’état défini par le commande mais idéalement au lieu de x,y ce serait le nom de l’équipement réseau.

Si on veut conserver de la flexibilité, les commandes émises depuis l’arduino devraient être une énumération commençant à 0 (état par défaut) au lieu de ‘G’ ou ‘D’ car ça permettra de gérer des éléments à plusieurs états (feux tricolores, triple aiguille,...) on envoie 0,1,2,3... et l’élément dessiné en position x,y se met dans cet état.

Ça va nécessiter de modifier tous les pavés existant de locoduino pour qu'ils sachent se mettre dans un état numéroté. Leur état par défaut (0) sera celui d’ajout des formes dans le pavé. Il faudra que la config de départ de l’arduino soit identique.

Noter que le MEGA reboot à l’ouverture de la console série, donc quand on lance le PP l’arduino rebootera. C’est intéressant car les deux programmes seront à leur état par défaut mais il faut en tenir compte pour "jouer avec le train". On ne peut pas commencer à ce l’arduino et des boutons physique comme vous avez pour le moment, puis se dire je lance le PP. il faut lancer le PP en premier ou ne pas l’utiliser sinon.

[Jsiorat]

Alors là, maintenant, je suis complètement largué !

dites-moi si je peux faire quelques choses ... dans mes compétences (en un seul mot!)!

[jpbbricole]

Bonjour Jacques et Jay M

Alors là, maintenant, je suis complètement largué !

dites-moi si je peux faire quelques choses ... dans mes compétences (en un seul mot!)!

Pas de panique, le problème est tout "simple", c'est la synchronisation entre l'état du matériel aiguilles et autre futurs, dans l'Arduino et l'affichage de leur état dans PP.

J'aimerai que l'Arduino n'aie pas à connaître les coordonnées d'un pavé. Partant du fait qu'un pavé ne traite qu'un objet, je crée une structure contenant les coordonnées L et C du pavé contenant un objet (aiguille, feu...), le ou les commandes pour l'Arduino ainsi qu'un pointeur qui contient l'identité de la chose commandée dans l'Arduino. ainsi on clique sur le pavé 12/7 qui envoie
BP=C1_V2
l'Arduino répond:
G1=0
A1=0
A4=0
Les 3 aiguilles à droite
A la réception dans PP, pour chaque ligne, PP va rechercher, dans la structure le poiunteur correspondant à l'identité de la réponse de l'Arduino et de par là, son état et les coordonnées du pavé qui permettra ca mise à jour.

Garder les coordonnées des pavés uniquement dans PP, fait qu'il faille intervenir dans l'Arduino, uniquement en cas de changement de hardware.
Pour autant que l'on aie un autre port Serial comme console (Bluetooth par ex.), on pourra lancer des ordres directement sur l'Arduino et, ainsi, PP sera toujours à jour.
On peu aussi imaginer un bouton ou une commande qui synchronise Arduino sur PP.

Je vais faire l'essai.
Je sens que l'hiver va être long

La flotte, la flotte....

Cordialement
jpbbricole

[Jsiorat]

Bonjour Jacques et Jay M

Pas de panique, le problème est tout "simple", c'est la synchronisation entre l'état du matériel aiguilles et autre futurs, dans l'Arduino et l'affichage de leur état dans PP.

Pas de panique ? le problème est tout simple ? pour toi très certainement !
Pour moi, tant que je n'ai pas l'exemple sous les yeux pour étudier, essayer ... c'est de l'hébreu !

Je voudrais préciser un fait :
Par défaut la liaison Dépôt vers Triage est effective !
pour passer du Triage vers Atelier1 => clic Droit ;
pour passer du Triage vers Atelier2 => clic Gauche ;
pour aller de Atelier 2 vers dépôt => clic droit ;
pour revenir au défaut => clic Droit.
Ça va pas être simple de gérer ça !

Mais j'ai HYPER confiance ... en toi !
bon courage
Jacques

[jpbbricole]

Salut Jacques

Mais j'ai HYPER confiance ... en toi !

Merci ç va m'aider à ne pas dérailler

Bonne après-midi, la flotte, la flotte, ....
jpbbricole

[Jay M]

en parcourant un peu locoduino je suis tombé sur cet article Un gestionnaire en C++ pour votre réseau

j'ai l'impression que c'est très complet et très structuré (côté Arduino et côté Processing). Il faudrait se poser la question - doit-on "réinventer la roue"?

[jpbbricole]

Bonjour Jay M

J'avais aussi vu cet article, mais aussi la remarque de Jacques

Je connais locoduino, les gars qui sont sur ce site sont hyper pointus et j'ai du mal à comprendre leurs écrits.

Je dois dire que j'abonde dans ce sens. C'est, peut-être le pourquoi de la présence de Jacques ici.

Cordialement
jpbbricole

[Jay M]

Je dois dire que j'abonde dans ce sens. C'est, peut-être le pourquoi de la présence de Jacques ici.

c'est vrai, ils sont très "programmation orientée objet" ce qui d'un premier abord est difficile car il faut se mettre dans ce mode de pensée. C'est nécessaire en Java et si on fait du vrai C++ c'est le cas aussi. C'est pas mal de se challenger les neurones un peu

un utilisateur de locoduino (Dominique) a posté dans le forum un petit tuto sur son experience et il dit

Je voudrais ajouter que j’ai mis en œuvre la méthode de Pierre dès son première article. C’est dans le forum, ici.
J’y décris une méthode pas à pas dans laquelle on voit bien comment le réseau est modelisé par les méthodes propres des objets zones et aiguilles.
Je dois dire aussi que je n’ai pas trouvé cela laborieux, mais, au contraire, lumineux.

il faut certes se mettre quelques notions "objet" en tête sinon on est vite perdu.

D'un autre côté vous voyez que le programme que vous avez concocté est déjà hors de portée d'un débutant et vous allez rajouter une couche de communication et synchro avec processing, ça ne va pas simplifier les choses.

pour le fun, développer son propre code c'est cool, mais Jacques ne pourra sans doute pas maintenir votre code.

Je me demande donc s'il n'est pas plus efficace pour un débutant d'investir du temps dans la solution qu'une communauté de passionnés spécialisés dans les trains a documenté.

[jpbbricole]

Bonjour Jay M

A Jacques de décider.

Pour ma part, je pense que Jacques sera apte à maintenir ce projet, vu les capacités d'adaptation dont il a fait preuve.
Je vais continuer ce projet, à titre personnel, je m'amuse toujours!

Cordialement
jpbbricole