How painful will it be to have to remember to reset the Program Mode state of each output to Hold Last State each time you download to the PLC and then back to Safe State? Our company uses a VPN to change programs on PLCs out in the field. I'm trying to prevent undesirable actions when going back to run mode. Yes, I'm a novice of AB. Call me a JEEP! Just enough education to pass!

 

Don't feel bad, I have been working with PLCs since early 80s. I was very surprised when I saved my AB configuration while the plant was running and it started up by itself when I downloaded some changes. This seems downright dangerous. I'm sure there's a simple remedy that the AB gurus will share with us, perhaps something in the startup routine. In the meantime save your configuration while stopped.

Regards
Roy

 

That is a very common result when you make a minor on-line change while in operation. Typically I use the first scan bit (S:1/15 in the PLC-5) to preset bits/words to a known start-up condition which is scanned first in the logic. Just put the preset conditions in a separate file and call it in the first rung of the MAIN routine conditioned with the first scan bit. That way it only is scanned once and won't take time away from the scan rate.

Everybody who has been at this game for more than a year or two has seen this. Once burned, you tend to figure out how to not have it happen again. The more damage/higher level plant management watching, the more detailed you get concerning not letting it happen again.

Regards,
Russ Kinner
SSOE, Inc.
Phoenix, AZ USA

 

Russ,
Thanks for the response, do you mind elaborating a little on what you do. Do you just set all the Inputs to Zero or do you have to switch things like controllers to manual, timer accumulators to zero.

As I said I have been working with PLCs for a long time but it came as a surprise to me.

You would think AB would include a routine since it's so important.
I guess you could also do the programming in the startup routine of ControlLogix

Thanks
Roy

 

I agree...................it is called a start-up routine. You can also program a fault routine and a shut down routine although in my experience any of these seam to be rare from all but the best programmers.

As I once told my bosses who did not want to take time to do this (paper coating). The analogy is that if I backed up the system making chocolate chip cookies, a month later while making oatmeal cookies I download the program. Guess what we are now making chocolate chip cookies again. They tend to understand that.

Dave Ferguson
Davco Automation
"The Developing Automation Value Company"

 

Dave,

Could you give an example of what's in the Startup routine? I work with many different PLCs and DCS systems. I don't have time to learn them all in great detail.

My interpretation of good programming is code with lots of documentation, not fancy routines with none.

Thanks,
Roy

 

Depending on how structured your system is makes the first scan program either quite easy or notoriously difficult to get to work just the way you want.

On some of my old assignments we created a sequential function chart (before SFC was available as a programming choice) and then it was simply to set the counters to 0 and everything went back to the starting point. That by itself set all outputs to 0 as well.

It can't be said as a blanket statement that a method will always work but... if on a ControlLogix 5000 you control the updating of the I/O rather than take the input module in directly (to make it perform more like a PLC-5), you can write 0 to all the inputs after the I/O updating is completed. Then all sealed-in coils (as you would see on a typical motor starter) would drop out. I would also load any recipes with a state that has no values; a default "null set" so an operator must load something before the system will start.

The I/O updating I mentioned above is done to prevent a change of an input mid-scan. I've seen situations where a bit is scanned at he beginning of a program and changes state before the end where it is referenced again. I'd say that 98% of the time that would have no impact but once in a while that change of state can cause some weird program performance that is truly difficult to find. You may not need to do that but I find it useful in most programs.

Russ

 

As has been said on here by a couple of people, on a startup routine you would clear out set points, load constants, clear latched bits, reset sequences, etc.

This could also be done on a shutdown routine and there are also programs that will run a fault routine if there is a major fault where you could reset bits and return equipment to a "safe" state.

Of course as one poster said, be doing some resets if your code is good, should put the rest of the machine into a safe state.

And as always, this takes a knowledge of the process, the controller used and the program written. In other words it is a software engineering project like most others.

Dave Ferguson

 

Saving the machine while stopped is one step but not the safest one. What if the machine was stopped on step 23 which was the "pull person into machine if they are not careful and steps 1-22 have completed" step. Now under a normal sequencing of the machine this step is ok because steps 1-22 have already been tested and made sure this step could not function improperly. But after a download, in an improper program, you now download step 23 into the machine and it does what step 23 does next.

This is a bad example of bad code but I have seen such things from either low bidder, low experience, new guy at vendor, or all of the above machines.

This programming kills people, it is not about having your video game lock up or your word processor stop, and there are many cases where the machine never killed anyone for 15 years, until it did. You must take every precaution to write and think of every possible safety hitch that can happen because it will.

I marvel at the failsafe systems that I have seen over the years. I walk over to the power switch and reach to throw it and they panic saying, this that or the other will happen... not very well thought out.

P.S. I have gotten a call to investigate a program after someone got killed... makes you think about such things, luckily (if that word fits) it was not the program... but you never forget those experiences when you write machine control code.

Dave Ferguson
DAVCO Automation
"The Developing Application Value COmpany"

 

Dave,

I agree with everything you said about how dangerous code can be. That's why I was very surprised to find my ControlLogix program re-starting where it left off. I have been working with PLCs since 1980 and don't recall seeing that before. How many new programmers are going to get caught out by this un-advertised feature?

Surely by default the system should be failsafe. Do any other PLC brands do that?

Regards,
Roy

 

Many of them can and do. No different than timing loops or putting an unlatch in the wrong place and getting a loop. No different that putting the output in the program 10 times and having them chase each other. This issue has been around since the 80's and before, it is not new. It is about experience. They all have their own way of handling these issues.

I also have been doing this for a long time, and almost every project, I find out something that I did not know.

The system is a tool just like a hammer. What you do with it is up to you build a house or hit someone with it. This is a topic that scares me, because it can be so dangerous if handled wrong and some managers today think that it is "easy" so why spend all of this time designing it.

Dave Ferguson

 

The bottom line is this.

It is the responsibility of the programmer to insure that a PLC system
operates correctly in all defined modes. That includes power down,
powerup, and program loading.

Every PLC I am aware of has tools to allow the programmer the capability of dealing with these issues.

 

Another possible solution is to put all "real world" outputs into their own file that is only scanned if defined conditions are met such as power on or mode selected (e.g. Auto, Manual, etc.). If the control power MCR is set up in such a way that it drops out whenever the PLC is switched into program mode for downloading an entire project, the mode selection should drop as well and in turn drop out any auto sequence regardless of step or sequential programming. As for internal latches, arrange them in such a way that they are grouped together in words that you can pick and choose which ones to write a 0 to on power up. By using a power on input from a hard wired MCR, you will have a safe start after download. Counters, RTOs and temporary storage registers would have to be dealt with in a similar manner as internal latches. If you want to keep current values, be sure to save online registers, cut in program changes then download.

 

You have the option to set up the output modules to "hold" their last state when the CLX is in program mode. See output module properties screen. Available for discrete and analog outputs.