Índice general Foros Digital, Electricidad e Informática Interface programable XpressNet

Interface programable XpressNet

Moderador: 241-2001



Desconectado
Mensajes: 630
Ubicación: Salamanca
Registrado: 12 Ene 2012 14:44
He encontrado el trocito de código que 'espía'. Deberías verlo en la libería:
XpressNet_mezucona_01.png
XpressNet_mezucona_01.png (126.24 KiB) Visto 1174 veces


De esta forma, el panel registra los mensajes encabezados por '0x52', que son los de petición a la central de cambio de accesorio, y les podrá hacer caso después si se refieren a un accesorio que esté en el panel.
Última edición por Norber el 29 Jul 2018 09:41, editado 1 vez en total
Saludos

[Multimaus + GenLi-S88 + +z21f. + RocRail (MacOsX)]
H0 Renfe, sin catenaria


Desconectado
Mensajes: 630
Ubicación: Salamanca
Registrado: 12 Ene 2012 14:44
Luego, en la función

void XpressNetClass::receive(void) {

}


es cuando se hace caso de ese tipo de mensajes, así:

XpressNet_mezucona_02.png
XpressNet_mezucona_02.png (63 KiB) Visto 1174 veces


y sería la función que ves en la línea 299

notifyTrnt(highByte(Adr), lowByte(Adr), Pos);


la que se encargaría de cambiar las luces en el panel si la dirección del accesorio cuyo cambio se ha solicitado a la central coincide con alguna de las del panel.
Ánimo!!
Saludos

[Multimaus + GenLi-S88 + +z21f. + RocRail (MacOsX)]
H0 Renfe, sin catenaria


Desconectado
Mensajes: 60
Registrado: 24 Abr 2016 20:03
Gracias Norber

Eso es lo que estoy haciendo,a partir de esa función manejo los LED

Así lo deje hace tiempo, espero liarme estos días con ello. Gracias por tus indicaciones

Saludos


Desconectado
Mensajes: 630
Ubicación: Salamanca
Registrado: 12 Ene 2012 14:44
Ya lo suponía Salus. Pero he preferido dejarlo bien clarito para que el próximo día, cuando le haga falta a alguien volver a trabajar sobre esto, se pueda acordar enseguida de cómo se hacía. Yo mismo sin ir más lejos, :D
Saludos

[Multimaus + GenLi-S88 + +z21f. + RocRail (MacOsX)]
H0 Renfe, sin catenaria


Desconectado
Mensajes: 60
Registrado: 24 Abr 2016 20:03
Entendido Norber, gracias por divulgar.

Saludos; Salus


Desconectado
Mensajes: 60
Registrado: 24 Abr 2016 20:03
Hola
Como comenté, he seguido dándole vueltas a esto, pensaba poder dedicar bastante tiempo a ello, pero, aunque en periodo vacacional, no ha sido así, mas o menos es que “uno planea y la familia dispone”, pero todo llegará.

Tengo una serie de sketchs que hacen cosas por separado, ahora esta cogido con hilos, pero mas o menos veo que la cosa discurrirá por estos caminos.

Esto es lo que quiero llegar a conseguir:

Usar expansores E/S PCF8574, para no depender de los puertos del Arduino, , cada uno aporta 8 puertos E/S, para leer teclas o manejar LEDs

A cada tecla se le asignará una acción, normalmente ejecutar una ruta, una ruta será una secuencia de órdenes DCC para controlar accesorios (desvíos, semáforos, etc.)
Las acciones a ejecutar pueden ser:
Ejecutar una ruta cambiando el estado de uno o más accesorios (p.e. manejar un accesorio con una tecla que cambia su estado alternativamente)
Ejecutar una ruta asignando un estado concreto de uno o más accesorios (p.e. manejar un accesorio con dos teclas o mover un conjunto de accesorios que formen una ruta entre dos puntos)
Ejecutar una ruta “reset” para inicializar todos los accesorios
Ejecutar varias rutas a la vez
Controlar el estado de la central on/off (paro emergencia)
Se definen accesorios y rutas “virtuales”, esto es, tomando una dirección DCC que esté libre en el trazado, se le puede ejecutar una ruta, al enviarle una orden desde el mando de la ventral, se ejecutará como si se pulsara una tecla en el TCO
Habrá una dirección DCC “virtual”, que al recibir una orden (on/off) desde el mando de la central, se habilite o deshabilite el teclado del TCO, para evitar conflictos si estamos controlando el trazado desde un PC, los LED’s siguen funcionando normalmente
Se podrá invertir el estado de un LED con respecto a su desvío para presentar en el TCO es la posición real.

