Keep track of operational hours. Add hours to existing hours

[bearsgone 1]

Hello I am new to PLC programming so this question could have been covered but I did not find it. I have Micrologix 1400 and trying to figure out how would I go about logging operational hours for a pump or a motor. In the event motor was stopped and restarted, should be able to add to existing hour count. After some value in hours has been reached, I want to set a bit which I will make an alarm. If anybody has a feedback, link or sample of code how this functionality can be handled, I would greatly appreciate that.

[kaiser_will 65]

I have done similar approaches before...very simple, with a seconds timer that increments a minutes counter which increments an hours counter. Super easy to test - throw a toggling bit branch around the Pump Running contacts, toggle the bit, and watch the integer and counter registers increment. The only way this will not work for you is if the alarm condition setpoint is greater than an increment (i.e., 90 minutes). In that case, take out the minutes-to-hours and hours-to-days increment part. I believe SLC-500 CPUs can handle 32767 for maximum integer value. Logix500PumpTimer.RSS

[bearsgone 1]

Thank you for your feedback, but when I try to run it I get: "OSR instruction is not valid on the currently selected processor!>1766 Microlofix 1400 Series A Can something else be used instead of OSR? PLC is: 1766-L32BXBA Edited 8 Jul 2010 by bearsgone

[bearsgone 1]

RE: kaiser_will I have changed all OSR to ONS, that is the recommendation for 1400s. However, timer do not work when I energize P101A. Code is attached live2.RSS

[Armadillo852 25]

Looks good to me with the exception that the rungs were not verified, or assembled. Also, I don't remember if there needs to be a value in the preset for it to time as well.

[kaiser_will 65]

Yeppers - set the timer preset to 60 and assemble the code.

[Armadillo852 25]

Thanks Kaiser. I wasn't sure.

[Shiner 2]

yes there needs to be a preset, if you are not sure how long it should run, maxing it out as kaiser will said at 32767 will give you 546 minutes or 9 hours. The other way to do it is if you need a minute based function, set the preset at 60, use the DN bit to toggle the rung that adds your minutes and use it to reset the timer continuously. I made changes also instead of moving 0 to integers it is cleaner to use the CLR function. I am making some assumptions because I do not know everything about your system, but you are clearing your integers as soon as you get an alarm state as well. I would clear them only when someone hits the reset button, this is more a personal preference, but can be cleaner in the code again in larger programs. In rung 1 you have the reset button bit in series with the output to latch as a one shot, it needs to be XIO so that it disables the rung while the reset button is being pushed and during this time the integer values are cleared so when it is released the rung will not be true again and you wont have a chase occurring. I used counters instead of integer functions for the minute and hour functions for ease of use...the minute done bit triggers a pulse to count an hour and the hour done bit sets the alarm Don't forget, in your data tables right click properties on your counters and set the memory type to static so that they will be retentive. I don't know what the one shot bit in rung 2 is for so I removed it as well. Unless absolutely neccessary one shots can be avoided. Some facilities will ask that you do not use them at all so it is good practice to find ways to do without them. There is a good discussion in this forum about the use of one shots and latches if you have some time search it and read it. Paulengnr

[Shiner 2]

pualengnr has some good thoughts on it

[bearsgone 1]

Hello Than you everybody for all the feedback. It works now. The only issue I have left is how do I reset N7:0 from PanelView. Presently I have B3:2/1 button but I have to press it ones to reset and another time to return to state 0. I am not sure how to reset with just one action with return to 0.

[Armadillo852 25]

Sounds like you have the button set for a maintained button. Set the button type on the HMI to a momentary push button. Also, I would get rid of the oneshot as it really serves no purpose here.

[bearsgone 1]

RE: kaiser_will' Hello Is there a way to set a bit to 1 if there is current sense detected above certain value for a given pump? After that check if bit is set start the timer. Purpose of it is to create maintenance alarm. Thank you

[bearsgone 1]

RE: kaiser_will' Hello Is there a way to set a bit to 1 if there is current sense detected above certain value for a given pump? After that check if bit is set start the timer. Purpose of it is to create maintenance alarm. Thank you

[paulengr 44]

