TODOPIC
Microcontroladores PIC => - Niple - => Mensaje iniciado por: Juan4kd en 27 de Febrero de 2013, 21:18:13
-
¿alguien me podra tirar un piolin?
Tengo el Niple 5.6 y me ha dado muchas satisfacciones, hasta ahora he hecho proyectos relativamente simples y ahora quiero usar el modulo Rx RWS 434 y el chip HT12D, y el correspondiente TX pero no tengo experiencia con esto y no me doy cuenta como conectarlo y como usarlo. En el manual del usuario no figura.
Desde ya muchas gracias por anticipado.
Juan Carlos
-
Perdon por mi ignorancia ¿que es el RWS 434?.
No será RS485 o RS232?
F.
-
Hola Fer_TACA
Gracias por responderme! El RWS-434 es el modulo receptor en RF que aparece en el Niple 5.6 cuando configuro el dispositivo RF, ahi aparece tambien el HT12D pero no me doy cuenta como conectarlo ni como llegan los datos..¿Hay que utilizar la UART?
Muchas Gracias, slaudos:
Juan Carlos
-
Buenos días a todos. Juan4kd: Estoy en el trabajo y no tengo muchos datos acá, pero hice un circuito, esquematico no real, donde el pic colocaba el dato de 4 bits luego de alimentar tanto al codificador como al trasmisor, y con el sexto bit del pic se producía el envio de los datos. Se puede omitir el manejo de la alimentación, ocupando así solo 5 bits del pic, eso permite manejar todo con pics de 8 pines. Los datos y habilitación usé inversores triger para eliminar ruidos y mejorar la estabilidad del circuito. En el deco y receptor el criterio es el mismo. Someramente es lo que hice y creo que funciona, fijate si te sirve la idea. Además en el datasheet están muy claros los esquemas para hacerlos, solo debés agregar el control del dato por el pic. Sería xolocar el dato, habilito envio, deshabilito envio, cambio datos y comienzo nuevamente. Creo recordar que el receptor retiene el ultimo dato.
-
Hola Fer_TACA
Gracias por responderme! El RWS-434 es el modulo receptor en RF que aparece en el Niple 5.6 cuando configuro el dispositivo RF, ahi aparece tambien el HT12D pero no me doy cuenta como conectarlo ni como llegan los datos..¿Hay que utilizar la UART?
Muchas Gracias, slaudos:
Juan Carlos
Te aconsejo que te descargues el ejercicio numero 4 de la seccion de descargas de la web de Niple.
A partir de ahi luego seguimos.
el link de las descargas: http://www.niplesoft.net/descargas.htm
F
-
Hola Fermin. Hola a todos nuevamente. Algo que noté en ese tutorial es que el TX no lleva el encoder propio del deco, por lo que al decodificador no llegarán los valores de las direcciones. La pregunta que hago es la siguiente: ¿Aún así reconocerá y decodificará el dato? Lo que desarrolle lo hice pensando que sin las adres no lo haría, y no veo como sin ellas validará lo llegado. De no ser así ¿podriamos estar leyendo ruido o me equivoco? Todo esto por lo que leí de lo critico de la relación entre osciladores RX y TX en cuanto a su resistencia determinante. Gracias por una respuesta que desde ya descuento.
-
Hola Santiago:
Ultimamente ando un poco espeso y despistado y no se si entiendo bien lo que indicas en tu ultimo post.
¿que tiene que ver el encoder del decodificador?
Algo se me está escapando. Claro que llevo un dia pesado. Me lo puedes aclarar un poco. Si no mañana lo vuelvo a leer a ver si esto mas despejado.
F.
-
Hola Fer, estamos por ahí tambien, con problemas que ocupan y derivan atención, es la vida. Lo que te decía es que el decodificador y el codificador están enlazados por una dirección de 8 bits, la que debe ser común a ambos. En el caso del manejo por Niple, no lo he utilizado aún en algún proyecto, el transmisor no recibe esas direcciones, pues no hay codificador presente, y por lo tanto no los trasmitirá. En el decodificador no estarán y por ello no debería poder validarlos, y de hecho cambiar las salidas paralelas, de no ser así pondría cualquier dato en ellas, no serviría para seguridad en CR de alarmas o eso. No los he trabajado con pics, pero sin ellos así se comportan. Espero haberme explicado bien, sino lo hago hasta que así quede. Me interesa pues es parte de algo que quiero encarar en el futuro. Gracias por tu inquietud y respuesta. Quedo a tu servicio en lo que pueda.
-
Mi problema es que no he trabajado con esos modulos, solamente lo poco que he leido así por encima para conocer como pueden funcionar.
No habia prestado atencion a lo del decodifcador. Ve que me toca seguir leyendo mas.
Asi que cuando me ponga un poco mas al día, veré que se pueda realizar.
F.
-
Por ahora ¡ Muchas gracias ! me han ayudado un monton..
Ya voy entendiendo como funciona... cuando lo tenga listo les reportare los resultados y lo que haya averiguado.
Muchas gracias, saludos.
Juan Carlos
-
Ok Juan4kd , con gusto te estaremos esperando para compartir en lo que se pueda. Una cosa que leí y se cae de maduro, no dejes pines de dir o dato al aire, aunqiue se dice posible, lo torna erratico al dato. Tambien lei que la relación entre los resistores del TR y el TX debe sr aproximado e 22 veces uno el otro. Por lo demás es simple y son confiable en su funcionamiento. Espero te salga todo a pedir de boca.
-
Por ahora ¡ Muchas gracias ! me han ayudado un monton..
Ya voy entendiendo como funciona... cuando lo tenga listo les reportare los resultados y lo que haya averiguado.
Muchas gracias, saludos.
Juan Carlos
Mwe alegro mucho que ta hayamos servido de ayuda.
Para eso solemos andar por aquí.
F.
-
Hola, buen día:
Los modulos TX y RX se comunican, encontre que no es necesario el integrado HT12E (codificador del transmisor) en el lado Tx porque el modulo Tx del Niple 5.6 genera el codigo.
Tambien ecncontre que las patas del HT12D (receptor) no es bueno que queden flotando, cuando las puse al + (el codigo que elegi es 11111111) comenzaron a comunicarse bien.
Por el momento el problema que aparece es otro: tengo que transmitir de un equipo y recibir en otro 3 bytes, segui las instrucciones del tutorial, la comunicacion funciona pero el modulo receptor del Niple 5.6 me mezcla los bytes recibidos en uno o 2 registros, y los sobreescribe, esto se ve porque durante la recepcion en el display aparecen sucesivos valores todo durante una sola ejecucion del modulo TX configurado para la transmision de los 3 bytes. Encontre que el modulo Tx del Niple para hacer una transmision de los 3 bytes hace 3 transmisiones separadas, se nota porque se producen 3 interrupciones separadas en el lado del Rx.
Ya llevo mas de dos dias haciendo distintas pruebas sin exito.
¿Alguien del foro ha tenido y solucionado dificultades parecidas?
Desde ya ¡Muchas Gracias!
Saludos:
Juan Carlos
-
Me imagino que para la recepcion al ser 3 bytes tendrás creados 3 registros diferentes e irás guardandolos segun los vayas recibiendo.
F.
-
Hola Fer
Si, tengo creados los 3 registros, empece haciendo lo que explica el tutorial al pie de la letra y aparecio esta falla, luego hice muchas otras pruebas sin exito... Quza me he equivocado en algo pero no me doy cuenta en que.
Saludos:
Juan carlos
-
¿Puedes adjuntar el proyecto que has realizado y te lo reviso a ver si encuentro algo?
F.
-
Hola, como están? Recien leo lo aportado y agradesco la aclaración que Juan4kd hace de la comunicación entre los modulos. Mi comentario es que el decoder lee y compara 3 veces el codigo y lo valida recien si es concordante. Lo que puede ocurrir es que se esté cambiando de codigo demasiado rapido, que no se sincronice por estar a velocidades diferentes, resistencias determinantes del clock no apropiadas, etc., insisten en la red que 47K y 1M son los apropiados o valores 22 veces mayor una de la otra, sin ello el dato leido no es bien decodificado. Estas son algunas causas probables, habran otras seguro. Niple contempla ese tiempo entre envio de un dato y otro? Cuanto es ese tiempo? No lo sé, pero a mi regreso veré si encuentro los datos. Un abrazo.
-
hola lucegiar2005:
Gracias por interesarte en mi problema...
Segui las instrucciones del Niple5.6 al configurar el dispositivo Rx, indica que el chip HT12D lleva una resistencia de 33K entre las patas 15 y 16. En cuanto a la resistencia de 1 MOhm no me doy cuenta donde tendria que ir, no encontre ninguna indicacion al respecto en el Niple ni en el Tutorial. No uso ningun chip en el Tx, al configurar el dispositivo el Niple no lo pide. El mismo modulo Tx del Niple genera el codigo de la validacion, al configurarlo hay que ingresar el codigo elegido de 8 bits, yo puse 11111111.
¿ Podria ser que la frecuencia del oscilador del HT12D no sea la correcta y por eso no funciona bien? Ahora pienso puedo probar con un potenciometro de 50 K e irlo ajustando a ver que pasa.
-
Hola: la resistencia de 1M la mencione solo como dato leido, va en el otro modulo. Probá con distintos valores de resistencia, 33K como dice Niple, 47K como aconsejan en la red, y trazá los resultados si mejoran. Hoy compré componentes y veo si en algún momento armo y pruebo. Ahora me voy a comer unos riñoncitos al vino a la casa de mi hija, por lo que ni pensar en inentarlo, jajajaja. Un abrazo
-
hola lucegiar2005:
¿Ricos los riñoncitos al vino?
Ensaye reemplazando la resistencia de 33K con un potenciometro pre set de 50 K en el proyotipo y probe de cambiar los valores de la resistencia entre 30 y 50 K, si esta demasiado alejado de los 33 K deja de funcionar, entre 33 y 40y algo funciona pero siempre igual, es decir con la mima falla. Se puede conclir que no es un problema de la sincronizacion del HT12D.
No se como se debe hacer en el foro para enviarte circuitos e imagenes del Nipl o el archivo .NPL
Desde ya Muchas gracias, saludos:
Juan Carlos
-
Para adjuntar archivos, debajo de donde rellenas el mensaje te aparece "opciones adicionales"
Click y se te abre unas opciones y das a examinar para adjuntar el archivio o imagen.
Pero fijate en el tamaño y tipo de archivo/imagen que quieras adjuntar.
Si ocupan mas que el tamaño permitido o lo comprimes o lo tienes que alojar en algun servidor externo al foro com 4shared o similar.
F.
-
Hola gonte, como están? Juan4kd los riñoncitos de maravilla, lo que me costo despertar esta mañana para los laborales fue por el riego proporcionado, jajaja. En fin, darse los gustos en vida tiene sus consecuencias. Te comento lo que, si alcanzo el finde, haré en una board:
1- armar el circuito acorde al datasheet y comprobar que se cominiquen correctamente.
2- Reemplazo los 4 bits de datos por las salidas o entradas del pic (donde pongo o leo el dato trasmitido)
3- Con un pin más del pic manejo el ET y VD (trasmitir y dato valido).
La idea es que las direcciones sean iguales siempre, pongo los datos y habilito trasmision por un tiempo, enviando los datos escritos. Cuando en el receptor recibo un dato valido, indicado en VD, lo copio a un registro para su uso. Habrá que ver el manejo de los registros para poner cada lectura en uno distinto o sobreescribir según corresponda. Asegurando el funcionamiento sin el pic se limita los errores al codigo de programa. Veamos que sale por ahí. Dentro de Niple no puedo variar nada, así podré jugar con tiempos y modos. Es una idea. Eso sí, HT12x en ambos circuitos.
-
Hola lucegiar2005
Entiendo la idea, me parece buena pero lo que se me escapa es lo siguiente ¿los 4 pin de datos del HT12x llevan 1 solo bit cada uno?, ¿como se hace con el Niple para transmitir y recibir la palabras de 8 bits y mas aun cuando son varias palabras?.
No se como lo hace Niple, no me he puesto a analizar el listado Assembler porque no soy ducho para nada con el assembler y no me da el tiempo como para ponerme a estudiar el Assembler del PIC.
En el tutorial, para recibir, solo usa 3 pines para datos del HT12D y el D4 lo usa para producir la interrupcion por RB0, y esto funciona, transmite y recibe los datos, solo que en el lado del receptor los datos recibidos no los acomoda en forma correcta en las registros que se configuraron en el dispositivo Rx.
Estoy tratando de buscarle alguna vuelta con el mismo Niple 5.6, quiza hacer 3 transmisiones separadas de 1 byte cada una y recibirlas en 3 veces o algo asi, pero se complica porque el receptor usa siempre la misma interrupcion por RB0.
Quiza Jorge Cano sepa algun rebusque como esquivar el problema, ¡el Niple es tan util y ahorra tanto tiempo al programar PICs!
Desde ya Muchas Gracias, saludos:
Juan Carlos
-
Hola a la concurrencia. Juan4kd La idea es más o menos así, los 4 de datos son dato y el quinto, RB0, obtiene una lectura 1 cada vez que se produce una trasmición valida. Con 1 en RB0 se leen y copian los 4bits recibidos a un registro, "lectura" por ej., dependiendo de una bandera indica si en el nible bajo o alto, completando 8 bits del byt. Imagino que lo hace de este modo siempre pues es el unico modo que encuentro.
Un contador me va diciendo en que palabra pondrá esos bits, y su reinicio lleva a comenzar por el primer registro. Tambien podemos con tres trasmisiones dar valor al contador y manejar la distribución de los datos en los registros. Todo depende de cuanta velocidad nececites, ¿para que nececitas esto?, parece complicado pero hasta no probar no lo descarto, debe andar. En el trasmisor es lo mismo pero copio los datos en los registros a enviar y en los nibles correspondientes. Un abrazo
-
Juan Carlos,
¿vas a adjuntar los archivos para revisarlos?
F.
-
Hola TACA: Buenas Tardes
Adjunto el archivo "remoto.NPL" solo que le cambie el atributo a .txt para que lo acepte el foro, (no figura el atributo .NPL antre los aceptados) lo que tenes que hacer es al archivo remoto.txtx cambiarle la terminacion por .NPL y verlo en el Niple, esta hecho con Niple 5.6, el micro es un PIC16F877A corriendo a 20 Mhz, el display es un LCD de 2 x16
Tiene 1 resistro de 16 Bytes (bolsa_hi y bolsa_lo) y uno de 8 bytes (lote)
¿Hace falta el circuito electrico?
Muchas gracias por todo lo que hacen, saludos:
Juan Carlos
-
Hola Juan Carlos,
mira he revisado lo que has adjuntado y en principio no veo nada raro en el programa.
Solo un detalle y no digo que con esto se solucione y que tenga nada que ver con lo que te pasa. Te explicaré que alguna vez tuve y otras personas tuvieron problemas con la presentacion de los datos en el LCD. Quizas sea es ele problema y no sea del envio de datos.
Normalmente que yo recuerde parece ser que Niple tiene o tenia optimizada la rutina de presentacion de datos para ser usado el LCD con el puerto B. Veo que tu has utilizado el puerto D. No se si puedes cambiarlo y probar a ver si se soluciona el problema. Ojo que no digo que sea este el caso, pues para mi daría lo mismo el utilizar uno u otro puerto.
Como no dices nada de los pines del puerto B, me supongo que estaras utilizandolos para otras cosas. De todas forma probaria por si acaso.
F.
-
Hola TACA: Buen día.
Hice la prueba y no mejoro. El display LCD siempe anduvo bien.
Hice un ensayo transmitiendo y recibiendo 1 solo byte y anda "de 10" lo transmite, lo recibe y presenta bien, sin errores, adjunto el archivo, recibe 1 solo byte y depues lo reproduce en 2 registros mas, lo hice solo para probar la presentacion en el display, tiene algunas desprolijidades, lo adjunto igual que el anterior, es el "remoto_4.NPL" solo que le cambie el atributo a .txt para que lo acepte el foro, al archivo remoto_4.txt hay que cambiarle la terminacion por .NPL y verlo en el Niple, esta hecho con Niple 5.6, el micro es un PIC16F877A corriendo a 20 Mhz, el display es un LCD Topway de 2 x16 comun.
Transmite y recibe bien 1 solo registro, cuando hay mas de uno solo aparecen los problemas.
Esto me hace pensar que no es un problema del Hard y que el Niple esta bien desarrollado, es mas, me parece un trabajo monumental de Jorge Cano y su gente, la falla es solo algun detalle que falta encontrar, puede haber un error mio al emplear el modulo de recepcion o de transmision del Niple o bien podria ser un "bugg" menor en alguno de los modulos.
Muchas gracias por la atencion a este usuario...
Saludos a todos:
Juan Carlos
-
Hola TACA: Buen día.
Despues de muchas pruebas "encontre una vuelta", tal vez no sea la mejor solucion pero la prueba funciono mas o menos bien.
En el programa del transmisor hice 3 transmisiones separadas por un temporizador de 2 seg (seguro que tambien anda con menos tiempo) entre si, cada transmision con 1 solo byte cada una y desactive las interrupcoiones durante todo el ciclo de transmision.
En el Modulo receptor puse 1 solo registro "borrador" y en la rutina de la interrupcion puse 2 registros, el de actualizar y un puntero que toma valores 1, 2 o 3, despues del fin de cada interrupcion y en el programa principal segun lo que indique el puntero se copia el reistro "borrador" a cada uno de los 3 registros del programa.
Adjunto los 2 programas del Niple como colaboracion al foro, por favor tengan en cuenta que son pruebas, no estan pulidos ni optimizados asi que se van a encontrar con algunas desprolijidades como ser registros declarados que no se usan etc..
Los subo como archivos .txt, porque el foro no acepta los archivos . NPL, despues de bajarlos, hay reemplzar el atributo .txt por .NPL y se abren con el Niple
Saludos a todos:
Juan Carlos
-
Hasta esta tarde no puedo revisarlos.
Cuando lo haga te informo del resultado.
F.
-
Bueno mira he revisao los proyectos que has posteados y no veo nada raro que pueda no funcionar.
Lo mismo sucedia con el el primer proyecto que adjuntaste.
No se que puede estar pasando.
Como ahora tengo un poquito mas de tiempo, intentaré repasarlos de manera concienzuda a ver si encuentro por que puedes estar leyendo los valores distorsionados en el primer proyecto.
Si encuentro alguna cosa que pueda estar molestando te informaré.
F.
-
Buenas noches a todos. Reapresco por acá, que aunque he estado mirando no esa mucho lo que he podido hacer. Por suerte parece que está casi terminado, felicidades Juan Carlo. De todos modos dejo algo que alcancé a programar pero no ha probar, por lo que no se si funcionen. Comento los funcionamientos de ambas: El trasmisor coloca los 4 bits de cada nible de cada registro en RA6, RA7,RA0 y RA1 y en ese orden, y con RB1 en 1 los trasmite durante x tiempo, secuencialmente y sigue con igual proceso hasta trasmitir los 3 registros. Cabe aclarar que quiero modificar para el envio de datos modificados unicamente. El receptor lee los datos recibidos y copia a temporal, cuando se completan ambos nibles del temporal los copia al registro correspondiente, los convierte a BCD y los muestra. En TX RB0 cuenta los paquetes, en RX lleva a la lectura cada ves que VT se pone a 1 y permanece hasta que valga 0, evitando lecturas sucecivas incorrectas. Como debo hacer las placas no he podido probar el funcionamiento. Busco que el mismo codigo sirva tanto para envios alambricos o no, manejando unicamente los deco-code. Un abrazo
-
Hola lucengiar2005:
Para este trabajo construi los 2 prototipos, armados en plaquetas, asi que los programas que postie estan probados y corren bien en los microcontroladors PIC en tiempo real, no en simuladores. Todas las pruebas estan hechas sobre los 2 prototipos Tx y Rx
Segui adelante con las pruebas y elimine los retardos de 2 seg en la transmision igual siguio funcionando bien, todo esta programado en el Niple 5.6, asi que si alguien los quiere usar, se pueden eliminar los retardos del programa del Tx.
Estoy mirando tus sugerencias pero no alcanzo a entender del todo bien como debe funcionar. ¿Seria una mejora a los programas que postie?
Desde ya ¡¡ Muchas Gracias por tu atencion!!
Juan Carlos
-
Hola a todos, como están. Juan Carlos me alegra que lo hayas logrado y te pido disculpas por lo poco aportado, pero el hombre propone y Dios dispone. De todos modos seguiré con el comenzado, no sé si sea una mejora, no creo si ya está funcionando, solo que ai llega a trabajar como quiero va a servir con cualquier medio de trasmisión que se disponga. Lo he hecho con un micro distinto para hacer las placas y probarlos bien, no tengo como probarlos simulando, y no me sirve armarlos usando un pic 877, pero el codigo que funcione será de facil aplicación a cualquier micro. Con el 628a me permite realizar los proyectos pequeños y no tanto. Un abrazo.
-
Hola a todos:
Ha comprado la actualizacion del Niple5.6 Rev 3, ¡¡funciona muy bien !!, es un lujo, vale la pena.
Algunos de los problemas que tuve con la comunicacion por RF estan resueltos con mas elegancia de lo que pude hacer con la Rev 0. El modulo RF Tx, ¡de 10!
¿Alguien del foro sabe como se utiliza el modulo Rx que aparece con un diamante de pregunta por el bit "rx_ok?"? No me doy cuenta como usarlo. en mi caso no tengo implementado el canal de retorno, solo el de ida: un equipo transmite y el otro recibe. El manual que baje del sitio Niple no dice nada al respecto.
El receptor recibe pero no consigo que meta los 3 bytes en las 3 variables, las pone siempre en la misma, la va sobreescribiendo ¿Alguien sabe como se puede manejar esto con la Rev 3? si utilizo el metodo que desarrolle con la Rev 0 separa los 3 bytes pero no es nada elegante y lleva un monton de bloques.
Muchas gracias, Feliz dia del Trabajador a todos.
Juan Carlos
-
Probá que TX haga 3 trasmisiones sucesivas y en el receptor implementá un contador que a cada recepción se incremente, según el valor de este se indica cual registro usar como almacenamiento del dato. Lo que se me ocurre es entre trasmisiones copiar el valor del registro declarado en el modulo RX al registro indexado, así si cont=0 el dato se copia en dato_0, si cont=1 -->dato_1 y si cont=2-->dato_2 y reset de cont, asi´el proximo se guardará en dato_0 y se rrepite.
-
Hola luceguiar2005:
Muchas gracias por la atencion.
La forma que me sugeris es la forma en que hice funcionar la comunicacion con el Niple 5.6 Rev 0.
El Niple 5.6 Rev 3 viene arreglado y mucho mas completo asi que con 1 solo bloque de transmision paso los 3 bytes bien. El lado TX esta resuelto
Lo que me falta es acomodar el bloque Rx porque no se como se usa y no encuentro nada en el manual. Con las mejoras que tiene esta revision seguramente no hace falta poner el contador ni nada de eso para y pasar los 3 bytes sin sobreescribir, pero no le he podido encontrar la vuelta al Bit "rx_ok".
Desde ya Muchas Gracias y feliz dia del trabajador a todos!!!
Juan Carlos
-
Hola Juan Carlos, espero estés bien. Declaraste los 3 registros para la recepción y la interrupción por flanco ascendente? porque si es así y no funciona deberías comunicarselo a Jorge Cano o a Lucas Palomba. En oportunidades dejar de hacerlo modular y darle a pulso puede ser buena idea. Si te funcionó con el 5.6.0 deberías probar igual modo con este. Un abrazo
-
Hola a todos:
Por el momento me voy arreglando recibiendo cada registro por separado..
¿Alguien me puede dar una ayudita?
¿Como hay que utilizar el diamante de condicion "bit_rx_ok=1" que aparece automaticamente al insertar el bloque recibir comunicaciones RF? ¿Adonde mando el "No"? ¿Adonde el "si"? si lo borro aparece un error de compilacion.
Muchas gracias a todos:
Juan Carlos
-
Si bien no he trabajado con el modulo resulta evidente que se trata de la condición if - them, o si-sino, donde pones una acción a realizar cuando el valor de lo recibido es valido, ahí y con un contador podes copiar, por ejemplo, el registro recibido a otro de una serie, lo que podría solucionar tu problema, Ej. Si es valido y si el contador = 0 ---> copiar dato a copia_0 y sumar 1 a contador, si valido y si el contador = 1 ---> copiar dato a copia_1 y sumar 1 a contador, y en el ultimo no sumo sino que reset del contador, si no es valido pregunto nuevamente. No me contestaste si declaraste igual cantidad de registros para la trasmición y recepción de los datos. Un abrazo
-
Hola Lucegiar2005
Pido disculpas por haber "desaparecido" tanto tiempo,
Paso a responder, es cierto, es una condicion "If Then", lo que no encuentro en el manual del Niple ni en el foro es alguna indicacion del correcto uso de esta condicion ¿Como fue pensada?, yo en mi trabajo conecte las 2 salidas del diamante de preguntas a la misma salida, lo que es una perogrullada pero no encontre otra cosa y asi funciono, si borro el diamante me da un error de compilacion.
Termine el trabajo del cliente y la comunicacion funciona bien, esta todo hecho en NIPL 5.6 pero no lo pude hacer en la forma que se podria entender de la informacion que dispongo del Niple, sino con un "rebusque" distinto. Si le llega a servir a alguien no tengo inconveniente en poner el "rebusque" a disposicion de todos.
El enlace es unidireccional y envia una palabra de 8 bits y luego una de 16 bits cada vez que se actua el boton en el lado del transmisor.
Ahora tengo un problema con el cliente porque a veces entran interferecias electromagneticas que falsean las palabras recibidas. Esto podria estar conectado con la pregunta anterior respecto de este registro o bit que indica una recepcion correcta o no, pero no encuentro ninguna indicacion de como configurar y utilizar esta condicion "if Then" en el Niple. Quza Jorge pueda darme alguna indicacion de como fue pensado el modulo.
Al no tener un canal de retorno se me ocurre como una salida posible que podria transmitir 2 o 3 veces la misma palabra digital y descartar las que aparezcan corrompidas, pero no estoy seguro que esto sea un buen metodo.
¿A alguien se le ocurre algo mejor?
Desde ya muchas gracias a todo el foro y en especia a Lucegiar
-
Hola Juan4kd, un gusto leerte. Lo primero que te comento es que no se si estoy en lo correcto, entiendo que en la comparación de un evento has dado salida si es verdad a una parte del codigo, y si es falso al mismo punto del programa, si es así carecede toda lógica, analisado como un salto condicional, voy a xxx si es verdad y a yyy si es falso, no tiene función si salta a xxx en ambos casos. Si lo eliminas y conectas la salida del anterior con la entrada del posterior dará el mismo resultado, cualquiera sea el resultado será lo mismo a ejecutar. Una condición "Si, si no" es eso, si verdad hago esto (.....), si no hago esto otro (.....), de ese modo está pensado siempre que se implemente en cualquier lenguaje.
Lo que tu llamas rebusque es parte de la programación, puede ser más o menos vistoso, pero si funciona el código es valido. El algoritmo de una solución varía según quien lo implemente, todos pensamos similar pero resolvemos de distinto modo, y todos son validos si llegan a buen puerto.
Cuando hablas de un registro de 16 bits imagino que son dos registros de 8 cada uno, enviados por el trasmisor como tal, tendía que ver el codigo, de todos modos si usaste deco HT12 el mismo comprueba en 3 oportunidades si es correcto el codigo por igualdad, recien entonces valida, las 3 veces debes ser iguales según entiendo, con lo que hace lo que te propones. Podrías probar con un pote y variar la R determinante de la velocidad, o probar filtrar la entrada cuidando este aspecto, un pote y un capacitor y variar hasta encontrar la mejor relación señal - constante tiempo.
Espero algo de todo esto te sirva para solucionar y definir el programa. Un abrazo
Nota: No te encierres en como fue pensado Niple, es un programa exelente pero está basado en otro lenguaje, te permite realizar rapida y confiadamente, pero si lees de C o C++, o cualquier otro, encontraras que la sintaxis difiere en los distintos lenguajes, pero cuando lo llevas al ansambler un salto condicional es lo mismo para todos, la condición dentro del mismo cambia pero se ejecuta del mismo modo, a una dirección a otra. Todo sirve para entender más a Niple.
-
Hola lucegiar2005:
Sigo con las dudas, entiendo como funcionan las comparaciones, la uso habitualmente, pero en este caso no me doy cuenta que hacer, para mi todavia no esta claro y necesito mejorar la recepcion en un trabajo para un cliente.
Adjunto la captura de la pantalla cuando se instala el bloque de recepcion por RF tal como aparece metido dentro de la interrupcion por RB0. Ahi se ve el diamante de preguna ¿rx_ok=1?. Esto esta pensado para ser usado de alguna forma que desconozco y tampoco encuentro en ningun lado la informacion pertinente.
Hasta ahora estoy utilizando el bloque de recepcion "a lo bruto" para salir del paso, pero creo que esta parte del Niple esta bien pensada por Jorge y su gente y que lo que estoy haciendo es un desperdicio y que puedo perfeccionar mis programas ya que tengo problemas con las interferencias electromagneticas que me corrompen los datos transmitidas de vez en cuando (no siempre).
Me falta la informacion de ¿Que indica este bit rx_ok? ¿en que casos se va a 1 y cuales se va a 0? Si no tengo un canal de retorno, este bit ¿indica algo que se puede usar? ¿en que forma?.
Desde ya muchas gracias por la atencion del foro y los consejos.
Saludos.
-
El bit que compara indica si se realizo bien o no la recepción, si se recepcionó correctamente continua con el programa, si no realizá una nueva lectura para validar el dato, esa es la acción que estimo nececitas.
Nota: dale unos miliseg. antes de comprobar Rb0 para formar un filtro de ruido que haga erratica la interrupción.