Bloques frenada aislar uno o dos raíles

Tengo una duda sobre el tema de los bloques de detención y frenada.
He realizado el montaje electrónico para que detecte el paso de una composición por consumo aislando un tramo solo en uno de los dos raíles, y funciona con el JMRI.
El tema que voy es que viendo vídeos aíslan los dos raíles, no se si realmente es para controlar la frenada de la composición.
Me podéis aclara este tema, muchas gracias.
Un saludo.

Para el control por software, los bloques de "detección" y "frenada" solo es necesario aislar UN carril. El frenado por software lo que hace es generar una orden de frenado para el decoder de una locomotora determinada y los cortes del carril NO son realmente para el frenado sino para los sensores de ocupación y permitirle al software saber donde esta la locomotora y si ha entrado o no en la zona de frenado.


Otra cosa es que se utilicen "modiolos de frenada" que NO funcionan por software sino que detienen el tren en función de alguna condición como un semáforo en rojo. Estos módulos SI que requieren aislar los dos carriles en ambos extremos, dado que estos generan una orden de frenada "universal" que afecta a todos los decoders y, por tanto, si estuvieran conectados al resto del circuito en el momento que actuasen pararían cualquier locomotora en cualquier parte del circuito.

En general solo es necesario aislar los dos carriles en el caso de usar estos módulos de frenado o entre secciones del circuito alimentadas por boosters diferentes.

Depende del tipo de gestores de frenada que uses.

Con els sistema ABC de LENZ, por ejemplo, con cortar un carril es suficiente.

Muchas gracias.
La idea sería con el sofw. JMRI controlar la frenada, no lo tengo seguro, y si no se puede sería como has comentado Fantito con el sistema de ABC, por evitar añadir mas electrónica.
Gracias, saludos

Fantito escribió:

Depende del tipo de gestores de frenada que uses.

Con els sistema ABC de LENZ, por ejemplo, con cortar un carril es suficiente.

El ABC de Lenz no es un módulo de frenada como tal, lo que hace es introducir una asimetría en la señal digital y no dar una orden de frenada "universal" por eso el sistema ABC (o los sistemas ABC autoconstruidos) requieren que los decoders soporten el sistema y reconozcan la asimetría de la señal como orden de frenada.

Por eso hablo del "Sistema ABC de LENZ" no del "Gestor de Frenada de LENZ"!!!!

Si los decoders soportan el sistema ABC.
Con el sistema (es la z21f) que tengo montado, por soft lo veo difícil, ya que el detector envía solo una señal a un arduino y este comunica al PC por puerto USB que hay algo, pero el programa no tiene información de la composición que ha activado el sensor.
Probaré con los diodos haber que tal, los cuales estén funcionando solo cuando realmente quiera detener una composición.
Saludos.

Es que si no tienes un detector RailCom, este no informará al programa de que tren se trata, y aún así, siempre tienes que definir en el programa qué tren es el detectado.
En JMRI (y en la mayoría de programas de gestión de maquetas) primero tienes que elaborar la lista de trenes que tienes con sus características (longitud, curva de velocidad, velocidad máxima etc...) y cuando el JMRI muestre una detección le tienes que informar cual de los trenes de la lista es el que está detectando y así el programa actuará según sus características.

Si haces un Block System por Acantonamiento gestionado por software, los sistemas y gestores de frenada son completamente prescindibles, por no decir que son incompatibles.

Muchas gracias Fantito por aclararme mas el tema.
Intentaré trabajar sobre esta linea, ya que los decoders que tengo instalado tienen esta opción del RailCom y ver si no me doy contra la pared.
Le tendré que enviar unas capsulas de cafe

Cuidado con Railcom. Para que funcione no basta con que los decos de las máquinas tengan esa capacidad, también los retroselalizadores deben ser capaces de soportar el protocolo y trasladar la información a la central y la mayoría de los comercializados no lo hacen. Además el software debe también de estar capacitado para usar la información Railcom para la gestión y no todos lo hacen (creo que JMRI se puede habilitar para ello pero no te lo puedo asegurar).

De hecho y a pesar de que ya lleva unos años de evolución, el Railcom no parece haber "calado" mucho y conozco poca gente que realmente lo use para la gestion de su maqueta.

La mayoría solemos continuar con el control "predictivo" por software, que funciona de forma bastante satisfactoria aunque requiere el trabajo adicional de "fichar" el material en el programa.
Te aconsejaría de que antes de hacer nada, te estudies bien como funciona el software que vayas a elegir, e incluso que te mires varios, para evitar sorpresas...

De momento el RailCom solo permite saber cuatro informaciones: La dirección del la locomotora (CV1, CV17 y CV18), La "velocidad" relativa (diferencia entre el valor de la CV5 con el valor del regulador del mando), La "carga" relativa del motor (la diferencia entre la frecuencia del giro del motor sobre la frecuencia PWM emitida por el decoder) y la información guardada en las CV 105 y 106 (el nombre de la locomotora por ejemplo. Es el caso de las locomotoras com Mfx). Con estos datos es imposible saber la información necesaria para establecer un Block System.
Lo que si que hay programas, como el JMRI, que ante esta información (por ejemplo: si la locomotora pasa por el punto de lectura del RailCom a una velocidad superior a la esperada, el programa reduce la velocidad) activa una orden u otra. O bién cuando el detector RailCom detecta un número concreto de locomotora la identifica con la base de datos que tenemos i usa esa información.

Para establecer un Block System necesitamos saber más datos de los que por ahora nos ofrece el RailCom, por eso hay que hacer previamente una base de datos con los detalles de cada tren.

Otro problema que presenta el RailCom es que para que sea leída la información emitida por el decoder con RailCom hay que establecer lo que se llama Cut Out, es decir que mientras se lee la información del Rail Com, el resto de los aparatos se quedan sin recibir a información necesaria. En este punto se han detectado problemas con aparatos conectados en la red LocoNet mientras se establece el Cut Out.

Muchas gracias de nuevo por toda esta información.
Por lo menos el tema de los raíles no los tengo que modificar, y ya es empezar a realizar pruebas con lo que has comentado, y en el peor de los casos haría el montaje de los diodos para realizar la frenada.
Y si da problema el tema del RailCom, pues a lo mejor utilizarlos en casos muy particulares como a la entrada de la estación o por pasos de los desvíos y evitar mucho su uso.
Lo dicho genial.
Saludos

Pablob escribió:

... si da problema el tema del RailCom, pues a lo mejor utilizarlos en casos muy particulares como a la entrada de la estación o por pasos de los desvíos y evitar mucho su uso...

Los problemas con el RailCom y en particular los derivados del CutOut no dependen de usarlo mucho o poco ni en sitios puntuales. Aparecen cuando se activa, aunque solo lo utilices en un punto. Por cierto también se han visto problemas con decos de sonido, que se reinician inopinadamente y en algunos casos decos no preparados para RailCom presentan mal funcionamiento al activar este y no solo con LocoNet.

Tendré en cuenta toda esta información.
Muchas gracias, saludos