As to the one shot, agreed. As to the momentary push button on an HMI, warning, warning, warning! Do not do this. It is very, very bad practice and sooner or later, it will bite you very hard. I know that this seems heresy because all those classes that get taught tell you to do it exactly that way, but believe me, you do not want to do it that way. It is bad practice, and it will eventually cause you to sit through safety review meetings and if you don't know what happened, it will be very tough to explain why your machine went "crazy". The problem goes like this: User triggers the button (button down/up doesn't matter). HMI creates a packet to set the PLC input bit to a "1". OK, so we got what we want. Then the button releases. HMI creates a packet to set the PLC input bit to a "0". Now this is where it gets important. What happens if for some reason this packet is corrupted or never gets there? As unlikely as this may SEEM, especially when working with large distributed HMI's or wireless communications, it happens much more frequently than you'd expect. Then the button becomes "stuck". Sometimes pressing the button a second time clears the problem, and sometimes NOT. Sometimes it seems that the HMI might "optimize away" things by deleting one or both of the packets because it sees that the message hasn't been sent yet and deletes the "1" packet and the "0" packet, which turns into "nonresponsive buttons" when the real problem is simply that there was a communication pile-up at the time. Maybe some electrician just plugged their laptop into the HMI or PLC. Whatever the case, the result turns into "stuck" or nonresponsive buttons. On a reset button or a "start" button, everything seems just fine. But now imagine what happens when you have the standard arrangement. On the screen, the operator has a "start" and a "stop" button. This is standard. In fact, it is required by NFPA 79. So right from the start, if you program in the accepted, standard way, you are being set up for the infamous "stuck button" problem. So the operator has pressed "start". The machine starts up. Everything seems OK. No panic yet. Now the operator presses "stop". The machine might MOMENTARILY stop for a split second, but then it suddenly takes off again! So the operator presses stop, stop, stop. Nothing works. Operator presses E-Stop. Finally everything stops. Operator presses Reset, and it takes off "on it's own" again. People start pressing buttons everywhere. Eventually the problem gets cleared up. Then you get to sit down and have a safety review meeting on what happened when your machine "went crazy", how much of a safety issue this is, and why you need to figure out what happened (after they pressed every single button on the screen) and make it go away. You'll probably end up putting in dozens of "panic" and extra "hard wired" stop buttons just because those are "safe", although they are no safer than the HMI, at least in your mind. Believe me, I've been through this problem countless times not only with my own code but with it seems like everyone else's too. The reason that the HMI is "different" is not because it's running Windows or that it's a glass console instead of a physical button. It's in how it is implemented. The fact is that physical push buttons have a "maintained" state. With most implementations (1756 IO "change-of-state" is the exception), they constantly update the PLC at the scan/RPI rate with their status (1 or 0). HMI's are completely different animals. They optimize away ALL of this. An HMI sends change-of-state events, not polling events. So if a packet gets wiped out coming from a push button, it's no big deal because the PLC will be updated again with the new status information on the very next update. HMI's do not do this sort of thing, and it is highly inefficient (really even with the push buttons) to do this. So the solution is to attack the problem directly, head on. Change-of-state communications requires change-of-state logic. Polled state communications requires polled state logic. If you address this seemingly simple problem, then you won't have to sit through those nasty safety review meetings where your PLC, your HMI, your department, and your next of kin are brought into question. Strangely enough, nobody panics as much if the button still works if you have to push the button once or twice...you know how it is when the mouse button doesn't work the first time...just try again and it will usually be fine. The old push buttons didn't always get recognized on the first attempt either, so they seem very relaxed about this idea of hitting it a few times to make it work. No idea why this is considered perfectly safe when it is caused by the exact same incident as "stuck buttons". The safe way to program this is to look for a single event (the button press) and not rely on two separate events. So in your HMI, just set the 1 bit one time and be done. Don't try to program fancy timers or anything else that might entail some sort of risky situation. We've got our event, so we're done. On the PLC side, simply check for the 1 bit and do what you'd normally do. Then the very next rung (or preferably, branch) needs to CLEAR the 1 bit. So now we have a single event from the HMI (set the input bit to a 1) and the PLC can conveniently capture and control the event capture...whenever it's a one, do the right thing and then clear the bit and wait for the next event trigger. Once you adopt this style of programming with HMI's, you may notice that a lot of other nuisance glitches like this disappear as well.

[paulengr 44]

Use an analog input to get an integer value representing the current. Then use the GEQ command to compare the value to your trigger point. Not sure why you want a timer since you described a situation where you usually want a latch. The unlatch might be a physical action (operator presses acknowledge), or it might cause a shutdown (and that's where the timer might be handy). Or you might program some hysteresis. For instance, latch if the current goes above 10 Amps but then unlatch if it drops below 8 Amps. The hysteresis is important if the latch is automatically cleared because if the current runs very close to your trigger point, the system will constantly "chatter" from seeing noise on the input. Commonly when you program this kind of thing, you want to suppress the trigger for the first 5-30 seconds during startup when you expect high currents. Otherwise it causes nuisance trips. If you get really fancy, then you can build a motor model, check individual phases and include some other checks such as current/voltage imbalance, and sell it as an electronic overload for several thousand dollars (e.g. Allen Bradley E3Plus, SEL 749A/Allen Bradley 825P, GE Multilin 269/269+/369, etc.). Or from your perspective if you really want the best protection that you can buy for a motor, connect 1 or 2 auxiliary contacts back to your PLC from the overload relay. If you buy one of those fancy overload relays, the second input can be an "alarm/call maintenance" signal, and you configure the alarms within the overload relay. Truthfully, these days the Allen Bradley E1Plus relays are cheaper, offer better protection, and more reliable than bimetallic or eutectic overloads. So I've pretty much gotten 100% away from buying anything but electronic overloads on new installations.

[bearsgone 1]

Thank you for the feedback. The logic here would be to calculate working hours for a pump. The only way, I think, I can tell if pump is running or not is based on current sense. In my situation a user starts and stops pumps with HMI but what if HMI pressed but pump did not come on for what ever reason. Would not current sense be the most sure thing that pump is actually running? Another reason would be if operator switches to manual mode, HOA, bypassing HMI. In this case current sense would be the only thing that guaranties that I do not loose operational hours. Later when I have 3000 work hours accumulated for the pump, I want to set the alarm for pump to be replaced.