Dirección común para todas las locomotoras

Yo lo tuve y sirve para un módulo completamente aislado. Con el Train Shuttle el tren hace una parada temporal y reanuda la marcha, eso sí, solo funciona con direcciones inferiores a 96.
El mismo Train Shuttle puedes programar un "ida y vuelta" o una "parada momentánea".

The train shuttle is a DCC command station/throttle with built-in detectors that can automatically reverse direction and simulate a station stop.

Es tecnología de los 90!!!!!!

Fantito escribió:

Yo lo tuve y sirve para un módulo completamente aislado. ....

Ya, pero Dvorak lo quiere para encuentros modulares

Dvorak escribió:

.... (es para encuentros modulares, y se desconoce el tipo de decodificador que lleva cada locomotora), ....

Un saludo

Yo lo usé en encuentros modulares, allà en el pretérito, y funcionaba bién haciendo una parada de unos 20 segundos. Eso si, paraban todos los trenes con dirección inferior a 96, cosas de Roco!!!!

Enviat des del meu Poppox P3 usant Tapatalk

El Matao escribió:

Hola Alfred.

La idea de tener un generador de frenada que o bien envíe la "velocidad 0" la dirección 0 o bien haga un barrido de las direcciones 1 a 127 es equivalente, pero mi duda es al integrarlo en un circuito como los encuentros modulares, veo un problema cuando momentáneamente (o no tan momentáneamente) se produce una conexión entre la zona controlada por el generador de frenada y el resto del circuito, sobre todo si da la casualidad de que un alocomotora se queda parada haciendo la conexión de forma permanente, toda la zona controlada por el booster correspondiente quedaría con información corrupta, se perdería control de las locomotoras y posiblemente se acabarían parando todas ellas.

Algo parecido a la discusión que ha habido sobre el problema de paso entre dos boosters en otro hilo.

Un saludo.
Gerardo.

Hola, Gerardo.

No hay posibilidad de que una locomotora puentee los dos boosters (el normal y el de frenado). En este esquema manuscrito, tenemos:
- CANTON 1 (le llamo de regulación). Tiene tres subcantones: CANTON 1A, CANTON 1B y CANTON 1C
- CANTON 2 (protegido).
- CANTON 3 (protegido).
- CANTON 4 (NO protegido).

En condiciones normales, el CANTON 1 está alimentando por el booster normal, al igual que sus cantones contiguos. En el CANTON 1, tenemos el subcantón 1B (más o menos en el centro del módulo). Yendo de izquierda a derecha, al llegar la locomotora al CANTON 1B, si CANTON2 o CANTON3 estuviera ocupado por otro tren, se activaría el RELE1, pasando de estar alimentado el CANTON 1 por el booster normal, al booster-freno. Como CANTON1B estaría mas o menos a mitad del módulo, al conmutar CANTON1 entre dos boosters, todos los ejes de la locomotora estarían dentro del CANTON 1

La señal de detección de cantón, en CANTON 2 y CANTON 3, sería de colector abierto, de esa forma se puede poner en cascada. Te puedo pasar más detalles, si quieres.

El Matao escribió:

Veo bien la idea, aunque claro, el barrido sólo funcionaría si utilizas direcciones cortas, lo ideal sería el planteamiento de la dirección 0 (broadcast)
Sobre el decoder D&H no sé si se podrá configurar en modo DCC exclusivo y si en ese caso respondería a la dirección 0

Pero hay un tema que me preocupa en ambos casos, a todos los efectos es como si en la misma maqueta tuvieses dos centrales DCC, la principal y una secundaria que está enviando a la dirección 0 la parada general (o haciendo el barrido), mi problema es que las ruedas de la locomotora pueden quedar haciendo conexión entre los dos tramos (o una locomotora larga) y entonces tendremos tramas erróneas DCC (al solaparse las dos señales) que pienso que pueden llegar a dar problemas.

