Esa es una gran pregunta y no sé los detalles de su caso. Solo mencionaré algunas cosas y algo de filosofía para el futuro.
Errores comunes:
1 Problemas de sincronización: la lógica escrita no se ejecuta según lo previsto, puede que no esté en el orden correcto. Los PLC escanean secuencialmente. A veces, estos pueden ser difíciles de precisar. vea si su software admite un solo modo de escaneo, para que pueda ejecutar un escaneo, revise los resultados lógicos, antes de escanear nuevamente.
- ¿La máquina Eureka ha tenido un éxito continuo?
- ¿Cómo se ve un yottabyte de información?
- ¿Cuáles son algunos de los conceptos más interesantes de las matemáticas?
- Cómo iniciar un servidor web local
- ¿Vale la pena hacer un MTech en informática del ISM Dhanbad?
2 errores de etiqueta. Las etiquetas no están escritas correctamente, tal vez tienen una letra o número mal escrito.
3 errores de mapeo de E / S. Esto es relativamente simple. Compruebe que la asignación y el escalado de E / S del PLC coinciden con lo que está en la lista de E / S. de ustedes no tienen una lista de E / S. Es la base de la automatización.
4 No bloquear las condiciones del proceso que están destinadas a causar algún resultado de actuación o control. Es posible que las alarmas u otras condiciones del proceso deban bloquearse para que no se sobrescriban o borren en el siguiente escaneo. Imagine un botón de parada de emergencia, si solo se presiona momentáneamente y no tiene un pestillo de botón físico (los botones de parada adecuados sí), el PLC puede no recibir ese disparador en el momento correcto en la lógica para usar. Al enganchar ese disparador en la lógica, podemos garantizar que al menos se use en el próximo escaneo.
5 Malentendido de instrucciones. Los programadores a menudo no aprenden completamente las instrucciones que usan y se adelantan a sí mismos. Si se usan instrucciones más complicadas en el código (por ejemplo, bloques PID, bloques de comunicación, bloques de alarma avanzados) asegúrese de que el programador sepa cómo funcionan. Lea el archivo de ayuda A para cada instrucción.
6 Optimismo humano. La suposición de que “funciona” simplemente porque terminamos de escribirlo y somos el “experto”. Escribir código de calidad requiere una mentalidad de que se garantiza que los errores estarán presentes y tenemos que ejecutar métodos básicos de calidad para encontrarlos (como editar un artículo, es el deletreo correcto, es coherente la estructura, etc.)
El mayor control de calidad por tiempo que puede hacer es una revisión por pares a medida que se desarrolla el código (no solo al final). Imprima el código cada vez que se complete una sección (sí, imprima en papel, los humanos encontrarán más errores de esta manera). Busque los errores básicos primero. ¿Hay comentarios, se usan las etiquetas correctas, la lógica utilizada parece lo que dice el comentario, es el código organizado? Si no hay comentarios o si el código no está organizado (presentado de forma limpia, es fácil de seguir) es probable que haya muchos errores.
Siempre revise por pares (y solo luego pruebe) el código en secciones a medida que se escriben. La idea es asegurarse de que cada unidad funcione antes de probar el sistema. Probar todo al final es extremadamente ineficiente.
otros consejos:
La mayoría del software de PLC tiene una función de “compilación” o algún equivalente que busca errores lógicos. correr eso regularmente
Siempre revise el registro de errores de tiempo de ejecución para ver si se trata de errores de instrucciones o de memoria. Muchos programadores no hacen esto. Busque su software para encontrar lo que llaman esa característica (Allen Bradley, fallas mayores y menores).
Si no tiene una cultura con la mentalidad que mencioné anteriormente, tendrá problemas y reelaboraciones constantemente.
Deberías poder leer el código sin que te partas la cabeza. si es difícil, entonces el programador no lo ha pensado lo suficiente. Un programa mal estructurado sin comentarios y nombres de etiquetas significativos es mucho más difícil de solucionar.
Le he dado muchos consejos para evitar problemas, pero en algún momento se necesita experiencia en programación para anticipar dónde es probable que se encuentren los errores y cómo “ponerlos en una caja”. Los mejores programadores recuerdan patrones que les han causado problemas en el pasado y son más cuidadosos al revisar las secciones. Para mí son las transiciones, cuando un equipo o sistema está haciendo la transición a otro modo o estado, pruebo con mucho cuidado para asegurarme de que no haya efectos accidentales (como que el equipo se apague / encienda repentinamente, interrumpiendo el proceso).
