Sign in to follow this  
Followers 0
kcor

MATH REGISTERS

10 posts in this topic

HAVE A PROGRAM THAT CAME IN THIS WEEK FROM A MANUFACTURER OF PACKAGING MACHINES IN BOSTON THAT WE JUST PURCHASED. LOOKING OVER THE PROGRAM, THE FIRST TWO INSTRUCTIONS IN HIS PROGRAM IS CLEAR S:13 AND CLEAR S5:0, THEY ARE LABELED AS S13-MATH REGISTER S5-MINOR ERROR BITS BEEN TRYING TO FIND THIS IN THE MANUAL FOR THE MICROLOGIX 1200, WHICH IS WHAT IS IN THE MACHINE. COULD SOMEONE EXPLAIN? SENT THEM A EMAIL, AND REPLY WAS THAT THIS WAS JUST SOMETHING THAT THEY PUT IN EVERY PROGRAM. THERE IS NO MATH GOING ON IN THE MACHINE, IT IS SIMPLY PULLING DOWN A CARTON, ADVANCING IT THROUGH, AND ALMOST EVERYTHING IS DONE OFF THE MAIN SHAFT GOING THROUGH THE MACHINE, THAT HAS CAMS THAT MECHANICALLY MOVES CYLINDERS ETC. IS CLEARING S13 AND S5 A GOOD PRATICE? THE ENGINEER FOR THE COMPANY THAT BUILT THE MACHINE SAID THAT SOME OF THE MACHINES THEY SELL HAS ENCODERS, SCANNERS, ETC., SO HE USES THE SAME GENERIC PROGRAM FOR EVERYTHING, JUST REMOVES WHAT IS NOT NEEDED.

Share this post


Link to post
Share on other sites
Well I think I understand what he is doing. He is preventing himself from getting called in everytime a PLC fault happens. I am guessing that the bit he uses to trigger these 2 lines of code is the first pass bit S;1/15 If he using the first pass bit he is using the power up sequence to clear any minor faults (S:5/0) and the lower math register(S:13). If he didn't and an encoder over ran its register then you would have to plug your laptop into the PLC and clear the fault (S:5/0). Clearing S:13 just means there will be nothing in the math register low word on boot up. Not really sure why he would want or need to clear the lower math register. I personally do not think it is a bad pratice until you are trying to find what is causing the fault. Now if the clearing of both of these regesters is unconditional I think that is bad pratice. PLC faults let you know if something is screwed up. If you have to constantly clear these bits then you have a problem. Just clearing the faults on every scan is not fixing the problem, it is covering up the problem. If this is now your machine, take the conditions out and see if the PLC faults out. Or even make them resetable on the first scan only. I would pick the reset on first scan. It can save you from coming in at 3;00am. You will just have to hear "I had to reboot that machine all last might to keep it running" the next morning.

Share this post


Link to post
Share on other sites
i did take them out, and everything still works okay. I assume it was just something left over from another project, and he just leaves it in, since it does not seem to bother anything. thanks

Share this post


Link to post
Share on other sites
Clay is right on in his explanations of why programmers clear the math fault bits in MicroLogix and SLC controllers. I've done this many times myself, to keep the program running while I chase down where I made the error and caused an overflow or divide-by-zero. Sometimes I'll do it on small routines because I plan to add overflow limiting and user-entry checking later. Sometimes I even get around to it ! In the hierarchy of programming sins, disabling overflow faults is a venial offense.

Share this post


Link to post
Share on other sites
Greetings kcor ... in order to REALLY get to the bottom of this, we’re going to need more details ... the main thing that’s “not quite right” is that the original programmer seems to be “clearing” those addresses that you mentioned at the BEGINNING of the program - instead of at the END ... unless there’s more to this situation than you’ve mentioned so far, clearing those locations at the beginning of the program isn’t likely to prevent a fault condition from shutting down the system ... for a specific example, many SLC/MicroLogix programmers insert an OTU (Output Unlatch) rung to turn OFF bit S:5/0 at the very END of Ladder File #2 ... for better or for worse, this trick will prevent shutting down the system in MOST cases where a “math overflow” condition occurs ... but ... putting the same rung at the BEGINNING of the program (instead of at the END) will have little or no effect if a “math overflow” condition occurs ... also ... if you really want to dig into this, please recheck the addresses that you mentioned ... specifically, the address S5:0 is not a valid syntax ... perhaps you meant to say S:5 (or maybe even S:5/0) instead ... anyway ... many programmers do many things - without really thinking them through ... possibly this is one of those situations ... on a related note: several months ago I ran across a customer’s program for a PLC-5 that had a “last” rung to “unlatch” bit S:5/0 - exactly the same way that many SLC-500 systems are programmed ... the interesting thing is that most PLC-5 systems will NOT automatically fault in case of a “math overflow” condition - so “resetting” the “overflow trap” bit on a PLC-5 is unnecessary to prevent a fault ... and on top of that, in most PLC-5 systems, bit S:5/0 is associated with the status of Station #40 on the Data Highway Plus network ... specifically, that bit has ABSOLUTELY NOTHING to do with a math operation ... obviously in that case we were dealing with a programmer who had more experience with the SLC/MicroLogix platform than with the PLC-5 system ... like I said, many programmers do many things - without really thinking them through ... if you’d like to go further with this thread, please post your .RSS file ... there might be something really useful going on here - but based on what you’ve posted so far, I think it’s likely that we’re dealing with a certain programmer’s “just because” habits ... Edited by Ron Beaufort