¿A alguien se le ocurre alguna idea más? para intentar incorporarla al desarrollo.

Para el montaje seguiré una idea que usé hace tiempo, aquí os dejo unas fotos.

Iré publicando mis progresos.

Saludos; Salus
Adjuntos
IMG_0637.JPG
IMG_0638.JPG
IMG_0639.JPG
IMG_0655.JPG
Última edición por sls_h0e el 25 Ago 2018 16:41, editado 1 vez en total


Conectado
Mensajes: 150
Registrado: 28 Oct 2015 09:35
Hola sls_hoe.
Tengo una idea parecida a la tuya, que dependiendo de determinados estados, por ejemplo semáforos, o vías ocupadas, o rutas, se realice una series de actuaciones el Nano, o he mi caso el Mega.
Estoy trabajando con el proyecto de nuestro compañero francés sam95.fr, que utiliza un arduino mega, con lo que ganamos unas cuantas entradas y salidas.
Al tener el programa controladas las entradas de los pulsadores, podemos encadenar unas series de actuaciones, según nuestro propio interés.

Desgraciadamente no tengo comunicación entre el arduino y la central (ROCO).
El modulo de comunicaciones es el típico Max485, que utilizo para la z21f, el cual me funciona.

Nos puedes indicar que programa estas corriendo en el Nano?.

Estaré pendiente de tus avances, y si alguien ha instalado el programa de nuestro compañero francés y le ha funcionado que nos lo cuente.
Saludos.


Desconectado
Mensajes: 60
Registrado: 24 Abr 2016 20:03
Hola Pablo

La conexión del interface con el MAX485 es la misma que la usada en la Z21f, al margen de configurar los pin's de conexión.

El sketch que comentas lo miré pero no me metí a fondo con él, el que me ha funcionado es el adjunto, que está en la librería XpressNet como ejemplo, es el que voy a usar como base de partida.

Le cambie una parte, donde envía las ordenes de cambio de estado

Cambié esto: (estas son las líneas básicas, faltan los "if" para decidir una acción u otra, añadir el byte alto para otras posiciones, etc)
SwitchAdr = 18
XpressNet.setTrntPos(0, SwitchAdr, B1000); //switch 18 recto
o
XpressNet.setTrntPos(0, SwitchAdr, B0000); //switch 18 curva

Por esto: (hay que ejecutar la orden 2 veces para cada estado, cambiando el dato enviado)
SwitchAdr = 18
XpressNet.setTrntPos(0, SwitchAdr - 2, B1000); //switch RECTO
delay(50);
XpressNet.setTrntPos(0,SwitchAdr] - 2, B0000); //switch RECTO
o
XpressNet.setTrntPos(0, SwitchAdr - 2, B1001); //switch DESVIADO
delay(50);
XpressNet.setTrntPos(0, SwitchAdr - 2, B0001); //switch DESVIADO

------------------------------------------------
Lo que te planteas hacer, va mas allá de un TCO (creo yo), en la mayoría de los sketchs que he visto, la parametrización estriba en cambiar variables, valores en las matrices para definir las direcciones DCC usadas, los pin's de E/S para teclas y LED's, tambien las secuencia de ordenes de las rutas. No es necesario tocar el código para customizar el TCO, al fin y al cabo un TCO es como un mando pero enviando ordenes predefinidas al pulsar una tecla.
Lo que propones en interesante, añadir una lógica de circulación, entiendo que para esto habría que "programar" añadiendo código al sketch, con las condiciones comparando estados, etc. según las condiciones de circulación para ese punto de la maqueta, lo tendré en cuenta, pero no se podría dar como terminado el sketch pues esa parte del programa es específica de cada trazado, cada persona se lo tendría que adaptar ya que no es posible definir algo genérico.

Saludos
Adjuntos
Xpressnet_Lib_Weiche.7z
(1.5 KiB) 31 veces


Conectado
Mensajes: 150
Registrado: 28 Oct 2015 09:35
Gracias sls_hoe, haber si en estos días lo puedo instalar y veo como meterlo mano.

Muchas gracias.


