Sign in to follow this  
Followers 0
Buckaroo

MCR

7 posts in this topic

I did not want to hijack the earlier thread but I have been meaning to post this queston here for a while now. Does anyone use the MCR instruction anymore? At one time i saw it quite a bit but now rarely run into it so I tend to forget about checking for it when I might me doing some online troubleshooting.

Share this post


Link to post
Share on other sites
It's: master control reset or something like that. You need to use two of this command in a block. When a condition is true what ever lines of the ladder in between will be ignored by the CPU until the first MCR becomes false. For security issues you have to make sure that you won't use it where inputs or outputs are related to security/emergency stop. I heard (or read) that experts can only use it because it can cause the process to be unstable at time. I have an oven where the programmer used it countless times through a complex program. We often have issue and the behavior is somewhat worrisome. I've studied it and could't always figures out why it was used. I cannot tell if it is this command or if it's because the power supply of the PLC is slightly not powerful enough. Soon I will change this P2 to a P4. I'll be able to see if this was the issue and not the command. There are seniors here who will surely post and give more advice. Hope I made some light.

Share this post


Link to post
Share on other sites
If it's power, then you will notice a red light on the power supply and you should easily be able to code a "power up" routine to catch this. Before doing this though, put an amp clamp on the power input to the PLC and check. If the power draw is within 80% of the rated full load, you may want to consider upgrading. Otherwise, it's a waste of money. Now, for that power up routine. In a PLC-5 or SLC, it can be something like this: XIC S:2/15 CTU C5:0 0 0. In a ControlLogix environment, you can use the F:S (first scan) bit the same way as the S:2/15 (first scan) bit. If you have these momentary "blinks" that you are referring to and you find that the C5:0 accumulator is increasing every time one happens, then you are having a power problem. In practice a PLC's power usage is pretty flat. I can't think of an instance where I had momentary glitches due to an undersized power supply on the PLC. I can think of instances where the PLC's power SOURCE was an issue and I had to add either a UPS or a power conditioner to maintain a stable power supply in the face of brown-out conditions. If the problem is just bad code with lots of MCR zones and all your electricians are scratching their heads, use my suggestion above and rewrite the code to get rid of them. It might still not solve the problem but at least you won't spend your time worrying about which instructions are actually running and which ones are just being converted into false conditions. Edited by paulengr
1 person likes this

Share this post


Link to post
Share on other sites
Paul a worthwhile post and I really learned something reading it. Thanks I'll keep the MCR replacement ttechnique you describe in my bag of tricks going forward.

Share this post


Link to post
Share on other sites
Safety and security are the same word in a lot of european languages... and québécois in this case. Edited by MikeSmith

Share this post


Link to post
Share on other sites
I use the instruction quite a bit. Works out nice when doing fault routines to help sort out faults based upon a particular condition. For example, I would use a power on bit for the MCR. So if my control power is off, I won't drive all my faults to my HMI.

Share this post


Link to post
Share on other sites
Really, the use of MCR's is not necessary in virtually all cases anymore. They were shortcuts in the past, especially in cases where there was only one long ladder file. Firstly, if it's a "Safety" issue, then you should have a safety PLC, or external hardwire interlocking anyway. Secondly, using them to organize code only makes the code more difficult to work on. You are better off using conditional subroutines. Thirdly, it is amazingly easy to make a mistake with MCR's, especially in the course of down-the-road program modifications. Finally (though I have other reasons to avoid them, I'm only listing the biggies here) MCR's make opening a program to troubleshoot something incredibly annoying. Cross-reference an output, go to it, see all the conditions are "TRUE", but the output is off... First thought, is there is some weird error. Ugh. YMMV

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