MCR Application

Can anyone post or explain a real, actual program example of where you are using the MCR instruction. I cannot think of a practial example to demonstrate why you would use this instruction Any feedback is appreciated.

I've never needed to use it because I usually have more complex alarm/safety routines, but I suppose it could be a simple way to drop power to a bunch of outputs if some condition is met?

Kind of a more "subroutine" based programming that most PLC guys tend to avoid.

The following may not be accurate for all brands.
The instruction itself is pretty much a holdover from the days before PLCs didn't have subroutines. However, there are two features that differentiate the MCR from a subroutine call that could be important. First, the logic within the MCR zone is executed whether or not the zone is active. This means less difference in scan time compared to a subroutine call. Second, all coil instructions within the zone are set to false, unlike subroutines where they retain their last state.

I'm going to go a step farther back with Steve Bailey's holdover comment. It really goes back to true relay logic. With relay logic it was very common to have a contact from a Master Control Relay (often the e-stop of the day, right or wrong) supplying power to all of the output logic. This design method was carried forward when PLCs came on the scene the make transposition of ladder circuit diagrams that much easier for early programmers. Now the instruction is just a holdover from early programming environments.

The function of the MCR can be duplicated by leading each rung in the MCR zone with the conditions controlling the MCR zone. So in the most fundamental sense there is no real good use for the MCR construct, especially the way the development environments I have used implement it. There isn't any obvious way to determine if you are in an MCR zone. That can make troubleshooting tricky, especially if you got to a specific rung inside an MCR zone via a serch.

I'm not sure how plcs handle MCRs from an implementation standpoint. I'm not sure if there is an optimization that will simply set all outputs in the zone directly to false if the conditions controlling the zone are false. But if there is an optimization then there might be a small scan time benefit.


Keith

Pretty much useless, and highly annoying.

Has anyone else out there tried to troubleshoot some logic just to find out that it wasn't turned on?

Has anyone else out there tried to troubleshoot some logic just to find out that it wasn't turned on?

Click to expand...

I've lost track of the number of times, both when I was troubleshooting on my own and when I was trying to help someone else figure out his problem.

Thanks. I'm still just looking for a real world application. The only thing I could possibly think of would be in commissioning a new machine where you would install some temporary logic (toggle bit) to enable/disable parts of the machine while testing. A soft E-stop if you will. The retentive nature of the outputs could be useful, but I still can't think of a real world application. Let me know if anyone has an example or example code.

in regards to your debug bits.

My standard program always has 2 defined and we require all oem's to use these bits.
b3/0 - unlatched - always off
b3/1 - latched - always on.

if something goes wrong we use these bits, not make them up.

We had that happen several years ago, oem created dummy bit and left it on.
mechanic somehow turned off the bit / word and the machine stopped.
10 pm call. oem had several of those bits. found them and removed them - 6 hours work. i'm on salary, so you know how I felt.

Now, we use those bits

james

Originally posted by PLC Sean:

I'm still just looking for a real world application.[/quote]

It is a functional instruction in a plc. Your question is kind of like asking "Give me a real world example of an ADD instruction". How you use it is really up to you.

In the purest sense, an MCR is an area control instruction. It isn't like a jump. An MCR will make sure that output instructions that are dependent on the rung logic status are evaluated as false when the MCR conditions are false. So "normal" output instructions are set to their false logic state. Things like latch instructions and math instructions are not evaluated.

You could use an MCR is you had, for example, 10 rungs that all started with the same logical conditions. You would combine the common conditions and use them to control the MCR and remove them from the 10 rungs, leaving only the uncommon conditions.

Most people use the MCR as you mentioned if they use it at all, as a soft e-stop. All the machine outputs would be in an MCR zone and would turn off based on the e-stop status.

Keith

I am just looking to see if anyone has used this instruction in a manner that normal scheduling can't easily accommodate. There is not a substitute for an ADD instruction (except maybe a basic up-down counter), but I can't think of a scenario where the MCR is a good solution. Let me know if anyone has a description or code to post of a real world application.

kamenges said:

I'm going to go a step farther back with Steve Bailey's holdover comment. It really goes back to true relay logic. With relay logic it was very common to have a contact from a Master Control Relay (often the e-stop of the day, right or wrong) supplying power to all of the output logic. This design method was carried forward when PLCs came on the scene the make transposition of ladder circuit diagrams that much easier for early programmers. Now the instruction is just a holdover from early programming environments.