Otra solución, que adolece del mismo pero que acabo de exponer, sería hacer un módulo que escuche la señal DCC de la central primaria y la reenvía a los sectores de parada, "trampeando" la información de velocidad, poniéndola a 0 (no a 1, parada de emergencia). Esto permitiría activar/desactivar luces y sonidos, y con un poco más de trabajo, incluso permitir que una locomotora avanzase a velocidad de maniobra (pena, no hay una función estandar para ello, depende del decoder) o invirtiese, estilo el funcionamiento del freno ABC

Pero vuelvo al problema planteado, ¿cómo evitamos este problema de mezcla de señales?

Un saludo.

En efecto, hacen falta dos boosters distintos:
- El normal
- El de frenado, si bien este último, sólo enviaría tramas de parada.

En efecto, como tú apuntas, lo mejor es que el booster de frenado, "lea" las direcciones de todas las locomotoras, a las que se dirija la central principal. De esta forma, en lugar de hacer un barrido de la dirección 0 a la 127, haría un barrido de las direcciones a las que se dirige el booster principal. Lo voy a hacer así. Se puede hacer, una lectura de todas las direcciones, e ir guardándolas, según se vayan leyendo, en un conjunto de registros (del 1 al 100, por ejemplo, y luego, volviendo al 1 y así sucesivamente y reescribiendo los registros). Esto permitiría tener sobre una instalación, en un momento dado, hasta 100 locomotoras distintas. Si tuviéramos, por ejemplo, solo tres locomotoras, en un momento dado, el booster de frenado, grabaría:
- REGISTRO 1: DIR. LOCO 1
- REGISTRO 2: DIR. LOCO 2
- REGISTRO 3: DIR. LOCO 3
- REGISTRO 4: DIR. LOCO 1
- REGISTRO 5: DIR. LOCO 2
- REGISTRO 6: DIR. LOCO 3
- REGISTRO 7: DIR. LOCO 1
...
- REGISTRO 97: DIR. LOCO 1
- REGISTRO 98: DIR. LOCO 2
- REGISTRO 99: DIR. LOCO 3
- REGISTRO 100: DIR. LOCO 1
Y haría luego el barrido de las direcciones grabadas en los registros.

A efectos de decodificar los paquetes, llevaría la señal DCC (pasada a 0-5V) a una entrada de interrupción del PIC. Cada vez que se produjera una interrupción, leería el contenido de un timer, y en función de su valor, podría discriminar si se ha recibido un cero (más de 100us en estado alto y otros tantos en estado bajo) o un cero (58us en estado alto y otros tantos en estado bajo). Habría que esperar a que termine el preámbulo (al menos diez unos), y tras el siguiente cero, daría comienzo la trama.

Lo veo factible. Voy a diseñar el hardware del módulo de frenado (que incluye, booster de frenado, "sniffer", detección de CANTON 1B, recepción de señal de cantones contiguos, y activación de semáforos en lado ESTE y OESTE). Espero terminar el PCB durante julio, lo pediré a fabricar, y calculo tener el circuito trabajando a final de agosto.

Un saludo.

Paco Mallols (Dvorak).

Hola Dvorak.

He estado dándole vueltas al esquema que has puesto y tengo dudas.

Dejando aparte el tema bidireccional y aún suponiendo que los subsectores 1A y 1C son suficientemente largos para contener al tren más largo de la explotación (y en los encuentros modulares no es raro encontrar trenes de 3 metros) me causa problemas si va un tren corto y detrás un tren rápido.

Con este esquema

donde he puesto en color rojo lo que serian unas líneas lógicas para el control de la señal y del relé (a implementar con un poco de electrónica) . Este esquema es para un sector y se engancharía con los anteriores/siguientes con la línea en rojo marcada, cada uno tendría una señal y un relé, aunque el generador de parada puede ser común a través de un bus paralelo al de la señal DCC (por cierto, he visto que me falta la alimentación del carril superior del sector 1C que es la misma que la de los carriles 1A y 1B)

De esta forma, la señal se pone en rojo si está ocupado cualquiera de los subsectores 1C 2A o 2B, hasta ahí bien.
Pero sólo se activa el STOP si
a) están ocupados el sector 2A o el 2B
b) está ocupado el sector 1B
c) NO está ocupado el sector 1C

