MCR instruction in CCW

[Lgillespie.5]

What instruction does CCW use for the MCR instruction from RSLogix500? I read in numerous places that CCW does not have an instruction like the MCR

 

[77nomad]

The SUS (suspend) function may be what you're looking for.

 

[Lgillespie.5]

How does the SUS instruction in CCW compare to the MCR instruction in Rslogix 500? I can't find any information on it besides the help window of CCW and it doesn't help at all.

 

[77nomad]

The way I read it is the SUS suspends the PLC from scanning. Where an MCR function allows for selected "zones" of outputs that get disabled.

 

[Lgillespie.5]

Ok but the description I keep finding is that it suspends the plc from scanning indefinitely. What about the TND instruction? I am trying to skip from rung 10 to the last rung on my ladder diagram for the program I made.

 

[Lgillespie.5]

I am using a Micro830 2080-LC30-48AWB controller

 

[I_Automation]

The TND would stop the scan and start from the beginning.

Any outputs that were ON after the TND would stay on as they are not being scanned.

A MCR zone shuts off all non-retentive (OTE) outputs in the zone of it is not enabled, which means the rungs are scanned to turn them off.

The best thing would be to create a MCR_Bit and XIC it on every line with an OTE to enable the rung.
Just before the end of your MCR zone XIO MCR_Bit then OTE MCR_Skip Bit.
On the next rung put a LBL MCRSkip.
At the start of your MCR zone add a rung XIO MCR_Bit XIC MCRSkip then JMP to your label.

 

[I_Automation]

For better readability here is a hand-made MCR Zone that will work on any platform without the MCR command:

 

[cidchase]

That.

 

[daba]

For better readability here is a hand-made MCR Zone that will work on any platform without the MCR command:

I can see that your posted code will work effectively, but cannot see the need for the JMP/LBL combination. IMHO that just clouds waters.

All that is required is to use XIO MCR_Bit as the first instruction in any rung you want the "MCR" to be actioned. Let the PLC scan the code anyway, your scan time reduction will be minimal, and the same scan time as if you had used an available MCR instruction.

This also means, of course, that your "outputs" code is no longer "position dependent", and you can then use MCR_Bit anywhere to control the outputs.

It also means you can have "multi-level" pseudo MCRs, each controlling its own set of "outputs" - e.g. you could have "MCR_Pumps", MCR_Valves, MCR_Drives, MCR_RunTimers, etc., etc. You can interleave these MCR_xxxx bits as much as you like, so you can program your outputs in the order that suits the application, rather than suiting the PLC and its "language".

One of my pet hates with MCR is that it is not visible on the programming software why a rung is not turning on an output bit. My thought processes have to make several iterations before I can see why - is the rung in a subroutine not being scanned - is the output "double-addressed" and being turned of elsewhere (could be word, or even file-level) - is the rung being jumped - is the rung in an MCR "zone".

All of the above has to be searched for, you cannot x-ref MCR (no-reference), and to x-ref a JMP you have to know its reference. All this searching (and sometimes you need to switch back and forth between "Search Down" and "Search Up" to make sense of it), takes expensive time while a machine is idle, or a process is in detriment, or a PV is going out of control, lots of scenarios .....

IMHO everything that controls an output bit (internal or external) should be present on the rung itself, so an engineer, technician, or whoever, none of which may be familiar with the code, can easily see which bit is preventing the output from being turned on. Debugging is a breeze if you can see everything !



True story : another engineer on a job was tasked with adding an output for ventilation fans to cut in if the oxygen level in the area fell below a preset (but still safe) value. Tested, and worked fine. A few months later I had to do a 600 mile round trip to find out why the vent fans didn't work in the event of an emergency stop in another, totally unrelated area of the plant. It turns out he had put the fan output inside an MCR zone, without realising he was in one, and, in his words, "because the outputs appeared to follow "some sort of order".

As an SSE for an SI, I would not allow MCRs, JMPs/LBLs (only if absolutely necessary), AFIs, or shorted branches. Our coding "standards" were written and enforced at all stages, even to the point of verification following site modifications.

 

[I_Automation]

Daba,


Personally I do not use MCR zones, and the JMP/LBL I only use for large sections that would be useless to process every scan, a few rungs (as I have seen some MCR zones) wouldn't be worth jumping over. And if it is called for I put the code to be jumped over in a subroutine of its own with a conditional call to avoid the JMP.



I do like the "MCR_Pumps" along with a main MCR bit, that idea I will borrow. Thanks



And, along with AFI's and shorted branches (which I never have done and have programmed them out when I come across them) I do not like connecting to a PLC and seeing the Forces Enabled tab lit up. To me that means something went wrong and had to get around instead of fixing the probelm - whether it was in the programming or on the line.