pupitre CC72000

Venez présenter vos projets à venir sur vos créations spécifiquement dédiéss à ORTS.

Modérateur : Modérateurs

FloBarr
Messages : 20
Enregistré le : 15 juil. 2011 11:15

Re: pupitre CC72000

Messagepar FloBarr » 25 mai 2017 12:40

Salut,

sncf68 a écrit :J'ai déjà réfléchi à plusieurs solutions pour communiquer les données :
- Solution 1 : Je suppose la plus simple à mettre en oeuvre du côté OR, l'écriture en continu dans un fichier texte, lu ensuite par un programme externe ( de ce côté là aucun soucis). Le Log d'OR le fait déjà en quelque sorte, malheureusement le fichier n'est pas écrit au fur et à mesure mais d'un coup à la fermeture de la session OR.
- Solution 2 : Permettre directement via OR la communication avec un port série, pourquoi pas avec un paramétrage dans le menu Options, avec un envoie sous la forme d'une trame normalisée (par exemple actuellement avec mon système j'ai une trame du genre Vxxx/Gxx/Fxx/... où les lettres sont les identificateurs de type de donnée (Vitesse, pressions cG, pression cF,...), xx la valeur, et / le séparateur.
- Solution 3 : Créer un programme externe capable d’échanger avec OR ne temps réel, et qui lui même permet la liaison série.


A titre perso, c'est la solution 3 qui serait la plus viable pour communiquer avec de vrais pupitre, ce programme externe gérant toute les particularités de l'équipement connecté.

Merci Olivier de ton appoint, ca serait d'une grande aide!!!

Florian

Avatar du membre
Groquik
Messages : 93
Enregistré le : 15 nov. 2005 1:20
Contact :

Re: pupitre CC72000

Messagepar Groquik » 26 mai 2017 16:33

Bonjour

La transmission de données en "temps réel" entre deux applis n'est pas ma spécialité, loin de là. Mais on peut quand même commencer à ébaucher un cahier des charges.

On cherche à diffuser des infos à un rythme assez rapide (au moins 10 fois par seconde), la sortie par fichier ne me semble pas la bonne solution à cause des accès disque, à moins qu'on puisse gérer un fichier en RAM (c'est possible avec Linux mais j'en sais rien pour Windows).
Après une recherche rapide, j'ai vu que certains préconisent un flux réseau. Ça peut fonctionner en localhost, comme en distant.
C'est asynchrone mais suffisamment rapide pour que le pupitre n'y voit que du feu.

Là où je butte par inexpérience, c'est qu'il faut trouver un moyen pour qu'Open Rails diffuse des infos sans attendre de retour, et même si aucune autre appli n'écoute en face (Broadcast). Alors qu'à ma connaissance, le protocole TCP/IP nécessite que deux applications se connectent et s'identifient.

On a pas besoin de sécuriser cette diffusion, ni d'horodater ou de numéroter les paquets. A chaque cycle où Open Rails calcule les paramètres, il faut écraser les infos précédemment envoyées.

De quelles infos a-t-on besoin?
Si on prévoit une interface suffisamment souple pour simuler une locomotive électrique, purement diésel ou diésel-électrique (la 72000 étant un hybride), on a besoin de :
(Liste non exhaustive à compléter, et je ne sais pas si Open Rails peut toutes les fournir)
Vitesse instantanée
Pression CG
Pression CP
Pression RP
Pression CF
Régime moteur
Régime moteur machine menée
Tension ligne
Ampèremètres moteurs
Voltmètres moteurs
LS QT
LS DJ
LS PAT
LS SF
Infos KVB (à détailler)
Infos Cab signal (vitesse but, distance but...)
Répétition des crans (Open Rails a-t-il fait des progrès par rapport à MSTS pour simuler les crans, les couplages, le shuntage...etc ?)