Pero como digo, no sé si existiría la posibilidad de que una parte de un tren que no active detección, pero que pueda cortocircuitar un sector que tenga activo la señal de STOP con una que no lo tengo.

Hola, Gerardo.

Puede que se me esté escapando algo que no veo, pero no creo.

En el esquema manuscrito, he nombrado la señal BUSY: como es en colector abierto, está a +12V cuando no se detecta cantón ocupado, y a 0V, cuando CANTON2 o CANTON3 está ocupado.

Los trenes pueden tener cualquier longitud. El único requisito, es que la longitud de CANTON1A y CANTON1B, tenga una longitud superior a la distancia entre ejes externos de la locomotora más larga. Por ejemplo, supongamos que en la locomotora más larga, tenemos una longitud de 200mm, la longitud de CANTON1A y CANTON1B debería ser, al menos, algo superior a 200mm.

Veamos un ejemplo.
-ESTADO 1: Una locomotora A está en CANTON2. La señal BUSY=0V. El semáforo está en rojo.

- ESTADO 2: La locomotora A pasa al CANTON3. La señal BUSY=0V (no cambia). No importa que la locomotora A tenga un eje en el CANTON2 y otro en el CANTON3.

- ESTADO 3: Estando la loccomotora A en el CANTON3, el eje delantero de una locomotora B, que se desplaza de izquierda a derecha, toca el CANTON1A. Nada cambia.

- ESTADO 4: Todos los ejes de la locomotora B, están dentro del CANTON1 A. La locomotora A sigue en el CANTON 3.

- ESTADO 5: Como la locomotora A sigue en CANTON 3, BUSY sigue siendo 0. El eje delantero de la locomotora B, toca el CANTON 1B. En este preciso instante, es cuando se debe activar el RELE1, y el CANTON 1 pasa de estar alimentado por la señal DCC, a DCC-STOP. La locomotora B, comienza rampa de deceleración, y se para completamente.

- ESTADO 6: La locomotora A, pasa al CANTON 4, y abandona completamente el CANTON 3. En este momento, la señal BUSY=+12V. A partir de este momento, se puede establecer una pequeña temporización de unos pocos segundos, para asegurarnos que en efecto, la locomotora ha abandonado completamente el CANTON 3, y no ha habido un falso contacto del último eje. Esta temporización, es al margen de la idea de principio que quiero explicar. El semáforo pasa a verde. Como BUSY ya no es 0V, el RELE 1 se desactivaría, por lo que CANTON 1 pasaría de estar alimentado por DCC-STOP, a DCC. La locomotora B, se pondría en marcha.

- ESTADO 7: El primer eje de la locomotora B tocaría el CANTON 1C. El último eje, seguiría estando en el canton 1B. Nada cambia.

- ESTADO 8: todos los ejes de la locomotora B, estarían dentro del CANTON 1C.

- ESTADO 9: el primer eje de la locomotora B, tocaría CANTON 2. En este preciso momento, la señal BUSY=0V, y el semáforo pasaría a rojo. RELE 1 seguiría estando como el dibujo, sin cambiar de estado.

- ESTADO 10: la locomotora B, entraría íntegramente en CANTON2. BUSY seguiría estando a 0V. Mientras, la locomotora B, podría haber llegado al CANTON 3 o no, no es relevante.

- ESTADO 11: el primer eje de una nueva locomotora (la locomotora C), tocaría el CANTON 1A. Nada cambiaría.

- ESTADO 12: todos los ejes de la locomotora C estarían dentro de CANTON 1A.

- ESTADO 13: el primer eje de la locomotora C, tocaría el CANTON 1B. En este momento, el RELE 1 cambiaría de estado, y el CANTON 1 pasaría a estar alimentando en este momento, por DCC-STOP.

- Se repetiría el ciclo desde el ESTADO 6...

