Messages récents

Pages: [1] 2 3 ... 10
1
Aide / Re : dcc monitor et dcc_basic_acc_decoder
« Dernier message par msport le Aujourd'hui à 02:34:55 pm »
Bonjour,

vous pouvez donner le lien vers l'article "avec l'écran LCD" ?

si il s'agit d'un écran LCD qui peut le plus peut le moins, la dimension se précise dans le setup et l'affichage dans dans le programme.

16x2 ou 20x4, par contre, les écrans adressables par points sont plus compliqués à gérer.

A vérifier, l'adresse I2C, si problème.
2
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
3
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  :)
4
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
5
...
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
6
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
7
Aide / Re : dcc monitor et dcc_basic_acc_decoder
« Dernier message par Cy83 le juin 08, 2023, 11:48:14 pm »
Bonjour,

Merci pour vos informations précieuses.
Sur vos conseils, j'ai réussi a faire le Sniffer (je vous l'avoue, une petite victoire !!)

Jai fait le montage "SANS ecran LCD" qui marche parfaitement
Je souhaite passer à l'étape suivante ==> "AVEC ecran LCD"

Je ne trouve pas d'informations sur la taille de l'écran LCD ?
Question bête : Est-ce que n'importe quelle taille fait l'affaire ou faut-il un écran de taille minimale (j'ai cru voir 16x2 ou 16x4 mais je n'en suis vraiment pas sûr) ??

Merci par avance
cyril
8
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
   
9
Bonjour

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

Pierre
10
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   :)
Pages: [1] 2 3 ... 10