System Self Diagnostic and Fault Prevention Favorites.

Hester · Apr 18, 2004

Equipment Failure Diagnostics and Fault Prevention via the PLC:
What are your favorite troubleshooting and Fault Prevention routines that you build into your PLC code?

I’m new and know very little about PLC programming, so while I come up to speed, would the guru’s give me a little latitude, because I admit upfront I know very little, and could use your help. My background is electronics hardware with some VB, VBA, C++, and OOP exposure. But I do not consider myself a very good programmer – I only have the desire to be better. BTW, I love this site. It is so helpful. Thanks!

I’m looking for diagnostic / fault prevention ideas such as:
Photo Eye Make and Break Logic:
http://www.mrplc.com/kb/index.php?page=index_v2&id=15&c=12
or Best Practices such as “Industrial Safety Control” by Jim Rowell:
http://www.mrplc.com/kb/index.php?page=index_v2&id=44&c=38

This article link provided by dandrade is good but is more academic than my current needs.
http://www.viverautomacao.net/Anexos/fault.pdf

Any messaging best practices would be appreciated too.

Thanks guys for the help.

ArikBY · Apr 18, 2004

Here the most common way to detect problems in motor starter and linear piston .
In the first sample, the No contact of the starter is connected in serial to the overload NC contact.So if the OverLoad have the problem
or starter fault can be detected.
Also if someone start the motor directly from the starter.
In the secound sample,If both of the sensors is on=Fault,
If the valve commended but the piston didnot reached the front sensor=
fault.
If the valve truned off but didnot reached the rear sensor=fault.
Also if someone operated the valve manually=fault.
I hope I gave you some direction.
BTW
If one of the faults appear the fault bit 210.00 come on.

Eric Nelson · Apr 18, 2004

Good Topic!...

I'm a big fan of using 'self-diagnostics' logic. There's no excuse for 'ignorant' machines...

Here's a few off the top of my head.

We build a lot of machines with pneumatic actuators, so I always check that all cylinders reach their 'home' positions when the machine is started. Here's a 'generic' version of the logic I use:



|  STARTUP                                  +----------------+

|----] [------------------------------------| Startup Timer  |

|                                           | Preset: n sec. |

|                                           +----------------+

|

|             COND.     COND.     COND.    STARTUP     STARTUP

|  STARTUP      A         B         C       FAULT        OK

|----] [---+---] [-------] [-------]/[---+---]/[-------( OUT )

|          |                             |

|          |           STARTUP           |

|          |             OK              |

|          +-------------] [-------------+

|

|  STARTUP   STARTUP                                   STARTUP

|   TIMER      OK                                       FAULT

|----] [-------]/[-----------------------+-------------( SET )

|                                        |

|                                        |             STARTUP

|                                        |             FAULT_OS

|                                        +--------------( ^ ) (One-Shot)

|

|  STARTUP    COND.                                     COND. A

|  FAULT_OS     A                                        FAULT

|----] [-------]/[--------------------------------------( SET )

|

|

|  STARTUP    COND.                                     COND. B

|  FAULT_OS     B                                        FAULT

|----] [-------]/[--------------------------------------( SET )

|

|

|  STARTUP    COND.                                     COND. C

|  FAULT_OS     C                                        FAULT

|----] [-------] [--------------------------------------( SET )

I use the one-shot to take a 'snapshot' of the REAL fault. Since a fault will dump the air, other cylinders may move, creating erroneous faults.

Arik's method of checking BOTH states of sensors is fine, but I do it a little differently. My machine sequences are broken down into as many individual steps as needed, so the sensors automatically get checked. For example, some may think a simple cylinder extend and retract sequence is two steps, EXTEND, and RETRACT. I see it with as many as NINE steps...

Cylinder extend request initiates STEP 1
STEP 1 - CHECK 'RETRACTED' SENSOR
Confirm that 'retracted' sensor is ON. If ON, initiate STEP 2
STEP 2 - CHECK 'EXTENDED' SENSOR
Confirm that 'extended' sensor is OFF, If OFF, initiate STEP 3
STEP 3 - CYLINDER EXTEND (valve turns ON)
Cylinder starts extending, and 'retracted' sensor turns OFF, initiating STEP 4
STEP 4 - CYLINDER EXTENDING
Cylinder reaches extended position, and 'extended' sensor turns ON, initiating STEP 5
STEP 5 - CYLINDER EXTENDED
Cylinder retract request initiates STEP 6
STEP 6 - CHECK 'RETRACTED' SENSOR
Confirm that 'retracted' sensor is OFF. If OFF, initiate STEP 7
STEP 7 - CYLINDER RETRACT (valve turns OFF)
Cylinder starts retracting, and 'extended' sensor turns OFF, initiating STEP 8
STEP 8 - CYLINDER RETRACTING
Cylinder reaches retracted position and 'retracted' sensor turns ON, initiating STEP 9
STEP 9 - CYLINDER RETRACTED

By monitoring which step takes too long, I can get (and therefore, GIVE) a much more accurate description of the problem!... :nodi:

beerchug

-Eric

Doug_Adam · Apr 19, 2004

Eric,

Looks good, and I tend to use similar code.
One problem I found is that for larger machines you can run out of timers for all your motors and cylinders.
I often now use counters, with a pulse timer set up, since before now I rarely used counters.
This way I conserve my timers.

Doug

dandrade · Apr 19, 2004

Hester
Equipment Failure Diagnostics and Fault Prevention via the PLC:
What are your favorite troubleshooting and Fault Prevention routines that you build into your PLC code?

Obliged by initiate this topic. ;-)
Well coming, as well as you I interest for this, and is part of my studies of deepen. After start, time of programming. .., the problems in this aspect, me incentive. I believe, that is a phase of knowledge, that we recognize the limitation and disadvantage of the PLCs.