Sí que habría un problema, si por ejemplo, entre ejes externos de la locomotora, tuviéramos (por ejemplo) 200mm, y remolcase inmediatamente después un vagón con luz. Al llegar la locomotora al CANTON 1B, todos sus ejes estarían en el CANTON 1, pero si el vagón con luz, tuviera un eje en el CANTON 1A, y otro en CANTON 5 (sería el que estaría a la izquierda del todo), entonces en ese caso, sí que habría un problema, pero solo en este caso, porque el vagón con luz iría pegado a la locomotora. En este caso, el CANTON 1A debería tener la longitud entre ejes de la locomotora, más el del vagón...pero si vagón no estuviera inmediatamente detrás de la locomotora, no veo problema.

Se tiene que cumplir, pues, que la longitud del CANTON 1A sea al menos algo mayor, que la distancias entre ejes de la locomotora más larga. Es el único hándicap que veo: justo detrás de la locomotora, no debería ir un vagón con luz (o que cogiera la tensión de la vía). No importaría que el tren midiese varios metros.

Atentamente:

Dvorak

La orden de frenado automático habría que programarla con "delicadeza": si el maquinista está atento y va a parar, el sistema debería dejarle hacer.
Me parece que eso es incompatible con el barrido para parar todo lo que se mueva en la zona regulada.

Por eso vuelvo a sugerir que el sistema identifique al tren y compruebe a qué pasos de velocidad lo van llevando. Si no parece adecuada y no se ve que pare, los 30 cm antes del semáforo conmutan al DCC de frenado y se le para en seco. Pero si el maquinista va con tiento, no habría que intervenir.

Norber, creo que la orden de parada en seco es ponerle la velocidad a 1 y la orden de parada según el parámetro de deceleración es ponerle la velocidad a 0, así si queremos que pare según sus parámetros, hay que enviar un paquete con dirección 0 y velocidad 0

https://dccwiki.com/Term:E-Stop

Por lo que leo, esa locomotora que no responde al paquete con dirección 0, ¿responde parando al pulsar la tecla de [STOP]?, si lo hace entonces lo mismo es que la central envía paquetes "Unicast" con velocidad a 1 en el caso de pulsar la tecla de [STOP], cosa que puede hacer con direcciones cortas o largas pues ella sabe qué locomotoras están activas

Para dilucidar esta cuestión haría falta un "sniffer DCC", yo tengo hecho uno LocoNET, pero aquí no nos vale.

Un saludo.
Gerardo

Norber escribió:

La orden de frenado automático habría que programarla con "delicadeza": si el maquinista está atento y va a parar, el sistema debería dejarle hacer.
Me parece que eso es incompatible con el barrido para parar todo lo que se mueva en la zona regulada.

Por eso vuelvo a sugerir que el sistema identifique al tren y compruebe a qué pasos de velocidad lo van llevando. Si no parece adecuada y no se ve que pare, los 30 cm antes del semáforo conmutan al DCC de frenado y se le para en seco. Pero si el maquinista va con tiento, no habría que intervenir.

Norber, lo que propones, es el "más difícil todavía", porque se tendría que monitorizar la velocidad, y actuar en el caso de que fuera excesiva. Además, la consigna de velocidad leída, no muestra necesariamente la velocidad real, porque la locomotora tiene su propia curva consigna/velocidad, y para una consigna dada, la velocidad real puede ser elevada o reducida...La dificultad que yo veo está en identificar el tren. Si tuviésemos Railcom, eso estaría hecho, pero no hay que contar con él, hay que tener en cuenta, que se desconoce el decodificador que lleva cada locomotora.

La intervención sobre la locomotora en el cantón regulado, realmente es suave, hasta el punto que el maquinista no se daría ni cuenta. Si el maquinista está atento, al llegar al CANTON 1B, reduciría la velocidad, pero realmente lo estaría controlado en DCC-STOP, y el maquinista pensaría que lo estaría frenando él mismo. Y si no redujese la velocidad, lo haría DCC-STOP, de una forma también suave (en verdad, sería la rampa de deceleración de la propia locomotora).

El Matao escribió:

Norber, creo que la orden de parada en seco es ponerle la velocidad a 1 y la orden de parada según el parámetro de deceleración es ponerle la velocidad a 0, así si queremos que pare según sus parámetros, hay que enviar un paquete con dirección 0 y velocidad 0

https://dccwiki.com/Term:E-Stop

Por lo que leo, esa locomotora que no responde al paquete con dirección 0, ¿responde parando al pulsar la tecla de [STOP]?, si lo hace entonces lo mismo es que la central envía paquetes "Unicast" con velocidad a 1 en el caso de pulsar la tecla de [STOP], cosa que puede hacer con direcciones cortas o largas pues ella sabe qué locomotoras están activas

Para dilucidar esta cuestión haría falta un "sniffer DCC", yo tengo hecho uno LocoNET, pero aquí no nos vale.

Un saludo.
Gerardo

Gerardo, yo pensaba que con el STOP, la tensión DCC desaparecería de la vía, pero según he leído en el link que has pasado, no es así. Tampoco quiero un frenazo brusco, no quedaría bien...

El único punto flojo que veo (de momento) al sistema que propongo, es que justo después de la locomotora, no deberíamos tener un vehículo con luz, porque el mismo, si tuviera un eje en el CANTON1A y el otro en el contiguo, al cambiar el sistema de DCC a DCC-STOP, tendríamos un cortocircuito seguro, parándose toda la instalación...

Todo sistema, tiene sus limitaciones. En el ferrocarril real, igual. Una zona neutra, debe ser lo más corta posible (ya que el tren pasa por inercia), y una locomotora no podría circular con los pantógrafos levantados, porque conectaría ambos cantones (o la zona neutra debería tener mayor longitud, que la distancia entre pantógrafos)...

Atentamente:

Dvorak

El Matao escribió:

Para dilucidar esta cuestión haría falta un "sniffer DCC", yo tengo hecho uno LocoNET, pero aquí no nos vale.

Aquí hay un espía DCC bien majo!

Entiendo que al final lo que se discutió en este hilo era el diseño de un módulo de frenada similar al Roco 10779.

Se supone que el sistema ABC no vale para todos los decoders y que existe la alternativa de combinar DCC y DC modificando la CV29.

He estado haciendo unas pruebas y la locomotora al pasar de DCC a DC hace un corto y que detecta la central a parte de que puede no frenar la locomotora en la parte de DC.
En mi caso particular,usando Roco, se supone que hay que añadir un módulo en las transiciones de DCC a DC para gestionar ese corto.


¿alguien consiguió implementar la frenada combinando DC y DCC deforma satisfactoria?

Sent from my M2007J22G using Tapatalk

OrEx1883 escribió:

Entiendo que al final lo que se discutió en este hilo era el diseño de un módulo de frenada similar al Roco 10779.

Se supone que el sistema ABC no vale para todos los decoders y que existe la alternativa de combinar DCC y DC modificando la CV29.

He estado haciendo unas pruebas y la locomotora al pasar de DCC a DC hace un corto y que detecta la central a parte de que puede no frenar la locomotora en la parte de DC.
En mi caso particular,usando Roco, se supone que hay que añadir un módulo en las transiciones de DCC a DC para gestionar ese corto.


¿alguien consiguió implementar la frenada combinando DC y DCC deforma satisfactoria?

Sent from my M2007J22G using Tapatalk

Hola, OrEx1883.

Conmutar de DCC a DC, no creo que funcione. Para que la locomotora se parase al conmutar de DCC a DC (suponiendo que el decodificador no hiciera nada raro), en DC la tensión debería ser cero, con lo cual la locomotora se pararía en seco, sin control de luces ni sonido. Si tuviera stay alive, no sé que haría... pero en cualquier caso, no sería una parada controlada.

A partir del espía DCC que crearon Norber y Germán, hice el frenador... y te confirmo que funciona. Consiste en hacer un "barrido" de direcciones (supongamos, 40 ó 50), y luego reenviarlas, poniendo a cero el byte de velocidad (dejando igual el bit de dirección).