The function of the MCR can be duplicated by leading each rung in the MCR zone with the conditions controlling the MCR zone. So in the most fundamental sense there is no real good use for the MCR construct, especially the way the development environments I have used implement it. There isn't any obvious way to determine if you are in an MCR zone. That can make troubleshooting tricky, especially if you got to a specific rung inside an MCR zone via a serch.
Keith

Click to expand...

Blimey Keith, you must have been in one of my classes !!

That is almost word-for-word how I describe my sentiments when discussing the dreaded MCR instruction....

In the A-B world, I don't think it helps that it isn't a pair of instructions with different names, (like UID and UIE for instance). Nor does it help that the current name for MCR is MASTER CONTROL RESET, and that is arguably wrong. When the instruction is TRUE, it enables the subsequent rungs, and when FALSE, it disables them. To be pedantic, the instruction should be called MCE - Master Control Enable, to better match its function. My memory is hazy on this, but didn't it used to be called Master Control Relay ? That would make more sense of how you construct the logic.

Anyway, as you say, a proverbial nightmare when debugging - you are staring at a rung that is showing Rung Logic Continuity, but the output is off, when it should be on.

My thought process would be....

Rung isn't being scanned.
1. Check that the subroutine is being called.
2. Check that it isn't being JMP'd.

Output bit being turned off elsewhere.
1. Check with cross-reference.

Conclude that it must be being controlled with an MCR.
1. Call up the Search facility, reconfigure it to search for Instruction Names, and remember to change the search direction to UP, and search for MCR.

OK, found the problem, MCR zone is RESET for some reason.

Now check that the programmer has done the job correctly, and used a "closing MCR" instruction (some don't, they leave it to the subroutine instruction END rung to do it!!).
1. Call up the Search facility, reconfigure it to search this routine only, remember to change the search direction to DOWN, and search again.

Not found, so assume the programmer was lazy, best to put one in so that anyone adding code to the end of this routine at a later date can clearly see that an MCR zone is implemented.

As a maintenance engineer, I'm not allowed to make changes, other than specific "corrections" to existing code, so decide not to bother adding the unconditional (closing) MCR rung, because it would mean a raft of paperwork, and I'd have to revisit the plant area to do the job, so just ignore the omission.

As already mentioned, whatever "permissives" are used on the opening MCR rung, I would put on every rung controlled by them, at least I will be able to see immediately why my output bit isn't on.

I've used them in situations where I have working code, but am trying to change the way it does a section of the sub. I'll throw an MCR in to ignore the original code without messing with it. But I never leave MCRs in final code.

kamenges said:

Most people use the MCR as you mentioned if they use it at all, as a soft e-stop.
Keith

Click to expand...

A soft e-stop !!

Now there's a contradiction in terms, lol. But let's not start that debate... It will surely take us into deep and dark places no-one wants to be....

Vince30 said:

I've used them in situations where I have working code, but am trying to change the way it does a section of the sub. I'll throw an MCR in to ignore the original code without messing with it. But I never leave MCRs in final code.

Click to expand...

That is incorrect Vince, the rungs of code within an MCR "zone" are still executed, but effectively with the "power-rail" turned OFF. That has the effect of turning off all non-retentive outputs, resetting all TON's, start TOF's timing, etc., etc.

If you really want to ignore sections of code, use JMP/LBL, that truly does ignore the jumped rungs.

PLC Sean said:

I am just looking to see if anyone has used this instruction in a manner that normal scheduling can't easily accommodate. There is not a substitute for an ADD instruction (except maybe a basic up-down counter), but I can't think of a scenario where the MCR is a good solution. Let me know if anyone has a description or code to post of a real world application.

Click to expand...

PLCSean,

As others have said: the instruction is pretty much in a PLC for compatibility/legacy purposes only. There are things it COULD be used for, but there is a better instruction/coding method for every single use of MCR that I'm aware of. I don't know of any situation where I'd recommend its use. If I found myself in a situation where I thought an MCR was a good/the only choice, it would make me honestly re-evaluate the code and its purpose.

Anyone still using an MCR is like someone who uses 4 add instructions in a row because they don't trust that newfangled multiplication.