Detector para crear cantón

Buenos días.

Me estoy planteando una pregunta a cerca de la creación de cantones. Estoy viendo que tanto Digikeijs como Roco, tienen los tradicionales detectores de presencia por consumo por Loconet DR4088LN y Roco Detector. En este tipo de detectores es necesario hacer dos subdivisiones en el cantón (detección y frenada) para cantones unidireccionales y tres subdivisiones en cantones bidireccionales.

Pero estoy viendo que también han sacado detectores de consumo por Railcom DR5088RC y Roco Detector (Railcom). El sistema Railcom por lo que estoy leyendo, a diferencia del Loconet es bidireccional, la información va de el decoder a la locomotora y de la locomotora al decoder ( por decirlo coloquialmente), mientras que Loconet es unidireccional, solo va del decoder a la locomotora.

Mi pregunta y duda es si usamos detectores con sistema Railcom, estos al enviar a la central información de consumo, dirección de la locomotora y velocidad instantánea, con estos tres parámetros, a la hora de hacer un cantón, no sería necesario hacer subdivisiones, si no que se podría poner un único detector indicando la longitud exacta del cantón y con los tres parámetros que puede leer la central de la locomotora que esta ocupando el cantón, puede tomar la decisión de detener el tren al final de éste, sin la necesidad de tener que crear una parte de detección, circulación y frenada. Simplificando la construcción de la maqueta y pudiendo ahorrar en la compra de detectores y no tener que tener tanto cableado en la maqueta.

No se si el tema de la digitalización de maquetas va por este camino, claro esta que los programas como Rocrail o Itrain, tienen que estar programados para poder soportar estas funciones.

Hola.

Veo que te estás liando entre los distintos buses o líneas de comunicación.

La conexión DCC es un protocolo entre la central y los decoders, bien de locomotoras, bien de accesorios y es unidireccional (de forma tradicional) esto es, la central envía órdenes a las locomotoras pero no recibe información de ellas.
El sistema Railcom lo que hace es que genera unos "huecos" (cutouts) en la señal DCC que los decoders que implementan Railcom detectan y aprovechan para enviar información de vuelta a los carriles.

Un detector Railcom lo que hace es que está a la espera de esos "huecos" y mira si un decoder ha puesto información.

Por otra parte, LocoNET es un protocolo entre mandos y central, y se puede utilizar para muchas cosas, en particular para señalizar temas como la ocupación de sectores y en el caso del DR5088RC para enviar por LocoNET la información Railcom que un decoder ponga en uno de sus sectores.

Tradicionalmente, los detectores de ocupación por protocolo S88 lo que hacen es que hablan con un ordenador (o con una central) a través de un tercer bus, que también es unidireccional.

El protocolo LocoNET no sólo es bidireccional, es igual-a-igual (peer to peer) lo que quiere decir que un elemento como el DR5088RC puede emitir mensajes que será interpretados o no por otros elementos que estén en la misma red.

Por ponerte un ejemplo, yo tengo un dispositivo hecho con arduino que está pendiente que algún mando (los mandos incluídos en algunas centrales como la Intellibox II siguen siendo mandos) envíe la señal de [STOP] para de forma inmediata enviar una señal de [START] a fín de que en los encuentros modulares se deje sin funcionar dicha tecla de [STOP], este dispositivo no depende para nada de la central.

En el caso del dispositivo DR5088RC tienes 16 sectores en los que además se está pendiente de la señal Railcom, así, por la LocoNET circulas las tramas que indican que un sector determinado pasa a estar ocupado, pasa a estar libre o tiene tal información de Railcom (sólo si el sector está ocupado, claro)

Esta información puede ser utilizada luego por otro dispositivo, que puede ser un simple display, un TCO independiente o un programa del tipo RocRAIL para aquello que desees según su programación.

Por otra parte, no te recomiendo eliminar sectores de los cantones, sigue poniendo dos para los unidireccionales y tres para los bidireccionales, ten en cuenta que no todos los decoders emiten Railcom y los que lo hacen, no todos emiten la información que pones.

El DR5088RC aún no lo he probado con la última versión, pero con la versión que lo he probado sólo emite la CV1 y además de sólo una locomotora en el sector, si tienes dos locomotoras no separa las señales y no recibes nada.

Un saludo.