Ma piste de travail est donc de
- lister toutes les données à transmettre
- Trouver l'endroit du code Open Rails où ces données sont calculées
- Les diffuser sur un port réseau (il faut se mettre d'accord sur le format, l'identification de chaque donnée par un token, le choix des unités (pour la vitesse ou les pressions...etc)

Avatar du membre
CM63
Messages : 1919
Enregistré le : 13 août 2010 21:48
Localisation : Un peu au large de la faille de Limagne
Contact :

Re: pupitre CC72000

Messagepar CM63 » 26 mai 2017 18:59

J'avais mls un message sur les communications inter-process, mais cela ne convient pas puisque ce n'est pas le même processeur. Je retire mon message. hors_sujet
Image

FloBarr
Messages : 20
Enregistré le : 15 juil. 2011 11:15

Re: pupitre CC72000

Messagepar FloBarr » 26 mai 2017 21:23

De ce que je vois, le popen ne serait pas d'une grande aide dans nos cas, puisque créant un process au sein du programme, et un pipe vers celui ci. Dans notre cas, il faudrait une ligne de communication vers un programme externe, que ce soit par un canal réseau, ou un pipe.

Flo

BB22210
Modérateur
Messages : 684
Enregistré le : 25 oct. 2004 23:34
Localisation : Isère (38)
Contact :

Re: pupitre CC72000

Messagepar BB22210 » 26 mai 2017 21:44

Hello,
RailDriver fonctionne comment ?

Christophe
Guignol et ficelle de préférence ...

Avatar du membre
sncf68
Messages : 129
Enregistré le : 09 oct. 2015 19:00
Localisation : Alsace
Contact :

Re: pupitre CC72000

Messagepar sncf68 » 27 mai 2017 14:40

Bonjour !

Groquik a écrit :De quelles infos a-t-on besoin?
Si on prévoit une interface suffisamment souple pour simuler une locomotive électrique, purement diésel ou diésel-électrique (la 72000 étant un hybride), on a besoin de :
(Liste non exhaustive à compléter, et je ne sais pas si Open Rails peut toutes les fournir)
Vitesse instantanée
Pression CG
Pression CP
Pression RP
Pression CF
Régime moteur
Régime moteur machine menée
Tension ligne
Ampèremètres moteurs
Voltmètres moteurs
LS QT
LS DJ
LS PAT
LS SF
Infos KVB (à détailler)
Infos Cab signal (vitesse but, distance but...)
Répétition des crans (Open Rails a-t-il fait des progrès par rapport à MSTS pour simuler les crans, les couplages, le shuntage...etc ?)


La liste des données à transmettre n'est pas aussi longue, il faut en effet impérativement :
Vitesse instantanée
Pression CG
Pression CP
Pression RP
Pression CF
Régime moteur
Régime moteur machine menée comme les UM sont souvent avec deux machines identiques, pour OR ce sera le même régime que pour la machine manante
Ampèremètres moteurs
Voltmètres moteurs
LS PAT
LS SF
Infos KVB (à détailler) OR/MSTS gère actuellement 8 affichages différents pour le KVB, que je suis en train d’essayer de définir, mais c'est un peu aléatoire dans certains cas
Infos Cab signal (vitesse but, distance but...)
pourcentage du throttle, que l'on peut ensuite exploiter comme on veut.[/b]

Pour les autres variables :
Tension ligne : toujours la même, donc à priori pas nécessaire
LS QT : pour l'instant absent d'OR
LS DJ : présent dans OR depuis peu, à voir

Mais là encore ce n'est pas la principale difficulté...

Amicalement,
Carlo

Avatar du membre
RM77
Testeur
Messages : 1226
Enregistré le : 03 août 2005 8:19

Re: pupitre CC72000

Messagepar RM77 » 27 mai 2017 18:50

Bonjour
sncf68 a écrit :...
Régime moteur machine menée comme les UM sont souvent avec deux machines identiques, pour OR ce sera le même régime que pour la machine manante
...

Et bien non, c'est partiellement faut. C'est vrai pour les trains de fret mais pas pour les trains de voyageurs. L'engin menant assure l'alimentation de la ligne 1500v de la clim ou du chauffage et dans ce cas, la loc de tête ne dispose pas de toute sa puissance pour la traction . C'est une perte de puissance qui est loin d'être insignifiante. A titre d'exemple, lors de la remorque d'un train de 10 voitures par une UM66400, on estimait que le premier assurait le chauffage du train et le second, la traction. Ce n'est pas tout à fait vrai, il restait quand même en rampe de 7 pour 1000 , une centaine de KW pour la traction.
J'en ai connu des conducteurs qui coupaient le chauffage pour grimper les côtes lorsqu'ils étaient en retard.... =.
A+
Deux choses sont infinies : l'Univers et la bêtise humaine. Mais, en ce qui concerne l'Univers, je n'en ai pas encore acquis la certitude absolue.
Albert Einstein.

Avatar du membre
sncf68
Messages : 129
Enregistré le : 09 oct. 2015 19:00
Localisation : Alsace
Contact :

Re: pupitre CC72000

Messagepar sncf68 » 30 mai 2017 19:03

Bonsoir !

RM77 a écrit :Bonjour
sncf68 a écrit :...
Régime moteur machine menée comme les UM sont souvent avec deux machines identiques, pour OR ce sera le même régime que pour la machine manante
...

Et bien non, c'est partiellement faut. C'est vrai pour les trains de fret mais pas pour les trains de voyageurs. L'engin menant assure l'alimentation de la ligne 1500v de la clim ou du chauffage et dans ce cas, la loc de tête ne dispose pas de toute sa puissance pour la traction . C'est une perte de puissance qui est loin d'être insignifiante. A titre d'exemple, lors de la remorque d'un train de 10 voitures par une UM66400, on estimait que le premier assurait le chauffage du train et le second, la traction. Ce n'est pas tout à fait vrai, il restait quand même en rampe de 7 pour 1000 , une centaine de KW pour la traction.
J'en ai connu des conducteurs qui coupaient le chauffage pour grimper les côtes lorsqu'ils étaient en retard.... =.
A+


Je suis entièrement d'accord avec toi ! Mais je parle là de la simulation dans Open Rails, qui ne prends pas en compte le chauffage du train, du moins à ma connaissance...

A+
Carlo

Avatar du membre
Groquik
Messages : 93
Enregistré le : 15 nov. 2005 1:20
Contact :

Re: pupitre CC72000

Messagepar Groquik » 30 mai 2017 21:41

Bonsoir

Open Rail prend en compte (ou semble prendre en compte) la consommation de chaleur des véhicules remorqués...

...SAUF que ça ne semble concerner que le chauffage vapeur.

Avatar du membre
RM77
Testeur
Messages : 1226
Enregistré le : 03 août 2005 8:19

Re: pupitre CC72000

Messagepar RM77 » 30 mai 2017 22:30

Bonsoir
Groquik a écrit :Bonsoir
Open Rail prend en compte (ou semble prendre en compte) la consommation de chaleur des véhicules remorqués...
...SAUF que ça ne semble concerner que le chauffage vapeur.

Pour les machine à vapeur, le chauffage du train nécessite de produire davantage de vapeur d'où une augmentation de la consommation d'eau et de combustible. Ca n'influence pas les performances de la machine, si le personnel et le matériel sont à la hauteur de la tâche. (A noter qu'il y a un robinet qu'on peut fermer).
Ce qui est assez comparable aux machines modernes à hachoir de courant où la puissance disponible est très peu impactée par la tension en ligne. Le chauffage ( ou la clim ) ne peut influencer que des machines à courant continue équipées de rhéostat et aux machines mono avec graduateur où il faut observer le thermomètre des volts en ligne sous peine de disjonction et le mécano doit maintenir la tension en ligne en réduisant l'effort de traction, en changeant de couplage ou en retirant des crans selon la nature du courant ( Là il n'y a pas de robinet mais un interrupteur ). Les machines les plus impactées par le chauffage et/ou la clim sont les machines diésels qui perdent 10,15,...% de puissance dés que ZCH est sur marche. C'est une perte de puissance qui peut dépasser les 30 % de la puissance totale. Pour info, en dessous de 1000v produit, la ligne train n'est plus alimentée. Le chauffage/climatisation est coupé pour protéger les équipements des voitures.
Maintenant, ce que fera OR pour le chauffage ..., dans 1 mois, 1 an, 10 ans ou plus ???
A+
Deux choses sont infinies : l'Univers et la bêtise humaine. Mais, en ce qui concerne l'Univers, je n'en ai pas encore acquis la certitude absolue.
Albert Einstein.

