Haz una pregunta
  Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos
Foros Registrarse ¿Olvidaste tu contraseña?

Temas similares

06/09/2008 #1


PICs en aplicaciones industriales?
Que tal es el desempeño de los PIC's en aplicaciones industriales, como en el control de procesos de empaque, impresión, manejo de grandes motores, y aplicaciones típicas de la industria.

Y si son buenos que se debe tener en cuenta para su uso?

Gracias.
06/09/2008 #2


Holas

La verdad no te recomiedo para ese tipo de procesos industriales, es muy complicado manejarlos, porque el programa se colgaria a cada rato o se saltaria a otras partes y haria lo que no tiene que hacer, todo esto debido al ruido , y a lña interferencia que producen todas esas maquinarias en especial los motores en los arranques, introducen mucho armonicos, tendira que poner unos buenos filtro ante todo, y eso es bastante trabajo, y si camba algo en la industria tendria que cambiar los filtros
Para ese tipo de aplicaciones es mejor usar PLC son como los PICS pero mucho mas robustos sonj para aplicaciones industriales

Saludos Jairo
06/09/2008 #3
Moderador

Avatar de Chico3001

Para Microcontroladores en procesos industriales prefiero Atmel o Freescale...
06/09/2008 #4

Avatar de asherar

Fijate que ahora estoy trabajando en un banco de pruebas de un motor a explosión.
El equipo está ubicado a menos de 1 m de la bujía.
Uso un pic 12F675, dentro de una caja metálica conectada a tierra, alimentado con una fuente regulada independiente y optoacoplando todos los accesos al pic (entradas y salidas).
Actualmente no tengo "mayores" problemas, aunque costó bastante depurar el sistema.
El tema es delicado pero no imposible.
En general hay que dedicarle bastante tiempo al blindaje de alta frecuencias, al
optoacoplamiento y a la "tierra" (evitando lazos, y eligiendo con cuidado el punto
de conexión).
Saludos.
07/09/2008 #5


Que me recomiendan de los Intel 80c51 o similares.
07/09/2008 #6

Avatar de Meta

Mira aquí.

http://www.informaciónplc.net/
07/09/2008 #7


Jairo dijo:
Holas

La verdad no te recomiedo para ese tipo de procesos industriales, es muy complicado manejarlos, porque el programa se colgaria a cada rato o se saltaria a otras partes y haria lo que no tiene que hacer, todo esto debido al ruido , y a lña interferencia que producen todas esas maquinarias en especial los motores en los arranques, introducen mucho armonicos, tendira que poner unos buenos filtro ante todo, y eso es bastante trabajo, y si camba algo en la industria tendria que cambiar los filtros
Para ese tipo de aplicaciones es mejor usar PLC son como los PICS pero mucho mas robustos sonj para aplicaciones industriales

Saludos Jairo
¿Quién te ha dicho eso? si quieres date una vuelta por www.microladder.com
Lo puedes programar en lader y es un "microcontrolador 16F877 y 876" lo intalé en paralelo con un PLC y los dos funcionan correctamente.

Cualquier micro lo puedes hacer funcionar en procesos industriales. Lo que uno tiene bueno puede no ser tan bueno en otros y viceversa
07/09/2008 #8

Avatar de Eduardo

Re: PICs en aplicaciones industriales?
josmtosu25 dijo:
......
Y si son buenos que se debe tener en cuenta para su uso?
Hacer bien todo el resto del circuito + instalacion.

Es lo mismo que quisieras hacer un auto con prestaciones especiales y creyeras que habiendo elegido un buen motor el resto de la mecanica es de menor importancia y la puede hacer cualquier aprendiz.
28/09/2008 #9
Excluido


Alejandro Sherar dijo:
Fijate que ahora estoy trabajando en un banco de pruebas de un motor a explosión.
El equipo está ubicado a menos de 1 m de la bujía.
Uso un pic 12F675, dentro de una caja metálica conectada a tierra, alimentado con una fuente regulada independiente y optoacoplando todos los accesos al pic (entradas y salidas).
Actualmente no tengo "mayores" problemas, aunque costó bastante depurar el sistema.
El tema es delicado pero no imposible.
En general hay que dedicarle bastante tiempo al blindaje de alta frecuencias, al
optoacoplamiento y a la "tierra" (evitando lazos, y eligiendo con cuidado el punto
de conexión).
Saludos.
exacto: el micro es el micro, si le va a caer agua deben protegerlo del agua (obvio).
si van a trabajar en un ambiente ruidoso deben protegerlo del ruido (electrico obvio).
si va a trabajar en un ambiente muy caliente deben .................
y todas estas mismas OBVIEDADES.