Me temo wue por el momento eso no sea posible. En el caso de itrain, por ejemplo, railcom permute "ver" la locomotora que ocupa un canton, pero el programa no utiliza el dato para la gestion, con lo que, al menos pir el momento es mas "adorno" que otra cosa.
De todas formas (y con tidos los reparos) es perfectamente posible controlar con un solo detector por canton, por medio de detectores "virtuales" disponibles en todos los softwares (aunque con distintos nombres). Claro que se requiere afinar muy bien los perfiles de velocidad de cada maquina y dejar la aceleracion y el frenado a cargo del software y no del deco y, aun con todo el trabajo del mundo, puede ser inexacto, por lo que sigue siendo preferible el colicar 2 o 3 detectores por canton.
Si que existe un "sistema" que orescinde de cortes y detectores en via, se trata de "Games on track". Este se basa en un posicionamiento tipo gps. Las locomotoras llevan unos receptores/emisores y, en alto, sobre la maqueta se colocan los "satelites" que como en el gps triangulan las posiciones y localizan las locomotoras, individualmente sobre el trazado. El sistema es muy preciso para la localizacion y de hecho, ni siquiera tenemos que introducir el plano de la maqueta: basta con hacer circular una locomotora por todo el trazado para que el sistema vaya haciendo el plano solo.

El Matao escribió:

Hola.

Veo que te estás liando entre los distintos buses o líneas de comunicación.

La conexión DCC es un protocolo entre la central y los decoders, bien de locomotoras, bien de accesorios y es unidireccional (de forma tradicional) esto es, la central envía órdenes a las locomotoras pero no recibe información de ellas.
El sistema Railcom lo que hace es que genera unos "huecos" (cutouts) en la señal DCC que los decoders que implementan Railcom detectan y aprovechan para enviar información de vuelta a los carriles.

Un detector Railcom lo que hace es que está a la espera de esos "huecos" y mira si un decoder ha puesto información.

Por otra parte, LocoNET es un protocolo entre mandos y central, y se puede utilizar para muchas cosas, en particular para señalizar temas como la ocupación de sectores y en el caso del DR5088RC para enviar por LocoNET la información Railcom que un decoder ponga en uno de sus sectores.

Tradicionalmente, los detectores de ocupación por protocolo S88 lo que hacen es que hablan con un ordenador (o con una central) a través de un tercer bus, que también es unidireccional.

El protocolo LocoNET no sólo es bidireccional, es igual-a-igual (peer to peer) lo que quiere decir que un elemento como el DR5088RC puede emitir mensajes que será interpretados o no por otros elementos que estén en la misma red.

Por ponerte un ejemplo, yo tengo un dispositivo hecho con arduino que está pendiente que algún mando (los mandos incluídos en algunas centrales como la Intellibox II siguen siendo mandos) envíe la señal de [STOP] para de forma inmediata enviar una señal de [START] a fín de que en los encuentros modulares se deje sin funcionar dicha tecla de [STOP], este dispositivo no depende para nada de la central.

En el caso del dispositivo DR5088RC tienes 16 sectores en los que además se está pendiente de la señal Railcom, así, por la LocoNET circulas las tramas que indican que un sector determinado pasa a estar ocupado, pasa a estar libre o tiene tal información de Railcom (sólo si el sector está ocupado, claro)

Esta información puede ser utilizada luego por otro dispositivo, que puede ser un simple display, un TCO independiente o un programa del tipo RocRAIL para aquello que desees según su programación.

Por otra parte, no te recomiendo eliminar sectores de los cantones, sigue poniendo dos para los unidireccionales y tres para los bidireccionales, ten en cuenta que no todos los decoders emiten Railcom y los que lo hacen, no todos emiten la información que pones.

El DR5088RC aún no lo he probado con la última versión, pero con la versión que lo he probado sólo emite la CV1 y además de sólo una locomotora en el sector, si tienes dos locomotoras no separa las señales y no recibes nada.

Un saludo.

Gracias por aclararme los conceptos que por lo que veo tenía equivocados. Al ver en Digikeijs los módulos DR4088LN y DR5088RC y ver que el segundo valía casi el doble empecé a investigar y llegue a la falsa conclusión que dije antes.

Por lo que veo, no hay grandes diferencias en el funcionamiento final de ambos módulos por lo que no entiendo para que sirve el DR5088RC, incluso me he planteado sustituir los tres módulos DR4088LN que tengo instalados por el otro modelo.

