Posibilidades de un espía S88 que actúa en XpressNet

Hemos conseguido espiar el bus S88 para que cuando un cantón aparezca "ocupado" se ordene a la central por Xpressnet cierto cambio de una serie de accesorios (señales, desvíos) o incluso la variación de velocidad de alguna locomotora.

Esto abre las puertas de la automatización a pequeña escala de maquetas sin necesidad de un ordenador y un software específico (RocRail, JMRI, iTrain etc), pero con la limitación de que los cambios deben estar programados y siempre serán igual: cuando el cantón X esté ocupado, que ocurra Y; cuando no esté ocupado, que ocurra Z. Y así.

La pregunta es ¿qué utilidad práctica se le puede dar a esto? ¿Hacia dónde merece la pena enfocarlo?
Gracias.

Estoy deseando ver cómo funciona eso.

Bueno, se me ocurre la gestión de cantones de forma independiente, o el cerrar la señal de salida de u na estación al salir el tren, por ejemplo

Un saludo

Hola
La ignorancia es muy atrevida, y desde esa ignorancia, me atrevo a comentar.
La pregunta es ¿Cuando se detecta un evento en el Bus S88, solo se detecta el cambio en un sensor?
Si es en un sensor, eso conlleva el cambio en un bloque, pero al ser un sensor, de facto obtienes una posición más precisa que un bloque, canton, y eso puede mejorar la toma de decisiones, o elegir que acciones tomar.
Eso es muy pobre, pero válido para los bloques de paso, y con eso se puede descargar de tarea el programa que se use para la gestión de la maqueta.
Pero creo, que después de este paso inicial, después se querra ampliar su "radio de acción", es decir mejorar sus prestaciones, eso conllevaría el uso de más datos para poder mejorar la toma de decisiones, lo que creo que nos lleva a terminar en un programa tipo (RocRail, JMRI, iTrain etc).
Por lo que el resultado es estupendo, pero pienso, por supuesto erroneamanente seguro, que es el núcleo de la resolución de un problema, que creo que está resuelto con (RocRail, JMRI, iTrain etc).
La toma de decisiones en cualquiera de estos programas (RocRail, JMRI, iTrain etc), supongo que están basados en la captura de los eventos que genera el S88, y similares.

Pero vuelvo al punto inicial de este aporte, hablar desde la ignorancia, y solo con un poquito de conocimiento de la labor de programación, pero por supuesto es una gran satisfacción el poder obtener resultados de este tipo.

Felices fiestas.

Antarjcor

Pues parece interesante, abre la puerta a un acantonamiento digital autónomo, sin necesidad de software adicional. Es evidente que el sistema es limitado pues no permitiría por lo que dices rutas alternativas y similares pero lo veo útil a la hora de, por ejemplo, "desatender" la circulación de los trenes por la maqueta, manteniendo el control manual en las estaciones, de forma parecida a como lo haríamos en analógico. De hecho para mi, que no busco una circulación completamente automatizada y que uso el software como "supervisor de seguridad" siempre me ha parecido matar moscas a cañonazos el usar un software complejo para mantener un simple acantonamiento. Espero que vayas dando mas detalles pues es interesante el tema y aunque yo no uso S88, sino LocoNet supongo que no seria complicado extrapolar el sistema para dicho bus.

EL OBJETIVO PRINCIPAL:

Pocas veces consigo anticipar las visitas de terceros a mi maqueta. Por lo general me pillan desprevenido: el ordenador portátil, si está presente, no estará encendido ni con RocRail ya dispuesto para ir reproduciendo las locuciones, controlando las agujas y modificando las señales según van moviendo los trenes mis invitados.

Por el contrario, la "mini exhibición" arranca con la maqueta como estaba del día anterior y, a lo sumo, le enciendo las luces y señales para que el invitado las vea. Luego empiezo a mover un tren cualquiera y siempre, inevitablemente, surge la pregunta ante el primer "rojo" rebasado:
– ¿Y los "semáforos" no cambian?
– No –debo decir con tono de disculpa que me duele por dentro–. Si el ordenador no está conectado a la maqueta todo es manual.
– ¡Ah! Creía que eran automáticos...
Y ahí ya me quedo chafado