decir que un PIC con la empresa y dedicacion que tiene atras no sirve para............
(o cualquier otro micro conocido )
son uds. los que no sirven para aplicarlo , pero no teman, eso se arregla con voluntad.



un circuito (agreguen si me equivoco) :

alimentacion
entradas
salidas
el micro.

bueno , la electronica es IMPRESIONANTE , hay mil , millones de cosas, y cada una para lo suyo, esxisten optos para las salidas.
filtros para las fuente s.
circuitos para las entradas.

en fin, no es lo mismo una cosa que optra , ya lo puse asiq ue termino.
saludos
10/12/2014 #10


PICs en la industria?........Si Señores!!!!
fernandob dijo: Ver Mensaje
exacto: el micro es el micro, si le va a caer agua deben protegerlo del agua (obvio).
si van a trabajar en un ambiente ruidoso deben protegerlo del ruido (electrico obvio).
si va a trabajar en un ambiente muy caliente deben .................
y todas estas mismas OBVIEDADES.

decir que un PIC con la empresa y dedicacion que tiene atras no sirve para............
(o cualquier otro micro conocido )
son uds. los que no sirven para aplicarlo , pero no teman, eso se arregla con voluntad.



un circuito (agreguen si me equivoco) :

alimentacion
entradas
salidas
el micro.

bueno , la electronica es IMPRESIONANTE , hay mil , millones de cosas, y cada una para lo suyo, esxisten optos para las salidas.
filtros para las fuente s.
circuitos para las entradas.

en fin, no es lo mismo una cosa que optra , ya lo puse asiq ue termino.
saludos
Saludos cordiales.

Estoy totalmente de acuerdo, se presentan muchos problemas al controlar cargas inductivas en AC con los PIC, pero con los ajustes necesarios se puede filtrar las perturbaciones y ruidos que generan los comportamientos inesperados (reseteos, colgadas y otros). Les comento que yo diseñe una controladora para una envasadora de productos alimenticios para una fábrica que tiene ambientes sumamente ruidosos (eléctricamente), la cual está gobernada por un PIC16F84A que inicialmente controlaba una secuencia de activación de motores y solenoides a través de CONTACTORES con bobinas de 220VAC/50Hz que a su vez estaban accionados por relés inversores simples de 12VDC-5A/250VAC activados por opto-transistores 4N25. Sin carga todo estaba genial, la secuencia y sensores respondían perfectamente, pero cuando realice las primeras pruebas de funcionamiento en la máquina NADA RESPONDIO COMO ESPERABA, el PIC se reiniciaba, los CONTACTORES se desconectaban, los sensores no eran atendidos por el micro aún utilizando interrupciones, en fin, nada salió bien. Después de varios días de investigación y pruebas decidí cambiar los 4N25 por MOC3011 (Opto-triac) y los contactores por TRIAC´s de acuerdo a la potencia controlada y todo se normalizó.
Desde mi punto de vista y habiendo pisado el terreno, opino que los que provocó el comportamiento anormal del PIC era la interferencia electromagnética (EMI) que generan las bobinas de los contactores y Relés (con todo y damper, snuber y demás). Por su parte los MOC detectan el paso por cero de la tensión AC para conmutar y eso ayuda bastante. Comentarles también que reparé varios equipos y maquinaria que tenian en su etapa de control a nuestros queridos PICs, asi que no debemos subestimarles. Aquí está la controladora ya instalada en la máquina y otras que desarrollé después con todo exito ya sin muchos inconvenientes.

Hasta luego.

Pdta.: Los ajustes a realizar son tanto en Software como en Hardware para el PIC.
Imágenes Adjuntas
Tipo de Archivo: jpg Envasadora.JPG (76,7 KB (Kilobytes), 119 visitas)
Tipo de Archivo: jpg Generador380VAC.JPG (100,6 KB (Kilobytes), 126 visitas)
10/12/2014 #11


