a finales de diciembre nos reunimos JM, Salus y servidora en casa de la primera parte contratante. El objetivo era realizar unas pruebas con TC9 y Railcom para comprobar como se integraba Railcom en la lógica de TC.
De manera mas concreta:
Objetivo:
Ver como TC recibe y trata los datos Railcom, combinados o no con RS, para ciertas funcionalidades de TC.
Funcionalidades de estudio:
1 - Visualización del ID de una máquina en el bloque de TC.
2 - Visualización de mas de un ID de máquina en un mismo bloque de TC.
3 - Concepto de ocupación de TC actuando con Railcom solamente.
4 - Ver el comportamiento de TC con Railcom para la Regla "Limited Aberration Protection (LAP)". (esta regla se encarga de parar un tren si TC supone que ha entrado en un bloque diferente al previsto).
Caso práctico de aplicación:
Imaginemos un haz de vías en una estación. Con vías (bloques) ocupados y vías (bloques) libres.
En caso de que un desvío de entrada falle mecánicamente, queremos averiguar que pasaría si un tren entrase en una vía ya ocupada con la regla "LAP" activada y Railcom en funcionamiento.
Utilizando solamente RS u otro sistema retro de ocupación por consumo, el tren entrante en vía erronea no sería detectado dado que el indicador de ocupación ya estaría activado por el tren estacionado en el bloque. Se produciría inevitablemente una colisión. (En mi caso, en escala 0, es una situación especialmente grave y costosa...).
Maqueta de prueba:
Esquema lógico de la electrónica utilizada:
A - Modelo centrado en una central Digikeijs DR-5000 (última versión).
B - Modelo distribuido entre una central Lenz LZV100 para RS y una Digikeijs DR-5000 para Railcom.
Resultados:
1 - Visualización del ID de una máquina en el bloque de TC.
En el modelo A se visualiza correctamente el número de IDentificación (ID) Railcom de la máquina en el bloque.
En el caso B no conseguimos visualización.
2 - Visualización de mas de un ID de máquina en un mismo bloque de TC.
En el modelo A no se visualiza correctamente el ID de la 1a. loco. Luego, al entrar la 2a. loco se visualiza esta. Al salir la última se vuelve a visualizar el de la 1a.
En el modelo B no conseguimos ninguna visualización.
3 - Concepto de ocupación de TC actuando con Railcom solamente.
Era importante comprobar como trata TC9 la detección de un tren con Railcom solamente. Pues bien, en ambos casos, TC9 no da ocupación por detección de Railcom. La ocupación solo se produce si hay consumo o impulso. Es decir la ocupación de bloque viene dada por el indicador de ocupación asignado al bloque y no por el Railcom asignado.
4 - Ver el comportamiento de TC con Railcom para la Regla "Limited Aberration Protection (LAP)"
En el modelo A la regla LAP se activa con la detección Railcom. A efectos prácticos ello significa que un tren será detectado cuando entre en un bloque ya ocupado. La regla LAP provocará su parada inmediata y por lo tanto se evitará el choque de ambos trenes.
En el modelo B, como era de esperar, no detección y choque.
Conclusiones:
1. Tras varias horas de prueba solo hemos sido capaces de activar Railcom en un entorno homogeneo de electrónica Digi. La combinación Digi/Lenz no ha funcionado.
2. TC9, trata la ocupación de bloques solamente a través de los Indicadores de consumo (o impulso) que ya conocemos. No trata la identificación para activar la ocupación de bloques.
3. TC9 solo es capaz de mostrar el código ID de una loco a la vez aunque haya varias en el bloque. En cambio por ocupación si que es capaz de mostrar los pictogramas de todas las locos que, según la lógica de ocupación, crea que están en el bloque.
4. TC utiliza la detección mediante Railcom para aplicar la regla LAP en sus schedules y así puede evitar de forma efectiva posibles choques.
Salut,
y tener todo el tiempo disponible para pruebas