Como no tenía mucha experiencia con los Arduino (y sigo sin tenerla, porque yo soy más de PIC´s), utilicé dos Arduinos: uno basado en el DCC-EX (para generar las tramas), y otro basado en el espía DCC de Norber y Germán, comunicados a través del puerto SPI. Es muy cómodo y fácil controlar los trenes a partir del DCC-EX. El circuito frenador funcionaba... hasta que dejaba de funcionar. El Arduino del DCC-EX, se acaba colgando a los pocos minutos. Hice muchas pruebas, analicé tramas del puerto SPI entre ambos Arduinos, pero no llegué a concluir el motivo del cuelgue...

Así que abandoné la idea de los dos Arduinos, y me centré solo en un Arduino, que aparte de contener el espía DCC, creé el código para generar las tramas DCC. No es difícil generar las tramas, en base al estándar DCC que está publicado (ya lo hice hace más de 20 años, con los PIC). En este caso, aparte de multiplicar el byte de velocidad por b'10000000', hay que recalcular el byte final, haciendo la XOR de todos los bytes. Hay que distinguir el tipo de trama, si es de velocidad con dirección corta, larga o de funciones, para reconstruirla... El resultado, es satisfactorio: funciona perfectamente (en casa): la locomotora frena de forma controlada (con su rampa de deceleración) teniendo activas las funciones. Es decir, puedes controlar todo, menos la velocidad. Lógicamente, mediante un relé, conmutas entre el DCC normal, y el "DCC de frenado". No hace falta saber la dirección de la locomotora que tienes en un cantón, porque como el "DCC de frenado" (que está solo en ese cantón), se dirige a todos las locomotoras que ha están en la instalación, una de ellas será la que quieres frenar. Para arrancar, vuelves a conmutar con el relé al "DCC normal", y la locomotora se pondrá en marcha con rampa de aceleración y sonido acorde. No he llegado a probarlo en una instalación con muchas locomotoras.

Mi intención era compartir toda la información en este foro... pero tengo muy poco tiempo, y estoy con otros proyectos, pero intentaré hacerlo. Me siento con la obligación moral de compartirlo, porque la base del proyecto es el espía DCC de Norber y Germán (aparte, de que a mí me gusta compartir las cosas, lo mismo que otros comparten las suyas). El programa que hicieron, lo analicé profundamente (te recuerdo que mi nivel de Arduino es de principiante), y es una pasada de programa (o sketch, o como se diga), de lo bien pensado que está.

Un saludo

Dvorak
(Paco Mallols)

Dvorak escribió:

OrEx1883 escribió:

Entiendo que al final lo que se discutió en este hilo era el diseño de un módulo de frenada similar al Roco 10779.

Se supone que el sistema ABC no vale para todos los decoders y que existe la alternativa de combinar DCC y DC modificando la CV29.

He estado haciendo unas pruebas y la locomotora al pasar de DCC a DC hace un corto y que detecta la central a parte de que puede no frenar la locomotora en la parte de DC.
En mi caso particular,usando Roco, se supone que hay que añadir un módulo en las transiciones de DCC a DC para gestionar ese corto.


¿alguien consiguió implementar la frenada combinando DC y DCC deforma satisfactoria?

Sent from my M2007J22G using Tapatalk

Hola, OrEx1883.

Conmutar de DCC a DC, no creo que funcione. Para que la locomotora se parase al conmutar de DCC a DC (suponiendo que el decodificador no hiciera nada raro), en DC la tensión debería ser cero, con lo cual la locomotora se pararía en seco, sin control de luces ni sonido. Si tuviera stay alive, no sé que haría... pero en cualquier caso, no sería una parada controlada.

A partir del espía DCC que crearon Norber y Germán, hice el frenador... y te confirmo que funciona. Consiste en hacer un "barrido" de direcciones (supongamos, 40 ó 50), y luego reenviarlas, poniendo a cero el byte de velocidad (dejando igual el bit de dirección).