Basta entrar a la página de microchip para ver que empresa es.
Basta luego ver la gama y variedad de chips que fabrica.
Hace cuantos años . . .
Que tengo que pensar o decir si un individuo que hizo un circuito y tiene problemas con este dice
Que integrado de porquería
En vez de reconocer que no supo solucionar el problema con el que se encontró.

Que les parece a ustedes más coherente ?
10/12/2014 #12

Avatar de torres.electronico

Las limitaciones se las da uno mismo si no lee las hojas de dstos y tiene un solido conocimiento de electronoca... vi personas qie son muy buenos interprwtando y escribiendo programas para micros, pero de elextronica cero... a tal punto que hasta vi implementar cargadores de celular como fuwntes... trafos con un puentw de diodos, etc etc...
tanto microchip, como avr, entre otros, dan gratuitamente pdf con recomendaciones de diseño electronoco (hardwsre o tecnicas de progrqmacion) parq hacer viable su producto con cualquier proyecto.
Saludos
12/12/2014 #13


Pues yo hasta que no los vi en la industria no me arriesgue a dar una opinión de ellos y de que si podían utilizarse en la industria "ruda", con las adecuaciones correctas y bien instalados. Después de que los vi funcionando en este cargador de baterías justo al lado de los filtros de armónicos y los mismos transformadores del cargador dije "todo es posible". Aquí estaban haciendo la instalación del banco de baterías para una subestación.

PD: El PIC16F877A es el que tiene la etiqueta blanca encima. La empresa que hizo la instalación del equipo no me quería dejar ver las placas (la mayoría del personal a capacitar era del departamento eléctrico, yo estaba de metiche con ellos como practicante y pues sabia un poco más de electrónica) cuando se retiró el personal de la empresa, los encargados de la subestación me ayudaron a abrir los cargadores y le “moví” la cinta y vi que era un PIC.
Imágenes Adjuntas
Tipo de Archivo: jpg PIC16F877A.jpg (356,0 KB (Kilobytes), 120 visitas)
Tipo de Archivo: jpg CAPACITORES Y TRANSFORMADORES.jpg (356,4 KB (Kilobytes), 104 visitas)
Tipo de Archivo: jpg BATERIAS.jpg (366,4 KB (Kilobytes), 105 visitas)
12/12/2014 #14

Avatar de palurdo

Bueno, yo soy de la opinión de que es perfectamente posible utilizar en industria un control con PIC, pero que jamás en la vida lo utilizaría para aplicaciones médicas o sanitarias serias (por ejemplo lo usaría para un oxímetro, pulsómetro, etc, y siempre con mis reservas y mil watchdogs y otros checks, pero no para una bomba de perfusión donde un fallo en el control de bombeo puede provocar una interrupción o una sobredosificación del tratamiento peligrando la vida del paciente).
12/12/2014 #15

Avatar de torres.electronico

palurdo dijo: Ver Mensaje
Bueno, yo soy de la opinión de que es perfectamente posible utilizar en industria un control con PIC, pero que jamás en la vida lo utilizaría para aplicaciones médicas o sanitarias serias (por ejemplo lo usaría para un oxímetro, pulsómetro, etc, y siempre con mis reservas y mil watchdogs y otros checks, pero no para una bomba de perfusión donde un fallo en el control de bombeo puede provocar una interrupción o una sobredosificación del tratamiento peligrando la vida del paciente).
Creo que no te hicistes un buen momento para leer lss ventajas y xaractetisticas de los DSPICs ...
13/12/2014 #16


palurdo dijo: Ver Mensaje
Bueno, yo soy de la opinión de que es perfectamente posible utilizar en industria un control con PIC, pero que jamás en la vida lo utilizaría para aplicaciones médicas o sanitarias serias (por ejemplo lo usaría para un oxímetro, pulsómetro, etc, y siempre con mis reservas y mil watchdogs y otros checks, pero no para una bomba de perfusión donde un fallo en el control de bombeo puede provocar una interrupción o una sobredosificación del tratamiento peligrando la vida del paciente).
por que ? . . Me gustaría una explicación . . . En que muchos aficionados usen quepic no quiere decir que ese ci sea una broma te haré una pregunta

