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.

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.

That's pretty close. What it does is that when it reads the first MCR instruction if the rung evaluates to "false", then it goes into a special mode similar to prescanning.

There are 3 output instructions on a PLC that have a special status. They are called "non-retentive" instructions. Those three instructions are OTE, TON, and TOF. All other output instructions are "retentive" types.

Just as with a prescan, whenever the scanner sees a non-retentive instruction, it evaluates it just as if the rung is false, no matter WHAT the actual ladder conditions are.

ALL other output instructions operate normally.

Whenever it hits the next MCR instruction (which is required to be an unconditional instruction), or the end of the program, it turns off the special MCR scanning and goes back to evaluating things as if nothing happened.

There are two key points here. First, the advantage is that if you have a whole bunch of rungs for different parts of a batch system, or alternatively if you have a whole bunch of rungs that start with something like "XIC Auto" or "XIC Manual", then you can make all the non-retentive outputs evaluate to false, which makes your program shorter. This makes your program run faster, too.

However, most people mistakenly believe that the rungs are simply skipped and not executed at all. So they write whole sections of their program with an MCR instruction at the beginning and at the end and expect that all of the instructions will be disabled or close enough to disabled that everything will work as expected. This is totally false, and what usually happens after that is usually some very strange and unpredictable activity. Remember, the rungs are still evaluated. Retentive instructions (anything except OTE, TON, and TOF) are still evaluated and handled normally. The rungs are not "skipped" at all. So if you aren't really, really careful about how you program your code, and if you mix retentive and non-retentive instructions, you can be in for a very nasty surprise.

To me, it's just plain hard to use MCR's without bugs except in some really simple code. For my personal sanity, I don't use them, and I strip them out of programs that have them when I go in to work on the program. Here's an easy way to do it as a first pass: First, delete the MCR and replace it with an OTE to a bit. Let's just call it "Zone". Now, read down through the code. For every rung that has a non-retentive output instruction (remember, OTE, TON, TOF), add "XIC Zone" to the beginning of the rung. When you reach the second MCR (if any), delete it. That's it.

Now you may very quickly find ways to simplify and improve the code. But at least if MCR's are confusing you, it won't be confusing any more.



Actually, this is partly right. There is no "security" issue. There is a safety issue. An MCR instruction is NOT a substitute for an Emergency Stop in MOST cases. However, it is very dependent on the safety code you are referring to. For instance, the burner management codes so far almost all require a true hard-wired master fuel stop circuit that is independent of PLC control. Machine safety codes often require a level of reliability (such as SIL 2 or more, also known as "control reliable") and require safety grade hardware that is well beyond the capability of a PLC in the first place. All machine safety codes that I'm aware of with the exception of OSHA's specific requirement for an Emergency Stop circuit for presses have pretty much eliminated emergency stop circuits. The risk assessment codes don't level room for an "unknown problem with an unknown outcome" for which the old knee jerk reaction of putting an emergency stop on it was always the "solution".



I just described how it works above. It's not unstable. It's just that it is difficult to troubleshoot and program in code where some instructions work as expected part of the time, and others work as expected all the time, and you have to carefully look at all the code to figure out whether it will work as expected all the time. It's sort of like using ONS, OTL, and OTU. All three instructions can be a source of lots of frustration and confusion. But once you understand what they do and how to avoid programming in transition-based logic (trying to stay with full state logic wherever possible), you will know where to use them to make code simpler and more understandable.



If this is a batch process, chances are the programmer used this rather than some other technique. I've mentioned writing state machines using an integer register in the past. If you are really that concerned about performance, a subroutine call (JSR) works even better than MCR zones. An SFC can also be used as an organization tool which then turns into a series of JSR's.



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.

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.

Safety and security are the same word in a lot of european languages... and québécois in this case.

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.

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