|
1. Prólogo
Para controlar los desvíos y demás artículos magnéticos y luminosos de
nuestra instalación podemos usar varios métodos, que
van desde el accionamiento manual hasta un
sofisticado control informático. En mi opinión
personal, el mas atractivo es la clásica consola con
pulsadores distribuidos sobre un "grafo" de las
vías. Es intuitivo y similar al utilizado en la
realidad. Los controles mediante simples
conmutadores en cajas de control Märklin o el
digital usando el Keyboard (Märklin 6040) resultan
poco representativos de la situación de los desvíos,
y el uso de un programa estándar de control nos
obliga a contar con dispositivos adicionales, como
el interface (Märklin 6051) o una central (Uhlenbrock
Intellibox, ECoS), además de suponer una sobrecarga
en el consumo y en tráfico de órdenes, lo que se
concreta a veces en fallos en el accionamiento. Una
interesante y novedosa opción es el sistema
"Track Control" de Uhlenbrock, pero se me antoja
caro y además necesita de una central Intellibox.
Littfinsky LDT también tiene un sistema modular,
pero también es complejo y caro. Anteriores a estos
está el sistema modular de Heki. Sobre este y los
demás nuestro compañero Antonio Sanz tiene un amplio
artículo en su
página web.
|
|
 |
|
| |
Este ejemplo
de tablero de mando, tomado de
www.indydigs.com/wires,
muestra lo que mi sistema quiere evitar: Una
selva de cables en la que cualquier fallo
siempre es difícil de diagnosticar y
solucionar |
|
Por lo expuesto, la elección sería la consola clásica, pero esta también
presenta un gran handicap: El exceso de cableado
para controlar todos los artículos. Cada desvío usa
3 cables, que deben de dirigirse al cuadro de
control. Esto hace que en poco tiempo nos
encontremos con un buen mazo de múltiples hilos que
tenemos que conducir a lo largo de nuestra maqueta.
Este problema se agudiza si, como es mi caso, la
instalación está compuesta por varios módulos
independientes, lo que obliga al uso de conectores
de bastantes polos y a una normativa compleja para
su conexión.
La alternativa para la reducción del número de
cables pasa por una codificación digital de las
órdenes y el uso de decodificadores en los desvíos.
El controlador para estas órdenes digitales puede
incluirse en la consola, pero su diseño, que debe de
incluir algún tipo de procesador (PIC), se presenta,
al menos para mí, como una tarea demasiado compleja.
La alternativa es el uso de algún tipo de
controlador estándar. Los PLC (Control de lógica
programable) resultan en este caso voluminosos y
caros (en otra sección de mi maqueta uso uno de
ellos, en un cometido mas simple). Esto nos deja
como única alternativa el uso de un PC. Esta opción
me resulta particularmente molesta, ya que el el
tamaño y el método de control (teclado, ratón) son
muy "chocantes" (en mi opinión) para su integración
en la maqueta. De todos modos, es la única opción
posible, y como vemos a continuación, solucionable
en gran parte.
2. El proyecto
El arranque de este proyecto fue dado por una
circunstancia casual: Buscando por eBay encontré que
estaban a la venta unas pantallas TFT de pequeño
tamaño con dos cualidades interesantes: Además de su
conexión al PC incluían dos entradas de vídeo, y lo
mas útil, equipaban un sistema táctil de emulación
de ratón. Esto solucionaba de un plumazo las dos
pegas principales del PC: Tamaño y sistema de
control. Esto me decidió y me puse manos a la obra.
Se usará el sistema clásico de Märklin Digital, con
señales de protocolo Motorola.
El proyecto se basa,
como ya he expresado, en la economía de cables a
través de la maqueta: Sólo son necesarios los dos de
la fuerza de tracción, provenientes de la Control
Unit (o de los boosters), y otros tres para este
control de artículos: +12 voltios de alimentación,
señal de control y masa. Total 5 cables que pueden
conducirse fácilmente a través de los módulos
mediante conectores sencillos.
El sistema consta de los siguientes elementos:
Hardware:
 
