Mi Tren

Regalos de navidad

Manolo — Sun, 29 Jan 2012 18:10:02 +0000

Estas navidades, como siempre, ha caído algo para el tren. Por un lado, esta estupenda locomotora.

A la locomotora ya le he instalado un fumígeno. Se trata de la pareja de la edición limitada 37912.

Por otro lado también me he hecho (regalo de mis padres) con estos vagones para completar el set del hace dos años.

Se trata del set 43981, venía un poco dañado en dos de los vagones de carga, así que el precio ha sido bastante bueno. Por un lado la puerta del vagón cerrado, que una vez reparada ya no se ve que estuviera rota.

Por otro lado el borde del vagón de carga de toneles… aquí los trabajos de reparación aún se ven… Supongo que también sirve para darle realismo.

Nueva locomotora HAMO e interfaz loconet

Manolo — Sat, 29 Oct 2011 10:51:24 +0000

Recientemente he incorporado a la colección una locomotora HAMO (BR012) y un interfaz para una mobile station.

La idea es convertir la locomotora a sistema marklin, usar el interfaz para comunicar con rocrail por loconet y dejar la mobile station como un control más.
Lo segundo aún no tengo muy claro si se puede hacer. El interfaz estaba pensado para una central intellibox. Así que tengo que investigar un poco más.
Para la conversión a digital en tres carriles la cosas es más sencill. No tengo ni que instalar el imán. la conversión es casi directa sólo me surge una duda: ¿para qué sirve el pequeño tornillo de la foto?

Reparando el tren grúa – paso II

Manolo — Sun, 17 Jul 2011 20:16:24 +0000

Este fin de semana he portado el último código al 12f675. En principio este es el ucontrolador que usaré para reparar la grúa ya que necesito un conversor AD para el calibrado de los motores.

Aún no tengo claro si necesitaré dos ucontroladores o uno. Necesito 4 pines de salida (uno por motor más el que lleva la frecuencia que marca la velocidad de los motores), 1 de entrada y otro AD. Con estas condiciones un único pic debería ser suficiente. Sin embargo, no he conseguido hacer funcionar la entrada en el pin que se utiliza también para el master reset (GP3). Creo que es un problema con la resistencia interna del PIC. Si no consigo hacerlo funcionar, necesitaré diferenciar las funciones de grúa en un pic, y las del decodificador en otro. En cualquier caso este era el plan original para así añadir 4 funciones de control de leds a la grúa.

Antes de investigar más, me voy a centrar en la placa de calibrado, que ya está hecha. Lo primero será ver si los motores funcionan y luego decidiré si necesito uno o dos pics.

Por otro lado, he probado la opción de programar una dirección de consist (función de grupo de locomotoras) y parece que funciona bien – como siempre al programar es necesario reprogramar varios cv para que funciona. El único problema, a resolver más adelante, es que la programación en la vía principal (POM) no parece funcionar. Esto no es clave para la reparación de la grúa, pero sí para integrar el decodificador de funciones en otras locomotoras.

Reparando el tren grúa – paso 0

Manolo — Sun, 10 Jul 2011 07:36:30 +0000

Antes de lanzarme a fabricar mi propio decoder para el control del vagón grúa, se me ha ocurrido soldar una bobina en el lugar de los coponentes quemados. El porqué viene de las notas de aplicación de elliptec – el fabricante de los micromotores – y también porque no había nada que perder. Al hacerlo, el decoder casi vuelve a la vida:

Recibe y acepta comandos. Lo sé porque lleva un pequeño led que parpadea al mandar acciones en cualquiera de los tres motores. Además funciona como marcan las instrucciones: primero siempre un comando de función a v=0
No consigue activar las salidas de los motores. Con lo que deduzco que hay algo más quemado. Además, la salida que está más alejada de la alimentación (creo que es la función 1) es la única que parece reaccionar y tiende a quedarse activa. Eso sí, tiende a reaccionar justo a la salida del microcontrolador, de ahí va a ¿un transistor? y nunca llega la señal a la salida del motor.

Así que me voy a intentar continuar con el plan de substituir el decoder. El siguiente paso, hacerme una placa de calibrado de motores… así de paso comprobaré si los motores aún funcionan.

Reparando el tren grúa – paso I

Manolo — Mon, 04 Jul 2011 19:09:57 +0000