Esto es lo que pretendemos solucionar: queremos que siempre haya un circuito –el visitante no sabrá que solo será uno– en el que cada nueva ocupación pueda dar lugar al oportuno cambio de señal, desvío o ambos, y así haya un recorrido automatizado aunque la maqueta se acabe de encender y no haya ordenador. Creemos que es posible hacerlo.


EL ACANTONAMIENTO AUTOMÁTICO:

Evitar que un tren alcance a otro con este sistema no parece viable porque todas las respuestas a los cambios de ocupación han de estar pre-grabadas en el código, luego ¿cómo decir al nuevo aparato qué trenes tiene que parar de entre todos los que pueden circular?

Tampoco vemos cómo forzar que un tren (desconocido) se pare ante una señal que está roja. Se podría habilitar quizá una zona de frenado ABC conmutada (que aparezca y desaparezca) por el nuevo invento, pero eso es mucho cableado si hay mucha señal...

hola,

Esto es lo que pretendemos solucionar: queremos que siempre haya un circuito –el visitante no sabrá que solo será uno– en el que cada nueva ocupación pueda dar lugar al oportuno cambio de señal, desvío o ambos, y así haya un recorrido automatizado aunque la maqueta se acabe de encender y no haya ordenador. Creemos que es posible hacerlo.

Sí que es posible hacerlo, lo que es más factible es el disparo de rutas al estilo como lo hace la ECoS, que cuando se active un sensor posicione los desvíos y señales o un control de un tren lanzadera, automatizaciones relativamente sencillas que dan ambiente a la maqueta y al alcance de la mayoría de programadores de Arduino.

Yo por mi parte llevo trabajando un tiempo en un autómata para Xpressnet. Ahora estoy con los test con diferentes centrales.

En mi caso escucho el bus Xpressnet ya que la central comunica por el bus las ocupaciones en la retroseñalización y los cambios en los accesorios (desvíos y señales).

Mi idea es tener un módulo simple que cuando se enchufe al bus Xpressnet ejecute acciones sobre las salidas (desvíos, señales y locomotoras) según unas reglas definidas por el usuario al estilo de los PLC (autómatas programables) en función del estado de las entradas (retroseñalización y accesorios). Este AutomataXpressNet lo conectaríamos temporalmente al ordenador para cambiar o añadir nuevas reglas.

Si quieres echarle un vistazo, puedes verlo aquí:

https://usuaris.tinet.cat/fmco/beta_sp.html#automata

La pregunta es ¿qué utilidad práctica se le puede dar a esto? ¿Hacia dónde merece la pena enfocarlo?

Depende de cómo proporciones los datos y del público al que va dirigido.

Si es para un público objetivo que tiene algunos conocimientos de la programación en Arduino lo primero que se me ocurre es que hagas una librería EspiaBusS88.h que incluya una función callback cambioSensorS88 (int sensor, int estado) donde informas del sensor que ha cambiado por lo que el programador podrá decidir que ordenes enviar por Xpressnet.