He extend the matter,is need.This about I possessed, little research... certain, not easy he develop the matter.

I challenge: Others way of diagnosis?
Difficult: Replace the traditional and ineffective watch-dog.... banghead

-----------------portuguese-----------------



Obrigado por iniciar este tópico. Bem vindo, assim como você  interesso por este tema, e faz parte de meus estudos de aprimoramento. 

Após, tempo de programação..., os problemas neste aspecto, me incetivou. Creio, que é uma fase de apredizado , que reconhecemos a limitação e desvantagem  dos PLCs.



Extender o assunto, é essecial. Esta área possui, pouca pesquisa... certamente, dificíl desenvolver o assunto. 



Desafio: Outros modo de diagnóstico ?

Difícil: Substituir o tradicional e ineficaz watch-dog.....

PLucas · Apr 19, 2004

dandrade said:
Ladder tags removed

-----------------portuguese-----------------

Obrigado por iniciar este tópico. Bem vindo, assim como você interesso por este tema, e faz parte de meus estudos de aprimoramento.
Após, tempo de programação..., os problemas neste aspecto, me incetivou. Creio, que é uma fase de apredizado , que reconhecemos a limitação e desvantagem dos PLCs.

Extender o assunto, é essecial. Esta área possui, pouca pesquisa... certamente, dificíl desenvolver o assunto.

Desafio: Outros modo de diagnóstico ?
Difícil: Substituir o tradicional e ineficaz watch-dog.....

Dandrade

There is no need to put your portuguese version in the LADDER tags, Then I (and others) will not have to scroll right to read you post.

Paul

TimothyMoulder · Apr 19, 2004

Don't spare the bits...

In my younger days, I would create a fault bit for the condition "cylinder did not move up." Then, if there were three or four possible scenarios that could result in such a problem, I just tied them all to that one bit and congratulated myself on my compact programming.

Thankfully, I am not so foolish these days, nor so young. I think those two conditions are related...

When you program faults, whatever means you decide to use, every single fault should be absolutely unique, and used only once in the program. In the above example, that means

MB3 = "Cylinder not up while homing"

MB4 = "Cylinder not up after pickup of parts"

MB5 = "Cylinder not up after drop off of parts"

The headaches this will save you are something you should pray never to see.

Good Luck! And welcome to the club

TM

Pierre · Apr 19, 2004

One variant this topic is that I allways have for my fisrt rung the output of an audible signal . Second rung would be the visual signal .

Often, when my diagnostic rungs fires an audible alarm, the programer can "see " the origine of the problem as soon as he opens his program.

I usually have the Alarms or watch-cats timers and counters under this rung in order of importance... the first one would be "Emergency cct disabled" and so on.

dandrade · Apr 19, 2004

The environment, usual and common of detect fails, is verify himself a known and true condition, did not occur.