Para reparar el desastre del vagón grúa, el primer paso ha sido retomar el proyecto del decodificador de funciones.

La primera versión que hice, aunque simplemente copiaba el diseño original de Paco Cañadas, no funcionó muy bien. No obstante, el software para el vagón grúa deberá ser algo diferente. De momento he traducido la versión original a un PIC16f628a, más que nada por si luego quiero hacer parte del programa que comunique en serie con el ordenador – posiblemente lo necesite para calibrar los motores.

Dejo aquí el código. Lo próximo será hacer el software específico de control y calibrado del motor

Función SpeedCurve en Rocrail no aprobada

Manolo — Tue, 07 Jun 2011 21:56:49 +0000

~~Aún no sé porque – no me han dado ninguna explicación – pero~~ la contribución del speedcurve no ha sido aceptada por el administrador de Rocrail.
~~A la espera de más información – al menos me gustaría que me dijeran porqué la rechazan –~~ he compilado un paquete basado en la rev 2631:

rocrail-setup-2.0.0-SpeedCurve-rev2631-win32.

Esta solución debería solucionar el problema de pérdida de memoria que describía en el anterior post. Los nuevos ficheros fuente (speedr).

La contribución no se va a incluir en la distribución oficial porque “sólo es útil para decoders de bajo coste que se pueden substituir por poco dinero” . Yo seguiré actualizando esta versión para uso propio, así que si alguien la quiere, sólo tiene que pedirla .

Función Speedcurve en Rocrail

Manolo — Sun, 05 Jun 2011 20:04:50 +0000

Este fin de semana he mandado a la gente de Rocrail una contribución para añadir una funcionalidad a Rocrail. Se trata de la capacidad de tener una curva de velocidad que se gestiona desde el ordenador.

La documentación está en Inglés:

Finally I have had some time to implement the functionality I was requesting. I am attaching an explanation on what the motivation was, and how it can be used.
Since I am not at all an expert on C, neither on the rocrail code, it has taken me longer than expected. Moreover, there is still a problem with the code – a memory leak – I have not been able to solve. I think it is in the way I am attaching the speedcurve parameters to the loc command (loc.c file)… but I am not sure – any help, correction and suggestion for improvement is very welcome.
Basically I have modified the wrapper description file to include a new property to the loc (speedcurve). Then I have modified the loc.c file to explore if a locomotive has this property and include them in the commands sent to the stations. Finally, in DDX, this parameter is treated in MM locomotives.
The reason to address only MM is basically because DCC decoders use to have an actual speedcurve functionality. In any case, since the information is transmitted to any station, anyone could make use of it to implement the speedcurve as I have made for DDX MM.
Hope this new feature to be of interest. It needs still some refinement for the memory leak.. but hopefully someone could give me a hint on how to solve it, so it can be included in a stable release – if it is of interest of course.
I am attaching the three source code files modified, a plan example and the explanation of the functionality.

Description and motivation

A speed curve is a well-known feature of new decoders, and especially it is a feature extensively used in DCC hardware. The solution is normally based on a number of CV that grants the user with the possibility to specify non-linear speed curves, which are closer to reality. The speed can be set per engine step and in addition it is also possible to define the acceleration and deceleration time.

Older decoders, and especially some low-cost solutions designed to work with the motorola format, cannot access such rich feature. In the best scenario it is possible to adjust the acceleration and deceleration time, but never to define different parameters per engine step. This handicap can be easily overcome by software with Rocrail, introducing predefined speed profiles per engine step that can be interpreted by DDX.

The speed curves by software, or speed profiles, are based in the definition of the time each step needs to be hold before going to the next/previous one. It is noteworthy to clarify that the functionality provided by a hardware speed curve is not exactly the same, since a speed profile will not affect the speed magnitude, but the acceleration/deceleration time between steps.

In this way, it is easy to code curves forcing long pauses to accelerate for the lower steps and short pauses for the higher steps, or long pauses to decelerate in higher steps and low pauses in the lower steps.

ACCELERATION CURVE 1

DECELERATION CURVE 1

Furthermore, speed profiles have been proved especially useful in some decoders that, in addition to the lack of a speed curve, have some particular time constraints to achieve an efficient behavior:

Märklin DIGITAL 146871 PIC-Decoder 1. This low-cost decoder needs some pause after any speed change request to actually reach the new speed. This is important when two consecutive commands are sent, and especially critical if a change of direction is requested. In those cases, the decoder needs to stop before implementing the change of direction. Without the mandatory pause, the engine does not “accept” the request, and the change of direction is never achieved.
TAMS LD_W_3. This decoder needs an update on the speed after a change of direction request. Otherwise, the delay in accepting the order depends on the loco stack of commands and active protocols in DDX – worst scenario up to 18 seconds of delay with MM, MMLP and DCC active.
Motorola format I. This protocol forces a stop whenever a change of direction is requested. The behavior can be improved by implementing speed profiles, which may help considering the speed when
the change of direction is requested as a persistent variable. In this way, after the change of direction is implemented, the speed is recovered and the loco does not stop.

How it works

The speed profiles are implemented as a new feature for DDX working on Motorola protocol locomotives. The user needs to define per each step (14 or 28 steps) the delay until the next or previous step. As an example, the accelerating curve in previous section is defined by:

Step	Delay to next step (ms)	Next step
0	1500	1
1	1000	2
2	900	3
3	800	4
4	700	5
5	600	6
6	500	7
7	400	8
8	300	9
9	200	10
10	200	11
11	175	12
12	150	13
13	125	14
14	100	NA

The curve can be extended to 28 steps. In any case, as expected, the last parameter – i.e. ms to go beyond the maximum step – is never used.

IMPORTANT: a minimum delay of 10ms between steps should be respected (100ms recommended value). Otherwise, depending on the platform, the rocrail serveray collapse.

In a similar way, the deceleration file is defined by:

Step	Delay to previous step (ms)	Next step
14	2000	13
13	1800	12
12	1200	11
11	1000	10
10	600	9
9	600	8
8	500	7
7	400	6
6	300	5
5	200	4
4	175	3
3	150	2
2	125	1
1	100	0
0	200	*Pause before sending a refresh in a change direction request

In this case, the last parameter, which was not used in the speed profile definition, has been used to code a pause if a refresh message wants to be sent at the end of the sequence when a change direction is requested – 0ms =non refresh.

In reaction to a speed change request, a sequence is initiated to reach the new speed going through the curve. In this way going from v=4 to v=9 would trigger the following sequence:

· Wait 700 ms and V=5

· Wait 600 ms and V=6

· Wait 500 ms and V=7

· Wait 400 ms and V=8

· Wait 300 ms and V=9

In the same way a change of direction in v=4 would trigger the following sequence:

· Wait 175 ms and V=3 reverse

· Wait 150 ms and V=2

· Wait 125 ms and V=1

· Wait 100 ms and V=0

· Wait 1500 ms and V=1 forward

· Wait 1000 ms and V=2

· Wait 900 ms and V=3

· Wait 800 ms and V=4

In the case of having any delay defined for v=0 – for instance 200ms-, at the decelerating curve, a last message would be sent:

· Wait 200 ms and V=4

The decelerating curve would be used in a similar way to go from v=9 to v=4.

Configuration

The configuration of any speed profile is done at the XML file describing the layout.

As a new parameter describing a loco, now it is possible to include a “speedcurvestep”:

For each step the ms to wait until the next and previous steps need to be set.

If a step is not defined, or if it is defined with a 0ms wait, it will not be considered in the acceleration, or deceleration profile. Thus, a speedprofile as the one above will produce the following curve:

ACCELERATION CURVE 2 (wait in v=0 3000 ms)

DECELERATION CURVE 2

The sequences presented(v=4 to V=9) before would become:

· Wait 0 ms and V=9

Delays equal to zero are not considered.

And V=4 change direction would become:

· Wait 100 ms and V=3 forward

· Wait 2000ms and V=2 forward

· Wait 1000 ms and V=1 forward

· Wait 1500 ms and V=0 forward

· Wait 3000ms and v=4 reverse

Examples

The attached file (speedr) presents the modified source files and four examples :

· One typical speed profile (curve 1, Firemen)

· One low cost (curve 2, 130TB)

· One motorola I (curve 3, BR44)

· One tams (curve 4, V160)

The rest of the locomotives are just included to test that the speedcurve does not affect other decoders.

ACCELERATION CURVE 3(no delay)

DECELERATION CURVE 3

ACCELERATION CURVE 4 (no delay)

DECELERATION CURVE 4 (repeat chdir)

Pantógrafo móvil y reparación de vagón grúa

