View Full Version : Old Timer
Bellows
May 19th, 2002, 09:19 AM
Hi Folks, I haven't programmed a PLC since back when the SLC503's first came out and I have forgotten a LOT! We used APS software back then. Here is my present problem.I need to program a Micrologix 1500 with the RSLogix 500 software.It is being used ONLY to monitor a sewage lift pump station and communicate by modem back to a county SCADA system (report by exception). There are about a dozen discrete inputs and one analog input for level.What I would like to ask are there some "housekeeping lines of programming" that I should include in the beginning of the program? Things that should be initally set like in case of power outage or reinitalizing data registers (for instance setting them to zero).I hope the question is clear. thanks a lot for your help. BTW Phil's book was a great review. I wish he would write a sequel dealing with analog and communication.Thanks, Bruce
Pierre
May 19th, 2002, 09:56 AM
-are there some "housekeeping lines of programming" that I should include in the beginning of the program?-
It's your call... but I always do.
I put them at the very end of the program. Thing like you mentionned and more. Some relatimg to communication, access, counting thing that should never happen. Max values with RTC tagged.
Some time I get back at a system a few years later and when I access it I go for those data and... although I cannot say it's a big help... it tells me something about the people who acces it... I count operators inputs... and other things.
Bellows
May 19th, 2002, 10:46 AM
Thanks Pierre for your input. Would you have any more specific suggestions on how to implement these items or where to look for such info? Thanks again, Bruce
Eddie Willers
May 19th, 2002, 12:31 PM
Your most common tool will be the "First Pass" bit, which is only set high for one PLC scan when the PLC first enters RUN mode.
In all of the SLC family processors (including MicroLogix), the First Pass bit is addressed as S:1/15.
So what do you do with it ? Go through your program and look for counters and FIFO registers. Also look for latching outputs (OTL and OTU instructions).
Those are the most common *kinds* of things you might want to reset when the PLC is powered up.
I just finished a similar pump station job myself, and on the first pass of the PLC program I reset two latching outputs that would otherwise trigger alarms, as well as setting to zero the pointer of an alarm stack FIFO.
I usually put in troubleshooting timers and counters for my own use, and those I don't reset on powerup, instead opting for manual reset when I'm actually online with the control system. I do carefully program them to prevent overflows (and thus PLC faults), but I'd like them to remain as "evidence" inside the controller to tell me about the behaviour of the system power and the master polling MTU.
Bellows
May 19th, 2002, 08:14 PM
Thankyou very much Eddie! that is exactly what I was looking for. I had completlely forgotton about the 1st pass bit. That is how we used to do it also. I appreciate your help from across the pond.
Pierre
May 20th, 2002, 07:50 AM
One more thing...
Write a few line of code to do this;
Get all your housekeeping data into a serie of consecutive registers.
Write a MOV of there actual values into a second serie of consecutive registers.
Have this MOV executed via a single Bit which you will toggle when ONLINE.
This to set a record of the last time you where in there!
Don't forget to move the date and time also.
Next time you're online you just look and compare the two series to see what has changed.
Tom Jenkins
May 20th, 2002, 09:28 AM
One thing I always put in my "power up" subroutine is code to range check all my setpoints. For example, if time delays for alarms are set to zero, or if alarm trip points are above or below a reasonable range, I initialize them. I do the same thing for the variables that I use to scale analog values to engineering units. This not only prevents some very strange occurrences if a power blip or dead battery causes my pre-sets to get lost, but also protects from the most egregious I/O (Idiot Operator) errors.
Bellows
May 17th, 2003, 07:33 AM
Thanks a lot Tom, I appreciate your input, Bruce (old timer)
.