Como no tenía mucha experiencia con los Arduino (y sigo sin tenerla, porque yo soy más de PIC´s), utilicé dos Arduinos: uno basado en el DCC-EX (para generar las tramas), y otro basado en el espía DCC de Norber y Germán, comunicados a través del puerto SPI. Es muy cómodo y fácil controlar los trenes a partir del DCC-EX. El circuito frenador funcionaba... hasta que dejaba de funcionar. El Arduino del DCC-EX, se acaba colgando a los pocos minutos. Hice muchas pruebas, analicé tramas del puerto SPI entre ambos Arduinos, pero no llegué a concluir el motivo del cuelgue...

Así que abandoné la idea de los dos Arduinos, y me centré solo en un Arduino, que aparte de contener el espía DCC, creé el código para generar las tramas DCC. No es difícil generar las tramas, en base al estándar DCC que está publicado (ya lo hice hace más de 20 años, con los PIC). En este caso, aparte de multiplicar el byte de velocidad por b'10000000', hay que recalcular el byte final, haciendo la XOR de todos los bytes. Hay que distinguir el tipo de trama, si es de velocidad con dirección corta, larga o de funciones, para reconstruirla... El resultado, es satisfactorio: funciona perfectamente (en casa): la locomotora frena de forma controlada (con su rampa de deceleración) teniendo activas las funciones. Es decir, puedes controlar todo, menos la velocidad. Lógicamente, mediante un relé, conmutas entre el DCC normal, y el "DCC de frenado". No hace falta saber la dirección de la locomotora que tienes en un cantón, porque como el "DCC de frenado" (que está solo en ese cantón), se dirige a todos las locomotoras que ha están en la instalación, una de ellas será la que quieres frenar. Para arrancar, vuelves a conmutar con el relé al "DCC normal", y la locomotora se pondrá en marcha con rampa de aceleración y sonido acorde. No he llegado a probarlo en una instalación con muchas locomotoras.

Mi intención era compartir toda la información en este foro... pero tengo muy poco tiempo, y estoy con otros proyectos, pero intentaré hacerlo. Me siento con la obligación moral de compartirlo, porque la base del proyecto es el espía DCC de Norber y Germán (aparte, de que a mí me gusta compartir las cosas, lo mismo que otros comparten las suyas). El programa que hicieron, lo analicé profundamente (te recuerdo que mi nivel de Arduino es de principiante), y es una pasada de programa (o sketch, o como se diga), de lo bien pensado que está.

Un saludo

Dvorak
(Paco Mallols)

Gracias por actualizar.

La verdad es que tu nivel de conocimientos de electrónica es muy elevado. ¿Tu no te llegaste a hacer una centralita propia? ¿Eres Ingeniero o Técnico de Electrónica o comunicaciones?

Yo iba a tratar de hacer incursiones con los PIC para replicar el decoder de Roco Geoline. Ya hay un proyecto de base pero me gustaría entender el código que hay detrás.

Sinceramente mis conocimientos de programación y ordenadores son buenos pero no los de electrónica a nivel de comunicaciones para incursionar en hacer equipos de DCC. No se si hay alguna documentación que permita adquirir una

Sent from my M2007J22G using Tapatalk

Dvorak escribió:

.... . El circuito frenador funcionaba... hasta que dejaba de funcionar. El Arduino del DCC-EX, se acaba colgando a los pocos minutos. Hice muchas pruebas, analicé tramas del puerto SPI entre ambos Arduinos, pero no llegué a concluir el motivo del cuelgue...

....

Ummm

Yo tuve un problema similar con mi primer "salvagatitos" y conseguí trazarlo a que tenía el DEBUG activo por lo que estaba enviando información al puerto USB (utilizo un arduino micro) y si no tenía nada conectado se acababa llenando algún buffer y se colgaba.

Fue desactivar el DEBUG y asegurarme que en producción no intentaba sacar nada por el puerto serie (USB) y se acabaron los cuelgues

¿podrías volver a mirarlo?

Un saludo

En condiciones normales, si se desactiva el Bit 2 de la CV29, la locomotora no funciona habiendo correinte contínua en la vía. No importa la polaridad.

Si una locomotora, con el bit 2 de la CV29 desactivado, circula normalmente por un circuito digital, en el momento que entra en una zona, préviamente aislada. alimentada con corriente contínua, se parará.