Manolo — Tue, 26 Apr 2011 13:08:42 +0000

Hace unos días tuve un accidente bastante importante con el vagón-grúa de bomberos. Aún no sé muy bien porqué, pero el circuito de control se quemó. El resultado es que la grúa ya no está operativa.

En la esquina inferior izquierda se pueden ver los tres elementos que acabaron socarrados. He intentado averiguar que eran, y ver si se podían substituir, pero ha sido imposible. Incluso al microscopio no ha habido forma de leer algo que diera una pista de que elementos podían ser. También probé suerte con diversos foros, y lo más que he llegado a averiguar es el nombre del fabricante de las piezas electromecánicas que hacen de motor: elliptec.

De hecho parece que märklin ha seguido bastante de cerca las guías de implementación que publica el fabricante – al menos en cuanto al microcontrolador se refiere. Y el propio fabricante publicita sus trabajos hechos para la marca. Por ejemplo, el modelo de pantógrafo móvil, y el del equipo de limpieza de la catenaria también utilizan la misma tecnología.

Ahora lo que me queda es la posibilidad de construir un nuevo circuito nuevo que emule el quemado… y a ser posible de tamaño similar. Lo primero será comprobar que efectivamente los motores piezoeléctricos siguen funcionando. Para ello ya me he hecho con la etapa de potencia que recomienda elliptec, y tengo la información de catálogo para buscar las frecuencias que hacen que el motor actúe en un sentido u en otro. Lo siguiente es hace un pequeño circuito que lo ponga a prueba.

Si los motores piezoeléctricos funcionan, trataré de integrarlos con el decoder DCC – que nunca terminé.

Nuevo set de vagones “Transporte de aviones”

Manolo — Mon, 25 Apr 2011 19:58:56 +0000

Hace un par de meses en un viaje a Alemania volví a comprar material märklin. La verdad es que iba buscando algunos vagones de mercancía para la composición Sand, pero me encontré con esta oferta de set:

Los datos de märklin los copio aquí abajo:

Escala: H0 Época: II

Modelo real: 6 vagones de plataforma y 1 furgón de cola de tren mercancías de la Deutsche Reichsbahn-Gesellschaft (DRG). 3 aviones Messerschmitt ME 109, desensamblados para su transporte por ferrocarril. Estado de servicio durante los años 1930.

Modelo en miniatura: 3 vagones de plataforma con batalla (distancia entre ruedas) larga y bastidores de carga para el transporte de fuselajes de avión, 3 vagones de plataforma con batalla (distancia entre ruedas) corta, plataforma de guardafrenos o bien garita de guardafrenos y bastidores de carga para el transporte de pares de alas, 1 furgón de cola de tren mercancías. 3 modelos de aviones (Busch). Fuselaje y alas premontados y asegurados con bastidores para carga. Los aviones no están disponibles sueltos. Longitud total incluidos topes 94,7 cm. Eje con ruedas para corriente continua 14 x 700580.

Serie única.

La locomotora correspondiente al set de vagones “Transporte de aviones” es la locomotora de vapor de tren mercancías de la serie 53 que encontrará con el número de artículo 37023 en el surtido H0 de Märklin.

Banco de pruebas

Manolo — Mon, 07 Feb 2011 15:05:46 +0000

Este fin de semana he podido construirme un auténtico banco de pruebas para locomotoras.

El proyecto surgió en LCTM. Miguel Angel Piera me dio la idea al enseñar el banco que se había hecho – y luego mandarme información sobre cómo construirlo – y Antonio Sanz me puso sobre la pista definitiva del banco que quería construir al pasarme un enlace a forotren donde se explica la lista de materiales a utilizar.

Mi receta es bastante similar a la original:

- 24 rodamientos de 3x8x3 para aeromodelismo. Los encontré en ebay a 1€ el rodamiento.

- 1 regleta de conexión eléctrica. La receta original hablaba de cables de 6mm. En realidad está es la parte más difícil de localizar y lo importante es que la separación de los tornillos de espacio suficiente para atornillar dos rodamientos (8mm+8mm mínimo). También es crítico que los tornillos utilizados por la regleta sean de un diámetro inferior a los del interior del rodamiento para poder atornillarlos (3mm).

