TCO + Aiguilles avec Processing 4.2

[Dom59]

Bonjour à tous,
mon TCO avance pas à pas (merci Pierre), l'étape suivante serait de pouvoir relier la position de l'aiguille  avec sa led d'occupation en "Processing".
exemple:
Aiguille A2 Droite; A2 (led verte), A2d (led rouge); Aiguillage en position normale,
Aiguille A2 Déviée; A2 (led rouge), A2d (led verte); Aiguillage en position déviée,

Voici l'onglet "Paves"pour l'aiguille:

Code: [Sélectionner]

class PaveAiguilleDroite extends PaveAiguilleSimple {
  PaveAiguilleDroite() { super(new FormeArc45(),new FormeDroit()); } L'onglet "Paves" pour la led:

Code: [Sélectionner]

class PaveDroitZoneA extends PaveDroit {
  boolean occupe=false;
 
  Pave manoeuvrer(boolean b) { occupe=!occupe; return this; }

  void dessiner() {
    super.dessiner();
    pushStyle();
    strokeWeight(ZOOM/2.8); strokeCap(SQUARE);
    if (occupe) stroke(ROUGE); else stroke(VERT);  // couleur des signaux
    ellipse(4.5,4.5, 1.1,1.1);
    popStyle();
  }Et l'onglet "TCO"

Code: [Sélectionner]

