TODOPIC
Misceláneas - Interés General => Uso y aplicaciones de los PIC / Curiosidades electrónicas => Mensaje iniciado por: BrunoF en 17 de Marzo de 2007, 23:35:27
-
Bueno, parece que posiblemente me surgirá un trabajo para automatización, control y monitoreo de una fábrica de tamaño mediano.
Tengo varias dudas, que espero puedan responderme personas con experiencia y conocimientos en el tema.
Mi principal preocupación es que "el jefe" me preguntó si conocía los protocolos y conectores standart utilizados en el mundo para hacer "compatible" en el futuro el sistema a desarrollar con los existentes.
Mi respuesta a su pregunta fué: "No sé ni de qué me estás hablando...por las dudas, que te recontra".
Entonces:
¿Existen conectores y protocolos standart para asegurar que mi sistema será compatible con los que se usan en la industria?
Estoy seguro de que si. La pregunta entonces es ¿cuál elijo, por qué, diferencias entre uno y otros, y dónde estudio sobre el tema?
Gracias.
-
Usá el buscador pibe .... :D :D :D
Hola Bruno ! :)
Sé que hay una tabla que te muestra los pro y contras de todos los protocolos de interconexión, que no recuerdo dónde la ví y además, tengo entendido que el óptimo (o el más usado) para la industria es el RS458, dado las distancias que podés cubrir, como la cantidad de periféricos que podés "colgar" del bus.
Pero más allá de eso, entré para felicitarte por el trabajo y desearte que te resulte de la mejor manera.
Y si en algo puedo sumar, acá voy a estar.
Saludos
Mario
-
jejeje uhh el peso de las reglas del foro recae sobre mi!
Debo decir que no busque porque ni siquiera sé qué es lo que debería estar buscando.
Sé que está el X-10 que es por la linea de 220V, y vi un par más gracias al sr. Google, pero soy un ignorante completo del tema.
Te agradezco que mencionaras al menos un protocolo, voy a esturiar sobre el tema.
Gracias Mario!
Un abrazo.
-
El bus CAN está de moda ahora en la industria.
Suerte!!! ;)
-
Hola Bruno:
Te comento un poco:
Sobre conectores no hay mucho de standart ,mas que el 232 clásico ,el resto es en función del equipo.-
Protocolos hay muchisimos ,el mas difundido o por lo menos mas comentado y bastante ácil de implementar es el modbus.-
Para comunicarse entre equipos (nivel físico) seguramente el 485 es el mas difundido.-
Pero todo esto que te digo cambia según el adepto a cada caso ,alguien comentará sobre fibra óptica ,otros sobre TCP/IP ,otros te diran que el profibus o el CANbus son los protocolos de facto ,pero todo pasa por la necesidad de cada uno.-
Saludos
Jorge
-
hola BrunoF, mi experiencia es que todos estos equipos ya estan hechos, osea normalmenta la industria compra estos paquetes de automatizacion en el cual tu solo eres programador de variables u operador. En la industria donde trabajo acaban de contratar a Mitsubishi para monitorear el funcionamiento de las autoclaves de esterilizado, y este sistema es estructurado y permite ampliarlo, y la programacion de los ambiente es bajo leader, como si fuera un PLC.
conclusion: creo que deberias investigar sobre el proveedor del sistema existente y de alli partir tu investigacion al respecto, porque existen varios protocolos conocidos, pero hay empresas que basados en estos crean los propios. saludos
-
Felicitaciones pibe!
Mira, yo no conozco mucho. Pero la planta de Cargill que hay por aca (gigantesca) usa CanBus (o Bus Can) para interconectar PLCs y algunas placas con uC que arma el capo de mantenimiento.
Saludos, y avanti!
-
Felicitaciones Bruno.
Creo que lo mejor para no quedar aislado, es evitar comprar equipos con protocolos propietarios, y en lo posible pedir que tengan 2 o más protocolos estandar.
En la empresa de ingeniería en que estoy, le trabajamos a varias empresas en el área petroquímica, el ModBus y el CanBus son los más usados, y todo lo que compran, además de cualquier otro protocolo, piden que incluya una conexión de este tipo.
Salud 8)
-
Hola amigo Bruno!!
Hace un tiempo que no trabajo en la automatización industrial. Pero aun así estaba dando y va a dar mucho el protocolo OPC http://www.opcfoundation.org/
---------------------------- Información de la wikipedia -----------------------------------
El bus OPC (OLE for Process Control) es un estándar de comunicación en el campo del control y supervisión de procesos. Este estándar permite que diferentes fuentes de datos envíen datos a un mismo servidor OPC, al que a su vez podrán conectarse diferentes programas compatibles con dicho estándar. De este modo se elimina la necesidad de que todos los programas cuenten con drivers para dialogar con múltiples fuentes de datos, basta que tengan un driver OPC.
En realidad OPC es un conjunto de protocolos entre los que podemos destacar los siguientes:
* OPC-DA (Data Access).- El original, sirve para el intercambio de datos a tiempo real entre servidores y clientes.
* OPC-AE (Alarms & Events).- Proporciona alarmas y notificaciones de eventos.
* OPC B (Batch).- Útil en procesos discontinuos.
* OPC DX (Data eXchange).- Proporciona interoperabilidad entre varios servidores.
* OPC HDA (Historical Data Access).- Acceso histórico a datos OPC.
* OPC S (Security).- Especifica cómo controlar el acceso de los clientes a los servidores.
* OPC XML-DA (XML Data Access).- Es una combinación de OPC-XML (eXtensible Markup Language) y OPC-DA.
* OPC CD (Complex Data).- Permite a los servidores exponer y describir tipos de datos más complicados en forma de estructuras binarias y documentos XML.
Este estandar está siendo mantenido por la Fundación OPC.
Entre las desventajas de este estándar podemos mencionar el problema de la seguridad, que aún no está resuelto y su dependencia del mundo Windows.
-------------------------------------------------------------------------------------------
Siempre he querido conocer mucho mejor este tema, pero es lo que pasa siempre, no hay tiempo ni tanto dinero :(
Depende de la complejidad de la automatización a realizar se necesitará más. Como ya han comentado el CANBUS esta muy de moda. Pero también está el MODBUS, PROFIBUS, OPC (Ya nombrado), SecurityBUS (este último es de PILZ, lider en automatizaciones de seguridad)
Por ejemplo en esta foto que adjunto de uno de los trabajos en lo que estube estaba controlado por Automatas Omron, varias Pantallas táctiles y un PC con el CX Supervisor (SCADA OMRON). Y todo estaba comunicado con RS485.
Depende de la complejidad de lo que controlas, se necesitara mas velocidad de transferencia en los protocolos. Cuanto más veloces más caros.
Saludos!
Diego J.
-
Bruno, hace tiempo estuve leyendo sobre el tema y espero mi pequeña experiencia te sirva de base para arrancar.
Hay que definir qué se entiende por protocolo estandar. Por un lado está la capa física y por otro lado la capa de red/enlace y el protocolo en sí.
Son muy usados como capa física, el RS485 (este debe tener al menos el 90% de uso) y luego le siguen el can bus, rs232 y otros.
En cuanto al protocolo de más alto nivel, se usa ModBus, Profibus y propietarios.
En su momento de Profibus no conseguí mucha información y según se comentó en más de un lado resolver un esclavo es algo bastante complicado, tanto es así que Siemens tiene un chip que gestiona esta parte del problema (y según recuerdo salen como 20 dólares cada chip). EL modo master de profibus es bastante más complejo (y de hecho en su momento no conseguí información fiable al respecto) y es realizado con una PC + hardware específico o bien un PLC.
Profibus también viene con interfaz ethernet y se llama Profinet.
El modbus es bastante más simple pero nunca lo he usado.
En mi caso, y dado el escaso tiempo de que disponía, terminé usando el protocolo "maunix" jeje, y asunto solucionado.
Hacer cosas compatibles con estándares lleva mucho tiempo, mucho esfuerzo y realmente se debe ganar mucho dinero (o vender cientos) para que se justifique. Les llaman estándares abiertos o cosa por el estilo pero la realidad es que para conseguir información realmente técnica (y no la masticada por alguien en alguna página web con un par de dibujitos) hay que poner plata. Son estándares abiertos, te los dan si los pedis pero tenés que pagar (y acá ya no tengo ni idea cuanto).
Por ejemplo, las normas ISO son abiertas, no son normas cerradas para el público pero para tener cada papelito que haga referencia a cada una debes poner 20, 50, 200 , 300 dólares... y te aseguro que con un solo papel (el cual hace referencia a otros 20 los cuales a su vez invocan a otros 20) no haces nada.
Tal vez no te dí la solución a tu problema, tal vez solo te transmití la frustración que sentí en ese momento cuando me ví con toda esa maraña de estándares, poco documentados y donde siempre terminaba cayendo en una página "oficial" donde había que ser "miembro" para poder acceder a información Y eso de ser miembro no era como sacar una cuenta en el foro todopic... había un hermoso link donde tenías que poner tu tipo y número de tarjeta de crédito :lol: :lol:
De todas formas, por más que no te de una solución (que es lo que me gusta hacer cuando escribo un post) al menos te puedo dar algo de infromación de los pasos que recorrí y con las paredes con las que me choqué.
Saludos
PD: Tal vez le dediqué poco tiempo, tal vez sí hay mucha información ... pero no me fue fácil conseguirla en el tiempo que la estuve buscando.
-
Hola amigos!
Antes que nada, muchas gracias a todos! La verdad que me están ayudando mucho.
Me ha parecido interesante el Bus CAN principalmente. Igualmente dedicaré tiempo a investigar sobre todos los que han mencionado, porque no quiero descartar ninguna posibilidad.
Olvidé mencionar que se trata de una planta hormigonera, en la cual se trabajan en temperaturas bastante elevadas para el secado rápido del hormigón.
Maunix, es interesante tu opinión porque planteás precisamente el gran temor que temía:
La existencia de grupos cerrados y la información inaccesible para nosotros.
Me hiciste acordar a cuando quise implementar el protocolo ADEMCO en un modelo de alarma que construí. Sencillamente no logré encontrar información al respecto y eso que estamos hablando de alarmas hogareñas. Diminutas en comparación a la industria.
¿Alguien ha implementado "algo" con el Bus CAN o algún otro standart o todos han terminado creando su propio protocolo(como bien dijo Maunix)?
Gracias nuevamente!
-
Hola:
Te paso un protocolo abierto ,bastante interesante y bien documentado:
http://www.hth.com/snap/
Saludos
Jorge
-
Bueno, bueno....
¿En que mundo vivimos?
Actualmente hay tantos protocolos de red y tantos medios físicos de comunicación en redes que todo ese mundo se ha vuelto un campo de batalla, donde los que guerrean son las compañías que venden los cables, transceptores, protocolos, etc.
Actualmente una opción que se usa cada vez más es el empleo de redes Ethernet:
Si no hay mucho ruido, ambientes explosivos la solución es utilizar cable de cobre
Si no es posible emplear el cable, entonces fibra.
Las ventajas son muchas, desde el punto de vista del diseño y topología de la red tendrás una sola red en la empresa desde el nivel más alto, desición y supervisión ,hasta el nivel de sensor (pasando por las 5 capas de un modelo de control industrial piramidal, que es el mas usado para estos sistemas, algo así como el OSI para redes)
Si diseñas equipos para la industria, te aconsejo ETHERNET, si tienes que seleccionar equipos para montar un sistema, lo mismo. Si después tienes que compatibilizar medios de diferentes protocolos y dispositivos físicos, compras los convertidores de medios (a veces se llaman switch igual que los de las redes ETHERNET, pero con salidas para diferentes protocolos) y con eso te quitas problemas de arriba. De hecho los fabricantes más reconocidos como Siemens, Mitsibishi, Ohmron, etc ya implementan la mayoría de sus PLC y controladores con puertos ETHERNET. Nada que las redes de PC se imponen y hay que vender.
Un saludo Reinier
-
Hola, no puedo hablar mucho porque laboralmente estoy en periodo de transición y estudiando a toda mecha para poder trabajar en esto. Por lo que me he estado moviendo, comparto la respuesta de Reiner. La mayoria de industriales con los que he hablado se limitan a tener un ingeniero informático en plantilla y comprar todo en base red Ethernet (hasta las cámaras de CCTV en IP).
Particularmente, estoy preparando un pequeño proyecto en base a RS485, porque encuentro que da bastante de sí, en especial a ruidos y distancias. Al mismo tiempo, en una manguera CAT5, te quedan 6 cables libres. Los puedes usar para otros canales 485, o en función de la instalación, la inyección de señal de cámaras de video (1 por par trezado. Llegan hasta 400m en color) como es mi caso. En cuanto a protocolos de comunicación no he oido nada, yo estoy haciendo mi propio código. Si no me equivoco, el 485 usa conector RJ45. Las placas PCI conversoras que hay en el mercado llevan 4 puertos. A todo esto, insisto que no tengo experiencia, todo esto es lo que he oido por ahí, pero con bastante fiabilidad.
Saludos, David
-
Buenas Bruno, por si te sirve, te comento algunas tendecias actuales de protocolos de comunicacion, o por lo menos eso es lo que nos comentan los representantes de plc y scadas de Argentina.
En principio depende de la marca, y la aplicacion puedes tener desde Profibus DP, Profibus PA, Profinet, y Ethernet, que es la apuesta se Siemens para su automatizacion, con las complicaciones que explico Maunix para implementar Profibus.
Alen Bradley, con ControlNET, y DeviceNET, estas no las maneje, pero desconozco si son o no abiertas.
Schenider Electric, te diria que es quizas la mas facil de implementar, ya que tiene el archiconocido Modbus, realmente facil de implementar, Modbus Plus, cerrado y solo utilizado por ellos, pero buen protocolo, luego el Modbus TCP-IP, que no es mas que la trama comun Modbus embebido en la trama TCP, la semana pasada tuvimos un curso con las ultimas novedades de schenider, y todas estan basadas en Modbus y Modbus TCP, principalmente, y para una automatizacion descentralizada, utilizan Modbus plus para comunicacion entre el PLC y sus distintas unidades remotas. Una solucion integral de esta firma, la de un centro de control inteligente (CCM), esta basada completamente en Modbus y Modbus TCP.
Conozco mas que todo lo que se refiere a industria aceitera y de granos, pero te diria que si tienes que hacer un producto que luego sea facil de comunicar, sin ninguna duda implementaria Modbus y luego Modbus TCP...
Saludos, espero haber ayudado...
Alejandro.
PD: y implemente modbus en unos equipos industriales, asi que si necesitas info, ningun problema.
Saludos de nuevo.
-
Creo que el tema de usar un protocolo estándar o no está en la versatilidad que le querramos dar a nuestro dispositivo.
Si queremos una solución particular, usando cosas estándar (ethernet como se ha mencionado) creo que está bien, pero si queremos agregar algo a una red ya existente o hacer compatible nuestro hardware con otro existente, la cosa es bastante diferente.
De por sí, es riesgoso utilizar pics en un ambiente industrial, porque al PCB hay que realmente diseñarlo MUY BIEN para que no haya problemas de ruido y las pruebas pueden ser realmente desmotivantes. Ojo con esto bruno, porque si bien el software puede ser tu fuerte y termines haciendo andar el protocolo ¡¡el hardware no es menos importante!! y se te puede realmente complicar con cosas que uno ni imagina.
Volviendo al tema de lo estándar y no estándar, es importante saber si quieres que tu hardware sea 'esclavo' de un PLC o de algo a su vez también estándar o si simplemente quieres comunicarte por una interfaz de hardware que sea conocida.
Me explico: puedes utilizar un protocolo BRUNOPROTOCOL montado sobre can bus y eso no te garantiza que si colocan otro equipo te puedas entender con ese equipo. En ese caso usaste un bus estándar pero el protocolo no lo es, amén de esto, seamos realistas y uno nunca diseña un bus así que siempre se cae en el 99% de los casos en un medio de comunicación que responde a algún estándar y se termina comprando un Integrado que nos resuelve la capa física.
Si quieres usar un bus estándar como CAN BUS o RS485 , y quieres que tu dispositivo sea esclavo de otro, entonces deberás ver o apuntar muy bien de qué quieres ser esclavo.
Profibus, Modbus, etc. Al usar uno u otro prácticamente te casas con usar un Plc de Siemens o de Telemechanique/Honeywell
Es un proyecto que dejé de lado porque en ese momento había que resolverlo con profibus o con "mi protocolo" y terminé usando el mío.
Respecto al hardware, te sugiero que cotices el trabajo como si usaras PLCs y luego usa los PICs. Un PLC bastante completo puede rondar entre los 500 y 1000 dólares. Un pic escasos 30 (teniendo en cuenta todo el pcb) , pero hacer una placa para un pic que tenga la robustez que tiene un PLC puede ser realmente muy costosa precisamente por las protecciones, etc.
-
Bueno, bueno Bruno, Felicitaciones !! :mrgreen: :mrgreen: :mrgreen:
Te comento luego de hacer un analisis para el producto que vos conoces que estaba haciendo, me decidi por el Modbus.
Explico porque lo elegi:
1. El producto, igual que el tuyo debe comunicarse en un ambiente industrial y en protocolo y medio estandar.
2. Ethernet es lo que mas a crecido, pero en PLC lo unico que es similar es el medio fisico, el protocolo en si aun no ha sido compatibilizado ni normalizado para todos, por lo tanto no hay estandar aun.
3. CAN es excelente (al punto que tengo esperando los chips para empezar con el) pero tambien en el medio fisico es en lo que hay estandar, luego existe DeviceNet, CanBus y otros cuantos protocolos (excelentes todos) pero aun no hay estandar.
4. El Modbus es aun hoy el mas usado del planeta, no hay dispositivo que no ofrezca Modbus en alguna de sus versiones, en www.Modbus.org encontraras todo respecto a el medio fisico y el protocolo.
Por ultimo, yo ya lo tengo andando, asi que te ofrezco ayuda si lo implementas... :mrgreen: :mrgreen: :mrgreen: :mrgreen:
-
Nuevamente gracias. Veo que hay más foreros de los que pensaba que anduvieron y/o andan en este sector.
Cada palabra que mencionan se traduce en cientos de paginas para leer, asi que deberé sentarme tranquilamente...
jansuini:
Gracias por el link! Lo voy a tener en cuenta.
Maunix:
Mi fuerte es, efectivamente, la programación(en realidad todo lo relacionado a la informática). En electrónica soy un cero a la izquierda. Igualmente espero que contraten un ing. electrónico también o al menos eso voy a recomendar ya que muchas cosas escapan a mis precarios conocimientos(como el tema de los ruidos por ej.)
MGLSOFT: Gracias por la data y por el ofrecimiento(seguro te molesto en algun momento)
Saludos.
-
¡Hola Bruno! bien por tí en ese empleo, no importa que la electrónica no sea tu fuerte lo que realmente importa es la capacidad de resolver un problema, (por tus conocimientos y aportes en el foro no creo que tengas problemas.)
por acá si te pones analizar cada quien hace un trabajo del cuál no es su área. Así tu ves a mecanicos haciendo trabajos de electricistas, y electronicos haciendo trabajos de informaticos y todo lo que alcance un contrato en una empresa.
Salu2 y exitos
-
Hola Bruno
Espero que te vaya bien en ese empleo
Si tienes tiempo puedes bucear a partir de
http://www.automation.siemens.com/net/html_78/support/tools.htm
http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&caller=view&lang=es&siteid=cseus&aktprim=0&extranet=standard&objid=18880715&DataKey=18880715&treeLang=es
Tengo entendido que a nivel industrial no existe ningun sistema de comunicación universal, sino que conviven varios, incluso en una misma planta industrial, en función de las diversas necesidades, por lo que existen "pasarelas" que permiten intercomunicar diferentes redes de comunicación.
Saludos
-
¡Hola Bruno! bien por tí en ese empleo, no importa que la electrónica no sea tu fuerte lo que realmente importa es la capacidad de resolver un problema, (por tus conocimientos y aportes en el foro no creo que tengas problemas.)
Disciento en algo. Creo que la capacidad para resolver problemas de nosotros es acotada. Uno tiene limitaciones. Por ej: Yo no me voy a poner a construir un edificio solo porque sepa resolver problemas con pics.
Uno sabe resolver un tipo de problemas, pero también pueden surgir otros que nos escapen a nuestro conocimiento/entendimiento. No porque seamos tontos, nada que ver con eso, sin porque simplemente no es nuestro campo de acción y puede que no veamos algo que es muy simple, hasta por el contrario, que minimicemos un problema por exactamente la misma causa (por no saber del tema y por ende no tomarlo con el rigor adecuado).
Por ej, yo no minimizaría el tema de los ruidos... incluso para un ing. electrónico es toda una ciencia lidiar con ellos. Hay ingenieros/técnicos que se especializan en esa área y hasta es importante destacar que por ej. el ruido a 1MHz, a 100MHz y a 1GHz se combaten de forma diferente!
También es diferente a nivel industrial, casero. A nivel exterior o interior. Para un equipo que maneja un motor que para un equipo que transmite por RF.
En fin, me parece adecuado que don Bruno pida/exija que le sumen un ingeniero electrónico especialista a su lado.
Hay algo que siempre digo en mi trabajo y es que "Hay que reconocer las propias limitaciones que uno tiene. Una vez reconocidas se avanza mucho más rápido ya que uno sabe con qué puede contar y con que no". En este caso Bruno ha reconocido su falencia en el área de la electrónica y me parece muy buena su decisión que buscar a alguien que le eche una mano en eso.
En las empresas no solo se tiene que garantizar el resultado, también se lo debe hacer en el menor tiempo posible! y es ahí donde reconocer las propias limitaciones nos allana terreno para agilizar los desarrollos en los que nos vemos envueltos.
Saludos
-
yo también siento no estar de acuerdo del todo con lo que expones Mauricio.
yo pienso que el ser humano siempre tendrá limitaciones en conocimientos, y estoy hablando en su propia área.
que mas me gustaría que por ejemplo en mi país cada persona se dedicara a trabajar en su área, como lo hacen en los paises desarrollados, el que tiene que trabajar con micros, y trabajará con micros; el que tiene que barrer, pués barrerá. :mrgreen:
recuerdo un comentario que escuché una vez, a los que somos telecom que decian que nosotros debiamos tener nociones de electricidad de potencia, y porque? : bueno esa persona decía que si por ejemplo se estaba en una montaña muy lejos de la ciudad arreglando una antena y por un motivo X esa antena trabajaba con un motor de alta tensión y si ese motor llegaba a fallar, pués nos tocaba al menos intentar repararlo.
por supuesto que me molestó ese comentario, porque sino fuera estudiado otra carrera.
pero resulta que en este país (por dar un ejemplo de la realidad latinoamericana) uno tiene que aprender de todo, porque puede darse el caso (y se dá) que no hay demandas de empleos en cada especialidad y para no quedarse en el aparato, no queda de otra.
personalmente he ido a varias empresas a entrevistas de trabajo, y yo reunía el perfil de los requisitos, pero no me contrataron ¿porque? bueno porque yo no tengo el título de electrónico y por que soy telecom y ellos no quieren eso.
esa fué la razón por la que le dije a Bruno, y es así donde se agarra experiencia en otras areas, porque sino ¿como se aprende?
-
esa fué la razón por la que le dije a Bruno, y es así donde se agarra experiencia en otras areas, porque sino ¿como se aprende?
Vivo en un país latinoamericano y sufrimos de lo mismo que sufres tú. Está tan incorporado a nosotros que realmente ya es un modo de vida.
Solo digo que hay conceptos que no se asimilan de un día para el otro y para el caso puntual de Bruno no creo que le den precisamente "mucho tiempo" para resolver el problema y si el trabajo lo vale, más vale sumar gente experta en el otro área que uno no conoce porque la curva de aprendizaje será realmente lenta y uno quiera o no para mi "el saber sí ocupa lugar". Nos lleva tiempo aprender cosas nuevas, asimilar conceptos, hacer pruebas. Es un tiempo que en muchas ocasiones no tenemos.
Por manejar un auto no me voy a poner a aprender de mecánica. Tengo una idea vaga de algunas cosas, pero no por eso soy un mecánico.
Lo mismo hablaba aplicado al caso de Bruno, uno puede tener las ideas básicas (no pasar un cable de datos por una línea de 13,2KV ) pero saber de eliminar ruidos en ambientes industriales no es una tarea trivial. Volvemos al ejemplo del auto. Uno puede solucionar un problema menor (auto sin batería, cable flojo) pero no va a poder resolver un problema de por ejemplo, el motor fundido. En este caso el cable flojo sería saber por donde pasar los cables, y arreglar el motor sería por ej. diseñar un circuito, gabinete y protecciones necesarias para que nuestro equipo no falle.
Esa era mi idea, espero haberme explicado mejor.
Saludos
-
esa fué la razón por la que le dije a Bruno, y es así donde se agarra experiencia en otras areas, porque sino ¿como se aprende?
Vivo en un país latinoamericano y sufrimos de lo mismo que sufres tú. Está tan incorporado a nosotros que realmente ya es un modo de vida.
Solo digo que hay conceptos que no se asimilan de un día para el otro y para el caso puntual de Bruno no creo que le den precisamente "mucho tiempo" para resolver el problema y si el trabajo lo vale, más vale sumar gente experta en el otro área que uno no conoce porque la curva de aprendizaje será realmente lenta y uno quiera o no para mi "el saber sí ocupa lugar". Nos lleva tiempo aprender cosas nuevas, asimilar conceptos, hacer pruebas. Es un tiempo que en muchas ocasiones no tenemos.
Por manejar un auto no me voy a poner a aprender de mecánica. Tengo una idea vaga de algunas cosas, pero no por eso soy un mecánico.
Lo mismo hablaba aplicado al caso de Bruno, uno puede tener las ideas básicas (no pasar un cable de datos por una línea de 13,2KV ) pero saber de eliminar ruidos en ambientes industriales no es una tarea trivial. Volvemos al ejemplo del auto. Uno puede solucionar un problema menor (auto sin batería, cable flojo) pero no va a poder resolver un problema de por ejemplo, el motor fundido. En este caso el cable flojo sería saber por donde pasar los cables, y arreglar el motor sería por ej. diseñar un circuito, gabinete y protecciones necesarias para que nuestro equipo no falle.
Esa era mi idea, espero haberme explicado mejor.
Saludos
ahora si entiendo mejor tu punto de vista Maunix, y he visto ese ejemplo con un tio mio, que es albañil. Él aprendió ese oficio de pequeño con una persona que era albañil y esa persona le enseñó lo básico para pegar un bloque, nivelar la hilera hasta llegar arriba, calcular la cantidad de cemento y arena, etc..
conocer un área uno solo es díficil, siempre hay que ver y aprender con otra persona que sea experta en esa materia.
-
Estimado Bruno : segun mi experiencia lo mas importante en esta tarea que inicias es ofrecer algo que se pueda diferenciar de lo tradicional
Segun cada caso , la solucion esta en relacion a la capacidad de ver cosas que otros no pueden ver .
Si no fuera asi , estariamos a merced de los equipos "standard" que se ofrecen.
Si nos llaman a nosotros , es porque ya llamaron a a " Pitsubishi " y cortaron espantados , bien por lo caro o bien por lo poco original
de la resolucion especifica.
Para lo que necesites , estoy a tu disposicion , y espero poder estar a la altura de la disposicion que vos tenes con los todos nosotros
-
Ya que ha salido el tema y por si les interesa (curso Ethernet industrial):
http://www.ats.nl/test/tr_contents.php?lang=e&country=e&course=C3
(no tengo absolutamente nada que ver. Lo vi y me acordé de este hilo)
Saludos, David