---------- Actualizado después de 7 minutos ----------

Supongamos que necesitas hacer un retardo de 2 segundos para lo más delicado que te puedas imaginar en la vida .
que usaría ?
Un par de transistores ? Que son bastante inmunes a variaciones de tensión .?
Usaría un micro de la marca más prestigiosa que sólo grandes ingenieros saben programas . . . Pero depende de una tensión precisa de alimentación . . Como sabemos es todo un programa que corre y eso aumenta las posibilidades de falla o imprevisto . .
O usaría un ci que tenía un operacional o un económico timer programable ?

Que usaría ?


Que le da más confianza ?
La marca del chip o el profesional que lo elije ?

Un cordial saludo
13/12/2014 #17

Avatar de aguevara

Aplicacion Industrial
Tu lo has dicho saltamon23 ..amen hermano. Practicamente todos los fabricantes de semiconductores en sus datasheets usan la leyenda "This device is not intended for life support equipment" o el clasico "Do not use in life support devices" pero si asi fuera el caso creo que no tendriamos equipos medicos disponibles.
Lo unico realmente importante es hacer la seleccion correcta del dispositivo, recuerden que existen versiones de un mismo componente pero SI hay variaciones en cuanto a su performance segun si es linea militar, estandar industrial o medica. OJO con eso.

Saludos !!

---------- Actualizado después de 15 minutos ----------

Les dejo una fotos de la aplicacion de un PIC16F877 en una tarjeta controladora de temperatura para un equipo de aplicacion de poliurea marca Graco.
Graco para quien no lo sepa es el lider mundial en equipos de suministro y aplicacion de fluidos (pintura, lubricantes, adhesivos, sellos y recubrimientos etc etc)

Saludos
Imágenes Adjuntas
Tipo de Archivo: jpg GRACO.jpg (115,2 KB (Kilobytes), 86 visitas)
Tipo de Archivo: jpg PIC.jpg (75,3 KB (Kilobytes), 79 visitas)
13/12/2014 #18

Avatar de torres.electronico

saltamon23 dijo: Ver Mensaje

Que usaría ?


Que le da más confianza ?
La marca del chip o el profesional que lo elije ?

Un cordial saludo
en mi caso ninguna de las dos.. quizas si la pregunta fuwra de otra manera (la marca del chip o el que lo va programar) responderia el profesional que lo va programar...
Vallan a la pagina de micrchip y busquen todas las notas tecnicas sobre app medicas, automotrices y veran que el hardware el 99.9% de las veces no es el micro el problema, sino el hardwsre y programacion..
buen sabado para todos
13/12/2014 #19

Avatar de palurdo

torres.electronico dijo: Ver Mensaje
Creo que no te hicistes un buen momento para leer lss ventajas y xaractetisticas de los DSPICs ...
Bueno, me refiero a los que el núcleo está diseñado íntegramente por Microchip. O al menos a los clásicos. Los PIC32 son en realidad core MIPS por lo que ya sé que puedo esperar de ellos (cosas muy buenas, por supuesto). Me refiero más concretamente desde la serie PIC10 a los PIC18, considerando sobre todo los PIC16 que son los más usados para iniciarse en la programación de microcontroladores junto con los AVR.

saltamon23 dijo: Ver Mensaje
por que ? . . Me gustaría una explicación . . . En que muchos aficionados usen quepic no quiere decir que ese ci sea una broma te haré una pregunta.
No he dicho que sea una broma, pero todo el que ha visto la arquitectura de los PIC de 8 bits y la de otros micros de 8 bits, como el legendario 8051, se da cuenta que los PICs tienen una forma "peculiar" de programarse, muchas veces tirando de código escrito "con trucos" para funcionar en PIC cosa que no se necesita en otras arquitecturas, pero yo no estoy discutiendo de eso, sería como comparar un automóvil con cambio de marchas automático a uno de marchas manuales, según para qué cosas, el de cambio de marchas automático se han de hacer "con truco" como por ejemplo la salida en pendiente pronunciada.

saltamon23 dijo: Ver Mensaje
Que le da más confianza ?
La marca del chip o el profesional que lo elije ?

