HispaLUG

[EDITO 12/2/12: las conclusiones y avances de este hilo han quedado finalmente en este otro mensaje (http://este%20otro%20mensaje).]

No hace mucho hice una review sobre el sensor IRLink (http://www.hispalug.com/foro/index.php?topic=14532.msg244671#msg244671) para NXT en relación (entre otras cosas) al control de trenes. En el video podéis ver el control de 2 motores PF y si os fijáis, cómo voy cambiando los parámetros en pantalla gracias al LabView, el lenguaje de programación en el que está programado el NXT-G de Mindstorms. Estos son mis primeros pinitos:

http://www.youtube.com/watch?v=aYc2_yusOCg# (http://www.youtube.com/watch?v=aYc2_yusOCg#)


El caso es que con ese sensor se pueden controlar automáticamente 8 canales de Power Functions (PF). Esto quiere decir que se podrían controlar 8 trenes o 4 trenes y 4 desvíos o cualquier otra combinación. Como podéis ver en el video, el motor se mantiene en funcionamiento aunque no reciba señal. Gracias al LabView, todo esto se podría controlar a través de una pantalla como la de la siguiente imagen, con el NXT conectado al PC a pie de vía:

(http://www.hispalug.com/galeria/albums/userpics/45155/Trenes_LV.jpg)

Eso si, las ordenes solo se podrían transmitir en zonas concretas, justo donde el sensor pueda influir, y tantas como sensores pongamos (hasta 4). Sería por ejemplo la zona de una estación. Todo esto hace que sea una herramienta muy potente para poder usarse en grandes dioramas de exposiciones. Podría también programarse para que no fuera necesario el uso del PC (es decir, completamente automatizado), pero a través de su pantalla tendríamos control total sobre desvíos y trenes y podría incluso pensarse en localizar su posición.

A partir de aquí empiezan mis dudas. Lei hace tiempo cómo funcionaban los sistemas de semáforos en vias de sentido único, pero no lo encuentro. ¿Alguien me puede explicar cómo funcionan o darme el enlace para intentar reproducirlo?

Segunda cuestión: dada mi escasa experiencia en temas treneros en exposiciones, desconozco qué trazados se suelen hacer. Os agradecería orientación al respecto. Aunque estoy convencido de que este sistema podría aportar mucho al respecto, sería un buen punto de partida para mi para seguir explorando posibilidades.  

Por último (de momento), aunque en la BrickSur ya vi los desvíos de Daniracer, ¿existen instrucciones de cómo automatizar desvíos con motores PF?.

Aviso, estos solo son mis primeros intentos y que puede que todo esto quede en nada, pero podría ser realmente llamativo en una expo tener una pantalla junto a las vías y controlar todo el diorama ¿no os parece? ¿le véis posibilidades reales?. En fin, espero vuestros comentarios, ayudas, opiniones... a ver qué va saliendo.  

Y tanto que le veo posibilidades reales  :}

De hecho has dado el primer paso, que es pensar cómo hacerlo.
Por mi parte yo pensé en hacer algo parecido, y con tu dato de que sólo funciona en una zona lo ideal es una estación.

Respecto desvíos, esta idea es la mejor que he visto de momento. Con los miniLA y un motor está chupado.
Instrucciones no tiene, pero te puedes hacer una idea. (En el 1:40)
http://www.youtube.com/watch?v=FcOKhXBXfvI#ws (http://www.youtube.com/watch?v=FcOKhXBXfvI#ws)
Yo voy a intentarlo con motores antiguos  ;)

Por lo demás, quitando las instrucciones que vienen con los packs de vias, no sé si hay algún circuito estandarizado, pero vamos, cada circuito es un mundo  :P

Gracias Blastem.

No tengo esos miniLA's, pero jugando, me imagino que saldrá igual con los grandes. De todas formas, si hay más ideas, serán bienvenidas.

En cuanto al circuito, no me refería a circuitos estándar, sino a los que ya se han realizado en anteriores encuentros HB. ¿cómo eran, qué diseño? ¿vía única dando la vuelta a todo? ¿desvíos? ¿cuántos trenes en movimiento a la vez?... en fin, todas estas cosas prácticas.

Bueno, y sobre todo, queda la cuestión de los semáforos. A ver si los treneros me orientáis un poco para intentar reproducir algo a escala que pudiera ser útil en un encuentro... si es que cuadra la cosa.

Muy bueno nxtorm! yo he usado el RCX y el NXT para el cambio de vías, pero de momento nada tan sofisticado como lo que has organizado tu, sólo había puesto un RCX por cruce.. tenia los IR* en la lista de deseos.. creo que cada vez lo veo más claro que han de caer!

gran inspiración, si señor!

Eso está genial por los canales que tienes 8 en vez de 3... pero tiene algunas cosas que fallan a la hora de que en la realidad esto funcione correctamente, necesitas saber la posición exacta de cada tren para realizas los cambios de vía y las paradas del tren, y sólo te quedan 3 sensores libres para tres posibles comparaciones.
Por otro lado eso se puede solucionar usando sensores digitales como ya se han usado en la caja fuerte. Pero creo que sólo se pueden usar sensores de contacto por lo que el motor de los trenes tiene que ser de 9V para que haga el contacto, de lo contrario el tren puede descarrilas al accionar el sensor por contacto físico.

Todo este sistema yo ya lo pensé en su día a la hora de la automatización que se ha puesto en las exposiciones anteriores. y como he comentado me he topado con todas estos problemas.

Así que lo ha hay que pensar es en hacer un multiplexor de motores de manera digital, para usar los trenes de 9V que son los más controlables, no obstante hay que modernizarse por que le futuro es rc, hay que seguir pensando.

SaLuDoS.

Hay multiplexores para sensores de contacto que puedes colocar encadenados y controlar hasta 128 sensores de contacto en cascada.
También los hay para motores y puedes usar hasta 8.
Tienen bloques de programación propios y no parecen difíciles de usar, pero sí de pagar.

Por mi parte intentaré robotizar el circuito con x sensores y 6 motores  dobes 9v (2 por cambio de aguja con polaridad invertida)

Hay que recordar que si usas trenes de 9V necesitas un puerto de motor por cada parara que quieras que haga el tren.
Cada andén es un puerto y cada cambio de vía otro.

SaLuDoS.

Interesante propuesta!

Ahora, por ser un agua-fiestas y tambien hacer el listillo, permiteme compartir un par de opiniones e ideas...

No es buena idea intentar automatizar los desvios.
Aunque se puede llegar a hacerlo con multiplexores etc, como ya mencionado, opino que no es NADA recomendable.
Más bien es un lio, probablemente solo apto para instalaciones permanentes y casos extremos.

Como ejemplo os muestro un control mio, controlando solo 7 desvios y 16 bloques de parada.
Ya lo sé que es practicamente incomprehensible, y por eso sirve bien como ejemplo de des-animo;

(http://www.majhost.com/gallery/Hoexbroe/Layout/Details/schattencontrolplc_1.gif)
-Hay que abrir el imagen en una ventana separada, para ver la alta resolucion.

Como dicho, haciendo el listillo, os propongo usar otra tipo de automatizacion. Puramente electro-mecanico, aunque se puede cambiar algunos de los mecanismos por combinaciones de NXT y software...
El truco más comun y sencillo de automatizar trenes es implementar un sistema de "auto-bloqueo" -que por cierto es muy parecido al mundo real.
En un sistema asi, todos los trenes siempre circulan en el mismo sentido, uno tras otro. Para evitar este "monotonia visual" el circuito es normalmente "aplastado" en el medio, dando la sensacion de una linea principal con trafico en ambos sentidos. Las curvas -formando un bucle de retorno- se puede esconder/camuflar, asi dejando el circuito en forma de un "hueso de perro".

He intentado dibujar un circuito asi, sin aplastar el circuito, para que los objetos de control y el "cableado" queda más claro;

(http://www.majhost.com/gallery/Hoexbroe/Layout/Details/selfblock1.jpg)

En el ejemplo hay 4 bloques, asi permitiendo un maximo de 3 trenes circular a la vez. (Con 5 bloques serian 4 trenes, etc...)
Hay 4 motores (para parar un tren) y 4 "sensores"/contactos electro-mecanicos que el tren actua cuando pasa por encima.
La idea es que el tren para por una pestaña subida (subida por un motor), y que estas pestañas suben y bajan segun que los tenes pisan los contactos en las vias.
-Un cable rojo a un motor SUBE la pestaña (y para un tren justo en el punto detras el mismo tren (para asi evitar choques)), mientras una linea verde BAJAR la pestaña en el bloque anterior, asi otra vez dando marcha a un tren alli.
Las modificaciones necesarias en los trenes y las vias (instalando contactos que abran y cierran con un roce mecanico) tal vez sean prohibitivas para algunos usuarios, pero es una manera clasica de automatizar maquetas de trenes...
El roce mecanico se puede eliminar usando SRK´s (Concatcos enpasulados en tubos de cristal, que se actuan con un simple iman)
Usando NXT y fotocelulas seria otra posibilidad.

Hoex, esto ya es nivel pro  :O
Impresionante el desarrollo y la conversión. Y la explicación para el sistema electromecánico me ha encantado.  ÔÔ

Me imagino que lo que busca nxtorm (y yo mismo a menor nivel) es poder hacerlo puramente LEGO con las herramientas que propone, y con vías RC, pero ya tengo a buen recaudo tu post, que me ha alegrado la mañana  :angel:

La idea de Hoexbroe está muy bien pero no es lego, esa más esa idea se puede hacer con lego pero sólo usando dos trenes y tres de esos "motores" en las vías, o nisiquiera usar esos motores y simplemente hacer una vía muerta en un lugar determinado que tal forma que al pasar un tren por allí se pare (al no tener corriente dicha vía) y al llegar un segundo tren empuje al primero sacándolo de allí y el segundo quedaría parado, y así formando bucle. pero yo cre que a la gente lo que le gusta es ver como los trenes entran a la estación y sale el otro del otro andén y así sucesivamente.

SaLuDoS.

umm, este hilo se está poniendo de lo más interesante. Podría ser un buen espacio para poner en común todas estas cuestiones e intentar sacar algo chulo. Ahora voy un poco pillado de tiempo, pero ya retomaré, habéis tocado muchos temas.

Cita de: Blastem en 05 de Enero de 2012, 11:04:54 AM
Me imagino que lo que busca nxtorm [...] es poder hacerlo puramente LEGO con las herramientas que propone, y con vías RC

Bueno, yo no soy de los puristas al extremo, así que no descarto elementos como los que explicaba Hoexbroe en su respuesta (magnífica por cierto) del tipo SRK (http://www.nxtorm.es/analogicos/sa-m-reed-switch.html) (perdón por la autocita). También he pensado en esa opción y en las fotocélulas. La ventaja de los primeros es que se pueden añadir hasta teóricos 128.

Lo que sí reconozco es que ando buscando soluciones en RC, creo que más pronto o más tarde, habrá que adaptarse, es una opinión. En RC, y contando siempre con un IRLink+1NXT el problema es que la zona de control sobre los trenes queda restringida a la zona de influencia del sensor. Pero en una expo, creo que seremos más de uno los que podríamos aportar 1NXT+1IRLink, con lo que el precio no es problema.

Por otra parte, en 9V existe la limitación de los motores que comenta Dani, yo no tengo experiencia en este sistema. Cierto es lo que dice Hoex, que la complejidad puede desanimar a cualquiera. Por cierto, no consigo ver la imagen en grande. Haré solo el apunte porque no lo he podido pensar, solo tengo la idea, allá va:

¿Sería posible subdividir el trazado en zonas independientes cada una controlada por un NXT? Cada zona comprendería: un control de trenes en la estación (Vía IRLink) + control de los desvíos en su radio de acción (con los motores PF) + detección de la posición de los trenes como fuera + 2 vías de conexión al siguiente "módulo".

Y ahora la más difícil: ¿sería posible crear un estándar sencillo al estilo GBC o microcity SIN COMUNICACIÓN ENTRE LOS NXT para controlar esas zonas? El objetivo es el siguiente: 1 NXT + 1 IRLink implica un circuito con 1 estación en el diorama con sus desvíos. Si se suma un segundo lote, se amplía a 2 estaciones en cada punta, etc. De esa forma, quizás sea posible simplificar la ampliación y controlar a la vez varios trenes en el circuito.

Ya digo que solo he tenido la idea y no me he parado a pensarla mucho. Quizás sea un disparate y no sea posible, pero como idea, al menos merece la pena explorar. Al estilo microcity, de un módulo muy pequeño se saca una construcción de ciudad compleja y ampliable. Lo mismo para GBC. ¿Será posible en trenes RC? Ale, a pensar, ahí queda la idea.  ??? 

A mí no me parece descabellado siempre que haya espacio suficiente.
Yo poco más puedo aportar sin el sensor... En cuanto pasen los exámenes empiezo a probar seriamente  :)

Cita de: daniracer en 05 de Enero de 2012, 13:56:08 PM
La idea de Hoexbroe está muy bien pero no es lego, esa más esa idea se puede hacer con lego pero sólo usando dos trenes y tres de esos "motores" en las vías, o nisiquiera usar esos motores y simplemente hacer una vía muerta en un lugar determinado que tal forma que al pasar un tren por allí se pare (al no tener corriente dicha vía) y al llegar un segundo tren empuje al primero sacándolo de allí y el segundo quedaría parado, y así formando bucle. pero yo cre que a la gente lo que le gusta es ver como los trenes entran a la estación y sale el otro del otro andén y así sucesivamente.

No, no, no! Pienso que es absolutamente prohibido que un tren choque y empuje al otro.
Estoy pensando en vias RC, y por lo tanto la nececidad de contactos e interuptores mecanicos y/o SRK´s e imanes. (Ya que los NXT están fuera de mi alcance.)
Si seria vias 9V TODO seria mucho más simple (e infinitamente mejor) instalando decoders DCC en todos los trenes, y usando software y hardware ya estandardizado y economico.

---

Post Unido para corregir el floodeo: 07 de Enero de 2012, 09:53:13 AM

---

Cita de: nxtorm en 05 de Enero de 2012, 17:56:11 PM
Lo que sí reconozco es que ando buscando soluciones en RC, creo que más pronto o más tarde, habrá que adaptarse, es una opinión. En RC, y contando siempre con un IRLink+1NXT el problema es que la zona de control sobre los trenes queda restringida a la zona de influencia del sensor. Pero en una expo, creo que seremos más de uno los que podríamos aportar 1NXT+1IRLink, con lo que el precio no es problema.

Si realmente queires (es un gran trabajo) puedes hacer un sistema cojonudo controlando hasta 8 trenes simultaneamente con tu idea. Es muy laboroso, ya que tienes que programar un imagen "virtual" de todo el trazado de vias, y hacer el software saber donde está los trenes en esta "state machine" version de tu maqueta.
Todavia vas a necesitar puntos de "feedback", pero si realmente es posible conectar hasta 128 SRK´s como entradas, eso ya está chupado ya que son muy baratos, y no es gran problema colocar un imán debajo de cada tren!

Vuelvo a proponer que la automatizacion de los desvios ya es otra cosa. No debes usar el IRlink para eso, ya que ese debe estar libre para los (hasta 8) tenes.
Desconozco las posibilidades de conectar muchas salidas al sistema NXT. Un multiplexador es un lio de cableado, aunque si te limitas a usar 4 salidas digitales se puede hacer sin morirse de asco. (4 salidas multiplexados SOLO te dan 8 salidas operativas. Eso seria para 4 desvios)

Inconvenientes importantes;
El trabajo en software de un control "state machine" con 4-8 trenes y algunos desvios es descomunal!
Seria practicamente imposible poder disponer de todos los 8 canales IR en una exposicion donde otros expositores tambien van a quierer controlar sus cosas.
Los SRK´s se deben poder leer instantaneamente. Nada de multiplex. No sé si eso es posble¿?

Nota adicional para los que opinen, que lo que quiere ver la gente es como llega el tren a una estacion a un andén, y luego sale otro tren de otro andén; Aqui se puede usar el hecho que los desvios vuelven a su sitio si los entras por "detras"; Si tienes dos trenes que circulan en sentido contrario en un ovalo de via simple con dos desvios (y un andén entre los dos desvios), entonces ni siquiere tienes la necesidad de automatizar estos desvios; solo es importante la posicion inicial de la aguja (o "lengua"¿?) para el tren que lo va a travesar desde el frente, -ya que gracias al efecto muelle del aguja del desvio, el desvio se puede pasar por ambos lados cuando el tren viene "por detras". (Uff, me he metido en un lio intentando explicarme...)

Me habéis hecho ver lo complejo del asunto para tenerlo todo controlado, así que la primera impresión ha sido...desisto. Con más calma, he continuado pensando en un estándar para todo esto y la idea sigue avanzando. La idea es que sea lo más simple posible. Esto implica varias cosas a evitar: la comunicación entre ladrillos, los elementos que requieran montajes complejos o soldaduras, los cables largos... Partiré de todo esto. Para más simplicidad todavía, el primer "estándar" solo permite la circulación de trenes en 1 sentido. Luego propondré (si es el caso) un modelo para 2 sentidos.

Módulo básico: material.

4 desvíos: 2 automatizados (con flecha en la imagen de abajo) y 2 no.
2 motores PF para las automatizaciones
1NXT+1IRLink para dar las órdenes a los trenes.
1 Receptor IR de LEGO más su caja de baterías.
1 sensor de luz situado a la entrada de la estación (quizás también otro antes de la salida).
2 trenes PF por estación.

Módulo básico: configuración.

(http://www.hispalug.com/galeria/albums/userpics/45155/a0_basico.jpg)

La  estación (en rojo) debe disponer de 2 andenes suficientemente largos para alojar cualquier convoy del diorama. El desvío automatizado de entrada de la estación (flecha) reparte los trenes al andén 1 o al 2. El circuito interior ("cercanías") es de trazado libre. En caso de un único NXT, sería el único trazado existente. La  vía superior es "abierta" para salidas de trenes con su desvío automatizado y otra inferior también "abierta" para llegadas de otros trenes.

2 módulos: conexión.

(http://www.hispalug.com/galeria/albums/userpics/45155/a1_dos.jpg)

Cada estación cuenta con un "circuito interno" controlado desde esa estación más la conexión al resto. Cada estación expide los trenes por la vía de su color. Este circuito es absolutamente equivalente a hacer esto:

(http://www.hispalug.com/galeria/albums/userpics/45155/a2_complejo.jpg)

Funcionamiento.

Los trenes podrán circular por cercanías libremente, incluso en sentidos contrarios. Y ahora el kit de la cuestión: CADA 5 MINUTOS, SE EXPEDIRÁ SIMULTANEAMENTE UN TREN DE UNA ESTACION A OTRA. El otro tren deberá quedar parado en la estación o bien dar alguna vuelta si hay tiempo para ello. A la recepción del tren, los trenes de cercanías (circuito interno) podrán volver a circular con normalidad.

Coordinación.

Los trenes entre estaciones tardarán tiempos distintos en llegar, no llegarán a la estación receptora a la vez. No es problema. Si un tren tarda 1 minuto en llegar, les quedan 4 minutos disponibles a los trenes de cercanías. Si le cuesta 2 minutos, solo dispondrán de 3 min. Al vencer los 5 minutos estipulados, cada estación expide un nuevo convoy y el ciclo se repite.

La única condición para que todos los NXT estén coordinados es la de iniciar la ejecución del programa en todos ellos a la vez.

Ampliaciones.

Ampliar con nuevos módulos/participantes es sencillo:

(http://www.hispalug.com/galeria/albums/userpics/45155/a3_tres.jpg)

Notas finales.

Los trazados pueden ser libres, con tal de que se respete el esquema (la topología). El programa del NXT, una vez creado, puede ser único para cualquier participante, evitando fallos una vez depurado y haciendo que nadie se quede fuera por este motivo. Esto es una gran ventaja.

El único parámetro modificable del programa son los 5 minutos de expedición de los trenes según las distancias de los trazados o los gustos, pero siempre en múltiplos de 5 minutos.

Otra ventaja es que siempre hay trenes circulando.

Creo que son normas sencillas, incluso con algún paralelismo con estándares que han podido consolidarse como el GBC. Ahora ya es turno vuestro para decir cuánto de disparatada es la propuesta y/o para mejorarla si es que puede ser útil en dioramas grandes. Cualquier duda, ya sabéis.

que medio usas para detectar el tren por que hay trenes rápidos y trenes cortos que no los puedes mezclar en las vías comunes por que se pueden juntar y te generarían un problema a la hora de que lleguen a la estación...

de todas formas tu hablas de trenes rc ¿no es así?

SaLuDoS.

Sí, sí, trenes RC.

Al principio de mi propuesta de estándar (http://www.hispalug.com/foro/index.php?topic=14680.msg247723#msg247723) de automatización de trenes de los dioramas proponía 1 o 2 sensors de luz (o color) en cada estación. De todas formas, con el método propuesto, no es posible que se junten o choquen trenes en vías comunes, ya que solo hay 1 en circulación. La propuesta a debate solo desarrolla cómo hacerlo, pero a priori la idea parece sencilla y factible (creo). Por concretar mucho sería así:

---

Resumen del estándar.

Cada estación mantiene 1 tren de cercanías (circuito cerrado corto) en circulación. Cada 5 minutos (o 10), el cercanías se detiene en el andén y se envía un segundo tren de una estación a otra (circuito largo) en el sentido de las agujas del reloj. Una vez ha llegado, el ciclo se repite. El sistema es ampliable a más participantes.

---

Mosquis, hacía mucho que no entraba en este subforo y descubro este hilo :)
Lo marco para leer con calma en cuanto tenga tiempo que he visto así por encima que algunas de las cosas que me planteaba ya están sobre la mesa.

Bueno, leído y entendido (creo :P) lo hasta ahora escrito.

Me encanta como se están concretando las cosas porque es más o menos la idea que yo tenía in mente: RC para dar órdenes a los trenes (hasta 4 y así dejar otros 4 canales para que pueda haber otras cosas RC por la sala sin que interfieran, importante en exposiciones... y en una casa con hijos que tienen coches RC jejeje), y cableado para comandar los desvíos.

Lo primero que hice fue entender por encima el esquema de estación oculta de Henrik. Para no haber visto nunca uno, creo que más o menos entiendo su funcionamiento, un conjunto de sensores, un conjunto de servos, y que en modo automático el que se abra una vía haga que a continuación se abra la siguiente. Lo siguiente fue entender lo de los cantones, que más o menos ya había leído algo del tema sobre trenes analógicos, pero es implementable en este caso sólo con el sistema 9V, o a lo sumo con trenes con motor PF "a piñón fijo" activados por un interruptor/sensor ubicado en su parte inferior.

Lo de los SRK no me lo había planteado, aunque doy fe de que es muy práctico... de hecho recuerdo que había un sistema de slot digital que los usaba como detectores. Yo había pensado más bien en sensores electro-ópticos, que son fáciles de construir aunque requieren soldaduras y un circuitillo básico, que devuelven una tensión alta o baja según si detectan o no un objeto a unos 2cm del sensor. Ahí es donde empecé a trabajar hará un añito, inicialmente para controlar un simple semáforo y bajar unas barreras, un circuitillo simplón a más no poder pero que ya requiere andar soldando, cosa que a la mayoría de treneros les echará para atrás. Por eso, pensé incluso en hacer un diseño de una plaquita fácil de montar y compacta para facilitar la vida a los que vinieran detrás, pero me faltaba el elemento clave: la modularidad, lo que yo hice estaba pensado para el fin que estaba pensado, por lo que para poder hacer algo "replicable" por más gente, primero había que definir una norma modular que permitiera enchufarlo... y ahí me quedé, porque el NXT lo controlo lo justito para hacer cuatro cosas con la caja NXT2.0 de mi hijo mayor, pero siempre en el mundo LEGO, no me puse a buscar como conectarla con el mundo exterior. Todo este párrafo para decir que si hay algún módulo que permita monitorizar "contactos" ya sean electrónicos, magnéticos o físicos con el NXT, se pueden "hacer palomitas" ;), da igual de que tipo sea el contacto si tenemos unos parámetros de tensión/corriente a respetar por cada sensor, y se pueden implementar todo tipo de sensores. A mi me gustan más los optoeléctricos porque cambias el sensor y cambias la distancia, o un módulo sencillito puede controlar varios puntos de un tramo de vías (para detectar p.ej. trenes largos)... pero todo se puede hacer con contactos mecánicos y más fácil y limpio aún, con SRK.
Mi duda es: ¿Como alimento el NXT con sensores externos? Pero aquí están los maestros del NXT que seguro que nos lo resuelven (tengo que echar un ojo con calma a tu web NXTorm)

Visto esto, está resuelto el tema de detectar trenes, y con un ladrillo se pueden enviar órdenes a trenes dentro de su rango de acción. Si el diorama tiene varios ladrillos controlando zonas, es tan fácil como enmascarar los emisores con unas pantallas para que no se desvíen las órdenes fuera de su rango, pero tampoco es problema si el número de trenes a controlar es discreto, y me explico: puede haber circuitos con 4 trenes en marcha pero con hasta Nx4 trenes aparcados siempre que cada grupo de 4 trenes parados esté en un andén que no reciba más que al emisor de "entrada/salida de su estación"... habría varios trenes "1, 2, 3 o 4" pero sólo uno de cada tipo en movimiento cada vez, y tantas dársenas con su IR-Link independiente como grupos de 4 trenes hubiera en movimiento. Esto, se puede obviar por ahora, es rizar el rizo, pero lo dejo escrito porque cuando se quiera crecer en número de trenes es una alternativa que conviene considerar.

Con esto están resueltas las dos primeras incógnitas: saber donde hay un tren y dar órdenes a los trenes de forma individual. La tercera incógnita son los desvíos, pero pueden hacerse mediante un sistema cableado usando los 3 puertos de motores del NXT que permitirían controlar hasta 3 desvíos o accesorios por cada ladrillo NXT (si se multiplexan, son más). Aquí veo un problemilla... me parecen pocas salidas por cada módulo NXT. Si es para desvíos, un ladrillo puede gestionar bien una estación sin problemas, pero si se quieren meter p.ej. barreras móviles, semáforos... o se ponen en paralelo con los desvíos, o se consumen puertos de salida. A eso aún no le he encontrado más solución que multiplexar las salidas, supongo que habrá algún adaptador para hacerlo (no me gusta meterme en tanto adaptador, que la economía no está para excesos, me gustaría hacer cosas con lo que tengo y si me gusta ya ampliaré).

Por otra parte está el tema módulos. El esquema último que has colgado, NXTorm, me gusta cuando pretendes con un ladrillo controlar un circuitillo único, con una estación y unas cuantas vías. De hecho el esquema viene muy bien porque permite optimizar un NXT y da directrices para implementar otros módulos.

Para concatenar varios módulos en un circuito grande, yo me planteo las cosas en términos de estaciones y playas de vías por una parte, y en control de tráfico en el diorama por otra parte. Me explico: Una estación o una playa de vías es autónoma, y puede funcionar sola sin mayor problema independientemente de que haya más módulos controlados por NXT en otra parte del diorama, o que sea ella solita la única zona controlada. Si defino el módulo "estación", pienso en los imputs del módulo (tren aproximándose), las variables internas (Vía uno, vía 2, vía 3..., presencia de tren en vía 1, en vía 2, en vía 3..., estado de los desvíos de entrada) y en las salidas del módulo (dar marcha al tren 1, 2, 3..., activar desvíos...). Hasta ahí es fácil y es similar a un sistema como el que pinta Hoexbroe más arriba en su mega-diagrama (bien detallado, pardiez... aquí está el URL de la imagen, que alguien no podía verlo en grande http://www.majhost.com/gallery/Hoexbroe/Layout/Details/schattencontrolplc_1.gif (http://www.majhost.com/gallery/Hoexbroe/Layout/Details/schattencontrolplc_1.gif)). Una vez pensado el módulo, su gestión es una máquina de estados que no es muy difícil de calcular para implementarla en NXT, de hecho si definimos un estándar de como numerar sensores y desvíos en un módulo, ese código puede aprovecharse para replicarlo y tener varias instancias según el tipo de funcionamiento que queramos (secuencial, aleatorio, manual...).

Es laborioso, pero relativamente sencillo de montar, aunque tiene un pero bien grande, que igual no es "tan pero":
¿Como se qué tren viene? Pueden venir el 1, el 2, el 3 o el 4, y yo lo aparcaré en una vía. Cuando tenga que decirle "vete", dejará su hueco en la vía, pero ¿Como se qué tren está en cada vía? Puedo saber qué vías tengo libres poniendo un sensor en cada vía, pero si quiero clasificar los trenes (esta vía para trenes largos, esta para los cercanías...) tengo que saber identificar al tren que llega. Ahí se puede p.ej. implementar un detector por colores o poner hasta 4 imanes pequeños bajo cada tren (coincidiendo con los 4 studs de las vías) y en cada stud poner un sensor. Así, pegando una plaquita de imanes a la base de cada tren, el sensor de "entrada" del módulo, sabrá si llega el tren 1, el 2... y luego sabrá donde está exactamente porque el mismo módulo lo habrá colocado en una u otra vía.

Resumiendo, una estación según este enfoque debería tener un sensor que diga cuando llega un tren (y que diga al módulo qué tren es el que llega),  a continuación activará los desvíos para ubicarlo en una vía libre y adecuada al tren que llega, tendrá un algoritmo interno que pare los trenes tanto o cuanto tiempo, y los saque según las condiciones que nos vengan en gana, un sensor de salida que nos diga si podemos ordenar a un tren salir de la estación, y sensores bajo las distintas vías de la estación que detecten cuando el tren que llegaba ha llegado a su posición de parada para ordenarle detenerse.

Así, con un módulo se puede controlar una estación. Si quedan puertos libres, se puede, como en el ejemplo que pone NXTorm controlar algún desvío adicional, pero eso prefiero considerarlo un módulo aparte. ¿Por qué digo esto? porque es más fácil resolver el problema "despiezándolo" que tratándolo como un todo. Para resolver ese circuito casero con una estación sencillita con dos vías, y un desvío para tener trenes en dos tramos distintos, haría un módulo aparte, y si el número de entradas y salidas del módulo caben en un NXT que ya tenga montada una estación, es cuestión de ponerlos juntos. ¿Qué os parece?

Así, el módulo de desvío que controle dos circuitos (los voy a llamar exterior e interior, o A y B, según gustos), es igual que el módulo de estación, una entrada diciendo qué tren llega, un desvío que manda los trenes por el circuito A o B, un sensor a la salida de cada tramo para saber que puedo enviar el tren "más allá de donde yo controlo" sin que choque con otro, y yatá. El módulo verá que viene un tren, y según el tren que venga, o según qué circuito está libre, lo enviará por uno u otro. El circuito tendrá sensores que eviten colisión de trenes antes de llegar a un desvío que une dos vías, o entrar en un tramo... algo así como los cantones que planteaba Hoexbroe en su circuito plano: para dejar pasar un tren de un punto tengo que saber que a partir del mismo no hay ningún tren.
Este módulo es algo más complejo de programar porque permite muchas variaciones, pero si lo consideramos como un tramo de circuitio interior y otro exterior, básicamente funciona idéntico al módulo de estación.

Si voy a implementar un circuito de estación y uno de circuito simple usando un único NXT podemos ahorrarnos el detector de qué tren llega al desvío que hay tras la estación, porque a ese punto llegará el tren que hemos mandado salir de la estación. A la hora de programar, yo lo programaría como una variable externa, pero al unir los dos módulos "se cortan las puntas" y se considera variable interna. Así se puede resolver el esquema en dos trozos independientes, requiere un pelín de trabajo inicial más, pero una vez hecho permite reutilizar todo para módulos más grandes.

¿Como uno módulos de circuito?
Una estación es autónoma, siempre y cuando no le envíen más trenes de los que es capaz de absorver. Lo mismo pasa con un circuito "X", que tiene una capacidad de trenes. Para ello es imprescindible hacer cantones, de tal modo que todo módulo sepa si a su salida puede enviar un tren, sabiendo que el módulo siguiente ya lo parará cuando llegue si no puede aceptarlo.

Para circuitos complejos, como un gran diorama, hay que diseñar todo en base a cantones: cada NXT controla su cantón/cantones, y sólo su cantón/cantones, y debe tener sensores a la entrada y salida de cada cantón. Supongo que todo esto está resuelto por los modelistas ferroviarios, yo hablo desde mi desconocimiento de la forma habitual de proceder, pensando en un circuito como una máquina de estados finitos. Lo explico mejor con un ejemplo:

Un circuito alargado, de sentido único "cuadrado" con una estación en cada estremo con dos vías cada una, que creo que es fácil de explicar sin pintar hablando de "norte, sur, este y oeste" como los cuatro lados del cuadrado:

Módulo 1: estación oeste
Módulo 2: estación este.

Cantón 1: Estación oeste
Cantón 2: línea norte
Cantón 3: estación este
Cantón 4: línea sur.

El módulo 1 debe tener un sensor que detecte cuando viene un tren por la línea sur (cantón 4) y lo detecte a la entrada de su cantón. Internamente funcionará como un módulo de estación, detectando el tren que viene, poniéndolo en la vía correcta, parándolo el tiempo determinado en la programación... y sacando un tren "cuando toque y pueda": es decir, tendrá un sensor para saber que la línea norte está libre (cantón 2), y sólo sacará un tren cuando toque si hay una vía libre. Si la línea de salida está llena, no podrá sacar trenes, e irá almacenando trenes hasta ocupar todas sus vías internas, y si llegan más trenes de los que puede albergar, los parará a la entrada.

El módulo 2 hace lo mismo, sólo que su entrada está por el norte y su salida por el sur.

Para saber que un cantón tiene "vía libre" yo pondría un sensor a la entrada y otro a la salida: Si pasa un tren por el sensor de entrada, el cantón está ocupado, y si pasa uno por el de salida, el tramo está libre. Todo módulo tiene que tener dos sensores para saber que el tramo de salida está libre, y un sensor con detector de tipo de tren a la entrada para saber que está llegando un tren.


En fin, creo que es demasiado ladrillo por hoy, espero que me haya explicado bien. Mi intención es que se pueda replicar todo en base a módulos, aplicando la filosofía de los cantones que comenta Hoexbro más arriba, y que cada módulo pueda programarse en un NXT. Habrá módulos complejos que puedan requerir varios NXT (p.ej. estaciones grandes), habrá otros tan pequeñitos que me quepan más de uno en un NXT, y circuitos que puedan implementarse por completo usando un único NXT con un sensor IR-Link y un módulo de muchas entradas por contactos, y tantos motores como desvíos. Las órdenes a los trenes irían siempre por RF con el IR-Link, y a los desvíos por cable. Los sensores estarían todos conectados por cable. Se pueden acoplar "funciones" auxiliares como semáforos autónomos (activados p.ej. por uno de los sensores), o controladas usando motores o puertos de salida del NXT.

Tengo que sentarme a intentar pintarlo, que seguro que facilitará la comprensión, e investigar sobre esos módulos para poder meterle un puñado de sensores a base de contactos al NXT.

PD: aquí radica la ventaja de un sistema DCC: Todos los sensores, motores, mecanismos, accesorios, están conectados a la vía y reciben de la misma o inyectan en ella la información, y un sistema central controla todo. Se ahorran kilómetros de cableado y la complejidad se reduce mucho... un sistema hecho con este sistema se puede implementar con soluciones "casi 100% LEGO", peeeerooooo.... requiere tirar cables por doquier, lo cual no es muy aconsejable para un gran diorama en un evento: un ejemplo: pensad que las dos estaciones del ejemplo están separadas entre sí 10 metros, hay que poner sensores al quinto pimiento de cada estación para saber que el cantón de salida está libre  :s

Edito: He estado dándole vueltas a la cabeza mientras recogía a los peques del cole. Tiene que haber una forma más simple de saber que el cantón de salida no tiene trenes sin necesidad de tirar un cable largo hasta la entrada del siguiente módulo.

Re-Edito: adjunto un esquema de módulos de las dos estaciones que comento más arriba. Sólo pinto los puntos con sensor de la estación Este y cantón norte (salida de la estación este). El cantón sur y estación oeste son lo mismo pero girado 180º. Se puede controlar la estación usando un IR-Link para comandar los trenes dentro de la zona de cobertura bordeada con trazos de color azul, dos sensores en el cantón norte para saber si está ocupado, un sensor en cada vía para saber cuando detener el tren, un sensor con detector de número de tren que entra, y un motor para ativar el desvío motorizado de entrada.

Para el esquema una estación y un circuito corto y largo, pinto sólo el dibujo con los mismos colores que en el gráfico de dos estaciones, para que se vea que básicamente es el mismo módulo

Glubs...  :D

Como insertar cita puede ser un poco liado, lo pongo en rojo y respondo a algunos temas. Vamos allá.

RC para dar órdenes a los trenes y cableado para comandar los desvíos.  
Ok, coincidimos, aunque no necesariamente deben ser 4 para desvíos y 4 para trenes.

Si hay algún módulo que permita monitorizar "contactos" ya sean electrónicos, magnéticos o físicos con el NXT, se pueden "hacer palomitas" [...] y se pueden implementar todo tipo de sensores.
No sé bien a qué te refieres con módulos, pero con NXT es posible controlar un buen número de contactos y leds. Por ejemplo, se podrían conectar 8 Reed's (SDK) a un puerto y 8 LEDs a ese mismo puerto. Aunque esto ya es harina de otro costal. Ya sabes dónde tienes amplia info.

¿Como alimento el NXT con sensores externos?
Esta no la entiendo bien Puli...

Si el diorama tiene varios ladrillos controlando zonas, es tan fácil como enmascarar los emisores con unas pantallas para que no se desvíen las órdenes fuera de su rango, pero tampoco es problema si el número de trenes a controlar es discreto.
El rango del IRLink es corto (hacia los laterales) si lo pones en vertical sobre las vías, por lo que no sería necesario enmascarar.

Puede haber circuitos con 4 trenes en marcha pero con hasta Nx4 trenes aparcados [...] y tantas dársenas con su IR-Link independiente como grupos de 4 trenes hubiera en movimiento.
Esta es una idea interesante. Yo también la anoto por si pudiera acoplarla al estándar en el que ando enzarzado.

Con esto están resueltas las dos primeras incógnitas: saber donde hay un tren y dar órdenes a los trenes de forma individual.  
Bueno, no dudo de que sea factible, pero a mí personalmente creo que me queda grande. Más abajo volveré sobre esto.

La tercera incógnita son los desvíos. Aquí veo un problemilla... me parecen pocas salidas por cada módulo NXT.
Con un IRLink ya sabes que se puede ampliar. Incluso dejando 4 para trenes, tendrías 4 desvíos PF y 3 desvíos NXT (o barreras o lo que fuera).

El esquema último que has colgado, NXTorm, me gusta cuando pretendes con un ladrillo controlar un circuitillo único, con una estación y unas cuantas vías.
En realidad, se pueden añadir los módulos que se quieran. Cada módulo implica 2 trenes más a sumar al diorama. Y en cuanto a las vías, se pueden hacer toooodo lo largas que se quieran y todo lo "complejas" (en trazado, no en cuanto a desvíos) que se quieran. Eso sí, respetando el esquema.

Resumiendo, una estación debería tener un sensor que diga cuando llega un tren (y que diga al módulo qué tren es el que llega), a continuación activará los desvíos para ubicarlo en una vía libre y adecuada al tren, un sensor de salida y sensores bajo las distintas vías para ordenarle detenerse.
He de reconocer que me cuesta seguir el hilo del esquema. En ese breve resumen que haces, coincide con lo que vengo proponiendo, aunque no tanto en su desarrollo y la implementación. Por ejemplo, tu segunda imagen al final es lo que yo he considerado prácticamente 1 módulo y coincide en el caso de un único NXT. Tampoco serían necesarios sensores bajo las vías.

Ahora mismo estoy intentando sacar el circuito estándar para un NXT e intentar un video si lo consigo para que lo veáis en funcionamiento. Intento sacrificar elementos y conseguir algo vistoso en un evento. No entendería una maqueta fija sin vías muertas, control total sobre trenes, etc pero en un evento es muy complicado (creo) cuadrar todos los programas de los distintos NXT. Entiendo que en lo que explicabas no existe comunicación entre los distintos NXT, con el consiguiente peligro de que se acumulen trenes en una estación y otra quede vacía ¿no?

La "madre del cordero" de lo que propongo (y así desvelo el punto clave) es el siguiente: los trenes circulan en el circuito cerrado. Cada 5 minutos, se para ese cercanías y sale el regional. Es decir, cada 5 minutos, cada estación "pasa" un tren a la siguiente. 

El truco para poder hacer esto y que no sean necesarios sensores en cada vía, etc es que todos esos trenes (la mitad concretamente del total) van codificados en el canal 1 motor A del mando PF. Imagina 16 estaciones y 16 trenes con el receptor IR en el canal 1A. La estación emisora dará las órdenes de salida en ese canal y la estación receptora también. Bien sencillo, 16 trenes en danza en un diorama, todos codificados en 1A con un programa en NXT-G de "pocas líneas". Una vez han llegado, todos parados y se activan los cercanías durante 5 minutos más y sucesivamente.

Respecto a la detección, ya he comprobado que un único sensor de color estándar (del que viene en el set NXT) a la entrada de la estación detecta colores dispares como el Emerald (verde oscuro) y el mercancías (amarillo) sin problema y ejecuta el cambio de vía. Y el tema de semáforos etc, podría programarse de forma independiente al control de trenes (otro NXT en comunicación BT con cada estación o aprovechando los puertos libres) si se quiere ampliar, pero incluso esto podría sacrificarse en un evento.

No se cómo lo harán en otros eventos, pero creo que al final los intentos se caen por una cierta complejidad, ya he visto varios casos de propuestas. Mi intento es el de simplificar y poner en movimiento el máximo número de trenes, de forma que sea viable para "mucha" gente. Suelen ser magníficas ideas, desde luego más elaboradas que la mía, pero que requerirían mucho tiempo de coordinación que en un evento no existe. O mucho esfuerzo de comprensión. Al final lo que funciona son normas sencillas tipo GBC o microcity.

De todas formas Puli, intentaré releer la segunda mitad con más calma. Eso sí, me ha gustado mucho, ya que en realidad lo que busco (más bien propongo) es debatir un modelo común sobre el que nos podamos poner de acuerdo y sumemos esfuerzos para su mejora, ya que hasta ahora, vamos proponiendo modelos personales distintos para luego poder mejorarlo de forma conjunta. Y tu propuesta es un modelo sobre el que basarse para debatir y que creo que tenemos bastantes puntos en común y buenas ideas que se pueden aprovechar. A ver si sigue la cosa.

Bueno, relee, que yo lo que pretendo es lo mismo, simplificar al máximo todo, por eso lo dividí en módulos mas pequeños... La idea parte de que una estación es un modulo independiente del resto y solo manda trenes si los tiene, y además puede ser tan grande como se quiera pero al ser independiente, el resto de módulos no necesitan saberlo.

El modulo de estación que he definido es el mas básico, y permite añadir al nxt que la controla el control de otro modulo, y así queda el circuito que has diseñado.

Me gustó mucho tu idea de que las estaciones y módulos no requieran conexión entre si, pues simplifica la programación. ESto convierte al conjunto de módulos en bloques autónomos con programaciones que pueden ser dispares, y ahí es donde aparece el problema que mencionas, que una estación puede llegar a acumular trenes y otra estar medio vacía... Esto obliga a que todo modulo deba tener unos parámetros de configuración fáciles de configurar sobre la marcha para que la cadencia de trenes sea homogénea.

Al ser bloques independientes, solo se comunican entre si enviando se trenes... Y con el sistema de cantones se previene que haya colisiones, pues un tren solo entra en un Cantón si esta libre. Habría que programar, se me ocurre, en cada estación para que si detecta trenes entrando se salte los timers internos y saque un tren para dejar espacio y que haya fluidez.

Sigo teniendo pendiente leer con calma tu web para ver cual es el sensor ese que permite leer sensores externos de contacto... Pero ahora me quedo sin tiempo, que mi mujer me dice que vaya para la cama de una vez :P mañana sigo e intento ser menos abstracto y pintar los bloques de funciones... Ea, mañana mas

ok, Puli, vamos bien pues con el espíritu Zen...

En su momento, cuando pensaba en todo esto, y leyendo otros modelos, pensé en el tema de los cantones. Pero le encontré un problema "mu gordo" para lo que andaba pensando, quizás por mi desconocimiento: ese sistema multiplicaría los IRLink a lo largo del circuito.

Ya me corriges, pero el sistema de cantones implica la capacidad de poder parar un tren en sus límites ¿es así?. Quiero decir, bien a la entrada o bien antes de abandonarlo. Eso, así a bote pronto, implicaría un IRLink por cantón, lo que lo hace casi inviable ¿no? 

Trasladando el concepto de cantones al estándar con el que estoy, sería así:

- Si hay 1 módulo (1 solo NXT y 1 IRLink) solo hay un cantón. Es decir, 1 solo tren en circulación, pero al menos siempre hay 1.
- Si hay 2 módulos (2 NXT y 2 IRLink) hay 2 cantones, el de ida y el de vuelta. Ya tenemos 2 trenes simultáneos. etc

De esta forma, toda la gestión (emisión-recepción) recae en cada estación. 

Cita de: pulipuli en 14 de Enero de 2012, 00:23:20 AM
Sigo teniendo pendiente leer con calma tu web para ver cual es el sensor ese que permite leer sensores externos de contacto...

Aquí tienes la forma de leer un pulsador (o un Reed Switch):

http://www.nxtorm.es/digitales/sd-g-un-switch.html (http://www.nxtorm.es/digitales/sd-g-un-switch.html)

En la sección justo a continuación, viene como conectar 8 pulsadores. Se puede llegar hasta 128 si no recuerdo mal, doy también la forma de hacerlo pero más adelante. Lo malo es que NXT-G es un lenguaje poco versátil para programar todo esto. Quiero decir, no es precisamente C y la cosa se hace muy muy engorrosa, pero poder, se puede.

Bien!!!, veo que es sencillo y barato leer interruptores. Se le puede añadir a lo sumo un ci para que convierta la información de 255 pulsadores/sensores a los 8 bits del Pfc8574 y así ampliar el numero de sensores usando solo un puerto del nxt.

Vuelvo a la carga con lo de los módulos, aunque estoy con el tablet y no puedo ponerme a dibujar. Para entender el texto, se puede seguir el dibujo que puse mas arriba.

Modulo estación
//define el comportamiento de una estación no terminal, con trenes en un unico sentido, visto desde fuera y sin importar el numero de vías que tenga o su funcionamiento interno

Entradas
Tren detectado a la entrada: código tren
//indica que un tren se aproxima a la entrada, y nos dice el código del tren si se uso un sensor capaz de identificarlo. El código será 0 si no se detecta un tren y un valor superior a 0 si se identifica un tren. Si el sensor solo detecta un tren, vale cualquier valor (por defecto 1), si detecta tipos de tren por color o de otro modo, indica un código. Pendiente de definir

Tren en vía (numero de vía): verdadero/falso
//indica si un tren está en el punto de parada en una vía. Pongo el numero de vía como argumento para que el modulo sirva para estaciones de 1 a N vías

Tren saliendo de Cantón de salida
//la estación tiene que llevar internamente el estado de libre/ocupado del Cantón de salida. Cuando un tren atraviesa la salida del cantón, el modulo debe detectar el flanco de bajada (es decir, detecta cuando ya ha salido). Importante: dependiendo del tipo de sensor empleado, habrá que depurar esta entrada... P.ej. Si se usa un sensor magnético ubicado en la cabecera del tren se puede quedar la cola parada dentro del cantón

Salidas del modulo
Parar tren (código de tren)
//si la estación no está lista o no tiene capacidad para albergar un tren más, debe detenerlo. Si se sabe el código del tren que entra, parará solo ese tren, si no, parará todos por si las moscas.
//también se usará para detener un tren en un andén.

Arrancar tren entrante(tren, velocidad, tiempo)
//lo inverso al anterior, hace entrar el tren a la estación o salir de un andén. Debe saber qué tren es, lo cual me lleva a pensar que es necesario un detector de tren a la entrada... Luego explico al final como hacerlo con interruptores magnéticos sencillos y baratos e imanes adheridos bajo el tren
//se puede indicar la velocidad a la que mover el tren.
//se puede mantener la orden durante un tiempo o hacer que se de una orden permanente si el valor de tiempo es cero.

Activar desvío (código desvío, izquierda/derecha, tiempo)
//acciona un desvío concreto y lo deja en la posición deseada. el parámetro de tiempo indica durante cuanto tiempo se debe activar el desvío pues según su diseño unos tardarán más que otros o incluso puede que un tipo de desvío solo necesite un pulso para activarlo y él se encarga automáticamente de arrancar y parar. Si tiempo=0, la activación es infinita, hasta que llegue otra orden. Esto permite desvíos accionados por un interruptor que se detienen solos al final del recorrido del motor/servo

Variables internas
Estado desvio(desvio)
//Debe conocerse siempre el estado de todos los desvíos motorizados. Cada desvio podrá estar a la izquierda o derecha. Devuelve el estado de un desvio concreto

Tren en via(vía)
//devuelve el código del tren presente en una vía concreta

Posición del tren (tren); vía, Cantón
//devuelve dos variables, la vía en la que esta el tren y el Cantón. Así sabemos donde esta cada tren, entrando, saliendo, o en una vía


Tren en Cantón de salida
//cuando un tren haya atravesado el sensor del Cantón de salida, esta variable se pone como falso. Cuando se saque un tren de la estactón, esta variable se etiquetará como verdadero.

Funciones internas

Tren entrando en estación (código del tren)
//Se lanza cuando se activa la entrada de un tren entrando en la estación en el flanco de subida
Si los desvíos apuntan a una vía libre, no hace nada o simplemente baja la velocidad del tren entrante
Si no apuntan a una vía libre, detiene el tren, localiza la vía a la que enviarlo, cambia los desvíos, y envía al tren la orden de marcha a baja velocidad
Se puede complicar definiendo etiquetas para acciones por tipo de tren, como trenes en paso, que enviará por una vía en paso libre sin bajar la velocidad, trenes largos que enviara a una vía determinada, etc

Desviar tren entrante a vía (vía)
//acciona los desvíos para que apunten a la vía señalada. Esta función debe conocer la topología de los desvíos y vías de la estación

Cola de salida de trenes (tren)
//función a ejecutar cada vez que un tren deba abandonar la estación, tanto si estaba parado en un anden como si es un tren en paso.
Añade un tren a la cola de salida, no hace nada mas

Salida de trenes
//esta funcion es un bucle continuo que comprueba la cola de salida de la estación y saca los trenes por orden.
//si hay un tren en la cola de salida, arranca la maniobra de sacar tren, si no, espera a que haya un tren. Si el Cantón de salida está ocupado, da la instrucción de parar el tren (por si era un tren en paso)y espera a que esté libre. Cuando el Cantón de salida esté libre, da la instrucción de marcha. Cuando el sensor de la via en la que estaba elmtren está libre, limpia la variable de la vía en la que estaba el tren. Espera a que el Cantón de salida esté libre y solo entonces quita el tren de la cola y vuelve al principio para sacar el siguiente tren de la cola.
La función A cada paso que da actualiza la variable de posición del tren.

Ahora no puedo seguir, luego lo repaso, lo paso a limpio, e intento dibujar los bloques. La definición del modulo es un poco enrevesada porque esta pensada para estaciones grandes o pequeñas, pero se puede simplificar mucho. Lo bueno es que facilita mucho la vida al programar el modulo.

Me queda pendiente lo de aclarar como hacer un detector de códigos de trenes con imanes de forma bar ata y sencilla

Enviado desde el tablet, disculpad las faltas de ortografía

Pulipuli, sigo sin tener claro cómo enviarás las órdenes a los trenes. ¿1 IRLink en cada posición o cantón o semáforo en los que el tren deba parar o arrancar? Si es así, eso es un pastizal... Lo digo por tener claro el "hard" antes de entender a fondo la parte de programación.

Por mi parte sigo haciendo progresos. Confirmo que un sensor de color estándar antes del desvío delante de la estación es suficiente para detectar el paso del tren. Le he añadido una función de autocalibración según la luz ambiente, ya que ésta influye mucho y puede dar al traste con la detección. A una mala, se puede poner una pared de bricks blancos enfrente para convertirlo en una fotocélula por reflexión más segura, pero no es necesario.

Con paciencia creo que lo acabaré sacando adelante, aunque no se si me dará tiempo a ajustarlo todo y sacar el video para mañana. Ya veremos.

La idea es un único irlink por modulo, y si resolvemos la limitación de motores, un modulo puede controlar todo un dio rama. El modulo de estación controla solo una estación, y si en el nxt cabe algo mas es donde podría haber problemas de cobertura si el circuito es grande. El cantón de salida, aunque sea larguísimo no necesita dar ordenes mas que a su entrada, lo que si que hay que llevar es un cable a la salida para poner el detector de tren saliendo.

En el peor caso, se pueden usar repetidores ir que no son tan caros como un irlink.

El detector de tren por imanes necesita cuatro sensores magnéticos que se ponen en la vía separados entre si 8mm, es decir, un stud. El código de cada tren se monta en una plate de 4 studs, poniendo o quitando en cada stud un imán pequeño de 4mm... Un lote de 50imanes salía por unos 10euros creo recordar. Lo importante es probar en imanes distintos para que no de error de lectura el que un imán muy potente active no el sensor que tiene debajo sino al de al lado también, es cuestión de hacer unas pruebas.

El plate con el código se adhiere a los bajos del tren, por lo que queda centrado con el sensor del suelo. Al pasar por encima se activaran solo alguno de los cuatro imanes,por lo que detectaría hasta 15 trenes diferentes. Como digo el único problema es que se usen imanes tan potentes que activen también el sensor de al lado o tan poco potentes que haya que ponerlos rozando el suelo, pero es cuestión de hacer unas pruebas.

El hard de un modulo de estacion es el ladrillo nxt, tantos sensores como vías, uno para el Cantón de salida y uno de 4 contactos (o sensor de color) para la entrada. Un irlink y tantos motores como desvíos. Si se consigue activar motores usando una salida y algo de hardware soldado (barato y sencillo, si no, lo descarto), un único ladrillo puede controlar un circuito grande y complejo... El limite son las entradas y salidas que se logren meter al ladrillo y su capacidad de proceso. El código, si se hace modular, puede ser un montón de bloques repetidos a base de copy paste, programas una vez y te olvidas.

Como proyecto vivo y en el que en cierta manera me siento identificado, porque uno de mis objetivos es automatizar un GBC con tren, he de decir que este tema me tiene enamorado.
En cuanto acabe exámenes quiero proponer alguna cosa al respecto, pero tengo que probar antes.

Nominado a MDM del mes  :}

Lo primero de todo, agradecer la nominación de Blastem. Y lo segundo... me arremango y al tema.

Una cuestión previa para aclararnos: usaré como "módulo" tu segunda imagen o mi "módulo estándar", que en el caso de un único NXT es totalmente coincidente (ya tenemos algo).

Bueno, pues la verdad es que voy aclarando poco a poco lo que propones, pero me da la sensación de que me pierdo en cosas fundamentales, no consigo hacerme una idea de conjunto, torpe que es uno. Digo esto por lo siguiente: propones el tema de codificar los trenes, pero el módulo solo dispone de 2 andenes. Ya aclarabas al final de otro mensaje que "1 IRLink y tantos motores como desvíos", entiendo que para los andenes. Ahora mismo estoy con pruebas reales en mi comedor, no quieras ver cómo está esto. Cuento con 2 andenes y un sensor de color.

Añadiendo un tercer andén, tendría que elevar el IRLink para que cubriera las 3 vías y entonces el cable del sensor de color ya no llegaría. Si pusiéramos en el módulo estándar 4 andenes,  el IRLink tendría que estar a unos 45cm de altura sobre las vías para cubrir los 36 cm de separación de esas 4 vías!! (ver review del sensor). Tampoco conozco el "repetidor" del que hablas, solo conozco el IRLInk.

En fin, que sobre el papel lo veo factible, pero al trasladarlo a la realidad, se me complica la imagen de lo que voy entendiendo que propones. Te pediría Puli que hiciéramos al revés, que me dieras tu opinión (bueno, la de cualquiera que quiera opinar) sobre el estándar (http://www.hispalug.com/foro/index.php?topic=14680.msg247723#msg247723) que propongo, dudas, reservas, desacuerdos, etc. Me servirá a mi también para aclararme con lo que dices y que intentáramos mejorarlo con tus propuestas (y las nuevas opiniones también) si es que es un buen estándar.

Haré un poco de campaña al respecto:
El GBC y el microCity funcionan con un módulo muy sencillo, simple más bien. La complejidad allí se consigue por adición de módulos, no por dotar de mucha funcionalidad al módulo básico. Esa es la idea, "copiar" la filosofía que ha funcionado en otros ejemplos.

Trenes es un poco diferente, pero siguiendo esta idea, el estándar permite ampliar todos los usuarios que quieran entrar, aunque quisiera participar el foro entero. Esto es posible porque todos los trenes que circulan entre estación y estación se mueven en el canal 1A. Y permite meter el trazado entre toda la city presente en el diorama, ya que el trazado puede ser libre.

He puesto 2 andenes por simplicidad, es lo mínimo para un cambio de tren en cada estación. Con ello se necesitan 2 receptores IR (4 canales de PF estándar): 2 canales para 2 trenes y 2 canales para 2 desvíos. Incorporar más desvíos al módulo básico implica meter más receptores IR, más altura del IRLink, más longitud de cables del NXT, más desvíos... Cuantos más elementos, más programación, más encarece y más se complica que un usuario lo pueda reproducir para hacer pruebas en casa y llevarlo ya configurado.

Cada nueva estación, incorpora 2 nuevos trenes funcionando, sin límite de estaciones. Otra ventaja es que el programa también es único y estándar. Meter variaciones en el NXT-g según la configuración de cada estación si éstas fueran distintas sería un cacao a la hora de cuadrarlo en un evento.

Y para más gracia, no es necesario codificar trenes, evitando cables adicionales y meter la programación en NXT-G, que sería compleja por lo engorroso de programar ahí cosas extensas. Solo la programación del ejemplo que estoy haciendo ya ocupa un trozo.

Aunque lo parezca, perfecto no lo veo (y más ahora que lo estoy programando), también le veo puntos débiles, pero de momento no digo nada porque quizás los pueda solucionar (van por el tema de programación).
Lo dejo aquí para no extenderme más, ya me das tu opinión al respecto.

Y de las últimas cuestiones que comentabas, sí te puedo aportar alguna prueba con imanes si te sirve la información, ya me dices. Tengo algunos imanes por casa y sensores Reed (SDK). Lo veo complicado de instalar como dices porque me dió la sensación de que necesitan un imán relativamente gordo y cercano para activarse (tipo enganche de tren), pero si quieres puedo probar cosas cuando pueda (ahora no) y te digo. Un saludo

Bueno, cuento por encima para profanos en que consistiría un modulo de entradas y otro de salidas? La página de nxtorm tiene unos capitulillos muy bien explicados que todos deberíamos entender pues es un montaje MUY asequible tanto en precio como en facilidad de montaje

Modulo de entradas.
Hay un chip que sabe transmitir la información digital presente en ocho puntos al bus del nxt. El chip lo hace todo, nosotros solo debemos poner en cada pin una tensión de 5v p.ej cerrando un interruptor, y el chip envía instantáneamente la información al nxt.

El chip lo podemos alimentar con un interruptor simple y una resistencia, o de mil maneras. Como ejemplo,modelos usar interruptores magnéticos que se cierran al aproximarles un imán, una fotocélula que detecta cuando hay o no luz, un micro que detecta cuando hay sonido, un foto detector que detecta cuando hay un objeto que pasa junto a él, etc. Si no sabemos de electrónica no hay que preocuparse en como funciona cada submodulo, serán media docena de componentes que valen unos céntimos cada uno y se montan así o asá

Módulo de salidas
El mismo chip del módulo de entradas puede transmitir la información del nxt a 8 pines. Podemos pedir que se activen o desactiven originando con ello acciones. La aciión más sencilla es activar un LED, pero usando un pequeño circuito de media docena de componentes, podemos hacer que active un motor. Si el circuitín lo es algo más complejo, podemos incluso conseguir que el motor se encienda para más o menos potencia y en un sentido u otro.

Si ponemos a cualquiera de los módulos un chip más, con los 8 bits que da un módulo básico podemos leer la información de hasta 256 puntos. Si quisiéramos p.ej. Implementar un sensor de cantidad de luz, podríamos usar hasta 256 niveles de intensidad, pero como en este proyecto queremos recibir solo información de encendido/apagado, podemos recibir información de hasta 256 puntos usando solo un puerto de sensor del nxt.

Por las mismas, un modulo de salida podría usarse para encender una bombilla con 256niveles de intensidad, o bien controlar el encendidomo apagado de hasta 256 dispositivos usando un único puerto del nxt.

Traducido esto a lenguaje vulgar, si me gasto unos pocos eurillos (muchos menos de lo que cuesta un sensor barato del nxt) y tengo una plaquita de circuito impreso, un soldador, estaño, y un alicate, puedo hacer una cajita de la que salgan hasta 256 cables con los que leer hasta 256 interruptores o sensores de información binaria (On/off, luz/oscuridad, sonido/silencio, detecto algo/no detecto nada), y otra cajita con la que encender o apagar hasta 256 dispositivos varios.

La caja de entrada es la mas simple, al menos si lo que quiero detectar es apertura o cierre de interruptores/contactos, la de salida requiere que si quiero controlar un motor ponga antes un pequeño circuitín para que pueda darle toda la corriente de alimentación, ya que el chip de control da sólo una tensión baja y con poca corriente... Ese circuitín es muy sencillo, un transistor y tres o cuatro resistencias, que son componente muy baratos (céntimos) que podemos poner junto al motor camuflados p.ej. Dentro de un brick 2x4

Con tantos puertos para un nxt se pueden hacer palomitas, ya que al igual que los sensores comerciales de nxt leen solo una magnitud pero con muchas posibles graduaciones, con estos caseros no vamos a poder detectar muchas graduaciones por puerto, sino muchos sensores sencillos

Por ahora, para las pruebas, se stá trabajando en un esquema sencillo, en el que solo se usan los 8 bits del circuito integrado que se comunica con el nxt, pero aun así permite leer la información de 8 interruptores o activar hasta 8 motores con un solo puerto, lo cual es mucho mas de lo que da un ladrillo nxt con sensores comerciales.

La programación nxt-g es sencilla, si usáramos las 256potenciales entradas solo habría que preguntar al sensor "haz esto cuando el sensor tenga un uno valor 37" pues eso implicaría que se ha activado el interruptor/contacto/puerto 37. Si trabajamos solo con 8 puertos la programación es un pelín más liosa, pues hay que interpretar los puertos en binario... Así, el primer pin de todos bastará con preguntar al sensor si se ha activado un numero par, el segundo si es múltiplo de 4, etc... Con una tabla como la que pone nxtorm en su web se hace rápido, pero esa pequeña dificultad añadida es el precio a pagar por tener un esquema eléctrico mas sencillo te, con solo un chip.

Moraleja:

el que quiera meterse en la parte de electrónica del proyecto podrá ponerse a jugar con pastilla tras, cables y placas de prueba, y el resultado de su trabajo serán unos esquemas eléctricos, un listado de componentes, un dibujo de placa de circuito impreso sobre la que soldar, y las instrucciones para hacerlo.  Con que esto lo haga una persona es suficiente, pero para ser productivos, como en todo, está bien que alguien más opine o contraste opiniones para que el desarrollo sea mas fluido y estar mas motivados

Lo mismo con la programación, habrá quien esté acostumbrado a programar en nxt-g y no le cueste hacer programo tras varios... Otros como yo que no están acostumbrados al entorno de programación pero que se les da bien el ver los módulos de programa como bloques relacionados entre sí, y otros que solo quieran hacer copy paste para probar sus circuitos

Por ultimo, habrá quien quiera solo pasar a ver que se cuece, y biene muy bien que esas personas den sunopinión abstrayéndose de las tripas y centrándose en el funcionamiento. Solo hay que tener ganas de leer mucho, y proponer ideas, que alguien habrá quien las aplique a sus campos de conocimiento y entre todos avanzaremos a tope

Ah, y no sempuedemolvidarbalmconstructor de lego sin mas que puede probar soluciones para construir o decorar desvíos, camuflar sensoresny cables... Todas las contribuciones pesan por igual porque el resultado final requiere tocar todos los palos, y es muy valiosa la aportación incluso del que solo pasa a ver que se cuece e idea una forma de escamotear un sensor entre dos bricks, que si no lo hace el, otro tendrá que hacerlo

En otro orden de cosas, alguien conoce algún libro o web de modelásemos ferroviario de la que pueda aprender como plantear el funcionamiento de un dio rama? Igual que me costó un buen rato hacerme a los rudimentos del funcionamiento de los cantones, seguro que hay algún sitio donde pueda leer algo que me facilite la visión de conjunto de un gran diorama para así poderlo aplicar a nuestros módulos

Quiero pasar a limpio el bloque de estación, y aprovechare para pensar como funcionaría una estación bidireccional, pero eso mejor para mas adelante que por ahora con el esquema simple es mas que suficiente

Igual que dije en el otro hilo, si alguien se pierde o no entiende algo que pregunte. Es preferible ir mas despacio si podemos ser más personas aportando ideas, porque no hay prisa y cualquier idea por peregrina que parezca es valiosa. Animaos a escribir algo los que solo sois lectores del hilo, que seguro que podéis aunque solo sea preguntar dudas... Por ahí se empieza jejeje

PD: enviado desde el móvil, disculpad las faltas de ortografía y los palabros raros

Sorrostrada por el flooding, hemos cruzado mensajes.

Nxtorm, yo tiendo a pensar en abstracto el modulo de una estación lo mas genérico posible, para que abarque de lo mas sencillo a lo mas complejo. Luego, una vez hecho el diseño abstracto, es muy fácil recortar e implementar casos específicos. Un ejemplo es como traducir mi "ladrillo" a las pruebas que estás haciendo: no hay sensor de trenes, sino un detector de color, solo dos vías... El módulo se simplifica mucho. A la hora de programarlo, se obviaran variables y entradas, pero el funcionamiento básico es el mismo: un bloque de programa que espere a tener un tren a la entrada para ver que hace con él, un bloque que gestione la salida de trenes, y en tu caso otro que gestione los circuitos corto y largo. Los cantones de entrada y salida de cada modulo requerirán sensores, y en tu implementación irán a este o aquel canal... Son detalles de implementación.

No queramos que las pruebas sean el estándar, sino solo pruebas para ver que quitar o poner para hacer un estándar. Vale que se aproximan mucho a la realidad, pero creo que si se piensa en abstracto, luego solo hay que aterrizar el concepto, pero si empezamos desde el suelo habrá que subir y baja varias veces cada vez que se añada o quite algo. El resultado final será como dices algo muy sencillo, unos diagramas de vías, una forma de numerar sensores y motores y una forma de poner el irlink para que cubra el espacio a controlar, además de un bloque de programa con unas variables que permitan ajustar el funcionamiento cuando juntas un modulo con otros.

Sobre el extensos de Ir, hay cachar ritos que reciben los ir en una banda y los transmiten normalmente mediante un cable para emitirlos de nuevo en otro punto. No son muy caros y se podría probar si pueden usarse para que un solo irlink controle una zona mas grande.

Me encantan las pruebas que estas haciendo, tienen mu buena pinta y seguro que funcionan a nada que le dediques un rato, son el germen de algo grande. De todas las cosas que me pasaron por la cabeza a la hora de pensar en el modulo abstracto, solo creo que deberías tener en cuenta los dos bloques básicos del programa, uno que permite a los trenes entrar y otro que les da salida. En el de salida, implementaría una cola para que el modulo dos partes del programa no intenten sacar a la vez los trenes, sino que todas las partes del programa los encolen y haya un bucle mirando esa cola y saquen al tren que toca cuando puedan. Si todo va como esperamos todos con ansia,yo,lo complicaría un poco para luego simplificarlo todo recortando lo superfluo, y así podrás dejar mas cosas probadas. Yo voy a intentar dedicar un rato a los moldes de conectores de motores, y otro a probar a hacer unos módulos de entradamy salida como los de tu web para verlo físicamente, además de aprender a programar nxt-g de una vez, que me da rabia verlo todo desde tan arriba y no poder aterrizar las ideas por falta de conocimiento especializado

ok Puli, gracias. Cualquier duda al respecto de NXT-G, a tu disposición.

Lo malo de los "repetidores" de IR es que la info de Power Functions va codificada, así que será complicado. Parece que tenemos aproximaciones distintas, tu vas "podando". Es perfecto. Seguro que aporta cosas, ya que yo parto de una idea distinta y es dejarlo en mínimos para ampliar con más módulos.

Respecto a dedicarle un rato... estoy a piñón... tengo grandes avances y seguro que sale y subo el video, pero ahora mismo, lo que más más me está dando por... quiero decir, lo que más problemas me está dando es el desvío que posteé en el otro hilo. Pero ya caerá, ya... Es menos "robusto" de lo que pensé en un principio cuando lo gestiono con el NXT. Eso sí, los trenes aceptan las órdenes perfectamente, salen cuando toca, no salen a la vez, paran bien, etc. Lo dicho, a ver si me hago con ello y puedo presentar algo en breve.

Comentarios de las pruebas: dada la inercia del tren cuando para, no se queda debajo justo del sensor, pero en el siguiente ciclo se activa bien y sin problemas. Para que lo tengas en cuenta. La realidad es lo que tiene. Y lo segundo, la función de autocalibración del sensor de color no solo va perfecta sino que además es necesaria, ya que la luz ambiente varía mucho a lo largo del día. Si alguien quiere detalles al respecto, que hable.

miraré con calma los repetidores buscando algunos por internet y viendo experiencias, y luego compraré alguno y haré pruebas con los mandos de trenes PF a ver como va la cosa. Creo que tengo alguno básico de algún extensor de TV que andará sepultado en el taller... es un sitio por donde empezar.

Todo se anda a pasitos, sin prisas, jeje, ¿alguien tiene prisa? cuando se avanza, se avanzó, cuando no... pues damos palique y hablamos de otras cosas que no todo es cebarse con los puntos críticos ;) Sobre las inercias, un punto a tener en cuenta es frenar al tren cuando entra en la estación, así se quedará parado más cerca del sensor y no saldrá arrastrando. Lo importante es que se quede parado, el programa ya sabe que está en la vía por lo que da igual un poquito más alante o atrás, mientras no se meta de cabeza al cruce estorbando. Es un problema más estético que funcional.

Lo de la autocalibración, ¿como la haces? supongo que la hará el programa al arrancar, viendo lo que mide el valor e la pared blanca de enfrente, pero no se como programas el que detecte un color u otro a partir de ese valor... la verdad es que estoy algo pez en el tema, por lo que cualquier refresco es bienvenido.

ok, perfecto Puli.

Respecto de las inercias, lo he resuelto orientando de nuevo el sensor, más centrado con las vías. Para parar el tren a la entrada de la estación se necesitaría un IRLink adicional. Pararía al tren justo debajo del segundo segundo sensor. Es la ventaja de poder experimentar en casa, luego te (os) puedo contar los avances.

Para la autocalibración, uso lo siguiente (más o menos, aquí está adaptado):  (pincha en la imagen para agrandar)

(http://www.hispalug.com/galeria/albums/userpics/45155/calib_luz_ok.jpg) (http://www.hispalug.com/galeria/albums/userpics/45155/calib_luz_ok.jpg)

Usa el sensor de color en modo "sensor de luz". Ninguna luz del sensor está encendida. La lectura sin tren delante oscila entre 42-43 ahora mismo, pero esto cambia. Con tren, según el color, 15.

El programa inicia leyendo la luz ambiental, que se almacena en una variable. Esto se repite en cada ciclo, cada 5 minutos aprox. Luego compara ese valor con el valor actual y si es menor, es que delante tiene un tren. En ese momento, el programa deja el bucle y avanza. Lo del  "-3" es por seguridad, para posibles fluctuaciones de luz. Espero que se entienda.

Bueno, y hace un rato he conseguido que funcione todo!!! oeoeoeoe!!.   :) Voy a editar, subir, etc y de aquí a un rato lanzo el video... con las explicaciones oportunas, que no os váis a librar. Ale, luego más. 

Mosquis, que poquito alcance tiene el puñetero IRlink, si hay que poner dos para una estación me parece una pasada.

Ya estoy deseando ver ese vídeo :) jeje, un pequeño paso para el minifig y un gran paso para la humanidad :D

jajja, si, así es.

Bueno, después de mil ajustes, por fin he depurado el programa y ha salido. El vídeo es tal cual, a la primera toma, y sin retoques ni nada. El pobrecito Emerald, después de tantas pruebas, está sequito de batería, así que va despacito. A un poco más de mitad del vídeo, se acelera 4x el vídeo. Todo lo que va antes es un ciclo, y lo que va después, otro.

http://www.youtube.com/watch?v=TMs_j0yBuNE# (http://www.youtube.com/watch?v=TMs_j0yBuNE#)

Un ciclo consiste en: circulación de un tren (cada vez uno) por el circuito corto interno (cercanías). En paralelo, un reloj del programa cronometra 5 minutos (bueno, en el caso del vídeo lo he dejado en 1 min). Pasado ese tiempo, un tren es enviado por el circuito exterior, da la vuelta y llega de nuevo a la estación. Entonces el ciclo se repite.

Los trenes son detectados por un sensor de color a la entrada de la estación.

Como podéis ver, el primer y el segundo ciclo no han expedido el mismo número de trenes. Supongo que se debe a que he tocado los cronómetros para el video, no he probado más. Eso es ya solo cuestión de ajustar.

Para añadir un segundo módulo, tal como ya expliqué en el estándar (http://www.hispalug.com/foro/index.php?topic=14680.msg247723#msg247723), al que por cierto tendré que hacer algún retoque después de la experiencia acumulada:

(http://www.hispalug.com/galeria/albums/userpics/45155/a1_dos.jpg)

Si tuviera ocasión, intentaré "testarlo" para 2 estaciones y 4 trenes con algún valenciano que se preste, paellita mediante. Si no va mal, simplemente es cuestión de duplicar el circuito, cargar el programa y listo. Ahora me queda documentar más el tema, escuchar opiniones y ver si puede resultar útil en eventos, ya decís.

Yo creo que puede funcionar y es 100% LEGO. Seguro que es posible mejorarlo con aportaciones, pero ya hay una base concreta sobre la que discutir. Bueno, y si no, me lo he pasado más que bien. Y sigo atento a los avances de Pulipuli  en este terreno y leander (y compañía) en el otro hilo. Ale, seguimos.

Como aplicación inicial es fantástica!!!

Atención, duda, respondeme pensando que nunca he usado desvíos. :E
La aguja de salida de la "estación" está en una posición intermedia para que pasen los trenes? No descarrilan?

Me gusta que sea todo LEGO y es una gran base para empezar a pensar en automatizar dioramas con RC  :}

Los trenes pasan igual en cualquier posición, porque la aguja tiene un muellecito que permite que se pueda mover aun estando bloqueada.
Lo que ocurre es que algunos trenes que pesen poco la aguja se queda bloqueada por que no tienen el peso suficiente como para quedarse pegados a la vía y desplazar la aguja entonces si que pueden descarrilar.



SaLuDoS.

Me gusta, se que solo es una prueba, pero se podría tener los dos trenes a la vez en marcha? o en sentidos opuestos??

Solo con que funcione bien asi, tal cual ya es un primer éxito, muy importante para estos mega-proyectos.

hay que camuflar un poco el emisor que ro va genial, lo único que le veo es que si los trenes van rápido o la sala tiene luz fluorescente puede que el tren no capte la orden de parada. Yo pondría el sensor de ultrasonidos delante de la salida de trenes para verificar que el tren ha llegado y se a parado, para que no salga el otro.

SaLuDoS.

Gracias!

Cita de: Blastem en 15 de Enero de 2012, 19:50:39 PM
La aguja de salida de la "estación" está en una posición intermedia para que pasen los trenes? No descarrilan?

Como bien dice Dani, es el muellecito el que evita el problema. El desvío es una "Y". Cuando el tren entra por arriba de la Y, da igual cómo esté el desvío, sale por abajo de la "Y". Solo cuando entra por abajo es cuando el tren va a un lado o a otro.

Cita de: Parda en 15 de Enero de 2012, 20:27:34 PM
Me gusta, se que solo es una prueba, pero se podría tener los dos trenes a la vez en marcha? o en sentidos opuestos??

A la primera, creo que no hay problema. Con configurar el NXT con el programa A y el B, quedaría solucionado. Con tal de que el tren del circuito corto llegue antes y se pare, no habría problema. A fin de cuentas, el "tren regional" (entre estación y estación) siempre debe ser un circuito bastante más largo y debería darle tiempo. Aunque es un poco peligroso...

A la segunda, creo que solo si los andenes son muy largos. Me explico: imagina los dos trenes parados en la estación, mirando en sentidos contrarios y con el IRLink arriba. El IRLink los habrá parado justo cuando la locomotora con el receptor estuviera justo debajo. Por tanto las colas de los trenes apuntarán en sentidos contrarios, con las locomotoras a la misma altura en paralelo. No quedaría muy bonito, pero así pararían.  Espero haberme explicado algo.

Cita de: daniracer en 15 de Enero de 2012, 20:35:50 PM
[...]lo único que le veo es que si los trenes van rápido o la sala tiene luz fluorescente puede que el tren no capte la orden de parada. Yo pondría el sensor de ultrasonidos[...]

La info del IRLink va codificada, no creo que interfiera, pero tampoco puedo poner la mano en el fuego. A mi nunca me ha dado problema por ese motivo. El problema del Ultrasonidos es la zona muerta, y habría que separarlo sficientemente de las vías (y del público!) pero desde luego es una opción.

Lo de la velocidad SI puede ser un problema. El vídeo está hecho a velocidad 3 para ambos. El mercancías va bastante más rápido y ese ha sido uno de los ajustes para que no diera problemas, y lo he resuelto, pero no he probado a más velocidad. También es cierto que el mercancías iba sin mercancías... :D

Y, tomándome una cierta libertad, añado aquí la respuesta a un comentario de Hoexbroe publicado en Proyectos de automatización de trenes PF (http://www.hispalug.com/foro/index.php?topic=14783.msg248987#msg248987) para guardar la coherencia del hilo:

Por otro lado tampoco veo factible el sistema propuesto por Nxtorm, en el sentido que no es suficientemente solida la idea de usar varios IR´s con el mismo canal, y intentar "apantallarles" entre si, para no mezclar los ordenenes. Creo que nunca va a funcionar en una exposicion en la vida real.

Para que el sistema sea viable y valido para una LUG, opino que debe ser "standard" Lego. Dificil! [...]

2) Como suele ser habitual en sistemas similares al que usa Lego, un poco de "hacking" del receptor y emisor POSIBLEMENTE (¿me atrevo decir "probablemente"?) mostraria muchas más canales disponibles que los 4x2 que usa Lego en sus productos actuales. Asi podria usarse el sistema propuesto por Nxtorm, haciendo usa de estos "ocultos" canales, evitando el problema de la necesidad de "apantallar" emisores con el mismo canal.
Inconveniente; No es "standard" tener que modificar electronicamente el receptor IR, aunque me imagino que se podria realizar sigiendo una guia, bastante sencillo, y sobre el NXT supongo que no necesita ninguna modificacion...¿?

El IRLink tiene tan poca potencia si lo pones en vertical y a poca altura que no es necesario en absoluto apantallar, no es ningún problema. Por darte un ejemplo, en el vídeo de más arriba está a unos 20 cm aprox de altura. Al principio de los ajustes, con el sensor más bajo, en las "pasadas de frenada" cuando llegaban a la estación ya no conseguía comunicarme con ellos en el siguiente ciclo por estar fuera de rango. Es decir, 4 o 5 cm fuera del alcance bajo el sensor y dejaba de funcionar. Lo mismo en vías laterales. Así que de estación a estación ni te cuento, no llega nada y de verdad que he hecho muchas pruebas al sensor. Lógicamente, si elevas el sensor tiene más campo útil, pero ni así sería problema, ya que la señal va en vertical.

Por tanto, la opción 2) no se hace necesaria, aunque algo he leído y a mí tambien me suena que esa opción de trastear el receptor es posible (creo que algo puso yagodiaz). De todas formas, intentaré hacer más pruebas y si puedo subo un vídeo y ya ves. El único problema real de interferencias en un evento podría venir cuando Sheepo y Parda se pongan a hacer una carrera de coches RC, ahí sí que habría que parar los trenes  xD

PD. Puli, no desaparezcas, que (espero) aquí aún hay mucho que rascar y seguro que sacamos algo por un sitio o por otro entre tod@s  ;). No me resisto a que podamos tener un tren algo más automatizado en algún próximo evento. 

Esque es un problema lo de la rapidez por que puesto que no puedes cambiar el programa según el tren que pongas... por eso te dige de poner el infra al final de la vía para que sea instantáneo, (llega el tren y se para) de lo contrario te puedes quedar corto o incluso pasarte.

SaLuDoS.

Anda, no había visto el vídeo, ¡como mola!.
¡Animo! poco a poco.
Con el tema NXT yo ni papa, y me pierdo con las explicaciones y comentarios que poneis.

Jajaja, Leander, tu eres más de litrónica :D es normal que el NXT de primeras te suene a chino. Piensa que es un arduino que tiene posibilidad de meter 4 sensores y tres motores PaP, que se comunica con los sensores usando I2C bus, y que se puede programar en Java, C... aunque la herramienta preferida de la comunidad es NXT-G, un entorno 100% gráfico donde no picas texto sino que insertas instrucciones que son iconos,  a los que puedes modificar parámetros. Como ves, está muy limitado en cuanto a puertos de sensores... pero es muy fácil de usar, y es 100% LEGO :)

NXTorm, enhorabuena por el resultado de las pruebas, es más que prometedor, y creo que no habría problema en enfrentarlo a un módulo equivalente para que dos estaciones se pasen trenes entre sí, y cada una tenga su circuito de cercanías, a lo sumo habría que añadir alguna pequeña puntillita... pero lo importante es que PROMETE!!!

A la pregunta de Parda, tal como está diseñado, puede tener los dos trenes en marcha, pero hay potenciales puntos de colisión como son el  cruce donde se unen los circuitos corto y largo. Se pueden implementar mecanismos para evitar la colisión a base de temporizadores o medición de velocidad media de cada tren, pero son pequeñas ñapas. Lo único que evitaría las colisiones es implementar más sensores y poder "parar/arrancar" allá donde sea necesario.

Por las mismas, si queremos implementar bidireccionalidad en los circuitos hay que añadir complejidad poniendo más sensores. Al final todo es cuestión de poner más sensores y aumentar el rango del IR-LINK, que para todas las ideas que tengo en la cabeza es con gran diferencia el principal escollo.

PD: NXTorm, no desaparezco jeje, sigo rascando, pero entre el trabajo, los niños, la casa... entro a ratitos mientras echo un pitillín con el móvil, mientras hago la cena con el ipad, mientras espero en el médico... a ver si junto un par de horitas con un PC y puedo avanzar un trecho en las especificaciones funcionales, intentando sacar una básica para poder unir dos circuitos como el que has implementado, cada uno con su vía de cercanías. Por cierto, ¿Qué alcance tiene el sensor de color que has puesto a la entrada? ¿cuanto se le puede separar de las vías?

He reprogramado el pic receptor para que cuando reciba la señal una vez deje el led encendido constantemente...
Me he llevado el emisor hasta el buzón que hay en la vuelta de la esquina (20 metros a ojo) y he apretado el botón... :P
...cuando he vuelto a casa ahi estaba... el led encendido  xD
A ver si me llegan el resto de los componentes para poder avanzar esta semana.  :_(

Me bajé a fumar un cigarro haciendo un kit-kat en el curro, y me puse a darle vueltas a "como vería yo un proyecto de trenes a lo grande", con bloques de software autónomos que controlan cada módulo sin necesidad de estar comunicados con el resto de bloques de software que controlan el resto del circuito, y he sacado unas cuantas conclusiones:

1.- Todo módulo de circuito debe tener a su entrada un detector de qué tren entra para poder pararlo. Si no se sabe que tren entra, no se sabe cual hay que parar
2.- Todo cantón de circuito (Cantón: tramo de vía única, sin desvíos, en el que como mucho puede haber un tren) debe tener a su salida un sensor para saber cuando se queda vacío. Ese sensor no hace falta que detecte el tren, sólo debe saber cuando queda vacío.
3.- Se pueden hacer circuitos bidireccionales, para ello es necesario tener sensores de detección de código de tren en cada una de las vías que entra/sale de un módulo.
4.- Todo módulo de circuito debe monitorizar el cantón o cantones de salida para saber cuando puede enviar un tren. Obviamente, si el módulo controla un tramo de vías (p.ej. el módulo de estación con circuitos corto y largo de NXTorm), no es necesario monitorizar ya que el propio programa sabe donde hay un tren en cada momento.
5.- La capacidad básica de direccionamiento de un sensor I2C 8574 son 8 puertos, y la máxima de 255 puertos. Esto obliga a que si se usa un sensor de tipo de tren con capacidad de hasta 7 máquinas (3 bits), se pueden implementar hasta 32 sensores (5 bits) por puerto del NXT, y si el sensor tiene capacidad de hasta 15 trenes (4 bits), se pueden implementar hasta 16 sensores por puerto del NXT.
6.- Si se implementa el control de los motores de los desvíos mediante puertos I2C con 8574, se gastan 2 bits por cada desvío, uno para girar a izquierda y otro para girar a derecha. El desvío debe llevar una pequeña electrónica que al recibir las órdenes por uno de esos dos pines, active el motor en el sentido correcto, y no hará nada si se recibe por las dos simultáneamente. Esto exige diseño electrónico. La otra opción es controlar los desvíos con puertos NXT estándar.
7.- El cableado de puertos de cualquier circuito debe estar planificado de antemano, y debe poder introducirse a los programas en forma de tabla preferiblemente para poder configurar el software fácilmente. De hacerse "a piñón fijo", cada vez que cambiemos un puerto de sitio en un módulo, vamos a tener que revisar toooooodo el código. No se si esto puede hacerse con NXT-G.
8.- Aunque más o menos creo que lo he comentado más arriba... cada vez que ponga un cruce con dos vías que pasan a una, hay que tener detectores en ambas, y tengo que tener la posibilidad de parar a uno de los dos trenes (con el algoritmo que sea). Así, cada cruce se puede considerar internamente como un pequeño sub-módulo. Si es un módulo independiente, los sensores deben ser capaces de saber qué tren es el que se aproxima, si es un sub-módulo de software, podrá saberlo consultando las variables del programa.

Y me surge alguna duda que los programadores NXT-G sabréis contestarme.
Cada módulo de software controlará un módulo de circuito, y será independiente del resto de módulos de software. ¿Puedo en un mismo NXT correr simultáneamente varios módulos? No se si se puede hacer directamente, o si tengo que guardar cada módulo en un fichero independiente y luego ir copiando y pegando los que vaya a utilizar en un nuevo proyecto, lanzando al principio del programa una bifurcación para que se ejecuten todos en paralelo.

Edito:
Para los que quieran juguetear un poco con circuitos digitales viendo lo que hacen o dejan de hacer las señales, un compi me ha recomendado este programa muy sencillito que te ahorra tener que estar pinchando y despinchando. Lo voy a usar para jugar a multiplexar/demultiplexar la salida de un PFC8574 y así tener las 255 entradas/salidas que puede proporcionar. Una vez "jugueteado", hay que hacer el diseño en fino con un programita más versátil, pero este te permite probar en la pantalla tirando hilitos antes de pinchar y despinchar

Hola,

Efectivemente habia colgado la mayoria de mis comentarios en el hilo equivocado; el de Leander.
Lo siento, ya que era más relevante aqui, asi que intento continuar aqui!

Con frenar "bruscamente", solo refiero a cortar la alimentacion al motor en lugar de bajar la velocidad secuencialmente dando ordenens por IR.
Es cierto que se necesita un interuptor fisico. Que tal ese;
(http://www.bricklink.com/PL/bb97.jpg?0) [pbricklink]bb97[/pbricklink]
Este funciona con "roce mecanico" y funciona de p.m. Tenia un set de esos (con dos semaforos) cuando era niño.

Con NXT´s comunicando entre ellos, pienso que no tiene porqué ser limitado a solo 3-4, pero enviando cadenas de bytes se puede direccionar más unidades, si todos los NXT que recibe el señal primera mira si es para ello; P.e; Si 10 NXTs ven el valor "3" en el primer byte recibido por comunicacion, solo el NXT con el programa numero 3 reacciona, ya que sabe que es el numero 3. -Como el sistema por radio-frecuencia de Leander.

Me interese mucho el video de Nxtorm, pero por desgracia no le puedo ver donde estoy ahora...

Madre mía, empiezo a estar desbordado... Bueno, muchas gracias por los ánimos, comentarios, etc. El video efectivamente es una prueba, pero ha funcionado perfectamente.

No se bien cómo organizar la respuesta, hay mucho y creo que lo separaré en 2... Empezaré por la primera (http://www.hispalug.com/foro/index.php?topic=14680.msg249038#msg249038) respuesta de Puli. Usaré el azul para citar el tema del que se habla. Entiendo que es un lío, pero...

[...] dos trenes en marcha [...] mecanismos para evitar la colisión a base de temporizadores [...] más sensores [...]

El "mecanismo" por el que sale el regional (circuito largo) es un reloj: cada 5 minutos sale un tren. Es como el juego de las sillas: al toque del silbato, se pasa un tren de una estación a otra en el sentido de las agujas del reloj. Siempre que el cercanías (circuito corto) regrese a la estación antes de que llegue el regional, se podría hacer. Pero el riesgo es que se juntaran varias personas en un evento con su módulo, haciendo que el circuito largo fuera demasiado corto y no le diera tiempo al cercanías a llegar a estación. Solución "posible": que una estación no envíe tren hasta que el tramo no quede libre (sistema de cantones). Esto colapsaría al sistema como un dominó, ya que al golpe del silbato todos deben enviar un tren. Yo lo descartaría. Recordad que en cada instante hay tantos trenes simultáneos en circulación como participantes/módulos.

[...] si queremos implementar bidireccionalidad en los circuitos hay que añadir [...] más sensores [...] y aumentar el rango del IR-LINK [...]

Hasta donde yo se, el alcance del IRLink no se puede aumentar. Lo que se puede es optimizar (ver review (http://www.hispalug.com/foro/index.php?topic=14532.0)). En cuanto a la bidireccionalidad sí se puede implementar. Como todo, tiene ventajas e inconvenientes. Me explico mejor con una foto:

(http://www.hispalug.com/galeria/albums/userpics/45155/tren_bidireccional.jpg)

Se ahorra un desvío automatizado, ya que los 2 desvíos de las flechas serían fijos. Solo queda automático el desvío del círculo de la imagen, ya que es el que envía al tren al circuito de cercanías (corto) o regional (largo). Como inconvenientes, varios: un sensor adicional. Antes con un sensor detectábamos los 2 trenes que entraban por el mismo sitio. Si quisiéramos estaciones (módulos) de 2 y 1 sentidos conviviendo en el mismo diorama, habrá que tener a disposición 2 programas diferentes. Por último, el problema ya comentado a Parda de andenes largos, ya que los trenes pararían cuando las locomotoras estuvieran en paralelo en la vía y justo debajo del IRLink. Complica un poco pero es una opción, aunque yo empezaría por lo sencillo.

[...] a ver si [...] puedo avanzar [...] intentando sacar una básica para poder unir dos circuitos [...]

No se si te entiendo bien Puli, pero ya está todo definido en el estándar que propuse ¿te refieres a eso?. Revisa a ver por favor.

¿Qué alcance tiene el sensor de color que has puesto a la entrada? ¿cuanto se le puede separar de las vías?  

Me alegra que me hagas esta pregunta  :D. La respuesta rápida sería "muy poco, cuanto más cerca, mejor". La respuesta sesuda sería que depende de las condiciones. Por poner un ejemplo burdo, con el sensor de color en modo luz ambiente (como ha sido el caso), podrías detectar el sol, que está muy lejos. O un coche lejano de noche en una carretera oscura acercándose. Si hablamos de superficies lisas de color uniforme (sin luz propia), el negro refleja mucho menos que el blanco y todo ello influido por la luz ambiente de ese momento y que está en constante cambio...

Para que te hagas idea de la diferencia, un sensor de ultrasonidos no puede hacer ninguna de estas cosas que acabo de decir, ni tampoco se ve afectado por ninguno de esos problemas. En resumen, mejor no separes el sensor de la vía más de 3-4 cm. Si las condiciones ambientales fueran fijas, se podría alargar mucho más el rango. Alternativa: usa ultrasonidos o un led blanco apuntando al sensor desde el otro lado de la vía a modo de "fotocélula en barrera".

CONTINUA EN EL SIGUIENTE MENSAJE

SIGUE EL MENSAJE ANTERIOR

Respecto al segundo post (http://www.hispalug.com/foro/index.php?topic=14680.msg249056#msg249056) que envías, el "Proyecto de trenes a lo grande" (cómo mola el título), lo que te puedo ofrecer es mi colaboración, en la medida de mi tiempo, si lo quieres implementar en NXT-G. Todo eso, verás que se complica bastante y se hace muy engorroso de programar, pero dicho queda. Lo digo porque a mí me queda grande en algunos puntos, tanto de electrónica como de programación, pero si te lanzas a ello, intentaré colaborar en lo que pueda, ya que el enfoque es distinto en mi propuesta estándar.

Puedo también comentarte puntos que domine más y que no vea claros. Voy a ello:

1. Saber el tren. Alternativo al tema de imanes bajo el tren, existe el "Sistema de Identificación por RF", conocido por RFID. Personalmente ya te puedes imaginar que preferiría emular esto de forma casera con los imanes como propones, pero lo veo complicado como ya te expliqué. Te dejo los enlaces: tag (http://www.brickset.com/detail/?Set=MS1049-1) y sensor (http://www.brickset.com/detail/?set=MS1048-1). Existen otras formas de emularlo, ya te daré info.

2. Sensor a la salida del cantón. Si no lo he entendido mal, eso obligaría a cables muy largos desde el sensor hasta el NXT de la estación de origen. Si por el contrario, el sensor está conectado a la estación destino, esto obliga a establecer comunicación entre una estación y otra (entre un NXT y otro) para pasarle la info. Complica la programación, el testado (necesitas 2 NXT) etc.

6. Controlar motores con I2C. Ni idea de cómo hacerlo, pero me resulta muy interesante, también por motivos obvios. Respecto a controlar el desvío con puertos del NXT, es perfectamente posible. Yo he usado motores PF para conservar la máximo la batería del NXT, ya que me sobran canales del IRLink. Otro motivo adicional: no existen cables de prolongación para NXT, cosa que no ocurre con PF, que sí hay prolongadores de cable. Bueno, y en ambos casos se puede cortar y hacer uno casero, eso sí.

7.- programas en forma de tabla.
El NXT-G no dispone de manejo de tablas. Con eso te lo digo todo. Sí que hay arrays 1D, pero nos salimos porque no es software original. Si quieres, en mi web hay un tutorial de arrays. De todas formas, este punto no lo acabo de comprender del todo, creo que por la nomenclatura que usas.

8.- sensores en cruces.
Este punto tampoco lo he seguido bien, pero ten en cuenta que si quieres parar un tren, en su cocorota debe haber un IRLink, que parece que ese punto estaba claro.

9.- Módulos de software en paralelo.
Sí, NXT-G lo permite, pero está desaconsejado. O mejor dicho, aconsejado solo cuando sea estrictamente necesario. La gestión de información compleja en paralelo en el NXT no la he probado nunca, no se cómo responde. En ese sentido, otros lenguajes (C, Java, etc) son mucho más potentes. Aunque se pueden hacer grandes cosas, el NXT-G es lo que es. Y bueno, comparado con un PC, el procesador del NXT también es limitado (supongo yo).

10.- Programa PCF8574.  No está el enlace Pulipuli.

Y ahora, turno para Hoexbroe. Y no te preocupes Hoex, ya entiendo que no es sencillo precisamente seguir el hilo de este hilo  :D
Respecto del (no se cómo llamarlo) bb97, ¿podría alguien dar alguna info adicional de lo que hace? No lo conocía y parece interesante artilugio. De todas formas, el IRLink da la orden de parar en seco. Meter ese elemento antiguo en un estándar complicaría las cosas para hacerlo fácil a la gente. Pero me ha llamado mucho la atención, desde luego.

Y de las conexiones BT con otros NXT, llevas razón, se puede y el NXT-G permite comunicarse con infinitos otros NXT (creo, evidentemente no he probado). Pero, simultáneamente, solo 1 master a 3 esclavos emparejados. Para comunicar con un 4º, hay que usar la función "cerrar conexión" y luego "abrir conexión" con el nuevo NXT. Esta función no la he usado nunca, pero descarta cualquier intento porque debe ser muy lenta en conjunto (seguro que más allá de los 20s si no más).

Bueno, siento el tostón ¿cuándo se habilita la videoconferencia en el foro??? Saludos

Jo, va a haber que dividirse en varios hilos para poder contestar por trozos y que no se pierdan partes de la conversación, porque estas respuestas-encíclicas van a acabar pareciendo un discurso de Fidel Castro xD

Empiezo por arriba del todo ;)

Bueno, mejor antes de empezar aclaro que estoy buscando como un desesperado una solución a los problemas de cobertura de los IR-LINK. Al principio me dije "si nos pasamos, una estación puede colarse en los trenes que están en la estación de en frente", pero si pensamos "a lo grande", y cada estación sabe qué trenes son los que tiene que mover, sólo enviará comandos PF cuando tenga que mover un tren que está en su área de gestión... así que descartado el problema de interferencias. Lo único que preocupa es que si nos pasamos podamos arrancar un supercar del otro extremo de la sala xD :P (es broma, con llegar a 4m me parece más que de sobra).
Ando detrás de una solución como la de este esquema http://www.discovercircuits.com/PDF-FILES/40kvcr.pdf (http://www.discovercircuits.com/PDF-FILES/40kvcr.pdf) que es un repetidor para 40Khz, que es donde operan los mandos de TV. Mis conocimientos electrónicos no llegan para saber si funcionará a 38Khz que van los PF, pero con el vistazo que eché por encima creo que no hay problema porque el amplificador 74c14 me parece que tiene margen de frecuencia de sobra, y el resto de componentes no parecen limitarla... igual me armo de valor y lo monto, pero tuve una experiencia negativa hace años montando en protoboard un emisor de IR controlado por un circuito digital, que no funcionaba porque interfería y emitía mucho ruido, o sea que si me armo de valor para montarlo lo haré soldando en una placa de prototipado y veré si chuta o no. La ventaja es que se puede dar más chicha con un transistor más potente y así alimentar más leds, o bien sacar latiguillos LED de la placa para poner LEDs remotos... hay que probarlo.

Bueno, a lo que iba...

Solución "posible": que una estación no envíe tren hasta que el tramo no quede libre (sistema de cantones). Esto colapsaría al sistema como un dominó, ya que al golpe del silbato todos deben enviar un tren. Yo lo descartaría.
El sistema de cantones se basa en que el máximo de trenes es menor que el número de cantones, por lo que siempre quedará un cantón libre al que enviar un tren. El único caso de bloqueo es que una estación tarde mucho en sacar trenes, y el resto no puedan sacarlos hasta que la primera no "trague", pero eso se ajustaría modificando su programa para reducir los temporizadores. Es un ajuste como los que toca hacer en los GBCs, siempre hay partes más lentas y toca hacer ajustes sobre la marcha, pero se puede acordar una temporización mínima y máxima de los módulos para evitar que esto suceda.

Mira que es sencillo el esquema del "apartadero", y no había caído en él :D. Como siempre, las colisiones se pueden evitar por dos métodos, los temporizadores que te aseguren que no hay convoyes kamikaze, o sensores a modo de cantones. Nuevamente, el tema de sensor implica poder parar un tren y para ello hay que conseguir alargar el alcance del IR-LINK.

Por cierto, me desvío del tema para no olvidarlo: he echado un vistazo al PFMate de Mindsensors, que es primo hermano del IR-Link, pero veo que también está limitado en potencia de IR a unos 50-75cm. Yo no lo pondría en la cocorota de una estación, sino p.ej. a su salida apuntando hacia atrás, pero si el andén mide más de 1m (uséase, lo normal), no llega a parar trenes a la entrada.

Y sigo con los comentarios numerados (que buenos los árabes que inventaron los numericos jejeje)

1.- Me planteé lo de RFID, pero los sensores son caros, y si hay que poner muchos... ufff... XD. Los interruptores magnéticos para eso son baratos y sencillos de montar incluso para neófitos en electrónica. Sólo hay que hacer pruebas hasta encontrar los imanes que mejor se adapten. Aquí hay un problema en el que no había caído: si multiplexo los 8 bits del PCF8574 para poder conectar muchos sensores simultaneamente, tocará implementar algún tipo de buffer, dado que es posible que dos trenes atraviesen a la vez dos sensores distintos. Moraleja: se complica mucho el diseño, por lo que habría que intentar respetar los 8 bits del 8574. Eso origina un problema: si los sensores son de 3 bits, nos comemos muy rápido los puertos del NXT, y tengo sólo 4: 1 para el IR-LINK, dos para sensores (16 bits) y uno para desvíos (8 desvíos usando p.ej. el controlador de servos de mindsensor), más los 3 puertos de motores PWM del NXT.  Hay que echar una pensada a este asunto, o ver si hay alguna posibilidad de aumentar el número de pines. Incluso he pensado en montar entre medias una plaquita con un PIC que haga de buffer, y emita usando esos 8 bits series de comandos al NXT, pero eso añadiría MUCHA complejidad al programa NXT-G, y está más orientado a otros lenguajes de programación que no son tan asequibles para todos.

2.- Sí, cables muy largos, es un incordio. Si trabajáramos con vías electrificadas que sirvieran de bus común DCC... otro gallo cantaría, pero entonces no estaríamos hablando de PF sino de DCC. Insisto en evitar el que las estaciones tengan más comunicación entre sí que los trenes que se "envían" una a otra, por eso el cable del sensor de "tren que abandona el cantón" es un simple cable de dos hilos, y no requiere control sobre el tren. Se puede resolver acortando el cantón de salida, es decir, acercando el sensor a la estación... pero para evitar colisiones, eso implicaría que el sensor de entrada del siguiente módulo se tendría que alargar :(

6.- Controlar motores con I2C. Yo he pensado dos formas, y he pensado incluso en servos baratos (en una tienda china online, por 4€ te los ponen en casa). La primera es para motores PF, usando dos bits, uno para cada sentido, y si ambos son 0 para frenar. Consiste en polarizar con un bit C1 mediante un transistor que de al menos 1A, y con el otro bit C2, ambos a la tensión de alimentación PF. Cuando polarizas con el transistor C1 o C2, lo que haces es ponerlo a 9V, y cuando deja de estar polarizado, lo pones a 0V. Así, si enciendes un bit y el otro no, el motor gira en un sentido, y si los enciendes a la inversa, pues sentido contrario.
La segunda forma usa sólo un bit, y con un 1 giraría en un sentido y con un 0 en el contrario, el motor en principio estaría girando siempre, por lo que requiere un módulo aparte para que el motor sólo gire hasta abrir/cerrar el desvío. Ese módulo puede ser un simple apaño mecánico que corte la alimentación. Aquí es donde entraría la posibilidad de usar servos... pero tengo que investigar un poco más y tal vez hacer un pedido para ir jugando.
Peeeroo... no dejo de pensar en el sensor de mindsensors que controla hasta 8 servos, que ya te viene montadito jejeje. Voy a ver si los servos chinos baratos de 4€ que he encontrado son compatibles ;)

7. Tablas en el programa. Bueno, cuando digo tabla, hablo de "conjunto de variables", en realidad da igual que estén o no ordenadas en forma de tabla. La idea es que se desarrolle una única vez el módulo de software y si fulanito lo quiere incorporar a su NXT pero ya tiene ocupados algunos puertos, que no tenga que ir tocando por todo el programa para ajustarlo, sino que sirva con cambiar unas variables estáticas definidas al principio una única vez.

8.- Cruce de trenes. Si dos trenes llegan cada uno a un desvío por una pata de la "Y", tengo que implementar un sensor en cada pata y tengo que poder pararlos mediante IR. Es cierto que implica un IRlink en la cocorota y una pareja de sensores de tipo de tren. La única otra forma de evitar colisiones es mediante temporizadores, pero eso no es práctico si uno varios módulos ya que puede haber dos módulos enviando trenes al mismo cruce en "Y".

9.- Tal vez lo que tengo que hacer es jugar un poco más con NXT-G, jejeje, que no he pasado de los ejercicios básicos de seguir la línea del suelo, buscar un objetivo, y poco más. Estoy acostumbrado a pensar programas que responden a eventos, y los eventos se pueden producir en sitios distintos y en cualquier momento, por lo que decía lo de las líneas paralelas para que cada una de ellas atienda un evento: Una que atienda al sensor de entrada a la estación, otra que atienda a los sensores de cada andén... y también otra línea, que no responde a eventos externos como tal, que gestione la cola de salida de trenes. Esa línea debería poder ser alimentada por el resto de partes del programa, como el "gestor de tráfico", porque la mejor forma de implementarla es mediante una cola: el resto de partes del programa "encolan" peticiones para los trenes (sácame este tren) y los va sacando en orden o mediante un sistema de prioridades.
Este punto tiene que ver mucho con el programa, por lo que por ahora no debería pensar en él, pero es inevitable que cuando pienso en abstracto se me vaya la cabeza a la implementación jeje.

Ahora busco de nuevo el programilla para jugar con pastillas digitales, leds y demás. No trae el 8574, pero si alguien quiere alimentar unas puertas lógicas, un contador, un multiplexor, etc. y ver que pasa, puede ser útil antes de pasar todo al protoboard para hacer las pruebas físicas con el NXT.

Pulipuli, Nxtorm no hagais respuestas tan largas hombre!!!! que ya ni vosotros mismos lo asimilais   :D :D :D
Id poco a poco, una buena solución para tenerlo siempre bien documentado sería compartir entre vosotros un archivo *.doc e ir añadiendo o tachando lo que avanceis. Así cuando tengais algo decente y seguro ya lo publicais.
Es que me da la impresión que estais más tiempo posteando que desarrollando.  :D
Es un consejo  ;)

Jejeje, sí, empieza a ser necesario un hilo donde pasar a limpio las cosas, pero en estas fases iniciales no hay nada como soltar muchas ideas inconexas para luego ir atando hilos :D

Me acaba de venir a la cabeza tunear un mando PF con un poquito de electrónica y así olvidar el problema de los alcances... voy a investigar un rato que seguro que en la web de Philo o similares me lo encuentro destripadito (o en el hilo de Blastem que está más a mano)

Enviado desde el móvil, perdonadme si se cuela alguna errata

Sí, también coincido. Al final estamos cruzando aquí los dos proyectos: el que va pensando Puli y el que yo propuse.

Por mi parte, me gustaría hacer alguna prueba adicional, ya que solo he hecho del tirón lo que se ve en el video, y me gustaría dejarlo un buen rato en marcha a ver cómo se comporta.  Pero en principio, a falta de estos ajustes y una guía, el modelo ya está creado y funcionando. Otra cosa es que guste y se le vea potencial en un evento.

Pregunta a los MODs: ¿os parece que abra un hilo nuevo titulado "Propuesta de estándar de trenes PF para eventos" o cualquier cosa así y dejemos este hilo para el debate de nuevas ideas? A fin de cuentas, es lo que dice el título.

Si es así, recopilo allí la propuesta del estándar (que básicamente es esto (http://www.hispalug.com/foro/index.php?topic=14680.msg247723#msg247723) con algún comentario/corrección adicional) le adjunto el video y a ver opiniones por allí. Y si no, ya decís y lo mantenemos aquí.

Es otro tema diferente con clara orienteción a eventos, veo bien crearlo e ir recopilando  :}

Yo por mi parte abriré otro con las descripciones funcionales de posibles módulos, que hay que ir depurando con calma.

Sigo teniendo en la cabeza el extender el IR, en el hilo de al lado ;) he dejado unos enlaces de hilos de eurobricks donde he ido viendo alguna cosita interesante. Es que lo que más me preocupa es el detectar que tren entra a un módulo y la posibilidad de pararlo, a mi modo de ver si no se puede hacer eso, sólo podremos correr dioramas con un número muy reducido de trenes, y el control de colisión en estaciones va a ser algo difícil sin comunicar NXTs... pero le doy una vuelta cuando tenga un rato a solas con papel y boli


Edito: sigo buscando información antes de ponerme a escribir. He encontrado este enlace para controlar motores utilizando puentes H, igual que hace el receptor PF http://www.hispavila.com/3ds/atmega/motorescc.html (http://www.hispavila.com/3ds/atmega/motorescc.html)

Bueno, llevo unos días reuniendo información variada de muchos temas, sensores, bus I2C, PICs, arduino, NXT-G... Ya tengo una visión de conjunto mas o menos e incluso he empezado a generar un documento .doc que iré troceando para abrir un hilo nuevo. Gracias a los nuevos cacharros móviles he podido ir haciéndolo a ratos muertos, porque salvo en el curro no estoy teniendo ni un ratito al lado de un PC, aunque eso ayuda a la hora de leer, pero para escribir es un rollo, y de dibujar mejor no hablamos.

La principal duda que tenía era si con NXT-G podría hacer submódulos de programa de tal modo que el mismo programa global sirviera p.ej. A dos personas que usan distintos sensores, pero que emplearan un mismo bloque "lee_sensor" por lo que el bloque general del programa sería común... Por suerte encontré este tutorial  http://www.nxtprograms.com/help/MyBlocks/tutorial.html#Making (http://www.nxtprograms.com/help/MyBlocks/tutorial.html#Making) para hacer bloques personalizados que me ha permitido ver que es posible sin necesidad de usar otros lenguajes de programación menos visuales y por tanto menos al alcance de la mayoría. Los bloques funcionales además pueden programarse en cualquier lenguaje y para cualquier dispositivo, por lo que si alguien quiere hacer su proyecto de automatización basado p.ej. en Arduino o con unos PICs, solo tendrá que programar los módulos, estando ya hecho el trabajo de alto nivel, y será sólo cuestión de tirar líneas de código. Al final, todos los módulos podrían comunicarse entre sí sin necesidad de programar interfaces entre módulos, sólo enviándose trenes y nada más, y al tener una programación común, el único problema al juntarlos será ajustar algún parámetro para evitar que haya partes del circuito que hagan de tapón.

En fin, que he hablado poco estos días, pero soy de los que no dicen nada hasta tener una visión de conjuNto.

He estado pensando en varias formas de implementar sensores, de comandar trenes y desvíos, incluso he visto las posibilidades de controlar con otros cerebros que no sean nxt para aquel que no tenga o no quierá comprarlo pero no tenga problema en soldar unas placas... Con Arduino se puede hacer muy sencillo y por menos de 50 euros por poner un ejemplo, pero no es tan tan LEGO, claro, y tampoco tan vistoso. Lo mismo con los desvíos, que habrá quien solo se plantee motores PF, y quien prefiera siervos chinos de 4euros.

En fin, que voy a ir pasando a limpio primero con un lápiz, iré colgando los bloques básicos funcionales, haré un demostrador usando nxt-g, y luego ya me iré metiendo en harina en la parte electrónica. Lo bueno es que al ser todo un concepto modular que permitirá varias opciones, una vez que se defina un formato para la señalización de trenes, cualquiera podrá coger la pata que más le interese y así podremos avanzar en grupo y dejar todo abierto a implementaciones particulares como la de Leander, que ni está usando NXT para su proyecto ni infrarrojos, pero que el resto podrá usar los mismos módulos de control aunque haya que reprogramarlos enun PIC.

Por cierto, para los friáis del nxt, entiendo que el programa no atiende a interrupciones generadas por valores enun puerto o cambios de su estado, no?. Lo digo porque lo ideal es que si un programa p.ej. Está en un bucle de 5 sg esperando que un tren entrea la estación, si en ese bucle otro tren activa un sensor, se podría no atender a tiempo la lectura, y "perder" el tren, con lo que hay choque asegurado. De ser así, corregidme los que controláis del tema, el programa estará controlado por un bucle de lectura de puertos, y deberán evitarse las esperas a que suceda algo para retornar lo antes posible a ese bucle, de modo que no se pierda ninguna lectura de sensor. A fin de cuentas no afecta mucho, solo que el chasis del funcionamiento de un programa de un modulo será menos lineal.

Por ultimo, una cosa que me preocupó fue el arranque e inicialización del circuito, que en el momento cero no tendrá trenes, lo cual requerirá un bloque de entrada de setup, y además hará faltaun botón de pánico bien visible para apretarlo si hay una eventualidad y evitar que se manden trenes p.ej a una vía donde se ha caído un muro sobre la vía y podría liarse la marimorena.

Ea, sigo elucubrando, jeje, y deseoso estoy de ver como van vuestros proyectos y reflexiones particulares.

Ya veo que no estás parado, ya.

Te contesto alguna cuestión, hasta dónde yo se.

Sin ser tan completo como el tutorial que has puesto (que es muy bueno) tienes también un pequeño tutorial en mi web: http://www.nxtorm.es/ayudas/ay-c-my-block.html (http://www.nxtorm.es/ayudas/ay-c-my-block.html). Ya digo que no es tan completa, pero tiene la ventaja de estar en castellano. También hay otra sobre la "Descarga e instalación de nuevos bloques". A la vista del tutorial que has enlazado, tendré que actualizar cosas.

Respecto a lo de salir de un bucle cuando un sensor detecta un segundo tren, que yo sepa no es posible abortar el bucle hasta que no se cumpla la condición de fin. Te las tendrás que componer en la programación de alguna forma para que constantemente esté pendiente de ambas tareas y acabe cuando se produzca una u otra (Icono "or"), o con un switch... no se, cualquier invento. En ese caso, sí podrás hacer la interrupción que buscas.

Recuerda que lo que si admite NXT-G es programación pralela (a evitar si no es necesaria). En esa "rama" del programa podrías hacer las lecturas de los sensores y meter el valor en una variable, de forma que siempre estuvieran actualizadas las variables en la línea principal del programa.

Como "Botón de pánico", puedes usar el icono STOP, que puedes encontrar en "Complete Palette/Flow/Stop". Este icono lo para todo, aunque recuerda que si es vía IRLink, el tren deberá estar bajo su (limitado) radio de acción para parar los trenes.

Por mi parte, ya subí los avances a un hilo aparte, y ando ahora viendo la fiabilidad del artilugio. Funciona perfecto, pero en alguna ocasión el tren queda fuera del alcance del sensor y en ello ando, modificando la posición.

En fin, espero que te sirva, ya nos vas contando. Suerte!

Holas;

Hilo muy interesante, en particular la aportación '« Respuesta #13 en: 06 Enero 2012, 22:34:13 »'.

Luego, habéis ido haciendo textos tan grandes que asusta leerlos....

Quizá podría colaborar en algo, pero mi actual falta de tiempo libre me hace desistir de siquiera intentarlo  :(