Desconectado
Mensajes: 630
Ubicación: Salamanca
Registrado: 12 Ene 2012 14:44
Magnífico montaje el mini panel de Ariza, ¡bravo! Qué bien diseñado y ejecutado. Seguro que es una maravilla verlo funcionar y utilizarlo.
Está resuelto con gran elegancia y pulcritud. Muy bueno. Me lo apunto, para el futuro. Hay detalles de ejecución realmente interesantes. Gracias por compartirlo.

Sobre el contenido del mensaje, hay cosillas que no me 'encajan'. Si estamos en el hilo del XpressNet, y estás trasteando con este bus, ¿por qué dices que
sls_h0e escribió:
...una ruta será una secuencia de órdenes DCC para controlar accesorios (desvíos, semáforos, etc.)

¿No será una secuencia de comandos XpressNet dirigidos a la central, para que ésta haga lo que tenga que hacer en DCC?

Tampoco entiendo bien cuando luego hablas de
sls_h0e escribió:
...una dirección DCC “virtual”, que al recibir una orden (on/off) desde el mando de la central, se habilite o deshabilite el teclado del TCO, para evitar conflictos si estamos controlando el trazado desde un PC, los LED’s siguen funcionando normalmente

Si el TCO es un aparato XpressNet, puede hacerse perfectamente interactivo y respetuoso con los demás aparatos del bus, y mediante la técnica 'espía' que documenté hace algunos días, no importaría que el PC hiciera cambios en la maqueta, pues podrían verse reflejados instantáneamente en el TCO. No veo la necesidad de desactivarlo, y me pasa además como antes, tampoco entiendo bien qué necesidad hay de involucrar las direcciones DCC en esto.

Por último, y a propósito de este asunto:
sls_h0e escribió:
Usar expansores E/S PCF8574, para no depender de los puertos del Arduino...

Esos expansores necesitan comunicación I2C para funcionar, que no sé hasta qué punto se puede hacer compatible con mantener al Arduino 'vigilante' y 'en sintonía' en el bus XpressNet. Yo fracasé hace algún tiempo en este asunto, aunque no debe ser imposible, pero sí difícil. Intuyo más sencillo manejar simples registros de desplazamiento tipo 74HC165 y 74HC595 por ejemplo. Pero no lo he probado.
Saludos

[Multimaus + GenLi-S88 + +z21f. + RocRail (MacOsX)]
H0 Renfe, sin catenaria


Desconectado
Mensajes: 60
Registrado: 24 Abr 2016 20:03
Hola Norber

Gracias por tus comentarios, te respondo siguiendo el orden en el texto

- En efecto es como tu dices, los comandos viajan por el bus XpressNet a la central y esta se encarga del resto

- La gestión de dirección virtuales es un "apaño" a usar si se necesita, por ejemplo para mover varios accesorios desde un mando que no memoriza rutas (ej.Multimaus), con eso se amplían las posibilidades de juego

- En el control desde un PC, cuando el programa de gestión lanza una ruta, cambiando es estado de los accesorios según convenga y poniendo en marcha los trenes en una circulación automática, si se cambia un desvío desde el mando de la central o el TCO, el programa puede no enterarse del cambio, por precaución es mejor asegurar que no se toca nada de lo que el PC esté gestionando en ese momento, en este caso el TCO se sigue actualizando de forma interactiva según los cambios desde otro mando o desde el PC, solo se inhabilita la entrada por el teclado del TCO

- Si se usan registros de desplazamiento o los pin's de Arduino, es necesario leerlos continuamente para detectar una tecla pulsada, dedicando tiempo de proceso que se incrementa cuantas mas E/S tengamos que controlar.
Los PCF se gestionan usando el bus I2C, pero el Arduino no vigila nada nunca, se usa la señal de interrupción que solo se activa cuando hay una tecla pulsada en alguno de los puertos E/S y se le envía al Arduino, solo entonces el Arduino busca el puerto donde se ha pulsado una tecla, lee los puertos E/S de 8 en 8 no de 1 en 1, todo el resto del tiempo el Arduino está "escuchando" el bus. En modo pruebas con 8 PCF's (64 puertos E/S) no hay retardo

Lo dicho, muchas gracias pos los comentarios

Saludos; Salus

Anterior

Volver a Digital, Electricidad e Informática

Síguenos en Facebook Síguenos en Youtube Síguenos en Instagram Feed - Nuevos Temas
©2017   -   Información Legal