Si tu público objetivo es un usuario sin conocimientos de programación Arduino pero que quiera automatizar mínimamente su maqueta digital entonces deberás proporcionarle alguna herramienta o pasos simples para que pueda llevarlo a cabo. Por ejemplo, como ha hecho Jindra Fucik con su XRobot ( http://www.fucik.name/masinky/robot/ ) que permite que el usuario programe condiciones y acciones de forma gráfica y sencilla o como mi AutomataXpressNet que lo hace creando reglas en lenguaje natural.

Si es para ti, puedes hacerlo personalizado para tu maqueta, tienes conocimientos de programación de sobra para realizarlo.

saludos,

Paco

Hola Paco!

Me ha hecho mucha ilusión ver que hemos coincidido más o menos en un proyecto nuevo. Solo he leído una vez la información que has ofrecido sobre el AutómataXpressNet y quizá la pregunta sea por ello apresurada, pero es que sin resolver esta duda no consigo avanzar:

fmco escribió:

En mi caso escucho el bus Xpressnet ya que la central comunica por el bus las ocupaciones en la retroseñalización y los cambios en los accesorios (desvíos y señales).

De esto ya me informaste hace unos 7 años a través del foro CTMS pero veo que me hace falta alguna aclaración más: sé que se le puede preguntar a la central por el estado de los sensores de ocupación pero ¿cómo sabe la central de dicho estado? Creo que la tuya (NanoX-S88) lo tiene fácil por razones evidentes pero ¿y la Multimaus de Roco? Recuerdo que me explicaste que hay retromódulos para XpressNet de Roco que "hablan mal" el protocolo pero que una interface (Rocomotion ref.10787) sí entiende su jerga (lo del XOR final "mal" calculado), y así puede informar al PC etc. Pero que eso no significaba que la central Multimaus se enterase de las ocupaciones, sino todo lo contrario: nunca podrá hacerlo. ¿Esto sigue siendo así?

Como yo uso la Multimaus (más tu magnífica GenLi-S88) me temo que no me queda más remedio que espiar el S88 porque preguntar a la central por las ocupaciones no tiene sentido. ¿Estoy equivocado?

Muchas gracias por tu paciencia!

hola,

En Xpressnet tu puedes preguntar por la información de retroseñalización de un módulo y la central te informa de su estado y el tipo que es:

-Decodificador de accesorios sin retroseñalización
-Decodificador de accesorios con retroseñalización (como el Lenz LS100)
-Módulo de retroseñalización (como el LR101 o el RS8)

De igual forma cuando se produce un cambio (en un desvío o una entrada de retroseñalización), es la central que envía a todos los dispositivos conectados al bus esa misma información referida al módulo que ha cambiado.

En Lenz LZV100, NanoX-S88 y Digikeijs DR5000 es así, (con la DR5000 solo lo he probado con retroseñalización RS me falta probarlo con los otros buses S88, Loconet, XN+FB) porque tienen un bus de retroseñalización (RS, S88, etc.)

El MultiMaus sólo (conectado a la caja negra que es el booster) no tiene bus de retroseñalización por lo que te informa de que todos son decodificadores de accesorios sin retroseñalización (lo que comúnmente llamamos desvíos)

El truco de Roco para tener retroseñalización en el Multimaus y conectarlo al ordenador fue crear un interfaz Rocomotion que generaba un bus de retroseñalización para sus retromódulos 10787 e informaba al ordenador pero sin pasar por la central, por tanto cuando le preguntas a la central sigue sin saber nada de los retromódulos.

Es el mismo sistema que hice yo con el GenLI-S88, la diferencia es que yo genero un bus S88 y le paso los datos de ocupación directamente al ordenador y Rocomotion lo hace conectando los 10787 al bus Xpressnet y generando una serie de respuestas especiales que solo entiende él y los 10787, mientras que la central no se entera.

Como tu preguntas a la central por Xpressnet y la central Multimaus no sabe nada tanto en un caso como otro, pues te responde pensando que quieres información de desvíos.

La Z21 tiene bus de retroseñalización pero no sé si pasa esta información al bus Xpressnet ya que no dispongo de ella, pero me temo que no lo haga ya que su protocolo es diferente y orientado a la conexión por red.

Como habrás deducido con el AutomataXpressNet las automatizaciones con el Multimaus son limitadas al no poder usar información de los contactos.



Soluciones para Multimaus + GenLI-S88

- La que tu has pensado, espiar el bus S88 e informarte de cambios en desvíos por Xpressnet y mandar órdenes por Xpressnet según la retroinformación.
- Ya que tienes toda la información junta en el puerto serie de GenLI-S88, que el Arduino haga de PC. Mandas órdenes y te informas por el puerto serie.
- Instalar rocrail en una Raspberry Pi (creo que incluso funciona con una Raspberry Pi ZeroW que vale en torno a los 18€, yo lo instalé en una Pi 3B+ en torno a 50€) que arranque automáticamente y tengas una versión simplificada, o no, de tu maqueta.


saludos,

Paco

Pues hemos considerado todas tus recomendaciones, Paco, y al final hemos optado por la primera, que desde esta tarde ya hemos visto funcionar: "...espiar el bus S88 .... y mandar órdenes por Xpressnet según la retroinformación..." Nos hemos llevado gran alegría porque con un ESP8266 ha sido posible hacerlo bien.

El objetivo será, al menos, automatizar un recorrido por una maqueta con S88: según va avanzando el tren irán conmutando las señales rojo/verde y cambiando los desvíos. Incluso podría controlarse automáticamente la locomotora, aunque esto último me hace menos gracia: soy demasiado juguetón como para delegar esa función!

hola,

Me alegro de que tu proyecto vaya avanzando

Una pregunta, el puerto serie del ESP8266 no trabaja con los 9 bits que necesita el Xpressnet, has utilizado la librería SoftwareSerial en su lugar? funciona bien?

saludos,

Paco

No se trata exactamente de esa librería sino de una adaptación que encontramos en internet que permite justamente crear conexiones 9N1: es la RS485SoftwareSerial.h de Peter Leroup, de 2017.

Gracias a ella no hemos ido avanzando "a ciegas" pues disponíamos del puerto serie USB del NodeMCU (ESP8266) para enterarnos de qué iba haciendo el micro con cada paso que dábamos al construir el programa, mientras el segundo puerto serie creado con esa librería interactuaba con el bus XpressNet.

Hemos usado una excelente tarjetita que hace de interface RS485 / TTL y no necesita más que dos pines (Rx y Tx), además de ser robusta, barata y supuestamente adecuada para un entorno industrial: la XY-017.

Las interrupciones quedaban también disponibles, así que leer la información directamente del S88 ("espiar") ha sido fácil. El programa hace como dices en tu web que hace tu GenLi-S88: solo es sensible / informa de los cambios de los sensores de ocupación.

Y para programar las acciones automáticas que desencadena la activación de cada sensor hemos implementado un sistema inspirado en tu curso de Arduino, que fui leyendo según lo ibas sacando en el foro CTMS.

Así que muchas gracias por toda tu ayuda, que ya ves que ha sido mucha!!

hola,

impresionante como lo tienes de avanzado el proyecto

No conocía esa librería RS485SoftwareSerial.h que me parece muy interesante, y más sabiendo que funciona

Me alegro de que mi pequeño cursillo sobre Arduino aplicado al modelismo ferroviario te haya sido útil. Tengo intención de añadir algún capitulo más al libro así que ves echándole un vistazo de tanto en tanto.

saludos,

Paco

Por fin puedo confirmar que este proyecto, que empezó hace dos años, está dando sus frutos. Ha habido cambios importantes pero el AUTOMÁTOR ya es una realidad

Resumo brevemente lo más importante:

1. Abandonados los micros ESP en favor del AVR328P que llevan los Arduinos Uno y Nano. Me cansé de sufrir pequeñas "traiciones" de los primeros que nunca parecían hacer exactamente lo que yo esperaba y llegué a pensar como que "tienen vida propia". Torpe que es uno, y que ya hacía falta ver resultados. Con el AVR y la experiencia que me han dado otros proyectos ha sido facilísimo.

2. El tren limpiavías recorre perfectamente mi maqueta, respetando señales, parando en las estaciones, esperando a las luces verdes, dejando atrás las que enseguida cambian a rojo, siempre con las agujas preparadas para el itinerario a recorrer. Muy efectivo, visual y... precioso, la verdad.

3. Si se saca la locomotora del limpiavías de la maqueta y en su lugar se pone otra controlada manualmente, el operador humano debe conseguir recorrer el itinerario que se le impone siguiendo la indicación de las señales, que pasan de rojo a verde, y vuelven al rojo, exactamente cuando corresponde si el maquinista lo hace bien. ¿Y si se salta el rojo? Pues mal hecho, pero evidentemente no pasa nada... de momento. Lo siguiente será extender el frenado ABC a toda la maqueta (¡ay, qué pereza!)


Como he hecho en otras ocasiones, regalo el software a quien haga / contribuya a crear un tutorial para que esto le sirva a más gente.