Share this post


Link to post
Share on other sites
Thanks Ron You where correct about the address, i just typed it in wrong. I checked another program that we got in from the same manufacturer about 2 years ago, and he had the same code at the first of his program. i attached one of them. It just seems to be something he does. 8105_PILLOW1200PLC.RSS

Share this post


Link to post
Share on other sites
A word of caution: Make sure that doesn't void your warranty. If the machine builder were to get sticky about it he could wash his hands of the whole machine because you modiifed something, even though that wouldn't have an effect.

Share this post


Link to post
Share on other sites
I just took them out to see if everything would still work, which it did. Then put the original back in.

Share this post


Link to post
Share on other sites
A problem with A-B PLCs is that the processor can fault out and stop for math overflow, such as a counter maxing out or a divide by zero math function. If you ever had a process that stopped on a dime with the customer losing many thousands of $/hour, then found the quick fix to keep the processor running was to add 1-2 easy rung(s) at the end of the main file (unlatch S:5/0), engineers are inclined to add such a preventative measure to all their programs. For SLC-500 CPUs and preventing math overflow faults from stopping CPUs, check out page 4-3 of this document... http://literature.rockwellautomation.com/i...rm001_-en-p.pdf It may sound like a duct-tape solution for the real problem, but at least it keeps your CPU from faulting. I have run into strange situations where the CPU faulted for divide by zero due to the analog speed feedback, used for a speed PID loop going berzerk due to a failing encoder feedback signal. Better to keep the processor alive and develop alarm strategies to sense such a situation and bring the machine to a safe condition.

Share this post


Link to post
Share on other sites
well ... it looks like there’s still some educational juice left in this lemon ... here are just a few more details for accuracy ... let's keep in mind that we're talking about an SLC/Micro type system ... first of all, a counter CAN overflow (or even underflow) - but that will NOT automatically cause a fault ... the counter has its own status bits for those conditions ... since it doesn’t use S:5/0, a “shut down the system” fault won’t normally occur when a counter “rolls over” ... next, notice that the “original programmer” in this particular thread is not locating his “reset” rungs at the END of ladder file #2 ... instead he’s locating them at the BEGINNING ... this is UNUSUAL to say the least ... now we haven’t dug all the way through what effect this unusual rung location is going to have on the operation of the system (yet) ... but it is NOT likely that having a “reset” rung located at the BEGINNING of ladder file #2 is going to prevent a “Math Overflow” fault condition ... that is pointed out in the text linked by kaiser will ... if the overflow occurs AFTER the reset, then a FAULT is still going to occur ... another point ... many people say that we should NEVER EVER use that little unconditional “unlatch” trick for the SLC/Micro “Overflow Trap” bit - and actually in most cases I tend to agree ... because in some systems an unsafe situation could occur as a result ... but that brings up the following question: how many programmers for PLC-5 and ControlLogix systems ADD the extra logic necessary to make those processors fault whenever a “Math Overflow” occurs? ... specifically, those platforms CAN certainly have “math overflows” too ... and like the SLC/Micro’s, they DO have “math overflow bits” ... but unlike the SLC/Micro platforms, a “shut down the processor” FAULT will not normally occur whenever an “overflow” takes place in a PLC-5 or ControlLogix system ... now yes, we CAN add the programming code to make such a FAULT happen for “safety reasons” - but most programmers don’t take those extra steps ... so if the “sauce is good for the goose” why isn’t the same sauce being used on the gander too? ... the point is that if we accept the perfectly valid argument that the SLC/Micro “math overflow” bit should NEVER be “bypassed” - then why do we normally allow what amounts to a “built-in bypass” to exist in a PLC-5 or ControlLogix system? ...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0