Gracias también renfe276 por tu aclaración, lo de dejar un solo detector era por el tema de la lectura de velocidad y dirección que "hace" RailCom. La maqueta ya esta montada la parte de las vías y viendo el tema no merece la pena que por ahora me complique con cambios que probablemente no funcionen bien.

Un saludo.

Un saludo.

Hola.

El DR4088LN permite conectar una serie de DR4088 "esclavos" tras él, el DR5088RC no, pero sólo envía las tramas de "sector ocupado" o "sector liberado" por LocoNET

El DR5088RC además de las tramas de ocupación, es capaz de leer la información Railcom enviada por los trenes y pasarla a LocoNET.

Obviamente si no vas a hacer uso de la información Railcom, no te merece la pena el DR5088RC.

Un saludo.

renfe276 escribió:

Me temo wue por el momento eso no sea posible. En el caso de itrain, por ejemplo, railcom permute "ver" la locomotora que ocupa un canton, pero el programa no utiliza el dato para la gestion, con lo que, al menos pir el momento es mas "adorno" que otra cosa.
De todas formas (y con tidos los reparos) es perfectamente posible controlar con un solo detector por canton, por medio de detectores "virtuales" disponibles en todos los softwares (aunque con distintos nombres). Claro que se requiere afinar muy bien los perfiles de velocidad de cada maquina y dejar la aceleracion y el frenado a cargo del software y no del deco y, aun con todo el trabajo del mundo, puede ser inexacto, por lo que sigue siendo preferible el colicar 2 o 3 detectores por canton.
Si que existe un "sistema" que orescinde de cortes y detectores en via, se trata de "Games on track". Este se basa en un posicionamiento tipo gps. Las locomotoras llevan unos receptores/emisores y, en alto, sobre la maqueta se colocan los "satelites" que como en el gps triangulan las posiciones y localizan las locomotoras, individualmente sobre el trazado. El sistema es muy preciso para la localizacion y de hecho, ni siquiera tenemos que introducir el plano de la maqueta: basta con hacer circular una locomotora por todo el trazado para que el sistema vaya haciendo el plano solo.

Esto que comentas es tipo al sistema de Faller con el carsystem digital?
Si es así, estéticamente en las locomotoras/trenes daría el cantazo el emisor "gps"

Hola.

Exceptuando el "sistema tipo GPS" (que desconozco), ya sea para la detección de cantones, o para el Railcom, es necesario cortes en la vía, "sí o sí", como ocurre en el tren real, porque precisamente lo que se pretende es detectar lo que pasa en un tramo concreto, que necesariamente debe estar aislado del resto, porque sino, toda la maqueta en sí misma serían un único cantón.

Por cierto, el Railcom, al menos con Lenz y ESU, NO indica la velocidad a la que va la locomotora. Me llevé un gran chafón cuando estuve trabajando con el Railcom, hace ya algunos años. Te indica únicamente la dirección de la locomotora, y si la locomotora está siendo direccionada o no, nada más. Es bonito ver en un panel de CTC el número de tren/locomotora, y cómo se van enciendo los leds del CTC, a medida que el tren se va desplazando...

Un saludo.

DVorak.

Pues desconozco por completo como funciona el CarSystem Digital. Si que te puedo decir que Games on Track tiene un sistema para el control de Car System.

Con respecto al RailCom, los cortes en los carriles siguen siendo necesarios, puesto que la información que manda el decoder no incluye ningún tipo de "geolocalizacion" con loq ue el programa de control peude tener datos de la locomotora pero no de donde esta, para eso continua siendo necesario dividir la maqueta en cantones y cortar vias.
Teóricamente RailCom podría mejorar la gestión al indicar de forma directa al software que locomotora esta en determinado cantón y que este no tenga que asumir de forma presuntiva cual es la locomotora como se hace. Sin embargo no todo es tan bonito y probándolo me ha dado mas de un problema con los CoutsOut necesarios para el funcionamiento del sistema. He visto bastantes casos en los que problemas de control de una maqueta en principio inexplicables se solucionaban desabilitando el RailCom en la central (y reaparecían al activarlo que siempre hay que hacer la prueba inversa para estar seguro). Personalmente pienso que para obtener lo que se espera de RailCom seria necesario, realmente, rediseñar todo el protocolo DCC (y probablemente con nuevo hardware) para que fuera realmente bidireccional. De hecho y a pesar del tiempo que llevamos hablando de RailCom no hemos visto avances espectaculares...