El Matao escribió:

Dvorak escribió:

.... . El circuito frenador funcionaba... hasta que dejaba de funcionar. El Arduino del DCC-EX, se acaba colgando a los pocos minutos. Hice muchas pruebas, analicé tramas del puerto SPI entre ambos Arduinos, pero no llegué a concluir el motivo del cuelgue...

....

Ummm

Yo tuve un problema similar con mi primer "salvagatitos" y conseguí trazarlo a que tenía el DEBUG activo por lo que estaba enviando información al puerto USB (utilizo un arduino micro) y si no tenía nada conectado se acababa llenando algún buffer y se colgaba.

Fue desactivar el DEBUG y asegurarme que en producción no intentaba sacar nada por el puerto serie (USB) y se acabaron los cuelgues

¿podrías volver a mirarlo?

Un saludo

Hola...

Desguacé el circuito conectado con dos Arduinos, reaprovechando los componentes más valiosos, por lo que me sería complicado reproducir ese montaje. De todas formas, te agradezco el apunte, es algo a tener en cuenta futuros proyectos.

¿Es DEBUG algún flag del Arduino micro, para generar algún breakpoint y descargar registros, o similar, como ocurre en algunos PIC´s?

Gracias.

Dvorak escribió:

El Matao escribió:

Dvorak escribió:

.... . El circuito frenador funcionaba... hasta que dejaba de funcionar. El Arduino del DCC-EX, se acaba colgando a los pocos minutos. Hice muchas pruebas, analicé tramas del puerto SPI entre ambos Arduinos, pero no llegué a concluir el motivo del cuelgue...

....

Ummm

Yo tuve un problema similar con mi primer "salvagatitos" y conseguí trazarlo a que tenía el DEBUG activo por lo que estaba enviando información al puerto USB (utilizo un arduino micro) y si no tenía nada conectado se acababa llenando algún buffer y se colgaba.

Fue desactivar el DEBUG y asegurarme que en producción no intentaba sacar nada por el puerto serie (USB) y se acabaron los cuelgues

¿podrías volver a mirarlo?

Un saludo

Hola...

Desguacé el circuito conectado con dos Arduinos, reaprovechando los componentes más valiosos, por lo que me sería complicado reproducir ese montaje. De todas formas, te agradezco el apunte, es algo a tener en cuenta futuros proyectos.

¿Es DEBUG algún flag del Arduino micro, para generar algún breakpoint y descargar registros, o similar, como ocurre en algunos PIC´s?

Gracias.

Desconozco este caso en particular pero en casi todos los compiladores DEBUG y RELEASE son flags y se notan en el rendimiento.

Sent from my M2007J22G using Tapatalk

Dvorak escribió:

....

¿Es DEBUG algún flag del Arduino micro, para generar algún breakpoint y descargar registros, o similar, como ocurre en algunos PIC´s?

Gracias.

No, es simplemente utilizar un Serial.begin() y uno o varios Serial.print (), nada más sofisticado

En la actualidad yo utilizo (copiado de un sketch de Paco Cañada ) el siguiente código

Código: Seleccionar todo

#define DEBUG

#ifdef DEBUG
char output[120];
#define DEBUG_MSG(...) \
  snprintf(output, 120, __VA_ARGS__); \
  Serial.println(output);
#else
#define DEBUG_MSG(...)
#endif


Y luego en el setup.

Código: Seleccionar todo

#ifdef DEBUG
  // Configuramos el puerto serie
  Serial.begin(9600);
  while (!Serial); // para Leonardo, Micro, Pro Micro
  DEBUG_MSG("Inicializamos la placa");
#endif


Y ya donde queramos sacar algo por el puerto USB Serie

Código: Seleccionar todo

DEBUG_MSG("Texto a sacar %i veces, [%x]",valor1, valor2); // podemos utilizar el poder snprintf

De esta forma, cuando estoy contento con el código lo cargo una última vez sin definir DEBUG y ya no genera código que utilize el puerto serie.

Un saludo