- 3 varillas de aporte para soldaduras eléctricas de 2,5mm de diámetro. Yo las compré en Leroy Merlin y la medida venía impuesta por el diámetro interior de la regleta de conexión. En la receta original se hablaba de varillas de 3,5mm. Ya digo que depende de las medidas de la regleta.

- 2 trozos de madera para sujetar las varillas.

- Plástico fino. Yo he reutilizado el plástico de la receta original. En ella se utilizaba canaletas de pasar cables de 25mm para agrupar los pares de ruedas, sin embargo en mi caso era una medida excesiva y dejaba una separación entre ruedas demasiado grande.

-6 tornillos, 24 tuercas y 24 arandelas. El tamaño no es crítico, esta tornillería se utiliza para sustituir las piezas de plástico de la canaleta que agrupaban las ruedas.

Lo primero que se hace es sacar la pieza metálica de la regleta. Ésta, junto con sus tornillos, es el soporte para los rodamientos. Con los 24 rodamientos se necesitan 12 de estas piezas metálicas, que darán lugar a un banco que pueda acoger locomotoras de 6 ejes máximo.

Para garantizar que los ejes estén bien alineados – los rodamientos queden bien enfrentados dos a dos – es necesario agruparlos de alguna manera. Además, con el agrupamiento, se tiene una forma fácil de desplazar los rodamientos por las varillas y adaptar la distancia entre ejes a diferentes composiciones.

Yo primero probé con la canaleta que mencionaba el artículo de forotren, pero me daba como resultado una distancia entre ruedas excesiva. Miré a ver si encontraba canaletas más pequeñas (apenas necesitaba bajar a 23mm) u otras soluciones como “U” metálicas o escuadras. Sin embargo era muy difícil acertar con una pieza que tuviera las medidas necesarias para garantizar la distancia entre ruedas y ajustar con la pieza metálica de la regleta.

La solución vino por reutilizar el plástico de la canaleta y ajustar la distancia entre ruedas con tornillería

Aunque la solución es menos limpia que la original, da más consistencia al agrupamiento, y se consigue menos vibraciones cunado las máquinas funcionan a plena velocidad. La distancia entre tuercas se regula para que el desplazamiento por las varillas sea suave.

El último paso es limpiar 3 varillas de aporte de soldaduras, y hacer tres agujeros en 2 piezas de madera. Los agujeros deben estar a 1,5 mm de distancia, es decir, 3 mm de distancia entre raíles. Esta medida puede variar dependiendo del grosor de la pieza metálica que se extrae de la regleta.

En uno de los extremos de las varillas se ajusta la toma de corriente y listo

Algunas consideraciones extras para una versión más avanzada del banco:

La receta original habla de 3 piezas de madera para sujetar las varillas. Yo he querido usar sólo dos para tener plena libertad al colocar los rodamientos y no limitar el número de composiciones. Sin embargo, con locomotoras pesadas, es cierto que las varillas sufren y empiezan a combarse. Para una versión más avanzada habría que volver a las 3 piezas de madera originales o buscar una solución alternativa. Las piezas tienen que ser lo suficientemente grandes para absorber las vibraciones de los rodamientos, pero si se pone una pieza central se quiere que ésta sea estrecha para no limitar el número de locomotoras que pueda usar el banco. Además, si se pone una pieza central es importante la posición de las varillas en los bloques de madera, debiendo quedar lo más altas posible. De lo contrario, la pieza central levantará las locomotoras de más de 3 ejes – aquellas que hagan uso de rodamientos a ambos lados del bloque central.
La toma de corriente en el artículo original era para sistema de 2 carriles y quedaba muy bien disimulada en los bloques de madera. Para una versión más avanzada sería bueno copiarla.
En forotren se mencionaban varios proyectos para adaptar un medidor de velocidad, al estilo de la solución comercial de märklin para los bancos de pruebas. Es algo a lo que no he dedicado mucho tiempo, pero creo que se podría incluir en una versión más avanzada, con conexión a rocrail y a un 7 segmentos.
Con las tres modificaciones anteriores solo faltaría una forma de “frenar” los rodamientos para poder empotrar el banco en una maqueta, al estilo de la solución de brawa (enlace). La idea es frenar los rodamientos para que las locomotoras entren y salgan del banco, en lugar de levantar el banco como hace brawa. Sin duda, cualquiera de las dos opciones – frenar o levantar – no es sencilla, y no sé muy bien si se podría conseguir una buena solución casera… habrá que probar.