DCC++ y decoder LDH

Buenas:

No me he presentado en la sección correspondiente, por ello, primero, en breves palabras digo:

me he metido en ferromodelismo a los 49 años, luego de décadas de modelismo en general. Estoy combinando trenes con robótica. Tengo 3 locos, GP9, FT y F7, algunos vagones de carga (todo americano), un tendido DCC de 5x2.60 metros, más o menos forma de L. Usando DCC++ corriendo en una Arduino Mega.

En cuanto a la consulta que quiero realizar, es porque si bien no tenia problemas con la GP9 y la F7 que tienen un Digitraz y un EZ Bachmann respectivamente, al colocarle un LDH a la FT, esta se plantaba cada vez que enviaba un comando a cualquiera de las otras 2. Y no era un problema de caida de tensión ya que el problema se producia aun si solo estaba la FT en las vias. O sea, las señales se confundían.

Lo resolví luego de investigar, y hay un número que se envia en la cadena que contempla DCC++, el internal register number, que yo enviaba en 1 y no traia problemas hasta la llegada del LDH. Se me ocurrió entonces probar con distintos números para cada loco, y ahi se solucionó.

En concreto, esta es la cadena que se envia a la Arduino corriendo DCC++ (ejemplo):

<t1 5741 30 1> (velocidad 30 avante para locomotora 5741)
o
<t1 5952 20 0> (velocidad 20 reversa para loco 5952)

el "1" que sigue a la "t", lo he cambiado por 1, 2 o 3, distinto para cada decoder, y problema resuelto.

Aclaro que comandando las locos desde JMRI no se daba el problema, sí desde DCC++ al que he modificado para que lea potenciómetros deslizantes a modo de throttles.

A alguien le ha sucedido esto?

Saludos,
Robert

Hola y bienvenido al foro:

Como probablemente dedujiste al arreglar tu problema, la instrucción para que la central mueva una locomotora debe incluir cuatro valores, siendo el primero el del Registro. No uso DCC++ pero leyendo el código disponible en Github no caben muchas dudas.

La central DCC++ debe funcionar como es habitual: manda continuamente a la vía los últimos parámetros que el usuario ha seleccionado. Así, aunque el descodificador de una locomotora ya haya obedecido la orden, si se queda sin tensión y se reinicia volverá a encontrar en la señal de la vía otra vez el comando que le dijimos en su momento, y reaccionará a él en cuanto recupere la tensión como si nada.

Para conseguir que los últimos comandos estén siempre en la vía es preciso que la central los esté mandando continuamente. Eso significa que la central debe almacenarlos en algún sitio, y ahí es donde entra la función del Registro (el número que sigue al código '<t'): un registro para cada comando distinto que debe repetirse permanentemente en la vía. Cuando tu mandabas todas las órdenes como '<t1...' borrabas de la vía las órdenes precedentes y las sustituias siempre por la orden nueva. Así que cualquier incidencia que afectara a los descodificadores que obedecían las órdenes precedentes les dejaba sin información en la vía a la que obedecer.

Aparentemente esta central almacena 12 registros distintos (mira en Config.h línea 23), y aparentemente también el controlador implementado en el JMRI hace uso de los registros bien.

Ahora tú también los usas bien. Tan solo hay que recordar que se pueden mantener presentes en la vía hasta 12 comandos distintos (para 12 locomotoras distintas funcionando a la vez), al menos mientras no se cambie el valor del macro MAX_MAIN_REGISTERS a un valor diferente.

Adjunto las instrucciones del uso del comando '<t...' que probablemente te dieron la pista de la solución. Provienen del archivo SerialCommand.ccp.

Código: Seleccionar todo

/***** SET ENGINE THROTTLES USING 128-STEP SPEED CONTROL ****/   

    case 't':       // <t REGISTER CAB SPEED DIRECTION>
/*
 *    sets the throttle for a given register/cab combination
 *   
 *    REGISTER: an internal register number, from 1 through MAX_MAIN_REGISTERS (inclusive), to store the DCC packet used to control this throttle setting
 *    CAB:  the short (1-127) or long (128-10293) address of the engine decoder
 *    SPEED: throttle speed from 0-126, or -1 for emergency stop (resets SPEED to 0)
 *    DIRECTION: 1=forward, 0=reverse.  Setting direction when speed=0 or speed=-1 only effects directionality of cab lighting for a stopped train
 *   
 *    returns: <T REGISTER SPEED DIRECTION>
 *   
 */
      mRegs->setThrottle(com+1);
      break;

Estuve investigando eso del máimo.

De todos modos el problema no se daba con los otros 2 decos. Solo con el LDH.