error checking

I am currently teaching myself PLC programing so my question my seem basic but bear with me. What are some suggested algorithms to monitor and report errors when lets say we activate a solenoid and want to make sure it has completed it's motion. Programing in basic a long time ago I used For/Next loops to do this.

Thanks,

Jim

For actions like the solenoid that you mentioned, you can start a timer when you energize the solenoid and disable the timer when the mechanism reaches the end of travel. If the timer ever gets to its preset, you have a fault condition.

Don't overlook the fault condition where the reaction to the solenoid takes too little time. Let's say you energize the solenoid and find that the end of travel switch is tripped in less than some minimum time. That could be an indication that the switch is adjusted incorrectly, or has failed in the closed postion.

Energizing a solonoid is one thing. Do you have any "feedback"?
How are you going to know if the proper operation took place?
Some solonoids will have a limit switch, analog position, or even something like a differential pressure switch.

ex:
IF: Did Limit switch make/change status when output energized? (in the alloted time or whatever)
THEN: YES, then go on
NO, then sound the alarms-turn off the power and go to the house!
LOL

The solenoid I mentioned is activating a cylinder with retract and extend sensors installed. Sorry for being too vague.

Jim,
I have, on similiar setups, used a timer for the "travel time". Allowing for a little more than the "usual" time needed.
Also, you may want to use the retracted LS as a check. When the output is energized, give a small amount of time and check to see if the retracted LS changed status (i.e. did the cylinder start to move).
Hope this helps.

Another fault would be if both forward and returned limits are acutated at the same time.

Cylinder Extend

Jim you may want to review This Post

That's one of the nice things about PLC's. They usually instigate some machine motion and then look for some result of that motion before, say, instigating a second motion. The nice part about it is that the controller that instigates the motion has all the required information to decide if everything is all right, or if something has gone wrong. Now, these days, with text displays, touchscreens, etc, that connect to these controllers, it's easy, albeit time consuming, to program all kinds of error and/or fault conditions. Then, through the display, tell somebody what's wrong--in plain english.

I, having come to be a programmer through the ranks of the troubleshooting electricians, write this kind of code into every system I do. All you have to do is ask yourself "what could go wrong, here?". Then write some code to catch it going wrong. It really gives the guys on the floor a head start when something bad happens. Instead of the operator saying "It didn't splice", the touchscreen says "the knife was told to fire, but did not move from home." It tells the electrician where to start--what to look for. If I have room, I include ladder rung #'s and hardwired drawing references, too.

Like I say, it takes extra time. But you only have to code it once, and it works forever.

There's all kinds of checks to put in--just use your imagination. If the up and down limits are both made at the same time, logic says that if you most recently told the thing to go up, it's most likely the down switch that is stuck--so tell somebody it's stuck.

The one I like best is the flow proof switch on blowers. Engineers always make sure the switch is made when the fan runs, but very seldom do they check to see if the switch opens when the fan is switched off. A stuck on flow switch could be very disastrous. it's easy to check it both ways. I do it all the time. If it's stuck closed--don't allow operation until it's fixed--through the code--and tell somebody what's wrong. This code prevents the lazy electrician from jumping it out, too.

Anyhow, I didn't mean to ramble--use your imagination and have fun.

While I agree in principle with what John says above, you may want to use a little restraint. Processing power isn't unlimited and more power isn't free. I have worked on projects that would not have withstood the 25% or 30% scan time increase a full-fledged, comprehensive fault detection and diagnostic package would have caused.
Don't get me wrong; put in as much fault detection as you can. But prioritize and add in steps. If you start getting into scan time trouble at least you have the most important detection software in place already.
The memory capacity of modern plcs has kind of led us by the hand to a situation where you can pretty easily drown a plc in terms of performance and use less than half its memory.

Keith