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 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 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

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 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. 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  :(