Problema TC con cruce de vías

[osca22]

Estoy haciendo pruebas con el TC, después de muchos años de sequía. Me encuentro con un problema para evitar que colisionen los trenes que cruzan poro dicho cruce. Para el TC son dos vías independientes y obviamente las schedules no saben que al lanzar los trenes por cada vía, pueden colisionar ya que no se respeta el piquete de entrevías . ¿Cómo poner en una schedule que si la otra esté ocupada no puede hacer circular trenes por esa zona hasta que no se libere la otra vía? Seguramente será una tontería por desconocimiento. Espero haberme explicado bien. Gracias de antemano

[xaviermbcn]

Buenas Jose Luis,

cuando puedas pon en tu firma la versión de TC que utilizas. Así podemos adecuar la respuesta.
Lo que yo haría es:
1. Aislar los carriles K del cruce.
2. Alimentar las K del cruce mediante un retroseñalizador.
3. Incluir el Indicador en el TC.
4. Asociar el indicador al cruce.

De esta forma toda ruta que pase por el cruce bloqueará el resto de rutas que intenten pasar.

Además me aseguraría de que, en las Schedules, no permitas Reservar las rutas ocupadas.
Y para acabar, si no tienes detección, por lo menos, en final de convoy, usa la opción de liberar el bloque en el paro del bloque siguiente.

Salut!

[osca22]

La versión es TC7 GOLD. Las detecciones son S88 por consumo. Adjunto el circuito TC para que lo mires. Creo que será lo mejor para analizar mi ineptitud

[xaviermbcn]

Jose Luis,

TC7, olvida lo que te he dicho. No puedes poner un indicador en el cruce. Pensaba que era un doble cruce desvío...

Acabo de probar tu circuito. Concretamente las schedules "Bloque 1 al Bloque 9" y "Bloque 3 al Bloque 4" y funciona perfectamente con el simulador.

A ti cuando te falla concretamente ? Con que schedules? En Simulador o en real?

imatge.png (88.41 KiB) Visto 103 veces

Salut!

[osca22]

En real. El problema es que para el tc son dos vías independientes. Y en algún momento las máquinas chocan. Se me ocurre la posibilidad que nos e como de crear una regla de si bloque x está ocupado, no ocupar bloque y.
Falla al lanzar las schedules.

[RhB]

Hola. Me da miedo preguntar porque si los que sabéis no lo habéis visto es que no funciona así, pero me extraña que si el TC ve en el esquema ese cruce lo trate como si fueran dos vías independientes y no cruzadas como lo son. Y que no "se dé cuenta" de que si manda dos schedules que utilizan ese cruce exista la posibilidad de que haya accidente.
Ya veo que no hay detección que le indique la posición relativa del tren y el cruce, pero aun así me choca lo que ya he dicho: que esa forma de trazado no tenga ninguna repercusión en el manejo de los itinerarios que controla el TC.
Saludos.

Manolo

[xaviermbcn]

Jose Luis,

si funciona con el simulador ha de funcionar en real. Lo que dice Manolo es así.
Prueba si van bien las detecciones, pon marcadores de frenado y paro. Y pon locos que tengan SpeedProfile si solo trabajas con un indicador por bloque.

Ya dirás.

[osca22]

Seguiré investigando ya que algo se me tiene que escapar. las locos tienen las speed profile hechas, los bloques tienen 1 sensor de consumo cada uno. Puede ser el tema de la señalización donde está situada. Ya os informaré

[RhB]

Hola. Pues perdonad que insista en mi teoría, pero yo no veo que tenga relación con la detección.
Vamos a ver: si tenemos un circuito con abundantes detecciones y lanzamos por él dos composiciones, el tren podrá hacerlas circular simultáneamente evitando las interferencias mediante la gestión de la información que las detecciones le proporcionan. Si no recuerdo mal, eso podría optimizarse con una cosa que permitía disminuir los bloques de distancia entre ellas.
Pero, llevándolo al extremo, o sea, si no hubiera ningún detector en todo el circuito y el SW tuviera un punto de contacto (o cruce) entre dos recorridos, el TC lo "sabría" y aunque diéramos la orden de lanzamiento de ambas, él detendría una para evitar esa posibilidad que atormenta a José Luis.
Resumiendo que, tal como lo veo yo (mal visto, probablemente) si hay un cruce y no hay suficientes detecciones, el perjuicio que acarrearía la cosa sería que sólo andaría una composición hasta llegar a destino, momento en el que arrancaría la otra, pero nunca que el sistema lanzara las dos, "viendo" que se pueden hostiar en un cruce cuya proximidad de las composiciones él TC no puede evaluar.
Saludos.

Manolo

[osca22]

. Manolo, tienes razón. O al menos te la doy. Hoy he estado cambiando cosas pero aún no he probado. Os iré informando de todo. Gracias por devanaros los sesos

[osca22]

Buenas. No he cerrado este asunto, ni mucho menos. Modifiqué la colocación de los sensores, y bloques para evitar los problemas de cruce. Parece que algo conseguí. Seguía haciendo pruebas cuando comprobé que una máquina, a pesar de haberle hecho previamente el Speed Profile, no paraba bien y al frenar más tarde, dejaba la schedule sin mover la máquina. Solución, hacer de nuevo la SP. Pues aquí, me vuelven a crecer los enanos, ahora me fallan las placas S88.
Resumen: El tema de choque en lso cruces se resuelve dependiendo de donde pongamos los sensores. Cuando tenga todo arreglado, seguiré informando y subiré el nuevo esquema de TC.

[osca22]

Al final el problema se solucionó de dos formas totalmente diferentes. LA primera fue el alargar la longitud de los cruces y añadir más sensores en estas zonas críticas, y la definitiva fue desmontar todo y empezar de nuevo que es con lo que esto actualmente, pero sin poder hacer las pruebas pertinentes. Cuando esté todo en funcionamiento, os hará un resumen del mismo para evitar que zopencos como yo caigan en cosas como la que me pasó a mi. Ahora toca esperar hasta que pueda tener todo documentado. Sin prisas prometo colgar la resolución del problema.