PC: Es suficiente con un equipo que soporte
Windows 98. En principio pensaba desarrollar el
sistema con MS-DOS, pero dada la falta de drivers
para la pantalla táctil descarté esa idea. Mi
elección es bastante particular: "Medio" portátil
IBM con un Pentium II, 64 Mb. y un disco de 8 Gb. Lo
de medio se refiere a que literalmente se le
seccionó la pantalla, resultando un artilugio muy
plano y de pequeño tamaño, que incluye teclado y
dispositivo apuntador. Una vez instalado en la
maqueta permanecerá oculto, ya que todo se
controlará desde la pantalla, aunque será accesible
mediante un panel deslizante. Perfecto.
Hace unos meses se hablaba en la lista del mal uso del vocablo "bizarro":
En este caso, y ofendiendo a nuestro idioma, podemos
decir que este PC es realmente "bizarro". En la
imagen de la izquierda pueden verlo junto con la
pantalla táctil, que ya presenta el software de
control, aún en desarrollo.
Para los que puedan prescindir de detalle del control táctil, el uso de
uno de estos portátiles IBM ThinkPad, que son muy
pequeños, es ideal, y supongo que pueden encontrarse
en el mercado de ocasión a buen precio. Para los mas
pudientes existen maravillosos Tablet PC, táctiles
pero a precios muy altos.
Pantalla/control: Están disponibles dos tamaños
de pantalla táctil (a un precio asequible: las de
15" que se usan en los TPV son bastante mas caras):
7" panorámica y 10,4" "normal". La de 7" es algo mas
barata y de un tamaño mas acorde con el resto de
elementos de control, pero su proporción 16/9 me
podría resultar inconveniente para el controlador de
vídeo del PC. Me decidí por la mayor de 10,4", que
aunque mas voluminosa, presenta mas espacio para
controles. La inclusión de dos entradas de vídeo
adicionales puede ser útil para el uso de cámaras en
la maqueta o incluso sobre alguna loco o vagón. El
ratón se emula táctilmente con una conexión USB, de
ahí la imposibilidad de usar MS-DOS. En las pruebas
que he practicado he encontrado satisfactorio el
sistema táctil, con la única salvedad de que es
aconsejable el uso de un puntero, al menos para los
que tenemos dedos "porrones".
Codificador: Una placa con conexión al puerto
paralelo del PC que incluye el chip Motorola
MC145026 y genera las señales seriales que controlan
los decoders de desvíos.
Decodificadores: Aun por decidir si usaré
decoders estándar de Märklin K83 (o compatibles) o
una placa hecha por mí. Cuestión de Euros.
El sistema usa un circuito independiente del de
tracción, que es controlado por mecanismos estándar
de Märklin (Central Unit + 80f). También este
proyecto puede ser de utilidad para aquellas
instalaciones en las que no se disponga de control
digital de los trenes, como son, en nuestro ambiente
Märklin las de escala Z, pero se quiera un control
algo mas efectivo de los desvíos y otros artículos.
Referencia:
-
Pantalla
táctil: En eBay se puede buscar como '7"
touchscreen VGA' o '14.4" touchscreen VGA'.
Aquí hay un enlace, aunque supongo que con el
tiempo desaparecerá:
10.4" VGA. Precios entre 160 y 180 €, mucho
menos que una de 15" de TPV, unos 400 €.
-
PC: Los
compactos IBM ThinkPad de 13,3" antiguos se
encuentran en eBay por unos 100-150 €, como este
ThinkPad 600. Hay que tener en cuenta que un
portátil actual se puede conseguir por menos de
400 €, así que sólo es interesante la compra si
se consigue a un precio muy bajo (el mío me
costó 0 €, ventajas de la profesión). En cuanto
a la "decapitación" del mismo, evidentemente
es algo que queda a la voluntad del usuario.
Si no se procede a esta cirugía, poco
aconsejable en un modelo nuevo, es mucho mas
práctico el uso de una simple torre (o de
sus componentes).
-
Codificador:
El chip Motorola MC145026 (y su pareja para los
decoders MC145027) teóricamente se encuentra
fuera de producción, víctima de la directiva
RoHS, pero yo no he tenido problema en
conseguirlo a través de mi proveedor habitual de
electrónica aquí en Cádiz. También disponibles
en Conrad Electronic, aunque no en otros
proveedores como RS Amidata. Para información
técnica
aquí puede descargarse su hoja de
características.
-
Decoders:
Las dos opciones son hacérselos uno mismo o
comprarlos hechos. Como veremos mas adelante mi
sistema tiene algunas diferencias con el Märklin
Digital, pero se pueden usar los estándar. Estos
se pueden conseguir a partir de unos 20 € (MAD
4), y podemos elegir además entre los
5211 de Viessmann,
los LDT en Conrad, o irnos directamente a
los K83 de Märklin (unos 30 €). Todos estos
necesitarían de retoques para permitir el uso de
la señal independiente de la de tracción. Para
construírselos uno mismo según mi proyecto
necesitamos chips MC145027, un chip MC14051, un
"piano de ratón" de 4 vías, 8 transistores BF680
y las bornas para las tomas, además de algunas
resistencias y condensadores. Y claro, la placa,
que hay que hacerla. Hay que hacer los números.
Software:
El ya citado Windows 98, que ofrece en este
caso varias ventajas: Pocas exigencias de hardware,
arranque rápido y poca ocupación en disco. Se
podrían usar versiones mas recientes, como XP, pero
necesitarían PCs mas potentes y tardarían mas en
arrancar, además de necesitar un disco mas grande.
Descartado el Linux, por el que siento gran
simpatía, pero del que conozco bastante menos que
de los engendros del Sr. Gates.
Visual Basic 6.0 para el desarrollo. Es
intuitivo, produce un código medianamente eficiente,
y hay gran cantidad de ayuda impresa y on-line. Para
la confección de los gráficos uso Paint Shop Pro
X2, mas fácil de manejar que el PhotoShop y con
posibilidades muy parecidas, al menos para esta
tarea. En principio pensaba usar simplemente MS-DOS
y QuickBasic 4.5, para el que tengo bastantes
librerías gráficas, pero, como ya he comentado, la
falta de drivers para la pantalla táctil me hizo
desistir de la idea. Una ventaja del QuickBasic
sobre el VisualBasic es que el primero dispone de
ordenes directas para acceder al puerto paralelo del
PC, cosa que no contempla el segundo. Esto tiene
fácil solución porque existen librerías para este
cometido:
www.pablin.com.ar. Además puede que simplemente
usando órdenes LPRINT se pueda controlar el
MC145026, aunque esto está pendiente de prueba.
3. Alcance del control.
Como ya he expuesto, la finalidad de este proyecto
es controlar solamente artículos magnéticos
(desvíos y señales) y luminosos, además de
dispositivos como vías de desenganche y módulos de
frenado, y en el futuro mecanismos mas complejos
como p.e. la rotonda. Este control se realiza independientemente del cableado de tracción a
las vías y usando una fuente de alimentación también
independiente. No contempla retroalimentación ni
ningún otro tipo de control. Es simplemente una
alternativa a la consola con los pulsadores y el
grafo de vías, con el fin primordial de ahorrar
cableado.
|
El uso de un PC para controlar el chip
MC145026 presenta algunas limitaciones. Al
usar el puerto paralelo de una manera
elemental, que en principio presenta 8 bits
de salida, tenemos que hacer algunos
recortes: El MC145026 tiene 5 "trits"(1)
para definir la dirección del decoder que
recibirá las órdenes. Esto supone 243
posibles direcciones (80 en el sistema
Märklin, que usa también sólo 4 bits de
direcciones). Además tiene una
entrada de datos de 4 bits, permitiendo la
dirección en cada placa de decodificación de
4 desvíos. Los dos buses suman 9 bits, por
lo que en principio nos sobra uno. Además el
PC no puede presentar 3 estados en sus
salidas, por lo que nos limitamos a
uso de 1's y 0's exclusivamente. Estas dos
circunstancias limitan las posibles
direcciones a 16 (4 bits), bastantes menos
que el sistema original. En principio, en mi
caso, el uso de 16 posibles tarjetas de
decodificación, con 4 canales cada una, es
suficiente, y casi podría decir que
excesivo. De todos modos el puerto paralelo
posee alguna señal más aparte de los 8 bits
de datos, por lo que con alguna programación
extra podemos controlar 32 tarjetas (5 bits
de direcciones). Estoy contemplando en el
diseño de la placa de control el posible
direccionamiento de este 5 bit. En cuanto al
uso de "bits" en vez de "trits", la cosa no
tiene arreglo sin un hardware mas
complicado. Serían 32 tarjetas contra las 80
del sistema Märklin... No es mucha
diferencia. |
|
El corazón del
sistema: El Motorola MC145026 genera los
pulsos que controlan los decodificadores,
con el mismo protocolo con el que gobernamos
nuestras locomotoras, aunque en este caso
las órdenes circulan por un circuito
independiente. La activación de la señal TE
provoca el envío de los datos presentes en
las patillas del lado izquierdo del diagrama
a través de la salida Dout
|
Los decoders. En caso de que los construya yo
mismo, incluyen unos "pianos de ratón" de 4 (o 5)
vías (al contrario de los estándar, que usan estos
DIP-Switches con 8 vías para simular los 3 estados
de la entradas, (aunque por economía los estándar en el DIP-Switch
también sacrifican una dirección, círculo amarillo
en la foto). Además no es necesario el circuito para
rectificar la señal de la vía. Si los compro hechos
hay que eliminar esos componentes, y tener cuidado
en la disposición de los switches para no establecer
ninguna combinación fuera de los estados "1" y "0".
Como información adicional, en la imagen de la
derecha podemos ver el esquema del decoder de
Viessmann (click para agrandar). En él vemos el chip
MC145027, y el decoder 3->8 74HC138 (que trabaja en
este caso de un modo diferente al multiplexor
MC14051 empleado por Märklin). Si fabrico los
circuitos emplearé este último. Con el se escoge
según los datos enviados la bobina correspondiente y
a través suyo se transmite el bit de control, tres
veces como se explica mas adelante. Un esquema del
K83, aunque a mano alzada, se puede ver
aquí.
El software. En principio controlar la placa
del codificador es muy sencillo: Cada vez que
pulsamos un icono de un desvío enviamos al puerto
paralelo un byte con la siguiente configuración:
4(5) bits de dirección de la placa del decoder + 2
bits para escoger entre los 4 desvíos de la placa +
1 bit para determinar la posición deseada del desvío
+ 1 bit de activación. Esta operación la realizamos
3 veces, para simular la señal, activa baja, de
control: Una vez con el bit alto, otra con el bit
bajo, y finalmente de nuevo con el alto. Esto, incluyendo la
correspondiente temporización (programable) entre
los tres envíos. Los iconos se arreglan en pantalla
en una matriz (16x11), e incluyen gráficos para los
artículos mas comunes. En un fichero se almacena
información sobre el modo de comportamiento de cada
uno (posibles estados, último estado, clase de
activación, etc). No es lo mismo pulsar sobre un
espacio vacío (no hay acción alguna) que sobre un
desvío triple, (al tener mas de dos posible estados,
y al incluir dos motores, necesita dos juegos de
órdenes consecutivas) que sobre una luz o un tramo
de frenado, (el estado ON/OFF permanece) o una vía
de desenganche (hay un pulso, como en los desvíos).
Además hay una pantalla en la que configuramos la
disposición de los iconos y sus direcciones, otra de
utilidades, y botones específicos para definir
trayectos, aunque yo en mi programa prefiero
denominarlos "macros". También se incluye la
posibilidad de definir dependencias entre unos
iconos y otros: p.e. cuando activamos una señal
podemos también activar la zona de frenado y un
desvío, y quizás alguna otra orden. En la siguiente
imagen podemos ver la pantalla de configuración, que
aunque funciona, todavía está falta de
verificaciones internas y de la correspondiente
"lógica": Como pueden ver se ha escogido un tramo
recto, pero aún así se permite la asignación de
direcciones de placa y canal, que además están
configuradas fuera de rango (sólo hay 4 canales
posibles).
Los iconos están dibujados en Paint Shop Pro, y
definidos en las propiedades de los controles en
Visual Basic. Este lenguaje tiene la característica
de que los ficheros gráficos definidos como
propiedades se incluyen en el mismo código del
programa una vez compilado, por lo que no es
necesario tenerlos en la carpeta del mismo. Este es
práctico excepto si queremos tener la posibilidad de
escoger entre varias apariencias o "skins". En mi
programa todos los gráficos de cargan en tiempo de
ejecución, lo que permite editar o modificar los
iconos y otros elementos mas tarde sin tener que
volver a compilar el programa.
Todos los controles están pensados para su uso con
la pantalla táctil, con botones grandes, y sin menús
o otros elementos menos controlables. Hay que tener
en cuenta que el PC va a estar oculto, y todo el
control se debe de hacer en pantalla y sin salir a
Windows, mas difícil de manejar táctilmente.
Mas adelante, y ya que se dispone del PC, se pueden
añadir otras aplicaciones, como una base de datos
con las locomotoras, o incluso un "JukeBox" para
reproducir música ambiente.
(1)
Un "Trit", al
contrario de un "Bit", presenta tres estados: "0"
(conexión a masa), "1" (conexión a +), y "Flotante"
(sin conexión alguna).
4.
Estado del proyecto:
Actualmente me estoy centrando en el desarrollo del
software, que está bastante avanzado. Tengo pendiente la
confección de la placa de control, y, o bien la compra de
decoders, o la confección de los mismos. En esta página iré
dando cumplida información de los avances realizados.
Quiero agradecer la colaboración prestada por
nuestro compañero y programador Ignacio de la
Fuente, idelafuente@,
por su ayuda con el Visual Basic, que ya tenía algo
olvidado. En agradecimiento a su colaboración, le he
despertado el "gusanillo" del control por PC, y ya
anda trasteando con tarjetas de entrada/salida para
su maqueta "zetera". Esperamos los resultados de sus
investigaciones.
|
|