Despite of opposite,sense from the phrase "detetion of the fail". The difficulty of defined you fail becomes them usual previous phrase.

Fails: Detect a condition done not permit
Diagnostic: Inform the cause or origin of fails, or predict the possible occurrence of you fail.

Dignostic:

Level of instruction: Flags of error, carry, fail... bits.
Level of program: Algorithm projected I specify.
Level of the equipment: Bits of fails of hardware, communication, special modules.

Structure:

Ways of compose an algorithm of detetion of fails and diagnostic.

He evaluates himself the rank of relevance between the variables and his conditions.

Way Storm: Verifies himself in a break of time, the information can be validates Ex:Watch-dog, windows of time.

Way Streak of validate: Values that a variable can achieve.
Ex: values of a variable in range instrument

Way: Itself an or more conditions occurred.
Ex: Logic combinacional basically.

Combined the three: Validate the value from the variable, for a determined instant or periods under known conditions

It grasped the result? Success in the programs. :teacher :beerchug

Obs: variable = variable or event.

Documents: FMEA -failure modes and effects analysis and basic matemathics (operations logics and domain time)

It clear or re-write text.

--------portuguese-------------
O meio, usual e comum de detectar falha, é verificar se uma condição verdadeira e conhecida,não ocorreu.

Apesar de oposto, o sentido da frase "detecção de falhas". A dificuldade de definir as falhas
torna usual a frase anterior.

Falha: Detectar uma condição não permitida
Diagnostico: Informar a causa ou origem de uma falha, ou predizer a ocorrência possível de falhas.

Dignostico:

Nível de instrução: Flags de erro, carry, fail... bits.
Nível de programa: Algoritmo projetado especifico.
Nível do equipamento: Bits de falha de hardware, comunicação,
módulos especial.

Estrutura:

Modos de compor um algotimo de detecção de falha e diagnostico.
Avalia se o grau de pertinência entre as variavéis e suas condições.
Modo Temporal: Verifica se em um intervalo de tempo, a informação pode ser valida
Ex:Watch-dog, janelas de tempo.
Modo Faixa de validade: Valores que uma variavel pode alcançar.
Ex:Valores de uma variavel no range um instrumento
Modo Condicionais: Se uma ou mais condições ocorreram.
Ex: Lógica combinacional basicamente.
Combinado os três, obtém: Validar o valor da varíavel, para um determinado instante ou períodos
sob condições conhecidas
Captou o resultado? Sucesso nos programas.
Obs: variavél = variavél ou evento.

Eric Nelson · Apr 29, 2004

Hester 'reminded' me about this topic...

Doug_Adam said:
One problem I found is that for larger machines you can run out of timers for all your motors and cylinders.
I often now use counters, with a pulse timer set up, since before now I rarely used counters.
This way I conserve my timers.

With the way I program my sequences (see THIS post), only ONE step is ever active at a time, so I can usually get by with just two timers per sequence. One for the 'EVEN' steps, and one for the 'ODD' steps. If either timer expires, I can easily determine which step in the sequence has stalled.



|  STEP 1                           +--------+

