TODOPIC

Mecatrónica => DMX512 - Diseños y Proyectos => Mensaje iniciado por: Khronos_Nieto en 16 de Junio de 2009, 08:32:25

Título: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Khronos_Nieto en 16 de Junio de 2009, 08:32:25
Modificación 24 Junio:  Fichero adjunto actualizado, con nuevo firmware que permite compatibilidad con el programa FreeStyler 512.

Buenas a todos compañeros.

Hace un tiempo que compré un par de focos RGB PAR32 que además de tener un modo autónomo, se pueden controlar por DMX.
Estos focos tienen 4 canales, uno para velocidad de parpadeo (Strobo) y los otros tres para los 3 colores r, g y b.

Siempre he querido poder controlarlos con el PC de alguna forma, ya que disponían de DMX, por lo que me construí una interfaz de puerto paralelo que hay en internet, con un pic16f84. Esta interfaz de nombre "manolator" desempeña su papel a la perfección, además es muy simple de construir y sale andando a la primera. La página en la que se puede encontrar es manolator (http://www.freedmx.com/)  ,he de agradecer a su autor el que ponga a disposición de todos sus diseños. Asi mismo, en la página del compañero nocturno Micropic (http://www.micropic.es) se puede encontrar mucha información acerca de esto.

El inconveniente se me planteó porque cada vez que quería controlar los focos de mi "mini sala de fiestas", tenía que bajarme al sótano mi PC fijo, monitor.. y todo lo demás. Dispongo de un ordenador portatil, pero esta interfaz se diseñó para puerto paralelo, y encontrar un puerto paralelo en un portatil es poco menos que imposible hoy dia.

Investigando en internet ví que existen varios diseños comerciales de interfaz USB-DMX, bastante caras por cierto, por lo que me planteé hacerla yo mismo.

Diseño de la interfaz:

El microcontrolador que elegí es un pic18f2550, los motivos son porque posee USB, USART, no es excesivamente grande y esta disponible en formato DIP.

El principio de funcionamiento es sencillo, recibe los datos por USB, los interpreta, y los envía por la USART en formato DMX. La salida serie del PIC debe ir conectada a un transductor que convierta los niveles de tensión del PIC a los del estandar RS485, para ello he utilizado un MAX488, valdría también el MAX485, aunque tambien hay otros muchos válidos de otros fabricantes.

Una de las principales consideraciones que tuve en cuenta es que la interfaz debía ser compatible con alguna otra ya existente. El motivo es que si se desarrolla un protocolo de comunicación particular, ningún programa software de control DMX va a reconocer a nuestra interfaz. Habría que investigar y desarrollar una librería específica para nuestra interfaz, y que a su vez se pudiera precargar en el programa software que vayamos a utilizar. Pero esto queda fuera de mis espectativas, por lo que me cogí mi programa de control DMX favorito: DMXControl (http://www.dmxcontrol.de/joomla/?lang=en) (que además es gratuito) e investigé cuales eran las interfaces USB soportadas.

El objetivo era "espiar" lo que el programa DMXControl enviaba al puerto USB, así como las posibles respuestas esperadas.
De entre todas las interfaces, elegí la DMX4ALL. Las demás estan preparadas para una comunicación USB en modo HID o Bulk Transfer con sus respectivas interfaces físicas, y resulta más dificil interpretar los datos que se envían, y aún más sin disponer de una interfaz física real.

Sin embargo la interfaz DMX4ALL se comunica con DMXControl basandose en una emulación de puerto serie. De hecho en el menú de configuración de esta interfaz en DMXControl podemos ver que te permite seleccionar el puerto serie que vas a utilizar, así como el baudrate.

El programa DMXControl, con la interfaz DMX4ALL seleccionada, envía una trama de 6 bytes cada vez que se varía el valor de un canal. En esta trama se indica el universo (grupo de 512 canales), el canal, y el nuevo valor. Estas tramas se envían continuamente, cada vez que varía el valor de cualquier canal. Además, por lo que parece, el programa no demanda ninguna respuesta de reconocimiento ni nada por parte de la interfaz física.

Toda la comunicación se realiza desde el PC hacia la interfaz, esta última nunca tiene que enviar nada hacia el PC, salvo en un caso.

Este caso es cuando se selecciona dicha interfaz (DMX4ALL) en el programa, y cada vez que lo arrancamos.
DMXControl envía el comando de 2 bytes: "0x63 0x3F", que es una especie de solicitud de reconocimiento, y se queda esperando durante 2 segundos aprox. una respuesta por parte de la interfaz. La respuesta de reconocimiento es un byte, "0x47". Si esta respuesta no se produce, el software da un error, corta las comunicaciones y no permite seleccionar dicha interfaz.

Por tanto nuestro pic debe estar pendiente y reconocer cuando se envía dicha secuencia de ACK y contestar inmediatamente. No obstante repito, esto solo se produce al inicio del programa, una vez hecho, queda configurado y permite el envío de las tramas en el formato anteriormente descrito.

Una trama de 6 bytes en formato DMX4ALL correcta tiene la siguiente forma:

Byte: 0    1   2    3   4    5
      " FF  01  00  01  AA  00 "

Donde:
- byte 0 es el byte de inicio de trama, siempre es 0xFF.
- byte 1 es el LSB (byte menos significativo) del canal escogido, de 0x00 a 0xFF para porciones de 256 canales.
- byte 2 es el MSB (byte mas significativi) del canal escogido, 0x00 o 0x01, para cubrir los 512 canales.
- byte 3 es el universo (puede haber varios universos de 512 canales cada uno), por defecto 0x01.
- byte 4 es el valor a asignar al canal, de 0x00 a 0xFF.
- byte 5 es el byte de finalización de trama, siempre es 0x00.

En el ejemplo anterior se envia el valor "AA" (170) al canal 1.

Desarrollo de la interfaz:

El desarrollo de la interfaz ha sido posible gracias a los distintos aportes de compañeros de este foro.

La parte de comunicación USB y emulación de un puerto serie virtual está basada en las librerías de ejemplo de CCS y en las explicaciones y desarrollos que ofrece en su página web el compañero RedPic. En la página de RedPic, http://picmania.garcia-cuervo.net (http://picmania.garcia-cuervo.net), se explica con todo detalle como llevar a cabo una comunicación USB CDC con el pic 18F4550, que esta parte es completamente equivalente al 18F2550 utilizado aqui.

La parte de la implementación del protocolo DMX en la USART de un pic, la he podido entender y añadir al proyecto gracias al diseño del compañero nocturno y su Receptor DMX (http://www.micropic.es/index.php?option=com_content&task=view&id=62&Itemid=1).

Adjunto al final del mensaje el esquema de la interfaz, el código fuente, código hex compilado y la simulación en proteus.

Espero les sea de utilidad, y si realizan cualquier mejora o ampliación por favor compartirla.

Un saludo   :-/ :-/ :-/ :-/.
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Nocturno en 16 de Junio de 2009, 08:41:55
Magnífico, querido Armando, plas plas plas.
Muchas gracias por compartirlo.
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: stk500 en 16 de Junio de 2009, 11:53:08
En Horabuenas!!
Muy buen trabajo!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: josmaroal en 22 de Junio de 2009, 06:03:25
Muy buena amigo Khronos_Nieto  y gracias por compartirlo  :-/ :-/
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Khronos_Nieto en 24 de Junio de 2009, 14:58:44
Muchas gracias por los comentarios compañeros, se agradecen sinceraménte.

He estado testeando el interfaz durante varios días y he encontrado dos problemas que hacen que no funcione correctamente.

Problema 1:

El primer problema es que no funciona con el programa de DMX, FreeStyler 512. Aunque dicho programa te permite seleccionarla interfaz DMX4ALL, la mi circuito no envía tramas DMX. He estado "espiando" las tramas que envíaeste programa y resulta que son completamente distintas que las que envía DMXControl. ¿Como es posible?

Estuve navegando y entré en la página oficial de DMX4ALL: http://www.dmx4all.de/ (http://www.dmx4all.de/), que resulta ser puramente una tienda en internet. Pues bien, para mi sorpresa ví que está disponible la documentación que explica el protocolo de comunicación y los comandos aceptados por DMX4ALL. ¡Bien! ¡¡Y yo aqui montando puentes entre puertos COM para espiar lo que envían los programas, cuando resulta que está todo en la página oficial!!

La documentación se puede encontrar aqui http://www.dmx4all.de/media/manuals_en/DMX412_Mini-USB-DMX_en.pdf (http://www.dmx4all.de/media/manuals_en/DMX412_Mini-USB-DMX_en.pdf)

Tras revisarla y hacer unas pequeñas pruebas, concluí que el formato de datos que usa FreeStyler 512 es el mismo quese explica en la página oficial DMX4ALL, por tanto es el auténtico, y el formato que usa DMXControl es otro distinto, aunque en el programa se llame DMX4ALL.

Aunque se explica en la documentación, a modo de resumen la trama "original" DMX4ALL (la que usa FreeStyler 512), tiene la siguiente forma:

//Byte: 0   1   2   3   4   5   6   7
//    " 43  31  34  30  4C  30  31  31 "
//
// Donde:
// - El byte 0 es el byte de inicio de trama, siempre es 0x43.
// - Los bytes 1, 2 y 3 son el canal seleccionado, en formato ASCII, de mayor a menor peso.
// - El byte 4 es un separador y siempre es 0x4C.
// - Los bytes 5, 6 y 7 son el valor a asignar, en formato ASCII, de mayor a menor peso.
//
// En el ejemplo anterior se envia el valor "11" (30-31-31), al canal 140 (31-34-30).

Espiando los envíos de FreeStyler se podemos comprobar que las tramas son así.

He modificado el programa del PIC y ahora soporta también este protocolo. Las tramas de DMXControl y FreeStyler son completamente distintas por lo que uso dos rutinas de decodificación distintas. ¿como distinguir en que programa estamos para usar una u otra? Pues sencillo, al arranque de cada programa se envía una trama de 2 bytes a modo de reconocimiento. Estas tramas son distintas, para el caso de DMXControl es: 0x63 - 0x3F y para FreeStyler: 0x53 - 0x32.

Según la que reciba, conmuto a un modo u otro.

Es cierto que en la documentación del protocolo se explican distintos comandos ante los cuales la interfaz tiene la obligación de responder con un ACK (0x47), pero en mis pruebas con FreeStyler ví que él, no exige nunca una respuesta, de hecho ni siquiera al establecer comunicacion por primera vez (como ocurre con DMXControl). FreeStyler es menos exigente, en cuanto arranca (y siempre que exista el puerto COM asignado) comienza a enviar tramas ante los cambios de los potenciómetros virtuales, no exige ninguna respuesta, por lo que le da igual lo que haya conectado al otro lado de la línea, el manda tramas sin parar.

Por este motivo yo solo he implementado la parte de decodificación de la trama, y funciona, aunque queda "pendiente de hacer" proximamente.

Modifico el primer post, adjuntando el nuevo código modificado. Comprueben en la simulación que ya funciona con FreeStyler.


Problema 2:

El segundo problema es mas preocupante, durante las pruebas a la interfaz hechas con DMXControl (me sigue gustando más que FreeStyler), he comprobado que funciona durante 2 o 3 minutos correctamente y luego se cuelga. Los focos se quedan en el último estado que envié, y el software se queda medio colgado, no responde a los comandos y tengo que cerrarlo. Entonces, sin desconectar la interfaz, vuelvo a arrancar DMXControl, pero ahora me salta con un mensaje de "Puerto COM no disponible". Sin embargo me voy al administrador de dispositivos y puedo ver que el puerto COM virtual sigue presente, y windows no indica que exista ningún problema de hardware. Vuelvo a cerrar DMXControl y abro el programa de comunicación serie Siow (el que trae CCS), y tampoco me deja abrir dicho puerto serie.

Todo esto me ocurre a los 2 o 3 minutos de funcionamiento correcto de DMXControl. Otra cosa que he intentado cuando dá este fallo es desconectar y conectar la interfaz sin cerrar DMXControl, pero tampoco se soluciona. La única forma es apagando el programa, desconectar y conectar la interfaz, y volviendo a arrancar el programa, entonces todo va perfecto durante otros 2 o 3 minutos.

Creo que el problema reside en que en algún momento se pierde la comunicación serie, lo suficiente como para que se cuelgue DMXControl. En el código del PIC he cambiado la forma de control del USB de la siguiente forma,

Este es el código original:

Código: [Seleccionar]
usb_init();                            // Inicializo USB
usb_cdc_init();                        // Inicializo como dispositivo serie virtual CDC

while(!usb_cdc_connected()) {}         // Espero hasta la conexión USB

for(;;){

   if (usb_enumerated()) {             // Espero que el dispositivo sea reconocido como emulador serie CDC
      if (usb_cdc_kbhit()){            // Compruebo si hay recepción USB
       -------
       -------
       -------
      }
    }
}

Y este el modificado:

Código: [Seleccionar]
usb_init();                            // Inicializo USB
usb_cdc_init();                        // Inicializo como dispositivo serie virtual CDC

while(!usb_cdc_connected()) {}         // Espero hasta la conexión USB

for(;;){

      if (usb_cdc_kbhit()){            // Compruebo si hay recepción USB

      }
}

La diferencia es que ahora no pregunto contínuamente si el dispositivo está enumerado, asumo que sí. Con esta modificación he conseguido que el interfaz no se cuelgue cada 2 o 3 minutos. Conecto todo, arranco el programa y lo pongo a funcionar, ahora funciona correctamente todo el tiempo.

Pero me ocurre una cosa aún peor, estando funcionando todo correctamente, me levanto de la silla y me dirigo a la habitación de al lado y le doy al interruptor de la luz para encender los tubos fluorescentes ¡¡ y el muy cabr.... se cuelga!!

¡Tengo un problema serio de ruido electromagnético! Pero no me explico como puede provocar estos efectos. Creo que no se trata de Windows XP, ni de DMXControl, ni problema de drivers ni nada, creo que el problema lo causa el PIC, que se resetea. De hecho le he provocado reseteos voluntarios y ocurre exactamente lo mismo. Tengo montado el circuito exactamente como se muestra en el esquema que adjunté, pero he de aclarar que utilizo un cable DMX de 10 metros hasta el primer foco, y otro de 15 metros desde éste hasta el segundo. Imagino que esto constituye una antena gigante para captar ruido eléctrico, y entendería que los focos no respondieran bién a los comandos, pero ¿colgarse el PIC?.

Según tengo entendido la unica forma de resetear el PIC es cuando cae la tensión de alimentación, ¿entonces cae la alimentación del puerto USB? ¿Puede ser por un exceso de consumo por parte de mi circuito, justo en el momento de encender los tubos fluorescentes? En ese caso el puerto USB cortaría la alimentación para autoprotegerse, y podría explicar el problema. Pero la verdad es que no quisiera alimentar externamente mi circuito, y más sabiendo que existen interfaces USB-DMX comerciales que se alimentan del USB y funcionan perfectamente.

He tomado varias medidas:

- conectar el chasis del conector USB al chasis del conector DMX
- soldar un cable entre masa y el cuerpo del cristal de 12 MHz
- colocar ferritas en el cable USB y justo a la salida del cable DMX

Pero sigue ocurriendo lo mismo, cuando enciendo las luces fluorescentes de la habitación de al lado, falla el circuito. Me queda por aislar el PIC, de la parte DMX, es decir, del MAX488. Según he visto en algunos esquemas utilizan optoacopladores en la línea de datos entre el PIC y el MAX488. Incluso para un mejor aislamiento llegan a utilizar convertidores DC/DC, para la alimentación del MAX488. No lo he probado todavía por no tener optoacopladores tan rápidos (250 Kbaudios).

Òjala esto solventase mi problema, aunque me parece una solución demasiado drástica, y mas bién orientada a la protección de los puertos USB de nuestro querido PC, que a evitar cuelgues del microcontrolador.

Con todo esto quizás no vaya por el camino correcto para encontrar la solución, a lo mejor solo se trata de un problema en el firmware del PIC.

Ya finalizo con 2 preguntas, disculpen la extensión del post, espero que no se les haga aburrido.

La primera pregunta es respecto al ruido, ¿como puedo protejer correctamente el circuito? Las medidas que he adoptado han sido un poco por intuición propia, y sin criterio alguno. Me gustaría conocer el consejo de algún compañero experto.

Y la segunda pregunta va dirigida a los compañeros del foro curtidos en USB: asumiendo que el PIC se va a resetear "de vez en cuando", ¿habría alguna forma de que el PIC retomara las comunicaciones como si no pasara nada  :mrgreen:?, es decir, que no hubiera que reestablecer la comunicación USB, inicializar, enviar descriptores... etc, y ¿como le sentaría esto al PC, suponiendo que es un corte de pocos milisegundos?

Muchas gracias compañeros por la paciencia para leer esto, gracias de antemano y un saludo  :-/ :-/ :-/ :-/ :-/!!!  
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Nocturno en 24 de Junio de 2009, 15:25:47
Yo te recomiendo lo de los optoacopladores. Creo que todas las instalaciones DMX que se precien lo tienen instalados.

Respecto al USB, me temo que no hay mucha solución. Sólo prueba una cosa si es que puedes: en el terminal de Windows puedes "Desconectar" del puerto COM, ¿puedes hacer lo mismo con tu programa?. Una vez que el PIC está reseteado "Desconectar" y "Conectar" en el PC suele funcionar.
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: stk500 en 24 de Junio de 2009, 21:13:05
pues bien , a mo con el DMXControl tambien se me colgaba, pero era problema de la configuracion de mi interface y lo configure, puede ser como tu dice que se calgue demasiado la USB de tu PC, eso tambien me pasaba cuando tenia varia cosas colga en la USB, por la otro lado, lo del Cable no es tan critico, siempre y cuando tu cable sea mallado, pero ojo!!!! se recomiendo cable de 120 'Ohm , aunque yo con una cable de microfono de 10 metro me iba sin problema, otras cosas puede suceder y es que tus Lamparas RGB coga parasito,  eso tambien me paso con los LED RGB LITE y los vendimos yo me quede con uno de ellos y todavia no encuentro el problema que se enciende por corto tiempo sin enviarle Señales DMX aunque por un tiempo vuelve a estado normal. yo te aconsejo que te haga un DMX tester y asi observa las señales que salen del DMX  USB o yo probaria con otros equipo, ya que no me confio en algunas cosas Made in china  :D
Saludos
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Khronos_Nieto en 25 de Junio de 2009, 09:15:26
Efectivamente Manolo, probé lo que me comentas de "deshabilitar" y despues "habilitar" el puerto COM y de esa forma consigo restaurar el puerto serie correctamente sin necesidad de desconectar la interfaz del puerto USB. Lo único es que el programa DMXControl si que me veo forzado a reiniciarlo, o bien, irme al menú de selección de interfaz y cambiar el puerto COM por otro cualquiera para luego volver al correcto. Esto estoy casi seguro que ocurre porque a ojos del programa, éste asume que el puerto COM continúa abierto, y no vuelve a enviar el comando de abrir puerto hasta que se reinicia de alguna forma.

Lo de los optoacopladores llevas toda la razón, y creo que va a ser la solución a mis problemas, y te comento porqué.

Ayer al leer tu comentario hice la prueba definitiva, conecté mi interfaz al PC, conecté el cable DMX a la interfaz y arranqué el DMXControl. En el programa tengo hecha una secuencia sencilla que cambia de color los focos, de rojo a verde, a azul..... y así cíclicamente. Cuando se activa, puedo ver como se mueven unos potenciómetros virtuales en el programa de forma suave y progresiva, a la vez que cambia el color de los focos. Todo va perfecto durante 10, 15 minutos... indefinidamente, hasta que enciendo los tubos fluorescentes de la habitación de al lado. Los focos se paran, es decir, se quedan con el último color asignado, y cuando miro el programa, los potenciómetros van a golpes, tardan muchísimo en moverse. Es una indicación clara de que el programa se ha colgado y de que el PIC se ha reseteado.

Pues bién, aqui viene la prueba. Desconecto todo y apago el programa. Ahora conecto la interfaz al PC, y arranco el programa, dejando sin conectar el cable DMX a la interfaz. Y ahora activo la secuecia cíclica. Al no estar conectado el cable DMX, evidentemente los focos no cambian de color, la señal que envía la interfaz va al "aire", entoces ¿como sé que todo está funcionando correctamente? pues muy sencillo, porque veo moverse los potenciómetros de forma suave y progresiva. Ahora enciendo y apago los fluorescentes de la habitación, enciendo un ventilador, una batidora..... :mrgreen: :mrgreen: :mrgreen: :mrgreen: todo lo que produzca ruido, y sigo viendo moverse los potenciómetros de forma suave y progresiva !!!

La interfaz sigue funcionando perfectamente   :-/ :-/!

A continuación sin tocar nada, conecto el cable DMX a la interfaz, ahora los focos si cambian de color, con lo que se comprueba que es cierto. Ahora desconecto el cable DMX del extremo de los focos, es decir, la interfáz queda conectada a un cable de 20 metros, pero que en su otro extremo va al aire. Repito el encendido y apagado de fluorescentes, y tras varias veces, miro al monitor y los potenciómetros van a golpes y ralentizados, el pic se ha reseteado y el programa colgado.

Conclusiones:

- El circuito de la interfaz, con el cable USB, y el propio PC, en su conjunto son aparentemente inmunes al ruido electromagnético. Tanto para el ruido que viene por la tensión de red 220V como el ruido de radioeléctrico.

- El origen de todo el ruido y problemas está en el cable DMX y en los focos. El cable capta el ruido radioeléctrico, y los focos (que no deben ser muy buenos) no filtran el ruido que les viene por la red de 220V, y lo sueltan al bus DMX, llegándole a mi querido PIC.

Tal y como indicas Manolo, la mejor solución es optoacoplar las lineas de datos, y a ser posible aislar también la alimentación del MAX488 con un convertidor DC/DC. En definitiva aislar al PIC del mundo exterior en todas las líneas.

Rafael, gracias por tu comentario, he seguido varios hilos tuyos en el foro respecto a DMX y se que dominas este tema. El cable que yo uso también es de micrófono, con conectores XLR de 3 patillas macho y hembra. Lo compro en mi tienda de electrónica habitual en Almería y lo pido como cable DMX, pero en la pegatina pone cable de micrófono, la verdad no sé cual es la diferencia. Acabo de abrirlo para confirmarte que es mallado, y NO lleva malla   :shock: :shock: !!

¡ Tengo la sala de fiestas en un sótano en la que todo es ruido eléctrico, y con cables DMX de 20metros y 15 metros sin malla ! Buen comienzo  :P :P....

Respecto de los focos, yo también sospecho de la calidad de los míos Rafael. Son dos par 36 RGB fabricados por Velleman para HQ Power, modelo exacto VDPLPS36BP, concretamente estos http://www.velleman.be/downloads/4/vdplps36bpgbnlfresd.pdf (http://www.velleman.be/downloads/4/vdplps36bpgbnlfresd.pdf).

Por las pruebas que estoy haciendo, cada vez confirmo más la teoría de que casi la totalidad de ruido que producen los fluorescentes, va a parar a la red de 220V. Por supuesto también hay parte que se "radia" en forma de ruido radioeléctrico, pero para que esto afecte, el circuito o el cable deben estar muy cerca del tubo fluorescente. Yo no entiendo mucho del mundo de la luminotecnia, pero pensaba que no eran fabricantes malo. Sin embargo he comprobado que no filtran nada de ruido, y lo cuelan todo al bus DMX.

Para colmo, hay ocasiones en que dejando los focos en un color fijo mediante comando DMX, desconecto el cable DMX del foco, y encendiendo y apagando los tubos fluorescentes, los focos se apagan, o cambian de color !! Es decir, sin cable de de datos conectado, interpretan el ruido que viene por la alimentación (red 220V) como un comando. Esto ya es increible. Menos mal que esto solo ocurre cuando el conector del foco se deja al aire, estando conectado a la interfaz DMX, obedece a esta siempre (antes de que se cuelgue por otros motivos... :mrgreen: :mrgreen:.)

Voy a continuar afinando la interfaz, y por supuesto compartiendo los avances.

Y animo al compañero escéptico y al incrédulo que esté dudando si montar o no esta interfaz USB-DMX, a que la pruebe, que pese a todo lo dicho SI que funciona. Eso si, usar cable apantallado y focos de buena calidad!!. Al que esté en las mismas condiciones que yo, en un ambiente con ruido por todos lados, cable malo y focos regulares, que idée una mejora y la comparta, o bien espere, que en breve modificaré el diseño del circuito para protejerlo contra todo tipo de ruido habido y por haber...

Muchas gracias por vuestros consejos compañeros, y un saludo !!!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: stk500 en 25 de Junio de 2009, 11:00:20
Pues cable de microfono que no son apantallado , no te lo aconsejo, se puede usar una cable de microfo apantallado siempre y cuanto no pase de 10 metro, pues es para eso, para evitar interferencia, te recomiendo que use cable de Digital 120 Ohm
 lee aqui     

What cable can be used?
The original and 1990 versions of the standard specify 120 ohm or 100 ohm 1– or 2–twisted pair shielded cable suitable for use with EIA–485 (120 ohm) and EIA–422 (100 ohm) electronics. Since DMX512 electronics are based on EIA–485, 120 ohm cable normally provides optimal performance. However, many installations are installed with 100 ohm (EIA–422) cable and perform flawlessly. The quality of the installation is probably more important than the distinction between 100 ohm and 120 ohm cable.

A common question is "can we use a good microphone cable?" The answer here is no. While there is some tolerance allowing for 100 ohm to 120 ohm cable, simply put, microphone cable is not at all suitable because of its high capacitance and incorrect characteristic impedance. It might work in some instances, but it is not appropriate for the electronics involved and it will fail at the most inopportune times.

EIA–485 (and thus DMX512) requires cabling between devices to be done in a point-to-point Daisy-Chain fashion. A star layout is not permitted (no ‘Y’s, stubs, or branches). If the physical requirements of a system do not allow for a daisy-chain installation, then the use of DMX512 splitter (sometimes referred to as repeaters or amplifiers) is required.

http://www.usitt.org/standards/DMX512_FAQ.html


Bien si usa opto acopladores es muchos mejor, tambien te aconsejo de usar Terminator si va a usar varios Aparatos conectados en serie, 
usando un conector Cannon XRL 3 pines , se pone una resistencia de 120 Ohm entre los pines 2 y 3, este Terminator lo pone en el ultimo de los aparatos que conecte. eso se hace para equilibrar las linea y evitar parasitos, como e´n tu casos, por otro lado te recomiendo no use cable USB largo y meno esos baratos que n o son apantallados sin filtro, te aconsejo asi o ambos lados con filtros http://www.masoportunidades.com.ar/aviso/3863638-cable-usb-con-filtro
Tambien esto lo digo para aquellos que usan RS485
Saludos
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Khronos_Nieto en 25 de Junio de 2009, 12:19:54
Gracias por la rápida respuesta Rafael, efectivamente la información que aportas de la normativa para cables DMX512 es clara y tajante en este aspecto, "no se puede usar cable de micrófono". Quizás en el caso que tu indicas, de un cable de 10 metros y que sea apantallado, puede ser viable. Pero en mi caso incumplo todas las normas, mis cables son de 20 metros y de 15 metros, y NINGUNO esta apantallado, por tanto no es válido.

Definitivamente voy a comprar cable nuevo, pero entre tanto voy a provar una cosa. He visto que mi cable tiene solo 3 hilos, dos para datos y el tercero masa, pero resulta que ese tercer cable une la masa con el propio chasis del conector, es decir, con la tierra. He leido en algún sitio que eso no es bueno, porque se crean bucles de tierra, y quizá sea por ahí por donde le entra todo el ruido. La prueba simplemente va a ser dejar el chasis sin conectar, es decir, que el cable no tendrá línea de tierra. No obstante es solo una prueba, el cable hay que cambiarlo.

Un saludo  :-/ :-/ :-/ !!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: stk500 en 25 de Junio de 2009, 14:31:10
pues ese cable de micro no es nada profesional, ya que en audio tambien hay que Aislar la tierra(Audio profesional no Hi-Fi) si le quita la tierra no pasa nada, claro es que cada aparatos tenga su toma tierra cada uno. exacto que son 3 hilo aunque ya se esta usando 5 pines
1=Gnd
2=Data -
3= Data+
4= Data- reserva para usar Full duple comunicacion
5=Data+ Reserva para usar full dupple comunicacion
 Acuerdaste de usar un terminator como te explique arriba

Suerte amigo

Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: dcmdcm en 31 de Julio de 2009, 17:44:10
hola, muy interesante el proyecto, pero por que solo ocupas 16 canales?
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Khronos_Nieto en 03 de Agosto de 2009, 17:53:59
Buenas compañero,

En realidad envío 100 canales pero sólo los 16 primeros contienen datos válidos, es decir, los datos recibidos desde el software a través de USB. El resto de 84 canales se fuerzan a cero.

El motivo de no enviar todos los canales es para poder hacer un refresco más rápido en el envío de datos. Investigando acerca del protocolo DMX512 ví que es flexible en cuanto al número de canales a enviar por lo que no es obligatorio enviar los 512. Lo que si es obligatorio es que la señal de BREAK, START y los bits individuales tengan su temporización exacta. Además entre inicio e inicio de tramas deben transcurrir como mínimo 1,152 ms. Con esto vemos que se permite un cierto márgen de variación en la tasa de refresco , y siempre cumpliendo con lo que dice el protocolo.

Teniendo en cuenta lo anterior la máxima tasa de refresco se conseguiría enviando tan solo 24 canales :
- 1 canal = 44 us
- Break = 88 us
- Marca = 8 us
Tiempo para enviar 24 canales = (24channel x 44us) + Break + Marca = 1,056 ms + 88 us + 8 us = 1,152 ms

Si se envía una trama detrás de otra sin dejar tiempo entre ellas se conseguiría refrescar un canal cada 1,152 ms, aproximadamente 868 veces por segundo.
Enviando los 512 canales tendríamos una tasa de refresco de tan solo 44 veces por segundo. Pero ójo!, nunca podemos enviar menos de 24 canales porque en ese caso no estaríamos respetando el tiempo mínimo entre inicio e inicio de tramas y los focos podrían no responder correctamente.

En mi caso particular sólo tengo 4 focos de 3 canales cada uno, que suman un total de 12 canales DMX. Por precaución envío 100 canales en vez de 24, que aun así mejoran el refresco notablemente (222 veces por segundo) respecto de enviar los 512 canales.

Además solo se procesan los 16 primeros canales, ya que no necesito más, y el resto hasta 100 lo relleno con valor fijo a cero.

Estas limitaciones hechas en el programa del PIC para "ganar velocidad" se pueden eliminar fácilmente modificando un par de parámetros en el código fuente en C que adjunto en el primer post.

Creo que no tiene mayor dificultad, pero si algún compañero lo necesita puedo modificarlo por él y colgarlo del foro.

Espero haber resuelto tu duda dcmdcm.

Un saludo !!!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: hume_86 en 15 de Agosto de 2009, 02:44:28
Hola Khronos_Nieto, soy nuevo en el foro y la verdad me interesa mucho tu proyecto, tambien soy novato en los PICs y estoy intentando armar tu interface para mis luces, pero a la hora de compilar el programa, el compilador me dice que faltan algunos archivos como <pic18_usb.h> <PicUSB.h>  <usb.c> etc, queria saber donde puedo conseguirlos o si tu puedes subirlos.  Ahhh yo consegui un 18f4550  :? pero creo que puede andarme, solo dejo los demas puertos sin uso. Con respecto a los canales, comentaste que solo pueden usarse 16 canales? gracias y saludos
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: jmorfeo en 28 de Septiembre de 2009, 00:03:35
Muy buen trabajo Kronos, me gustaría seguir avanzando con tu desarrollo. Lo estuve probando con Proteus 7.4 SP3 y DmxControl 2.10 build 4 y funciona "correctamente" pero por ahí se tilda uno de los dos. Anda bien con el Hex que pasas pero intenté hacer un .COF con lo que pasaste, me lo compila con 4 warnings  y después en proteus no me funciona. Y lo más extraño es que el canal de muestra que debería salir por el puertoB es el canal2 dmx y no el 1... Yo creo que hay que resolver bien el tema de la conexión USB el resto parece correcto y con respecto a lo ruidos habría que probar en un placa bien fabricada y con varias protecciones para ver como funciona. Yo voy a comprar un PIC18F2550 así lo pruebo y voy a tratar de mejorar el programa con la parte de USB en CDC.
Hume, esos archivos que preguntas están en los drivers del CCS y otros en el include que pasó Khronos.
SAludos
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: hume_86 en 01 de Octubre de 2009, 23:18:21
Hola jmorfeo, gracias por contestar, el problema de los archivos lo solucioné, el tema es que yo usaba el C18 para compilar y no encontraba los archivos, ya instale el CCS y los puede encontrar, ahora me esta dando otros errores al compilar, los cuales no me he puesto a solucionarlos por falta de tiempo  :?. Cualquier problema o solucion que surga comentalo que puede ser de gran ayuda.
Saludos
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: jmorfeo en 02 de Octubre de 2009, 11:10:52
Yo ya pude hacerlo funcionar pero con la versión del CCS 3.249  :-/, perocon la 4.093 no hay forma  :?. Estuve planteando la consulta en el foro de CCS y todavía nadie responde. Debe haber habido un cambio en los drivers y eso afecta al compilador.
Por otro lado se me cuelga el DMXcontrol despues de usarlo la primera vez y eso que soy prolijo y lo desconecto antes de cortar la simulación pero se ve que tiene problemas el programa, voy a probar con Freestyler a ver si tengo más suerte.
Me gustaría mejorar el programa de Khrnos usando la máquina de estados que dan en el AN1076 (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en527825). Habría que traducirla a C y antes probar con una comunicación USB CDC que ande diez puntos, una vez que logramos comunicarnos le agregamos el código DMX de transmisión que hay que probar antes solo, mandando unos datos de potenciómetros por ejemplo.
Comentame tu opinión, Saludos
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Khronos_Nieto en 06 de Octubre de 2009, 23:32:08
Buenas compañeros !

Me alegra el saber que les puede ser util el diseño presentado.

He tenido este proyecto un poco aparcado por cuestiones de trabajo y porque me atranqué un poco en el tema de las interferencias. Hace poco he vuelto a retormarlo, ahora dispongo de osciloscopio y he podido ver que la tensión 220 AC de mi casa es un auténtico caos de interferencias, bueno, más concretamente algunos tubos fluorescentes son los causantes, ya que en el encendido meten un ruido tremendo.

Siguiendo los consejos de Manolo y Rafael he optoacoplado las salidas DMX + y DMX -, incluso sospechando de que las interferencias vinieran por la masa común, he colocado un convertidor aislado de DC/DC, de forma que toda la etapa de salida queda aislada eléctricamente del PIC. También he usado cable bueno (apantallado) de tan solo 10 metros y un terminador al final del bus. Los problemas se han suavizado, ya no ocurren tan frecuentemente, puedo tenerlo horas funcionando sin problema. Pero si enciendo y a apago los famosos fluorescentes insistentemente al final logro que se cuelge.

Ya se lo que pensareis "pon reactancias y cebadores electrónicos a esos fluorescentes y problema resuelto" pues llevais razón, es lo que debo de hacer. Pero me gustaría tener la tranquilidad de poder llevar mi equipo de luces a casa de un amiguete y que funcionase decentemente sin importar los ruidos eléctricos que existan en ese sitio.


Como última opción en mis investigaciones, estoy convencido de que el PIC se resetea por algún motivo. Probando he forzado un reset (hardware) y el efecto es el mismo que el de las interferencias, DMXControl se cuelga. Asumiendo que el PIC se va a "resetear de vez en cuando", estoy tratando de conseguir que el programa retome la conexión USB con el PC y que no se pierda el puerto serie virtual.

Actualmente esto no ocurre y sospecho que es porque al inicio del programa tengo puesto un "usb_init()", y esto hace que se quede esperando la inicialización del USB sin éxito, ya que ésta negociación ya se hizo al conectar por primera vez el cable al PC.

Mis conocimientos de USB con PIC son básicos y principalmente se basan en los ejemplos del compañero RedPic. Creo que algún otro compañero del foro ya hizo algo parecido a modo de "conexión/desconexión en caliente" por lo que voy a investigar.

Jmorfeo, me alegro que al final pudieses hechar a andar la simulación, estoy totalmente de acuerdo contigo en lo de conseguir una sólida comunicación USB CDC antes hacer cualquier otra cosa. Creo que yo también voy a tirar por ese camino. De todas formas la parte del código que controla la transmisión DMX creo que vá perfectamente. Yo tengo hecho una mini-mesa DMX con un PIC, utilizando este trozo de código para enviar comandos y va de lujo. Me encantaría de que compartieras tus experiencias o cualquier avance con el proyecto.


Un saludo !!  :-/ :-/ :-/
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: jmorfeo en 09 de Octubre de 2009, 00:04:42
Hola Khonos!! Te cuento que recién compro el 18F2550, Estuve haciendo las pruebas en Proteus y le bajé la velocidad del micro  a 16Mhz para mi PC no se muera y funciona ok con Freestyler pero con DMXControl se me cuelga el DMXControl. Solo queda enviando datos, se ve que no obtiene respuesta del PIC pero este sigue funcionando.
En realidad estoy armando la interfaz para probar un Receptor DMX de un trabajo que estoy haciendo con un 16F883, que controla leds RGB por 3 canales DMX y por otros dos le voy a pasar los datos para dos motores PAP (PAN y TILT) tipo scanner... y cuando pongo todo junto en proteus porque no tenía el PIC, no logro la recepción de los datos. Si verifico que los recibe el 18F2550 pero cuando reviso la trama DMX veo en vez de tener los dos bits de Stop de 8 us tengo 12 us aunque el dato sigue siendo de 4 us. De todos modos tengo que hacer mas pruebas ya que es muy probable que la falla sea de mi programa...
Tengo un ASM que me anda en la realidad con el que controlo los leds solamente, con un PWM por soft de un 16F628 que lee un DIP-Switch para saber  el canal DMX del primer color. Voy a probarlo de nuevo...
Con respecto al USB-DMX me gustaría que enviara los 512 canales para hacerlo completo y funcional. Y para esa cantidad de datos el programa se pone lento para la recepción USB, me parece. Yo creo que se podría trabajar con una versión traducida a C del código del AN1076 de Microchip que pongo antes y recibir USB por interrupción o meterlo entre medio de la máquina de estados de la nota de aplicación. Y mejorar la comunicación USB pero recién estoy aprendiendo a usarla. Aunque anda bastante bien... con Freestyler... por lo menos
Me parece bien las modificaciones de las aislaciones que hiciste pero me parece que si se resetea el micro puede ser por problemas de tensión, o patas en el aire, falta de capacitores de filtro de alta frecuencia en la fuente o falta de capacitores en la alimentación del PIC de 100nF.
Sigo sin saber porque no me anda el USB con la versión del CCS 4.093... alguna idea??

Saludos  :D :D :D
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Khronos_Nieto en 14 de Octubre de 2009, 22:13:49
Buenas...!

Jmorfeo, me alegro que continúes con las pruebas. A mi si me funciona con DMXControl, no sé donde puede estar el fallo. ¿Seleccionas la interfaz DMX4ALL? ¿Seleccionas el puerto COM correcto?. Despues de esto debería dar OK al darle a verificar. De todas formas voy a intentar comprobarlo cambiándole yo tambien el reloj a 16 MHz.

Me parece buena idea adaptar la nota de aplicacion AN1076 para la transmisión DMX, no lo he probado con 512 canales pero quizás lleves razón y se vuelva lenta la ejecución. Tal y como está diseñado el programa, una vez que se pone a transmitir permanece en ese proceso hasta que acaba, y entre tanto pueden estar llegando nuevas tramas por USB. Haber si saco un poco de tiempo y lo miramos.

Respecto a porqué no te va con el CCS 4.093 no te puedo ayudar, yo uso el 3.235 y parece que va bien. Es una idea al aire pero ¿quizás sea porque los drivers y archivos descriptores no valen de una version a otra? Me refiero a estos "usb_cdc.h" y "descriptor_usb_dmx.h".

Un saludo!!  :-/ :-/ :-/
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: luiscolo en 11 de Marzo de 2010, 00:18:35
Estimado Khronos:

hace algo mas de un año tengo una interfaz dmx bidireccional que funciona conectada a la pc,
para no sumergirme en el mundo usb (cosa q ya tendre q hacer) la hice rs232
y me compre un adaptador usb rs232 de esos de mercado libre
desde el principio LA HICE OPTOACOPLADA, con dos fuentes de alimentacion independientes
(es decir dos trafitos, dos puentes de diodos, etc etc etc) y tres opto, uno para transmitir,
uno para recibir y uno para cambiar el sentido del transceiver
desafortundadamente, cuando la uso con el adaptador usb-232, al conectar algo en la misma zapatilla
se cuelga el convertidor usb232, lo q me recuerda tu problema
nunca pude determinar si se cuelga el pic, pero lo dudo
las luminarias q le conecto (de leds) tambien las diseño yo y tienen exactamente el mismo esquema de aislacion
y nunca dejan de funcionar
la unica mejora casi promisoria la obtuve al dejar de usar los usb del frente del pc y usar los de atras
por otro lado, aunque nunca hice una prueba estadistica, no recuerdo haber tenido problemas usandola en rs232
por lo que adjudique todos los problemas a una mezcla entre el puerto usb de la pc y el convertidor

lo que nunca logre explicarme es como el ruido pasaba a traves de donde hacia donde, ya que todo esta optoacoplado
espero saber si pudiste resolver el tema del cuelgue, porque quiero empezar con el usb y no quisiera sufrir
las desventuras de conectar algo y q todo deje de andar, ya que uso mucho las luces en eventos, y la linea ahi
si que es un verdadero desastre, por ahi 40 kw en par 1000 conectados a dimmers, moviles, etc etc etc

te mando un saludo enorme y gracias por compartir la info!
Luis
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Khronos_Nieto en 11 de Marzo de 2010, 23:53:43
Buenas Luis,

Lo primero darte la bienvenida al foro y agradecerte el compartir tus experiencias y conocimientos.

Según comentas tu diseño de interfaz DMX está muy bien estudiada y protegida contra el ruido. En mis investigaciones sobre los fallos puntuales que daba la interfaz fuí siguiendo los mismos pasos que tu describes. Con los optoacopladores mejoró bastante la cosa, pero aun así se colgaba de vez en cuando, por lo que empecé a sospechar de cualquier fuente de ruido.

¿Por donde se cuela el ruido?
En mi caso descarté el ruido radioeléctrico, es decir, el que viene por el aire. A modo de prueba envolví el diseño en papel de aluminio (creando una jaula de faraday) conectado a tierra, pero los problemas persistían. Por tanto el ruido circulaba por cable.
 
Ya que las lineas de datos están optoacopladas, el único vínculo entre mi circuito y el bus DMX de los focos es la masa común. Pues bién me hice de un conversor DC/DC aislado galvánicamente (Texas Instruments los envía como samples), de forma que la masa de mi circuito y la masa del cable DMX que va a los focos quedara separada. Esto mejoró bastante la situación, ya era bastante dificil provocar el cuelgue del conjunto PC-Interfaz. Incluso sospeché de la propia alimentación de la interfaz (a través de una fuente convencional de transformador, puente de diodos y un 7805), por lo que lo alimenté con una pila.

Con todas estas medidas logré erradicar casi completamente el problema. Digo casi porque rara vez se colgaba la interfaz. De momento he desistido porque no se me ocurren nuevas ideas pero con los comentarios y experiencias como la tuya y de otros compañeros, se ayuda mucho a seguir la investigación. Mi objetivo es que tenga suficiente fiabilidad y robustez como para usarlo en eventos y espectáculos.

De todas formas estoy convencido que las Interfaces USB-DMX comerciales se tienen que colgar también...  :mrgreen: :mrgreen: :mrgreen:, con la diferencia de que esas te cuestan 400$ . En algún foro he visto comentarios de gente quejándose precisamente de eso.

Bueno, perdona por una introducción tan extensa, en base a lo que ya sabemos se me ocurre lo siguiente:

1 - Estoy completamente de acuerdo contigo en que el PIC no se cuelga, no obstante se podría comprobar manteniendo un led encendido al inicio del programa.

2 - Quien se cuelga es el puerto serie "virtual" que crea el PIC o el adaptador RS232-USB en tu caso.

3 - Tiene que ser un cuelgue muy rápido porque si observas el Adminstrador de dispositivos de Windows, este puerto "virtual" sigue existiendo tras el cuelgue.

4 - Una posible solución sería arreglarlo mediante programación. En mi programa PIC una vez hecha la rutina de inicialización del USB, asumo que la conexion serie existe y me dedico a leer y escribir sin preguntar si realmente "sigue existiendo dicha conexión". Cuando por un espacio de tiempo ese puerto virtual "no exista" debido al impulso de ruido, cualquier intento de acceso fastidiará el asunto. El problema de esto es que la parte del PIC se podría solucionar, pero.....nuestro querido DMXControl solo comprueba el puerto en el arranque, despues se dedica a leer y escribir.

5 - Lo que comentas de los puertos USB delanteros y traseros de tu PC me ha hecho reflexionar. Tengo entendido que en un PC algunos puertos USB dan mas corriente que otros, casualmente los traseros dan más corriente. La prueba está en que algunos discos duros portátiles USB llevan dos conexiones USB, una de datos/alimentación y otra de solo alimentación. Dependiendo del PC o del puerto al que lo conectes es necesario enchufar solo el cable de datos/alimentación, o conectar los dos porque "le falta corriente" y necesita un apoyo.

Creo que aquí esta el quid de la cuestión, pudiera ser que la desaparición momentánea del puerto virtual fuese provocada por un "sobreconsumo" en el puerto. En esta situación el PC corta el suministro de corriente a este puerto para protegerse, y lo reestablece cuando cesa el sobreconsumo. Esto es exactamente lo mismo que desconectar el cable USB y volver a conectarlo!! Desaparece el puerto serie virtual y tiene que volver a ser creado, pidiendo descriptores... etc... y todo esto con el PIC y el DMXControl a su rollo pensando que no ha pasado nada...!!

¿Puede el ruido ocasionar ese sobre consumo? No lo se, pero quizás si que haga caer la tensión Vcc de 5v del USB lo suficiente. ¿Por donde se cuela? Pues no queda otra que a través del propio PC, cuesta creerlo porque si hace eso como va a seguir el microprocesador del PC tan tranquilo, pero no le encuentro otra explicación.

Mi siguiente paso va a ser poner un filtro de red al enchufe del PC.

Bueno, perdona de nuevo por el rollo, espero que mis comentarios te puedan ser de ayuda. Por último aclarar que no todo es tan negro, mi caso particular es bastante problemático ya que ese fluorescente que me provoca tantos problemas en mi casa es una auténtica factoría de ruido. Con decirte que si enchufo cualquiera de mis montajes justo en el enchufe que hay debajo del tubo fluorescente, cada vez que enciendo el tubo se cuelga el microcontrolador, sea cual sea...jejje  :lol: :lol:. No creo que esto sea muy normal en cualquier casa o local..!! Tengo mucho tubos a lo largo de mi casa y solo me pasa en ese.... es un caso muy extremo pero me niego a cambiarlo, es un auténtico laboratorio para el estudio de ruido  :mrgreen: :mrgreen: :mrgreen: :mrgreen:..

Espero sinceramente nos sigas comentando tus avances.

Un saludo compañeros.

Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: stk500 en 12 de Marzo de 2010, 04:38:25
Muy buena vuestras informacion, pero hay algo que habeis olvidado y es las masa comun y la toma de tierra, porque una PC en este caso, tiene su masa directa a la toma de Tierra, yo recomiendo si va a comandar con este protocolo, recomiendo un DMX- BOOSTER, estos aparatos de compone de diferente entradas y Salidas de Bus con Optoa acopladores, osea un HUB, el caso comenta el amigo Khronos sobre lamparas florecente y los ruidos, es debido que todos florecente hacen ruidos y a veces es por laas conexiones interna del florecente,, algunos fabricante de lampara recomienda un cableados cubrirlo con metal, y toma de tierra que no falte nunca, ahora la pregunta de todos estos es,
ha revizado cada aparato de tu casa sobre fallos de impedancias? Habeis medidos la toma de tierra con el Diferencia?
pues todos esto hay que tener en cuenta cuando se usas un grupos de aparatos conectados a una Fase o diferente Fases, otros factor con el USB, si lo usan en un SHOW recomendar usar una alimentacion externa al USB, asi no sobrecargan el Bus USB de la PC.

Saludos
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: luiscolo en 16 de Marzo de 2010, 01:28:27
Estimados Khronos y Rafael:
Aca les adjunto un esquema de la interface (si es que el foro me permite agregar una mas en este tema).
Disculpas por lo tonto del esquema, pero me parece que va a ser claro.

Una de las posibilidades de las que desconfio es de la caja metalica,
tengo muy presente que alguna interfaz comercial es bien de plastico.

Ya he construido una de plástico yo tambien, pero ahora que me decido a probarla,
al driver del conversor usb-rs232 se le dio por hacer que el windows muestre esa odiosa pantalla azul.

En cuanto logre hacerlo funcionar posteo los resultados, incluyendo puertos delanteros y traseros del cpu.

Por otro lado, he llegado a pensar en la posibilidad de pasarme a un puerto ethernet,
ya que no logro confiar ni el el puerto usb en si ni en los drivers de windows,
aunque hoy he pasado el dia consultando y veo q es una tarea algo... trabajosa!

Bueno, pronto posteo, un abrazo!
Luis
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: todopic en 16 de Marzo de 2010, 15:25:33
Hola Luiscolo, tienes conectada la resistencia de 100-120 ohm en la salida RS485?
Ademas, donde dices "la malla no esta conectada", tendrias que conectarla con una resistencia de unos 10 a 100 ohm

Suerte!

Norberto
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: luiscolo en 16 de Marzo de 2010, 22:26:56
Hola Norberto, gracias por tu aporte,
Si, el bus esta armado segun la especificacion 2.3, 2.4, 2.4.1, 2.5 y 2.5.1
del documento original de la ESTA para RDM (terminadores, biasing, etc)
Por otro lado el transmisor es asilado, por lo cual cae dentro del Anexo A.1
de documento original del USITT para DMX.
Esta decision es porque el riesgo de descarga electrica en un transmisor no aislado
es alto, sobre todo si el transmisor se conecta en una toma sin descarga a tierra;
y porque por otro lado, al estar conectado a la PC o la notebook, cualquier falla de asilacion
en cualquier dispositivo de la red terminaria conectando la masa de las compus
a uno de los dos polos del enchufe, (falla bastante habitual en muchos dimmers por cierto)
lo cual sumado a que la mayoria de los cables "dmx" no respetan la asilacion entre masa y carcaza
terminaria en una catastrofe (de esas que vez cuando te traen para reparar dimmer, splitter, consola
y moviles, todo de una sola vez)

Por otro lado, he probado el adaptador usb->rs232 en la interface con gabinete plástico,
y por cierto no me llevó mas de dos enchufadas al 220 para que deje de funcionar,
al igual q lo que explicabas Khronos, el puerto no se desmonta del administrador de dispositivos
pero la unica forma de poder volver a reconocerlo es desconectarlo y conectarlo nuevamente,
Por otro lado, y que he olvidado mencionar antes, el mouse usb (que esta en el enchude usb de al lado)
tambien se cuelga, aunque no tanto como el adaptador 232, y tambien es necesario desenchufarlo y volver a
enchufarlo para que ande nuevamente.

Finalmente, he probado con el puerto serie directamente y no he logrado que nada deje de funcionar,
lo cual sigue desalentandome a confiar en un usb para esta tarea; deberia consultar con algunos amigos si las
interfaces comerciales (esas de plastico azul traslucido muy bonitas) tienen este mismo problema;

por otro lado, ya he instalado el wireshark y he empezado a mirar las tramas ethernet,
no parece tan descabellado ni taaaan inalcanzable,
he llegado a imaginar un router con una interface y dos computadoras a la vez :D
al estilo de los nodos de la "mama grande" :D

Bueno esto es todo por ahora, y me alegra haber entrado al foro (es la primera q participo en uno)

Saludos, Luis
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Khronos_Nieto en 24 de Marzo de 2010, 21:07:08
Buenas compañeros..!

Lo que comentas Luis de hacerlo a través de ethernet suena muy muy bien.!! Habría que estudiar el tema, mis conocimientos en ese área son muy limitados. Estaré atento a tus progresos. Por cierto, veo que estas padeciendo los mismos "cuelges" del puerto serie virtual que yo, es para volverse loco..! Sería muy interesante que tu que conoces gente del mundo del DMX y la iluminación espectacular, preguntaras lo de que tal van las interfaces USB comerciales. Por lo menos si también fallan, como decimos por aquí "mal de muchos, consuelo de tontos" :D :D :D

Estoy completamente de acuerdo con lo que comenta Rafael, se debe buscar al culpable de los ruidos, a veces por mucho que quieras protejer a tu circuito, es imposible hacerlo inmune a todo tipo de interferencias y hay que actuar sobre el "causante".

Un saludo.!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: luiscolo en 26 de Marzo de 2010, 02:35:29
Buenas amigos!

Tema USB:
Justamente hoy he avanzado un poco en la experimentacion del malvado cable usb-serial:
la fuerza de la necesidad me llevo a lograr instalar un driver que funcione (sin pantalla azul) en mi compu de escritorio
y a instalarlo en la portatil ya que el lunes debo ir a programar a lo de unos clientes.

Ya que tenia todo funcionando, hice el ensayo en la portatil, y para mi sorpresa no logre colgar el puerto en la netbook,
he hecho casi un maremoto de conexion/desconexion y ni pestañeo! es decir, siguio funcionando perfectamente!
Agrego q es una netbook bastante... (emmmm low profile?) economica :) de esas q vende acer con pantalla de 11.6,
con lo cual no es que tengo la re calidad de hardware en esa maquinita, (o sera que si?)
Para colmo de males la portatil estaba con el cargador conectado y cargando,
y la alimentacion de la interface estaba tomada de un puerto usb de la maquina,
asique mucho optoacoplador pero la misma masa :D

Finalmente desenchufe y me vine a la pc de escritorio (los puertos del frente) y rapidamente logre que deje de funcionar.
Entre la frase anterior y esta que escribo ahora (2.10 am jeje) ensaye los puertos traseros de la pc de escritorio
(misma interace tomando los 5 V de la pc) y tuve varios resultados interesantes:
el primero es que nunca se colgo el puerto serie, es decir que nunca dejo de funcionar,
y el segundo es que recibia algunos caracteres extraños por el puerto durante las conexiones/desconexiones
cosa que para estas instancias no me parece tan grave, sobre todo tomando en cuenta que la fuente switching de los
leds hace unos chispazos bastante poderosos cuando la conecto!

Bueno hasta aca el tema usb por hoy, me resisto a descartar esos puertos (al menos aun!)

Pasando al tema Ethernet, tampoco soy un experto, mas bien soy menos que principiante;
ademas, asi como me reconozco muy buen programador en assembler, el C es casi un agujero negro para mi,
aunque me vengo entrenando porque ya veo que no tengo otra chance, pero me falta entrenar muuucho aun :)

Sin embargo he aprendido bien el protocolo ethernet y el ip, y algunas generalidades del arp y otras menudencias que andan por alli, ya que si buscas sobre ethernet nadie dice nada que no empiece con tci/ip, asique he leido todo lo q pude.

Parece ser que hay dos opciones:
la pila tcp/ip de microchip y los modulos de tibbo: aunque los primeros salen bastante menos y parece ser que
tambien hay que trabajar bastante mas, aun no me decido pero me gustaria saber que piensan ustedes.
Y por ultimo me pase del visual 6 al 2008 (previa discusion con windows de 6 horas para poder instalarlo)
ya que es una herramienta libre con lo cual no habra que esconderse para usarlo, y de hecho trae el mscomm y el winsock,
los que he probado y funcionan a la perfeccion (segun la define microsoft jeje), de hecho he podido enviar y recibir
paquetes tcp y udp entre las maquinas y he mirado todo el trafico con el wireshark y se comprende perfecto!

Debo admitir que el ethernet me tienta mas:
no necesita drivers, y se puede configurar el producto desde cualquier navegador (al estilo de los routers) con solo poner la direccion ip!

Bueno espero sus opiniones a ver que les parece, y perdon por el largo del post :D

Un abrazo!
Luis
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: piovi en 19 de Junio de 2010, 18:28:28
Buenass!! he buscado muuucho un circuito como este y la verdad que esta muy bueno, quisiera saber si alguien lo hizo y funciona correctamente, sin ofender perdon...
y descargue de el link para bajar el proyecto que pusiste, pero no estan los valores de las resistencias ni de casi ningun componente en el esquema y realmente me gustaria mucho poder hacer este circuito! si alguien me puede contestar...   muchiiisimas gracias por todo este esfuerzo, Saludoss!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Juanm en 02 de Julio de 2010, 13:39:05
Buenass!! he buscado muuucho un circuito como este y la verdad que esta muy bueno, quisiera saber si alguien lo hizo y funciona correctamente....y descargue de el link para bajar el proyecto que pusiste, pero no estan los valores de las resistencias ni de casi ningun componente en el esquema....

funciona si, lo hice, tube que cambiar la parte del transiver, que use un SN75176BP, pero anda lo mas bien

las resistencias, meti una de 10k en el reset, y la parte de los led no la arme, pero se calcula por ley de ohm teniendo en cuenta que los leds comunes tienen de 2 a 2.8v de caida, y una corriente de 25 a 30mA, asi que con 5V maximos que le puede suministrar el pic (el voltaje USB es de 5v, por eso digo que son 5v max) te queda entre 3 y 2.2V que tiene que haber en la resistencia por lo que dijo el viejo kirchoff, asi que quedaria R=2.5V/0,025A (redondeo a 2.5V y tomo la Iminima que es 25mA o 0.025A) tonces quedan resistencias de 100 ohm, para trabajar en lo seguro ponele una de 220 o mas (tampoco tanto que si no ni prende)

los capacitores que van al lado del cristal son de 22pF o 33pF (es lo que puse yo) para estabilizarlo, si no se ponen funciona igual (mejor ponerlos)




ahora pregunto yo



lo quiero modificar para 512 canales, no se programacion (estoy aprendiendo lo basico pero en pascal)

segun estube viendo, hay que modificar en la parte del codigo que dice esto:
Código: [Seleccionar]
/************************************************************************
*                          RUTINA PROCESA                               *
************************************************************************/
void Procesa(){

Envia_Break();
Envia_Start();

indiceTX = 0;

while (indiceTX < 16){                // En este bucle se envían los 16 canales de datos
   if (TXIF==1){
      TXREG = TramaDMX[indiceTX];
      while (TRMT == 0){}
      indiceTX=indiceTX + 1;
   }
}


while (indiceTX < 100){             // En este bucle se envían el resto de canales, forzados a 0.
   if (TXIF==1){                    // No es obligatorio enviar los 512 canales que dice el protocolo,
      TXREG = 0x00;                 // nosotros solo utilizamos 16, sin embargo existe un tiempo mínimo entre
      while (TRMT == 0){}           // el comienzo de una trama y el comienzo de otraq ue hay que cumplir.
      indiceTX=indiceTX + 1;            // A efectos prácticos, se podrían enviar tramas de tan solo 24 canales (no menos),
   }                                // con lo que se conseguiría un refresco mas rápido.
}                                   // En nuestro caso enviaremos tramas de 100 canales para ir sobre seguro.
                                    // De estos 100 canales, 16 tendrán datos válidos recibidos por USB y los restantes se fuerzan a 0.
delay_us(100);


}


si lo cambio a esto:

Código: [Seleccionar]
/************************************************************************
*                          RUTINA PROCESA                               *
************************************************************************/
void Procesa(){

Envia_Break();
Envia_Start();

indiceTX = 0;

while (indiceTX < 512){                // En este bucle se envían los 16 canales de datos
   if (TXIF==1){
      TXREG = TramaDMX[indiceTX];
      while (TRMT == 0){}
      indiceTX=indiceTX + 1;
   }
}


//while (indiceTX < 100){             // En este bucle se envían el resto de canales, forzados a 0.
//   if (TXIF==1){                    // No es obligatorio enviar los 512 canales que dice el protocolo,
//      TXREG = 0x00;                 // nosotros solo utilizamos 16, sin embargo existe un tiempo mínimo entre
//      while (TRMT == 0){}           // el comienzo de una trama y el comienzo de otraq ue hay que cumplir.
//      indiceTX=indiceTX + 1;            // A efectos prácticos, se podrían enviar tramas de tan solo 24 canales (no menos),
//   }                                // con lo que se conseguiría un refresco mas rápido.
//}                                   // En nuestro caso enviaremos tramas de 100 canales para ir sobre seguro.
//                                    // De estos 100 canales, 16 tendrán datos válidos recibidos por USB y los restantes se fuerzan a 0.
delay_us(100);


}


funcionarian todos los canales?? (los 512)
o hay que modificar algo mas??


vi en una parte que decia
Código: [Seleccionar]
/************************************************************************
*                         RUTINA DE INCIALIZACIÓN                       *
************************************************************************/
void Inicia(){

// Inicia variables.

for (aux=0;aux<16;aux++){
   TramaDMX[aux]= 0x00;

ese aux<16 tengo que cambiarlo tambien?? y en algun otro lado???


perdon por todas las preguntas, y espero alguien me pueda responder


saludos y gracias desde ya



Edit: aca subo 2 imagenes, de la parte de las pistas y una superior con los componentes, se puede hacer de distinta forma y mas chico, pero lo hago a mano y me da pereza hacer las pistas mas chicas :P

(http://img295.imageshack.us/img295/3563/usbdmx.th.jpg) (http://img295.imageshack.us/i/usbdmx.jpg/)
(http://img268.imageshack.us/img268/6039/usbdmxpistas.th.jpg) (http://img268.imageshack.us/i/usbdmxpistas.jpg/)
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: piovi en 21 de Septiembre de 2010, 13:51:26
Muchas gracias juanm, pro buscando imagenes e internet me di cuenta que el SN75176BP no es igual al max488, me podrias decir en que pines del SN75176BP van los que antes estaban en los pines  2, 3, 5, 6, 8, 7 del max? y de los capacitores del Xtal cual va de cada lado, o es lo mismo?? desde ya muchisimas gracias por el aporte a todoss!! a muchos que tenemos pequeñas cosas nos cuesta demasiado una consola DMX o pagar el robo de caro que es una interfaz,... saludos!!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: ariel landa en 02 de Diciembre de 2010, 17:06:56
hola Khronos_Nieto.
te cuento ya hace como 6 meses me arme tu controladora dmx la cual me anda de 10 ahora el problema que me surgio es el siguiente yo la usaba con 4 efectos led de 3 canales cada uno lo cual me dava 12 canales de datos hasta aca bien  desde el principio me salto algo rarro en la interfaz. lo rarro era que tenia que tener el segundo canal del freestyler al maximo para que ande la controladora es decir que en 16 canales que tiene le tenia que restar 2. mas de 16 nunca me detecto la iterfaz.
ahora me compre 4 cabezas mobiles de 8 canales cada una lo cual me voy a 2 canales con las cabezas y 12 de efectos led.
mi gran problema es: como ahora para que me tome minimo 100 canales como para no tener mas drama y como se puede solucionar el tema del segundo canal. desde ya muchas gracias a todos y espero respuestas.
me olvide de comentarte yo no se programacion si me podes facilitar el hex modificado seria de mucha ayuda.
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Khronos_Nieto en 11 de Diciembre de 2010, 23:32:30
Buenas compañeros,

Disculpad mi ausencia en este hilo de DMX, sigo frecuentando mucho el foro pero apenas he tocado nada de DMX desde este pequeño proyecto. Además resulta que los focos RGB con los que hacía mis pruebas no los tengo ahora disponibles (están en casa, a 400 km.. :lol: :lol:).

Para Ariel Landa y otros que han preguntado acerca de como incrementar el número de canales, si hechan un vistazo al código verán que es muy muy sencillo. El programa realmente no tiene dificultad ninguna, y creo recordar que estaba mas o menos bien comentado. De todas formas os comento lo que hay que hacer para aquellos que no se manejen mucho en C.

Abran el archivo principal "Interface_usb-dmx2.c" y dentro de la rutina "Procesa", está la siguiente sentencia: "while (indiceTX < 16){" simplemente incrementen ese 16 a un número superior (máximo 511 evidentemente).

También hay que incrementar el tamaño del array que almacena los valores para cada canal, originalmente es de 16, pero si ponen por ejemplo 100 en el while anterior, tendrán que poner también el array con un tamaño de 100. El array esta declarado en la zona de variables "int8 TramaDMX[16];".

Simplemente es cambiar esas dos cosas y recompilar en CCS.

Un saludo.!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Juanm en 18 de Febrero de 2011, 01:41:55
GRACIAS KHRONOS!!!!!!!!!!

habia intentado hacerlo pero metia 512 xD (no se casi nada de programacion, solo pascal que no es igual pero es parecido, e intente hacer algo sin entender nada, error burdo, y no contar al 0 como un canal, puede ser?? )

cuando ande con tiempo y consiga el pickit de un familiar reprogramo y comento a ver si funka

MUCHAS GRACIAS CHE! sos un capo  8)

salutes
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Juanm en 19 de Febrero de 2011, 01:37:31
tengo una duda, cambie los valores que dijiste y no toque nada mas, compilo, el ccs me da 4warnings pero 0 error, eso esta bien??

grabo el pic con el hex nuevo y cuando conecto el USB me tira como que no reconoce el dispositivo, saco, grabo de vuelta el mismo pic con le mismo programador pero con el hex ORIGINAL y lo reconoce al toke....

que estoy haciendo mal?? cambie los 2 uses en la carpeta del CCS y los modifico para que me anden (tenia como directorio de los uses un /include/nombre_del_include y lo cambie a <nombre_del_include> para que me funkara, al igual que en el programa principal... esta mal eso?? )

lo que me queda probar es compilar el programa si como me lo mandas vos (el programa en C original) a ver si es problema de la compilacion u otra cosa...

EDITO:

esto es lo que me tira el log

Código: [Seleccionar]
Executing: "C:\Archivos de programa\PICC\Ccsc.exe" +FH "Interface_usb-dmx2.c" #__DEBUG=1 +ICD +DF +LN +T +A +M +Z +Y=9 +EA  #__18F2550=TRUE
>>> Warning 203 "C:\Archivos de programa\PICC\drivers\pic18_usb.c" Line 514(1,1): Condition always TRUE
>>> Warning 216 "Interface_usb-dmx2.c" Line 533(0,1): Interrupts disabled during call to prevent re-entrancy:  (usb_token_reset)
>>> Warning 216 "Interface_usb-dmx2.c" Line 533(0,1): Interrupts disabled during call to prevent re-entrancy:  (usb_tbe)
>>> Warning 216 "Interface_usb-dmx2.c" Line 533(0,1): Interrupts disabled during call to prevent re-entrancy:  (usb_cdc_flush_out_buffer)
      Memory usage:   ROM=21%      RAM=49% - 55%
      0 Errors,  4 Warnings.
Loaded C:\Documents and Settings\Juan\Escritorio\USB DMX\Interface_usb-dmx2.cof.
BUILD SUCCEEDED: Sat Feb 19 02:43:03 2011
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Juanm en 21 de Febrero de 2011, 12:51:08
bueno, al fin logre compilarlo y que me funke! no sar el compilador desde el MPLAB, compilen directo del CCS, no se por que no me funka compilando desde el mplab...

muchas gracias!!!!!!!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: DJ TRAN-C en 23 de Abril de 2011, 18:44:02
Tengo un problema:

Conecto la interfaz dmx al puerto usb de la Pc me pide el driver !y no consigo donde sacarlo!  :shock: :shock:
si me pudieran ayudar se los agradecería mucho.
Saludos.
 :o
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Juanm en 30 de Abril de 2011, 23:45:34
Esta en la carpeta "include", si mal no me equivoco es el archivo "mchpcdc.inf", por lo menos use ese de "diver"  :shock:
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: matgg en 15 de Mayo de 2011, 02:14:13
Buenas gente:

Estoy siguiendo este tema y quiero probarlo con el simulador, pero qué es lo que debería ver en el simulador???

porque las salidas siempre estna en 0
deberia usar el programa y configurrar que use el puerto virtual del proteus???

Muchas Gracias

si tengo que poner ese puerto alguno sabe cuál es? o como puedo saberlo??

 :-/ :-/
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: mauro36 en 16 de Octubre de 2011, 22:02:38
Hola a todos los del foro, queria hacer comentario con respecto al esquema.
En el pin de VUSB hay un capacitor ceramico de 470nf cuando en realidad va un capacitor electrolitico de 10uf.
Quiza con eso tambien se reduzca el ruido que te hacia "reiniciar" el micro
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: wilmar88 en 08 de Enero de 2012, 23:48:11
Muy bueno el proyecto, en la sumulación 10 puntos, ahora lo armé en protoboard pero con el 4550, alguien lo probó con este??? porfavor si alguien podría decirme los pasos para seguir para cambiar al 4550 ya que soy nuevo con el CCS y no se como modificar esta cuestión, muchas gracias :)!

Una cosita mas, en el dibujo dice 12Mhz puedo colocar uno de 11.0592 o uno de 20mhz??? y en el programa dice 48000000 en el clock, se debe cambiar?? o algo en las cabeceras del pic?

Wilmar
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: dishelt en 12 de Febrero de 2012, 20:11:31
hola  a todos, tengo pensado contruir el circuito de manolator, pero tengo una duda, no es mas facil poner un adaptador de paralelo a usb?
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: luiscolo en 15 de Febrero de 2012, 00:57:56
Estimado Khronos y toda la gente del hilo y del foro:
aun no me he dado por vencido respecto del usb y los ruidos electricos y el descuelgue del puerto serie;
finalmente, he decidido hacer un "casting" de adaptadores usb_rs232 de los disponibles en mercado libre, y el resultado fue el siguiente:

todos ellos, excepto uno, tienen el mismo problema, que con cualquier ruido electrico se desconectan del programa aunque no se desmonta el puerto, y la unica manera sigue siendo desenchufar y reenchufar el adaptador,

pero... pero !!!!!

un modelo chipset cp2102 funciona a la perfeccion, ademas de tener drivers firmados digitalmente,
con la interfaz optoacoplada (como siempre lo estuvo) he hecho tormenta de conexion/desconexion y ni una sola vez he logrado el efecto tan odiado, nunca ha dejado de funcionar y creo que sera la opcion definitiva, al menos por este año, para mis comunicaciones usb a la pc!

lamento no tener una solucion para el mismo problema con los pic, pero bueno, ya habra algun otro forero que de en la tecla,
por lo pronto les acerco esta solucion ya que he estado desahuciado con este tema, llegando a pensar que no iba a tener solucion;

les mando un abrazo grande y hasta pronto!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: cristiancrm en 14 de Marzo de 2012, 17:17:54
Hola, amigos. Cómo están?

Yo estoy haciendo una interface DMX también basada en el code de nuestro queridísimo amigo.
También se me presentó la idea de hacerlo vía RS232 directamente y tuve que recurrir a un conversor.
Bueno, hace un tiempo concurrí una presentación de productos Microchip que se hizo en BsAs, y ahí nos entregaron una placa que cumple la funcionalidad de convertir USB a señales RS232 (incluye el MAX232, con lo cual también tiene salidas TTL). Bien, ese día conocí al MCP2200. Es un integradito que necesita un cristal de 12Mhz y un par de capacitores para salir funcionando. De todos los adaptadores que probé, éste me resultó de maravillas. Posee una aplicación para cambiar el VId del USB entre otros parámetros. También es posible modificar el boudrate. Para quienes viven en BsAs, pueden conseguirlo en Elemon, ahí los venden y creo que cuesta algo de u$s4.

Respecto a la interface DMX, aun no logro hacerla funcionar. Configuré el PIC para que la USART funcione a 250Kbps. Desde el hyperterminal envío las tramas una a una y funciona de maravilla. Pero el problema aparece cuando lo hago desde el FreeStyler. Por algún motivo no interpreta los datos que le llega al PIC y no hace nada. Para poder comprobarlo, en cada estado de recepción puse un led, de manera que se pueda verificar si realmente llega el 0X43 de inicio de trama. Desde el hyperterminal el led enciende bien cuando le envío 0x43, pero no desde el freeStyler. Analicé los datos que el FreeStyler envía y noto que están bien, con la única diferencia que éste lo envía todo junto (C001L255, por ejemplo), mientras que desde el hyper terminal sale byte a byte.
También hice una aplicación en VC# para usar el mismo método que usa FreeStyler para enviar los datos. De comienzo tampoco me funcionó, pero me dí cuenta que era un problema de configuración del PIC, estaba configurado para usar 9bits, y VC# usaba 8bits. Luego de cambiar eso, desde VC# funciona de maravillas. Pero claro, no tengo aun toda la funcionalidad que ofrece freeStyler, es por eso que quiero hacerlo funcionar con éste último.
De momento, mi idea es usar el puerto serie conectado al PIC, y a éste conectarle los 3 Leds, sin enviar nada por medio de otro puerto. Como les comenté, esto funciona bien desde HyperTerminal y desde VC#.

Mis preguntas son:

1 - A qué baudrate opera FreeStyler sobre el puerto configurado? No pude ver el baudrate, pero sí el puerto COM.
2 - Es posible que freeStyler esté trabajando a otro baudrate que el configurado en el PIC?

Desde ya, muchas gracias a todos y éxitos!
Cristian.










Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: cristiancrm en 14 de Marzo de 2012, 19:42:42
Hola, amigos.

Para complementar mis preguntas, a continuación les dejo el código del firmware que estoy haciendo para el DMX.
Si alguien tiene alguna sugerencia al respecto, bienvenida será.
Básicamente el problema está cuando intento usar el FreeStyler. Veo que los bytes de reconocimiento se envían al PIC, pero no recibe respecta de este. Lo mismo pasa cuando intenta enviar la trama DMX. Lo raro es que desde VC# (como les comenté anteriormente) envío exactamente lo mismo y sí me responde. No conozco mucho FreeStyler, pero para validar los datos que envía lo hice con un analizador de puerto serie, como hizo nuestro colega.

Básicamente está compuesto por dos interrupciones.

1 - Interrupción del Timer para definir el nivel de cada led.
2 - Interrupción del Puerto Serie por recepción, para adquirir los datos enviados desde la PC.

En la interrupción de la USART se puede observar el algoritmo para analizar los datos de la trama recibida. Está dividido en dos partes: por un lado, la recepción de los bytes de reconocimiento que envía el FreeStyler. El PIC devuelve 0x47. Por otro lado, la recepción de los datos de la trama siempre y cuando el PIC haya respondido el ACK a FreeStyler.
Probé también sin validar los bytes de reconocimiento, ya que FreeStyler envía a "rolete" la trama, pero no pasa nada.

Estoy atento a cualquier comentario.
Gracias de antemano.
Cristian.

Código: [Seleccionar]
#include <18f2610.h>

#FUSES HS                                                                     //High speed Osc (> 4mhz)
#FUSES NOPROTECT                                                              //Code not protected from reading
#FUSES NOBROWNOUT                                                             //No brownout reset
#FUSES NOLVP                                                                  //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O


#use delay(clock=20000000)
#use rs232(xmit=PIN_C6, rcv=PIN_C7,stream=PC)

/************************************************************************
*                     USART registers                                   *
************************************************************************/

#byte BAUDCON=            0xFB8                                               // BAUD RATE CONTROL REGISTER
#byte SPBRGH=             0xFB0                                               // EUSART Baud Rate Generator Register, high Byte
#byte SPBRG=              0xFAF                                               // EUSART Baud Rate Generator Register, Low Byte
#byte RCSTA=              0xFAB                                               // RECEIVE STATUS AND CONTROL REGISTER
#byte TXSTA=              0xFAC                                               // TRANSMIT STATUS AND CONTROL REGISTER
#byte RCREG=              0xFAE                                               // EUSART Receive Register
#byte PIR1=               0xF9E                                               // Peripheral Interrupt Request (Flag)
#byte PIE1=               0xF9D                                               // PIE1 (Peripheral Interrupt Enable 1)
#byte TXREG=              0xFAD                                               // Registro de Transmisión

#bit SPEN=                RCSTA.7                                             // Serial Port Enable bit
#bit RX9=                 RCSTA.6                                             // 9-bit Receive Enable bit
#bit SREN=                RCSTA.5                                             // Single Receive Enable bit
#bit CREN=                RCSTA.4                                             // Continuous Receive Enable bit
#bit ADDEN=               RCSTA.3                                             // Address Detect Enable bit
#bit FERR=                RCSTA.2                                             // Framing Error bit
#bit OERR=                RCSTA.1                                             // Overrun Error bit
#bit RX9D=                RCSTA.0                                             // 9th bit of Received Data
#bit TX9D=                TXSTA.0
#bit TRMT=                TXSTA.1                                             // Bit del estado de llenado del buffer TSR (0 lleno / 1 vacio)
#bit BRGH=                TXSTA.2                                             // High Baud Rate Select bit 
#bit SENDB=               TXSTA.3
#bit SYNC=                TXSTA.4                                             // EUSART Mode Select bit
#bit TXEN=                TXSTA.5
#bit TX9=                 TXSTA.6
#bit TXIF=                PIR1.4                                              // Flag de interrupción de transmisión de la EUSART
#bit RCIF=                PIR1.5                                              // EUSART Receive Interrupt Flag bit
#bit RCIE=                PIE1.5                                              // EUSART Receive Interrupt Enable bit
#bit BRG16=               BAUDCON.3                                           // 16-bit Baud Rate Register Enable bit
#bit ABDEN=               BAUDCON.0                                           // Auto-Baud Detect Enable bit

/************************************************************************
*                    Variables globales y constantes                    *
************************************************************************/
#define RED_LED      PIN_B0                                                   // Define el PIN donde se conectará el LED Rojo
#define GREEN_LED    PIN_B1                                                   // Define el PIN donde se conectará el LED Verde
#define BLUE_LED     PIN_B2                                                   // Define el PIN donde se conectará el LED Azul

#define DMX_WAIT_START     0                                                  // Para salvar el estado de espera de bit de start
#define DMX_WAIT_CHANNEL   1                                                  // Para salvar el estado de espera de bits de canal
#define DMX_WAIT_SEPARATOR 2                                                  // Para salvar el estado de espera de separador
#define DMX_RECEIVE_DATA   3                                                  // Para salvar el estado de espera de valor del canal
#define DMX_SET_DATA       4                                                  // Para salvar el estado de seteo de datos

int8 Ticks = 0;                                                               // Para salvar el número de ticks del Timer
int16 redValue = 0;                                                           // Para salvar el valor del nivel del LED rojo
int16 greenValue = 0;                                                         // Para salvar el valor del nivel del LED verde
int16 blueValue = 0;                                                          // Para salvar el valor del nivel del LED azul

int8 receivedData = 0;                                                        // Para salvar el dato recibido desde la USART
int8 byteCounter = 0;
int8 DMX_status = DMX_WAIT_START;                                             // Para salvar el status del autómata
int16 selectedChannel = 0;                                                    // Para salvar el canal seleccionado
int16 tmpChannel = 0;
int16 tmpChannelValue = 0;                                                  // Para salvar el total de bytes del valor del canal
int16 channelValue = 0;                                                       // Para salvar el valor del canal seleccionado

int8 ackFlag = 0;
int8 ackStatus = 0;

void sendAck(){
   
   if (TXIF==1){           
      TXREG = 0x47;         
      while (TRMT == 0){}   
   }                       
   
   return;
}

void setData(){                                                               // Setea los valores recibido para cada canal
   
   if(selectedChannel == 1){
      redValue = channelValue;
   }
   if(selectedChannel == 2){
      greenValue = channelValue;
   }
   if(selectedChannel == 3){
      blueValue = channelValue;
   }
   
   
   return;
}

/************************************************************************
*                       Interrupción Timer 0:                           *
************************************************************************/
#int_Timer0
void TIMER0_isr()
{
   Ticks++;
   
   //Si el timer llega a 0, entonces enciende los LEDs cargando el valor recibido.
   if (Ticks==0){
     
      if(redValue)output_high(RED_LED);
      if(greenValue)output_high(GREEN_LED);
      if(blueValue)output_high(BLUE_LED);
   }

   //Si el Timer es igual al valor establecido, apaga el LED.
   if(Ticks==redValue)
      output_low(RED_LED);
     
   if(Ticks==greenValue)
      output_low(GREEN_LED);
     
   if(Ticks==blueValue)
      output_low(BLUE_LED);

   set_timer0(128);
}
/************************************************************************
*                       Interrupción USART:                             *
************************************************************************/
#INT_RDA
void receivedUSARTData(){
   
   if(!ackFlag){
      while(RCIF){
         receivedData = RCREG;
         switch(ackStatus){
            case 0:
               if(receivedData == 0x53){
                   ackStatus = 1;
               }
               break;
            case 1:
               if(receivedData == 0x32){
                   ackFlag = 1;
                   sendAck();
               }
               break;
            default:
               ackStatus = 0;
               break;
         }
         
      }
   }else{
      while(RCIF){                                                    // Repite el proceso siempre que exista un dato en el buffer
         receivedData = RCREG;                                                  // Salva el dato recibido desde la USART.   
         
         
         switch(DMX_status){
            case DMX_WAIT_START:
               if(receivedData == 0x43){
                 
                  DMX_status = DMX_WAIT_CHANNEL;
                 
                  byteCounter = 0;
                  tmpChannelValue = 0;
                  tmpChannel = 0;
                 
                  byteCounter++;
                 
                  output_high(PIN_C0);
                  output_low(PIN_C1);
                  output_low(PIN_C2);
                  output_low(PIN_C3);
               }
               break;
               
            case DMX_WAIT_CHANNEL:
               if((receivedData > 0x2F) && (receivedData < 0x3A)){
                  byteCounter++;
                  tmpChannel = (tmpChannel * 10) + (receivedData - 48);
                 
                  if(byteCounter == 4){
                     DMX_status = DMX_WAIT_SEPARATOR;
                  }
                  output_low(PIN_C0);
                  output_high(PIN_C1);
                  output_low(PIN_C2);
                  output_low(PIN_C3);
                 
               }else{
                  DMX_status = DMX_WAIT_START;
               }
               break;
           
            case DMX_WAIT_SEPARATOR:
               if(receivedData == 0x4C){
                 
                  DMX_status = DMX_RECEIVE_DATA;
                  byteCounter++;
                 
                  output_low(PIN_C0);
                  output_low(PIN_C1);
                  output_high(PIN_C2);
                  output_low(PIN_C3);
               }else{
                  DMX_status = DMX_WAIT_START;
               }
               break;
           
            case DMX_RECEIVE_DATA:
               if((receivedData > 0x2F) && (receivedData < 0x3A)){
                  byteCounter++;
                  tmpChannelValue = (tmpChannelValue * 10) + (receivedData - 48);
                  if(byteCounter == 8){
                     
                     DMX_status = DMX_WAIT_START;
                     channelValue = tmpChannelValue;
                     selectedChannel = tmpChannel;
                     
                     setData();
                           
                     output_low(PIN_C0);
                     output_low(PIN_C1);
                     output_low(PIN_C2);
                     output_high(PIN_C3);
                  }
               }else{
                  DMX_status = DMX_WAIT_START;
               }
               break;
           
         }
      }
     
   }
   return;
   
}


/************************************************************************
*                       Programa Principal                              *
************************************************************************/
void main()
{
 
   set_tris_b(0);
   set_tris_c(0b11001111);   

   // Activamos las interrupciones de recepción del Timer0
   setup_timer_0(RTCC_8_BIT|RTCC_DIV_1);
   setup_timer_1(T1_DISABLED);
   setup_timer_2(T2_DISABLED,0,1);
   setup_timer_3(T3_DISABLED|T3_DIV_BY_1);

   // Configuración de la USART
   TX9=1;
   TXEN=1;
   TX9D=1;
   SPBRG=19;                                                                  // 230400bps en 20Mhz.
   SPBRGH=0;                                                                  // Byte alto para el BRG
   BRGH=1;                                                                    // High Speed
   BRG16=1;                                                                   // 16 bit BRG
   SYNC=0;                                                                    // Transmisión asíncrona
   SPEN=1;                                                                    // Activamos la USART
   RX9=0;                                                                     // 9 bit para la recepcion
   SREN=0;                                                                    // Desactiva recepción de un byte
   CREN=1;                                                                    // Recepción activada
   ADDEN=0;                                                                   // Desactivada la autodetección de dirección
   FERR=0;                                                                    // No hay error de frame con 1 se activa
   OERR=0;                                                                    // No hay error de overrun con 1 se activa
   
   
   int i =0;
   for(i=0;i<=3;i++){
      output_high(RED_LED);
      output_high(PIN_C0);
      output_high(PIN_C1);
      output_high(PIN_C2);
      output_high(PIN_C3);
      delay_ms(300);
      output_low(RED_LED);
      output_low(PIN_C0);
      output_low(PIN_C1);
      output_low(PIN_C2);
      output_low(PIN_C3);
      delay_ms(300);
   }
   
   enable_interrupts(INT_RDA);
   enable_interrupts(INT_TIMER0);
   enable_interrupts(GLOBAL);
   
   
   set_timer0(128);
   redValue = 0;
   greenValue = 0;
   blueValue = 0;
   
   
   while(TRUE){
     
   }
}
Título: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: carlangas123 en 16 de Marzo de 2012, 12:48:54
Hola, que tal estube leyendo todos los comentarios del asunto, y la verdad me interesa armar la interfaz para probar mi receptor DMX, les pediria por favor si pudiesen poner como queda el nuevo esquema con el DC-DC  y el opto para aislar el micro contra intereferencias. Saludos
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: jfsh2000 en 28 de Marzo de 2012, 17:35:31
Hola amigo muy buen trabajo ((:-)) ((:-)) ((:-))

Saludos
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: Fran95 en 25 de Mayo de 2012, 11:11:04
Hola, para que sirven los led de r1 a r8? cual seria el mejor codigo para utilizar finalmente?  soy nuevo, gracias, saludos
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: marcodifeo1 en 28 de Junio de 2013, 23:44:28
Hola, es un excelente proyecto, estoy trabajando en algo parecido pero con Transferencia Bulk.

Quería usar el codigo Interface_usb-dmx2.c para utilizar la parte de la comunicacion DMX del USART. Soy medianamente principiante en el tema de CCS y me topé con que hay muchas definiciones del tipo #byte y #bit, donde todas las variables, por ejemplo PORTA, PORTB, TXSTA, etc, las cuales no pude encontrar en la ayuda de CCS.

Como voy a utilizar un bootloader quería sacar estos direccionamientos a memoria, pero no se como CCS interpreta la función de cada variable.

Bueno, espero que puedan ayudarme.

Gracias y saludos!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: dinoelectro en 11 de Agosto de 2013, 13:29:23
hola compañeros he construido un adaptador USB DMX que funciona bien con freestyller (nunca se cuelga), el formato de comunicacion es DMX4ALL ASCII TRANSFER


(http://www.forosdeelectronica.com/gallery/files/2/1/0/8/3/6/pcb_-_usbdmx_adaptador_2_thumb.jpg) (http://www.forosdeelectronica.com/gallery/showimage.php?i=6896&c=member&imageuser=210836)

(http://www.forosdeelectronica.com/gallery/files/2/1/0/8/3/6/pcb_-usbdmx_adaptador_thumb.jpg) (http://www.forosdeelectronica.com/gallery/showimage.php?i=6895&c=member&imageuser=210836)

para mas informacion puedes revisar el siguiente link:

http://www.forosdeelectronica.com/f24/aporte-adaptador-usb-dmx-freestyler-pic18fxx50-102893/

Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: AKENAFAB en 11 de Agosto de 2013, 13:35:35
Felicitaciones compañero!

Tiene muy buena pinta! ((:-)) ((:-))

Gracias por compartir!!


Saludos. 8)
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: dinoelectro en 11 de Agosto de 2013, 14:20:10
Felicitaciones compañero!

Tiene muy buena pinta! ((:-)) ((:-))

Gracias por compartir!!


Saludos. 8)

Gracias AKENAFAB!!!  quiero aportar con el código fuente desarrollado en PIC CCS. por si desean ampliarlo y/o mejorarlo. la trama DMX es transmitida por medio del PIN TX del microcontrolador.

saludos!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: kaneda en 04 de Noviembre de 2013, 23:29:48
Hola amigos, estoy diseñando mi propia interfaz dmx, pero tengo una duda,  cuando reciben un dato, se procesa y se envía una nueva trama dmx... Pero que pasa si entra un nuevo dato mientras se está enviando la trama? Se pierde? Cada cuanto tiempo el software dmx control envía un nuevo dato?
 Muchas gracias, espero puedan ayudarme :)
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: stk500 en 05 de Noviembre de 2013, 01:03:19
Tu dice cuando se recibe un dato.....
el micro no procesa nada y en el protocolo DMX siempre hay un Receptor y un Emisor, creo que te daria cuenta que el protocologo trabaja a alta velocidad, 250,000 Kbaud, cuando envia dato lo esta enviando al o a los canales expecificos que tenga previo ya selecionado, los datos nunca se pierden,
Referente tambien a tu pregunta,
Cada cuantos Tiempo el Software DMX Control envia datos?
la respuesta es la misma de arriba.

Saludos
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: kaneda en 05 de Noviembre de 2013, 11:00:03
En realidad yo me refiero a la comunicación entre la pc y el transmisor. Es decir, la comunicación USB. Que sucede cuando se envía más de un dato por el puerto usb mientras el transmisor está enviando la trama dmx por la salida rs485?
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: sebasleclercq en 25 de Junio de 2014, 14:05:43
Hola compañeros! Estoy metiendome de a poco en el tema de los micros y soy iluminador desde hace años y la verdad los felicito y me intereso mucho su trabajo, es mas, ya estoy en la contruccion de mi propia interface. Ahora, me surgio una duda que creo que es realmente interesante. Nadie trato de ver que datos se envian el software de sunlight con la interface? Pregunto porque me pareceria mas que interesante poder hacer que la interface funcionara con dicho software. Espero ansioso su respuesta muchachos. Saludos!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: stk500 en 26 de Junio de 2014, 00:18:36
El Sunlight no tiene comparacio con MADRIX http://www.madrix.com/
y Funciona con un moton de Interface

Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: todopic en 28 de Junio de 2014, 10:05:00
Hola Amigos!, como dice Rafael, MADRIX es maravilloso!, lo empleo en un piso led, y los efectos generados son fabulosos!, además de las posibilidades de pacheo..   :mrgreen:
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: luis_manuel.ordaz en 19 de Diciembre de 2014, 02:21:25
excelente interfaz amigo solo le encontré un detalle, al cambiar de color o cambiar a cualquier función por medio del freestyler tiene un retardo(1 seg), lo cual no representa tanto problema para el caso de que solo se quiera cambiar de colores y funciones simples, pero al utilizar el scanner o una cabeza la función de mover en modo manual la luz, esto se convierte en un problema, ya que no responde inmediatamente y resulta sumamente complicado seguir un objetivo mediante la función de movimiento manual.
yo utilice un PIC18F4550 y un cristal de 19.9 MHZ, no se si el problema radique aquí en el cristal o sea algún error en el programa del pic, espero su ayuda, de antemano gracias.
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: stk500 en 19 de Diciembre de 2014, 07:02:12
Hola Luis Manuel, y Bienvenido a nuestros Foros Todopic,
de este projecto no se nada, pero en el codigo de programa ya debe estar el Cristal que usar y deberia usar ese, sino no va a funcionar como debe ser.

Saludos
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: mattfabiani en 06 de Enero de 2015, 19:27:57
Alguien tiene alguna mejora o actualzacion, esto comenzó en 2009 y estamos empezando el 2015, me gustaría armar esta placa!
Título: Re: Interfaz USB-DMX basada en DMX4ALL.
Publicado por: angulial en 16 de Enero de 2015, 04:05:46
Yo eestoy haciendo todo lo posible por hacer mi propia interfaz con los elementos que tengo a la mano, ya logre controlar la luz haciendo mis matrices de numeros manual, el problema es que no logro conectar la interfas a el programa de freestyler, quisiera saber si krhonos nieto me podria pasar este pdf http://www.dmx4all.de/media/manuals_en/DMX412_Mini-USB-DMX_en.pdf por que el link ya no te lleva al pdf o alguien me puede explicar con lujo de detalle las tramas a recibir y a enviar entre el microcontrolador y el programa, en el momento en el que me salga posteo el codigo digramas y mas... de antemano gracias por la informacion
Título: Re:Interfaz USB-DMX basada en DMX4ALL.
Publicado por: ElectronicaLuis en 14 de Noviembre de 2016, 15:10:50
Saludos kronos, un placer. E armado la interface dmx y me funciona, pero tengo el siguiente problema. Yo envio un movimiento cambio de gobo a la luz y fino lo hace, pero si dejo de enviar instrucciones a la luz, esta vuelve a su estado de TEST quisiera saber porque? Saludos
Título: Re:Interfaz USB-DMX basada en DMX4ALL.
Publicado por: locodelafonola en 13 de Marzo de 2017, 09:22:33
Hola gente querida
Fabrique la interfaz ., hace ya algun tiempo con el 18F2550
me funciona bien ., con el freestyler
Tuve que cambiar el disco de la compu ., y tengo problemas de la insatalacion de los drivers
El window 7 32b ., me da el error de firma del controlador
He desabilitado la fima digital ., pero igual me larga error ., aunque si lo reconose como "USB DMX"
Alguien tiene ., un instalador mejor .,  o hizo un .EXE para intalarlos
Desde ya muchas gracias .,  y espero sus respuestas