    paves[c++][l]=new PaveAiguilleDroite().rotation(4);
    paves[c++][l]=new PaveDroitZoneA();
    paves[c++][l]=new PaveTexte("A2",3,GRIS_FONCE);
    paves[c++][l]=new PaveDroit();
Question:
comment faire si ce n'est pas trop compliqué ?
Le but étant d'utiliser la souris de l'ordi (par clic ) qui pourrait aussi être utilisée par la suite via l'usb + Arduino + le petit réseau, sauf erreur de ma part,
D'avance je vous remercie,
Dominique,

[Pierre59]

l'étape suivante serait de pouvoir relier la position de l'aiguille  avec sa led d'occupation en "Processing".

Je ne comprends pas de quoi il s'agit

Pierre

[Dom59]

Bonjour Pierre,
actuellement, lorsque je "clic" avec la souris, sur le "Pave" de l'aiguille, celle-ci change de position, soit en position droite, soit en position déviée. Ce que je voudrais essayer, serait qu'au "clic" de la souris, il y ait en plus l'allumage de la "led" suivant la position de l'aiguille,
merci Pierre,

Dominique

[Pierre59]

Quelle led ?

Pierre

[Dom59]

Bonjour,
la led étant un PaveDroitZoneA avec ellipse rouge (occupation) ou grise située à côté du PaveAiguilleDroite, le "clic" souris étant indépendant de la led lorsque je "clic" sur l'aiguille et vise versa,

j'ai tenté cela dans l'onglet "Paves" mais ce n'est pas bon.

Code: [Sélectionner]

class PaveAiguilleDroite extends PaveAiguilleSimple {
  PaveAiguilleDroite() { super(new FormeArc45(),new FormeDroit()); }             // constructeur

}
   
if (PaveDroitZoneA(A2d;c10;l20) == HIGH && PaveDroitZoneA(A2;c11;l20) == LOW) {  // Pave de zone avec sa del
    PaveAiguilleDroite(FormeDroit); // allume la del du TCO
else {
    PaveAiguilleDroite(FormeArc;c11;l19); // étéint la del du TCO
   
}
Dominique

[Ptittrain12]

Bonjour à tout le monde !

Me remettant à la réalisation d'un réseau (analogique) que je n'avais pu continuer pendant plusieurs années, je réfléchis à la réalisation du TCO.
A l'origine, j'avais commencé avec le langage Delphi et la P.O.O. qui m'avaient paru très adaptés.
 Puis, constatant qu'une gestion des aiguilles par des arduino (servos) simplifiait beaucoup le travail, j'ai découvert Processing pour être, ensuite, émerveillé par le magnifique travail de Pierre59 que l'on ne saurait trop souligner.

Ceci étant, je suis confronté, pour le TCO, au problème suivant que le programmeur peu aguerri que je suis n'a pas réussi à résoudre :

Les premiers pavés expérimentaux du TCO, que je construis au moyen de PShapes (dont j'ai lu qu'ils augmentaient la rapidité des programmes), sont parfaitement fonctionnels et je constitue autant de GROUP de pavés que de cantons. Ceci, notamment pour des changements plus simples de couleurs par canton en une seule manoeuvre.

A ma grande surprise, alors que des instructions telle que rotate() etc.. fonctionnent parfaitement pour des GROUP de PShapes, les instructions color(), Fill() etc.. c.à d. tout ce qui concerne les remplissages de couleurs ne semblent pas marcher..
Evidemment, je pourrais brutalement traiter le problème au niveau de chaque pavé par des void mais, une seule commande de couleur par GROUP (et donc pour tout un canton) serait plus élégante !..   

Quelqu'un aurait-il une idée à ce sujet ?.. 
Un grand merci,
amitié à tous,
jj T   

[Pierre59]

Bonjour

Je veux bien vous aider. Mais il me faudrait plus d'informations, un listing du programme peut-être ?

Pierre

[Ptittrain12]

Bonjour Pierre,
Navré pour la réponse tardive.. je ne m'attendais pas à une réponse aussi rapide et encore moins une réponse de votre part !.. J'en suis extrêmement touché.

Ayant commencé, dans la maison du Rouergue, la réalisation d'un réseau assez grand (une quarantaine de cantons), je méditais depuis plusieurs années au futur TCO.
Mon réseau sera équipé d'une commande centralisée dont je fus totalement satisfait pour un premier réseau expérimental à Paris (après pas mal de mises au point électroniques et aidé de façon décisive par son concepteur, le génial Jean Chavany ).

J'avais beaucoup lu, relu et approfondi vos travaux sur le  TCO qui m'ont permis de découvrir Processing, étonnant et splendide outil..
Ceci étant, ils me semblaient un peu complexes pour le presque débutant Processing que j'étais.  Aussi m'étais-je tourné vers l'éventualité d'une adaptation perso de la proposition de Christian (Ménage à trois).
Mon idée était de dessiner avec des PShapes puis de regrouper les pavés à raison d'un GROUP par canton. Bien sur, l'idée était de simplifier le travail de rédac. pour n'avoir à commander qu'avec une seule instruction les changements de couleurs pour un canton.

Je me disais aussi que, peut-être (mais je n'en suis pas du tout certain), comme je l'avais travaillé pour Delphi, les GROUP étaient, dans les profondeurs du langage, des classes et que ces classes admettaient des instanciations avec héritage des propriétés etc.. bref, une déclinaison de P.O.O..

Ceci pour découvrir que, si des opérations comme rotate, translate etc.. fonctionnent pour les GROUP, je n'arrive pas à faire tourner ce qui concerne les couleurs..

Voilà.   Je vous joins un petit bout d'essai.

Merci d'avoir de l'indulgence pour l'amateur que je suis !..
Bien amicalement,
jean-jacques
   

[Pierre59]

Bonjour

Effectivement :

  Groupcanton.setFill(GRIS);

compile bien mais ne fonctionne pas comme on pourrait l'espérer

par contre colorer séparément tous les éléments du groupe fonctionne bien :

       PShape[] tab=Groupcanton.getChildren(); // obtention des fils
       for (PShape p : tab) p.setFill(GRIS); // pour tous les fils colorer en GRIS

Cordialement

Pierre

[chris_bzg]

...
Ceci étant, ils me semblaient un peu complexes pour le presque débutant Processing que j'étais.  Aussi m'étais-je tourné vers l'éventualité d'une adaptation perso de la proposition de Christian (Ménage à trois).
...
jean-jacques
 

Bonjour Jean-Jacques,

Cela me fait plaisir de voir quelqu'un qui se tourne vers la modernité alors que les forums sont remplis de projets de TCO à l'ancienne, avec interrupteurs, potentiomètres et LED.

L'article "Ménage à trois" a été écrit pour faire la synthèse de ce que proposait Pierre dans ces articles (sans ce qu'il avait publié, mon article n'aurait sans doute jamais vu le jour). En effet, il y a assez peu de choses à faire pour commander un réseau analogique :
- savoir alimenter une voie de garage
- savoir changer le sens du mouvement sur une voie
- savoir commander une aiguille
Avec ces trois cas, on traite toutes les topologies de réseau. La nouveauté dans mon article était l'interface qui consiste à passer de Processing au réseau réel et la communication entre les deux.

J'ai donc appliqué ces principes à mon petit réseau et j'ai construit une interface : aujourd'hui, je commande mon réseau directement avec la souris de mon ordinateur. Le prochain Loco-Revue est supposé décrire tout cela afin d'inciter les modélistes à oublier l'électromécanique.

Je suis donc persuadé que vous arriverez au même résultat sur votre réseau, avec sans doute des améliorations auxquelles je n'ai pas pensé. Bonne continuation.

Christian

[Ptittrain12]

Je réponds à la fois à Pierre et à Christian que je remercie et auxquels j'adresse le témoignage de reconnaissance d'un quasi débutant à l'époque en Arduino et, plus récemment en Processing. Oui, vos contributions m'ont à la fois fait rêver et beaucoup agité les neurones (grand plaisir..).

A l'époque, j'étais pas mal investi en Delphi et Pascal Objet, outils extraordinaires, qui, si j'avais eu un peu plus de temps (que j'ai préféré consacrer à mes vieux parents en fin de vie), auraient produit des résultats à peu près comparables.    Ah, les Classes, les instances et les inherited() !..
Ceci étant, les Arduino sont arrivés et, pour toutes les raisons imaginables, sont un vrai régal.. (ah les dizaines d'aiguilles sur servos avec un simple Méga !..).   Je dois dire aussi qu'à l'issue d'essais que j'avais fait à l'époque, et contrairement aux copains du monde automobile qui ne jurent que par le CAN et me prédisaient les pires avatars, l'I2C se comporte très bien même sur une assez longue distance. (au besoin, il y a les amplis à 2 francs, six sous..).

Bon, ceci étant, je n'ai "que" le TCO à traiter car tout ce qui concerne la gestion des convois, sécurité, signalisation etc.. est assuré par la CS80 qui  - à condition qu'on ait un ou deux Rigol(s) pas loin -   reste géniale..   (Grazie Mille, Monsieur Chavany !.. et chapeau !).
   
Pour les itinéraires, le transit souple sera, lui aussi en partie géré par la CS mais avec des itinéraires type programmés en Processing.  Le PC renseignera une CPLD (une bonne vieille Mach130 - 5 volts (immédiatement compatible, donc, avec les infos TTL de la CS)) qui, programmée en booléen, tracera les itinéraires..
Les cartes d'entrées-sorties : tout simplement des Velleman USB.
   
Voilà.  Maintenant, il n'y a plus qu'à !..

Un grand merci encore (et quel plaisir de parler de ça avec des correspondants agréables à notre époque complètement folle où le "débat" est un mot qui n'existe plus..

Très bonne journée   
jean-jacques

[Ptittrain12]

J'oubliais une chose : Les GROUP au sens de Processing recouvrent-t'ils en interne (ou se recoupent-ils avec..) la P.O.O. du même Processing ?..  ce serait intéressant..
amitié
@+  jj 

[Pierre59]

J'oubliais une chose : Les GROUP au sens de Processing recouvrent-t'ils en interne (ou se recoupent-ils avec..) la P.O.O. du même Processing ?..  ce serait intéressant..
amitié
@+  jj 

Non, les groupes de Processing c'est juste un tableau de PShapes, rien à voir avec la POO.

Pierre

[Ptittrain12]

Bonjour Christian,

 

".. Cela me fait plaisir de voir quelqu'un qui se tourne vers la modernité alors que les forums sont remplis de projets de TCO à l'ancienne, avec interrupteurs, potentiomètres et LED. .."

"... Le prochain Loco-Revue est supposé décrire tout cela afin d'inciter les modélistes à oublier l'électromécanique...."

La modernité / L'ancienne : Je pense qu'à la condition qu'on investisse quelques heures dans l'examen de ces outils ultra-performants (Arduino / Processing) le résultat est à la hauteur des espérances.. L'investigation.. la recherche : quelle satisfactions pour l'esprit !   mais ça rejoint la terreur qu'éprouvent maintes personnes lorsqu'on les questionne sur leur contact avec l'informatique (ou d'autres disciplines des temps actuels).
 
Ceci étant, comment ne pas se souvenir avec émotion des 3 tomes de Chenevez et de ses dizaines de relais ?  dans mon adolescence, leurs énigmes étaient d'un autre intérêt que celles qui auraient pu résulter de la lecture de romans policiers !..

Je me régale à l'avance pour le prochain L.R. !..
Bon week-end (et encore grand merci pour tout).
@+  jjt    (Pardon pour la présentation du message, j'ai du mal avec le formatage différent de la couleur des encadrés de citations)

[chris_bzg]

S'il y a des gens pour vouloir travailler avec des interrupteurs et des relais, grand bien leur fasse. D'ailleurs, je pense aussi à ces gens là puisqu'un article faisant le point sur les relais devrait paraître dans le bulletin de l'AFAN (pas le prochain mais le suivant).
Malgré cela, j'essaie depuis bientôt dix ans de montrer que les microcontrôleurs font bien mieux mais comme vous dites, il faut consacrer quelques heures à essayer de comprendre. Au début, les modélistes étaient réticents au numérique et maintenant, tout le monde ne jure que par lui ! L'utilisation des microcontrôleurs commence à émerger après 10 ans d'inertie. Pourtant, LOCODUINO a publié sur de nombreuses techniques appliquées au modélisme ferroviaire.
Je ne peux donc que me réjouir de voir des gens comme vous qui se lancent dans des techniques innovantes. Et je reste persuadé que vous arriverez au but car vous avez ce soupçon de curiosité et de pugnacité nécessaire pour réussir. Bonne continuation et on reste à votre disposition.