|----] [----+-----------------------| TIM01  | "ODD" Steps Fault Timer

|           |                       | 3 Sec. |

|  STEP 3   |                       +--------+

|----] [----+

|           |

|  STEP 5   |

|----] [----+

|           |

|  STEP 7   |

|----] [----+

|

|  STEP 2                           +--------+

|----] [----+-----------------------| TIM02  | "EVEN" Steps Fault Timer

|           |                       | 3 Sec. |

|  STEP 4   |                       +--------+

|----] [----+

|           |

|  STEP 6   |

|----] [----+

|           |

|  STEP 8   |

|----] [----+

|

|   TIM01     STEP 1

|----] [--------] [--------------------( SET } STEP 1 Fault

|

|   TIM02     STEP 2

|----] [--------] [--------------------( SET } STEP 2 Fault

|

|   TIM01     STEP 3

|----] [--------] [--------------------( SET } STEP 3 Fault

|

...etc....

I rarely find it necessary to use different timer presets for each step. A preset slightly higher than the lengthiest step works fine on my machines. This is mainly used to simply indentify where the problem lies, so timer presets are not that 'critical'. More or less a "I can't continue, and this is why" message.

Also, my sequence faults to do not automatically reset if the problem goes away. They must be acknowledged to continue.

beerchug

-Eric

Tom Jenkins · Apr 29, 2004

Many PLC brands comm fault bits only trip on a time out, or if a cable is unplugged, or other limited events. I put my own comm fail bits in PLCs on a comm link. I do this by reading a real time clock seconds register or a free wheeling clock register. If the value read from the slave is unchanged after a time delay or a count I set the fail bit. Then you can detect not only loss of communications but also if the slave processor is locked up or faulted.

Hester · May 23, 2004

Implementation of a Timer Pulse for Counters.

Doug_Adam said:
One problem I found is that for larger machines you can run out of timers for all your motors and cylinders.
I often now use counters, with a pulse timer set up, since before now I rarely used counters. This way I conserve my timers.
Doug

This sounds like a great idea Doug. ? Could you elaborate some more on your pulse timer set up?

The way I envision it, is in one of the first rungs you set up a timer that times out every 100 ms, and set it for endless loop. Then set the Timer DN contacts to input into your counters. ? Is this what you are doing??

Thanks

jdbrandt · May 24, 2004

watch-out

I usually have the Alarms or watch-cats timers and counters under this rung in order of importance... the first one would be "Emergency cct disabled" and so on.

In the U.S. we call them watchdog timers.

File this under 'translation problems'.

In this same vein, I once found a circuit board made by a
Danish company that silenced an audible alarm device, and
they translated their native nomenclature to:

Hooter Acknowledge Board.

Yea, buddy!

jdbrandt · May 24, 2004

seriously

My view on this subject tends to fall into one of two categories:

1. Alarms that are really bad/fatal
This would be a motor overload or fuse blowing. Something so bad that the machine can't continue normally.

2. Cautions that are not that really bad, but that the operator should know about.
These would be things like:
'Slow travel' alarms. If you have a cylinder, with the machine freshly build or operating under normal conditions, the extend
should nominally take xx.xx seconds, and the retract should take xx.xx seconds. If the operation takes longer than that, this might
be cause for concern.
Interlock not made for next operation. This would be the fact that the operator needs to close something or do some other action before pushing the button that caused this caution to be reported. Think of this as a sort-of expert overseer, telling the operator what he should have done.

Bartech · Aug 2, 2012

Hello, I am a newbie.

congratulations for this very interesting forum!

My question:

to perform diagnostics of a cylinder controlled by single solenoid valve I can use this method:

|

|

|   valve    front sensor          +----------------+

|----] [---------]/[--------+------|     Timer      |

|                           |      +----------------+

|                           |

|                           |

|                           |

|                           |

|   valve    rear sensor    |

|----]/[---------]/[--------+

|

|

|

|

|

|   Timer                    Fault

|----] [--------------------( SET )

|

|

how to run diagnostics of a cylinder driven by a double solenoid valve?

What I mean is that once the cylinder has finished the forward run the solenoid is de-energized.
Now how do I know if the sensor is burnt out, or if the operator manually operates the valve and turn back the cylinder?

I had thought of using a latch bit (retentive) in this way:

|   valve forward                  +----------------+

|-------] [------------------------|     Keep       |

|                                  |   OP_LATCH     |

|                           +------|                |

|                           |      +----------------+

|                           |

|                           |

|                           |

|   valve backward          |

|-------] [-----------------+

|

|

|

|

|     OP_LATCH    front sensor       +----------------+

|-------] [-----------]/[-------+----|     Timer      |

|                               |    +----------------+

|                               |

|                               |

|                               |

|                               |

|     OP_LATCH    rear sensor   |

|-------]/[-----------]/[-------+

|

|

|

|

|

|   Timer                    Fault

|----] [--------------------( SET )

|

|

|

|

|

is it correct this method, or is there a more clever way?

Thanks to all

Bartech

System Self Diagnostic and Fault Prevention Favorites.

Hester

Member

ArikBY

Member

Eric Nelson

Lifetime Supporting Member + Moderator

Doug_Adam

Member

dandrade

Member

PLucas

Member

TimothyMoulder

Member

Pierre

Lifetime Supporting Member

dandrade

Member

Eric Nelson

Lifetime Supporting Member + Moderator

Tom Jenkins

Lifetime Supporting Member

Hester

Member

jdbrandt

Lifetime Supporting Member

jdbrandt

Lifetime Supporting Member

Bartech

Member

Similar Topics