Un cordial saludo
Te cuento algo que me pasó hace muchos años. Diseñe un dispositivo que debía realizar ciertas tareas dentro de una máquina, una especie de autómata. El requerimiento es que esas tareas disponían de una configuración que debía permanecer cuando se apagaba el dispositivo y se volvía a encender. La configuración se guardaba en unas pocas variables como contadores, flags, etc. La programación la hice en un 16F84A funcionando a 4MHz.

A pesar de que programé la detección de reset por brownout para hacer un arranque en limpio del sistema, el micro se "colgaba" si el aparato se encendía antes de que la fuente se hubiera apagado del todo. Incluso el watchdog que se supone independiente del micro era invisible para este. Se solucionó aparentemente con un simple circuito que mantenía MCLEAR en estado bajo mientras la alimentación fuera menor de 4V.

Pero lo peor fue la retención de los datos. Los parámetro sólo se modificaban cuando el usuario accionaba cualquier tecla del teclado numérico, por lo que por cada pulsación, las variables se guardaban en la memoria EEPROM del micro, y en cada reset se volvían a leer. Poco tiempo después los operarios se empezaron a quejar de que los dispositivos se volvían inoperativos pasados unos días. La rutina de grabación de datos en EEPROM era la correcta y la de comprobación lo mismo, es decir, hasta que los datos de la EEPROM no fueran los mismos que los de los registros implicados el dispositivo no operaba normalmente o bien se proporcionaba un mensaje de error en display tras varios intentos fallidos de grabar en EEPROM (esto nunca pasó).

Testeando el sistema que tenía para recuperar el micro tras el apagado y encendido de éste, descubro sorprendido que aunque el programa del micro permanecía intacto en la FLASH y aparentemente se ejecutaba, los datos de la EEPROM habían variado, a veces un bit, a veces varios bytes. El glitch de alimentación del micro había corrompido la EEPROM, lo que producía que hubieran valores absurdos en las variables y el micro se colgase (como por ejemplo punteros indexando fuera de las tablas). Cuando pude comprobar que pasaba esto de manera bastante frecuente, consideré dos opciones. O bien usar una eeprom externa vía I2C o SPI para leer y grabar las variables, o insertar una combinación especial del teclado (que reproducía una condición determinada en el puerto de I/O) para que en caso de bloqueo, los valores de las variables pasasen a ser los programados en el código por defecto (volviendo a tener que configurar de nuevo el operario todo el dispositivo). Como era un diseño ya cerrado, es decir, que el hardware ya estaba en uso y sólo cabía una actualización de firmware, opté por lo segundo, conformando al cliente pero no se quedó demasiado contento ya que en no muy pocas veces el dispositivo no respondía como se esperaba que tuviera que responder.

Y me encuentro cómodo como sabeis programando PICs en asm, pero he visto fallar estrepitósamente código infalible en PICs que no fallaría en otros microcontroladores. Si una máquina industrial se bloquea, se puede volver a poner en estado de reset o se pueden implementar ciertas alarmas externas, pero hay sistemas que si paran, sería un desastre, como por ejemplo la refrigeración de la cámara de un reactor nuclear. He visto ascensores funcionando con PIC16F877 pero el sistema de frenado de emergencia era independiente controlado mediante disparo inercial (no estaba controlado por el pic).

Y por supuesto, eso de tener que estar usando truquitos de software o de hardware para que el PIC funcione en condiciones, no debería ser lo normal.

Y mi reflexión no tiene nada que ver con que se use para fines profesionales o amateurs.
14/12/2014 #20

Avatar de arrivaellobo

Sólo quería comentar que yo he visto PICs funcionando en tarjetas electrónicas que controlan ciertos aspectos de navegación en vehículos militares, aviones, tanques, buques, etc. Os dejo la foto para que lo veais. Ésta tarjeta en concreto va en un módulo que avisa al piloto del avión cuando le han disparado un misil y lo que hace es alertarle, así que creo que sí podemos confiar en los PIC para aplicaciones serias, siempre y cuando el diseño tanto hardware como software sea el apropiado claro.
¿Tienes una mejor respuesta a este tema? ¿Quieres hacerle una pregunta a nuestra comunidad y sus expertos? Registrate

Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO ©2011, Crawlability, Inc.