FloBarr
Messages : 20
Enregistré le : 15 juil. 2011 11:15

Re: pupitre CC72000

Messagepar FloBarr » 04 juil. 2017 9:52

Salut à tous,

Dans le cadre d'un autre projet, il m'est venu une petite idée, à voir si ca peut être concrétisé pour open rails:
il a été évoqué jusque la la possibilité de créer un canal de communication entre 2 applis, et visiblement, ca n'est pas si simple... Il pourrait exister une autre solution, mais je ne connais pas assez visual studio pour expérimenter: il s'agirait de créer une fenêtre en arrière plan avec toutes les infos utiles dans des controls quelconques. Le programme souhaitant avoir accès aux donner n'aurait plus qu'à venir "lire"cette fenetre. Cette lecture peut se faire de manière très simple, et ne consomme quasiment pas de ressources (testé et validé).

Je vais essayer de piger comment fonctionne visual studio pour tenter de mettre en place cette solution (si quelqu'un s'y connait, je veux bien un peu d'aide!)

Peut être une idée à la con, mais à titre perso, c'est a tenter!

Flo

Avatar du membre
sncf68
Messages : 129
Enregistré le : 09 oct. 2015 19:00
Localisation : Alsace
Contact :

Re: pupitre CC72000

Messagepar sncf68 » 08 juil. 2017 14:00

Salut !

L'idée est intéressante, juste une précisons : sous quelle forme veux-tu afficher les données dans la fenêtre ? Avec des jauges comme sur l'écran du jeu actuellement ?

Le problème d'une modification d'Open Rails c'est qu'elle devra être effectuée à chaque nouvelle version du jeu.. Mais si tu arrive à faire quelque chose de propre je pense qu'il est possible de la soumettre au créateurs du jeu, qui pourront l'ajouter à la version "officielle".

Mais si tu te lance dans la modif d'OR, pourquoi ne pas coder directement l'ouverture d'une liaison série, pour qu'OR puisse envoyer les données directement à une carte arduino, sous forme d'une trame normalisée à définir ? A voir éventuellement : https://msdn.microsoft.com/fr-fr/librar ... t(v=vs.110).aspx

Malheureusement pour l'instant je n'ai pas trop le temps de creuser de ce côté :/

Amicalement,
Carlo

BB22210
Modérateur
Messages : 684
Enregistré le : 25 oct. 2004 23:34
Localisation : Isère (38)
Contact :

Re: pupitre CC72000

Messagepar BB22210 » 08 juil. 2017 17:06

Hello,
Oula ca fume par ici, des idées a creuser <2<

le lien msdn est :https://msdn.microsoft.com/fr-fr/library/system.io.ports.serialport(v=vs.110).aspx
@+
Christophe
Modifié en dernier par BB22210 le 15 juil. 2017 12:56, modifié 2 fois.
Guignol et ficelle de préférence ...

FloBarr
Messages : 20
Enregistré le : 15 juil. 2011 11:15

Re: pupitre CC72000

Messagepar FloBarr » 09 juil. 2017 15:56

sncf68 a écrit :Salut !

L'idée est intéressante, juste une précisons : sous quelle forme veux-tu afficher les données dans la fenêtre ? Avec des jauges comme sur l'écran du jeu actuellement ?


L'idée est de faire afficher sous forme numérique, ce qui permettrait de ne plus interpréter, mais de lire réellement une valeur. De plus, cette lecture se faisant en utilisant le handle de la zone ne demanderait que très peu de ressources, et pourrait être actif a n'importe quel moment (n'importe quelle vue) contrairement à la vue cabine.

sncf68 a écrit :Le problème d'une modification d'Open Rails c'est qu'elle devra être effectuée à chaque nouvelle version du jeu.. Mais si tu arrive à faire quelque chose de propre je pense qu'il est possible de la soumettre au créateurs du jeu, qui pourront l'ajouter à la version "officielle".

On en est pas là! Et cette modif étant prévue pour un simu, il n'est pas question de mettre a jour OR a chaque release. Ca simplifiera un peu de ce coté!

sncf68 a écrit :Mais si tu te lance dans la modif d'OR, pourquoi ne pas coder directement l'ouverture d'une liaison série, pour qu'OR puisse envoyer les données directement à une carte arduino, sous forme d'une trame normalisée à définir ? A voir éventuellement : https://msdn.microsoft.com/fr-fr/librar ... t(v=vs.110).aspx

Je souhaite avoir un programme d'interface intercalé entre l'arduino et OR. De ce fait, la liaison série est inutile. Par ailleurs, le faire de parser la fenetre permet d'avoir un systeme ou OR n'a rien a faire, si ce n'est mettre a jour ladite fenetre: pas de liaison à établir ou quoi que ce soit d'autre.

C'est une idée a gratter, et je continue, mais je butte sur mes connaissances de visual studio plus que sur la technique en elle meme!

Flo

Avatar du membre
Groquik
Messages : 93
Enregistré le : 15 nov. 2005 1:20
Contact :

Re: pupitre CC72000

Messagepar Groquik » 09 juil. 2017 16:27

Bonjour Florian

Je te conseille de te renseigner sur les webservices et le protocole SOAP.
Les données sont transmises entre deux applications sous un format XML par des requêtes HTTP.
Les deux applis peuvent être écrites dans des langages différents et tourner sur la même machine, ou bien communiquer par le réseau.
Ce n'est à priori pas ce qui est le plus approprié pour transmettre des infos en temps réel. Mais compte tenu du peu d'informations à passer, ça peut très raisonnablement tourner à plus de 10 appels par seconde. Ça me parait de toute façon nettement moins gourmand que de passer par une fenêtre graphique et de la reconnaissance.
Je viens de voir ça en Java, et à priori, c'est assez simple à coder en C#. La bibliothèque .Net fournit tout ce qu'il faut.

Quant à implanter ça dans OR, je suis encore à la recherche du moyen. De plus, OR prévoit des fonctions multi-joueurs, donc c'est peut-être déjà dans le code source.


Retourner vers « ORTS: Vos projets »