Latches question in compactlogix

So I know there is a lot of material on here about latch and unlatch topics, but I didn't find anything that helped shed some light on a problem I've been battling. I'm in a new job as of recently, and in getting used to all the "new" stuff I've been diving in feet first to some problem child machines...

My question is this: I have a compactlogix 1769-L35E V19 controlled machine, in which previous programmers have latched and unlatched real world outputs and so much so have latch conditions in one ladder and unlatch conditions in another ladder, what are some of the challenges or consequences of such programming?

The basic program structure is for "Main" to contain all the JSR's to the individual ladders, in no particular order. What I am experiencing basically is loops on the outputs where valves are cycling at nearly the scan rate...i'm really running into some walls on this and trying to avoid a total re-write, but in all my years of exposure to PLC's I have never encountered such a beast as this.

Well, the consequences could be from non-existent to random stops & deadlocks. It's also very difficult to modify such code and make sure that nothing else is affected.

Without seeing what you're dealing with directly, I'd gather some information on the machine & propose a plan to your boss on how you can clean it up, make it easier to maintain and prevent any trouble which may come up in the future by leaving this in.

I'm assuming you mean there are multiple OTL and OTU instructions for the same outputs. I agree that this can be a nightmare to troubleshoot. I agree with Vlad Romanov that the system could run fine, or you could get intermittent problems. I worked on a system like this once. I thought it would help if I moved all the OTL's into one routine and all the OTU's into another routine. This was a huge mistake, because this messed up the timing of the latching and unlatching and many things stopped working entirely. So my advice is, don't do what I did, if you have to rewrite logic then do it slowly and test thoroughly at each step of the way.

So...I kinda am the boss in a way...

I am pretty much 'the' PLC guy and my real actual boss would pretty much green light anything I wanted to do, so its not matter of selling someone on a solution, I'm just flat out unable to understand how to unravel some pieces. Its the classic machine runs all the time and is always behind so there really never is a time to shut it down and redo it, so were doing the piston rings while the motor is running.....via the tail pipe.

I guess what I am trying to get at is, SLC is synchronous correct? Logix platform is immediate updating or asynchronous? If so, what is the consequence of latching a real world output, or unlatching for that matter, when there are other XIC or XIO's out in the logic for the given address. For argument sake, there is only one latch/unlatch per instances, so not a case of multiple OTU's or some such. Can the asynchronous nature of latching a real world output create a situation where the intent was x but result y because the logix platform immediately sets the outputs rather than at the end of the scan?

hanlonmi06 said:

So...I kinda am the boss in a way...

I am pretty much 'the' PLC guy and my real actual boss would pretty much green light anything I wanted to do, so its not matter of selling someone on a solution, I'm just flat out unable to understand how to unravel some pieces. Its the classic machine runs all the time and is always behind so there really never is a time to shut it down and redo it, so were doing the piston rings while the motor is running.....via the tail pipe.

I guess what I am trying to get at is, SLC is synchronous correct? Logix platform is immediate updating or asynchronous? If so, what is the consequence of latching a real world output, or unlatching for that matter, when there are other XIC or XIO's out in the logic for the given address. For argument sake, there is only one latch/unlatch per instances, so not a case of multiple OTU's or some such. Can the asynchronous nature of latching a real world output create a situation where the intent was x but result y because the logix platform immediately sets the outputs rather than at the end of the scan?

Click to expand...

I would NEVER latch a real-world output, full stop.

I would never latch internal bits that drive real-world outputs either.

If I had multiple sequence or state logic that need to drive the same outputs, I would use interposing and unique "slave" bits, bringing them all together on a final "OR" rung to drive the outputs using OTE's. It makes it so much easier to trace back through the logic if all bits are unique, the cross-reference tool is invaluable.

In terms of the I/O updates, in the Logix5000 platform Output data is sent to the modules at their respective RPI settings, and different modules can be updated at different rates.

There is also an Output data update performed at the end of the scan of each Program, but those can be turned off if needed.

I don't like latches as when I get called to a down machine that is run with all latches and unlatches it always seems to be that there was one strange condition the programmer forgot to include to unlatch something.

I have gotten into some small automation machinery that was all OTL & OTU's and ended up writing a complete new program - that was faster than trying to dig through the program as it was. Unfortunately for production lines programmed that way a rewrite could take months, so start digging.

latching real world outputs is overall bad practice




imagine having a power blip, and then the machine starts moving before resetting the process.... sound dangerous? It's because it is.

I get that its bad practice. I also didn't write it...I just cant seem to unravel things past a certain point, so I was wondering if there was some fundamental thing I was missing when making the jump from SLC to logix with respect to this situation. I am under the impression that the machine was upgraded to a compact in the not too distant past, so someone somehow had to go from the SLC code to the new code and I suspect they just bit banged the logic, poor styles be damned.

see NFPA 79 electrical standard for industrial machinery.
i'm quoting from memory, no machine shall resume running when power is applied to the outputs without having gone through a reset.

in other words, the machine has to be homed first before resuming operations.
there are exceptions to this rule. please get a copy and read up on the rules.

If the outputs create a hazardous condition when the e-stop is reset, you need to fix the issue.

what I would do, is this.
watch the machine and study its operations, do a cell phone video if allowed, write down what is going on.
study the manual controls and how the operator uses these controls.

print out the program and see if you can follow the instructions line by line.
write notes if you have to on the paper.

then copy the program and rename it.
open the program and turn all bits off, then simulate the program offline one rung at a time from beginning to end.
yes, it's a royal pain, but you will get insight on what the thought process was when the program was written.
you then could modify the code a little at a time.
BUT !! save the plc program to the pc first and put a copy somewhere that it cannot be changed. then modify the code little by little.

before modifying the code, think about what you need to do, have a backup plan, and then do what you need to do.
BE prepared to defend your actions to the boss if something goes sideways.

james

This topic comes up every so often...

Here's a brief summary of my input.
The OTL and OTU instructions are not evil, they are ok to use.
If you code something so that it operates in an unsafe manner, your code is to blame - not the instructions you used.
If you code something so that it is difficult to maintain or troubleshoot, your code is to blame - not the instructions you used.
The OTL and OTU instructions can be used to make programs easier to maintain and troubleshoot.

Upgrading from a SLC to a Compact or ControlLogix can affect how the program operates. OTL and OTU can make this worse. It should have been addressed when upgrade was done, but that does not always happen. I have seem many upgrades that were not done right. You can do an update of I/O in code by using new bits instead of the actual I/O and updating the new bits to the actual I/O at the start and end of the logic. Cheezy but it will make it work like it did before the upgrade.

Might I suggest you try and obtain a copy of the original SLC program to see if the reason for the latches was an attempt to overcome some sync/assync problems from the conversion .
This might also help with understanding what the program is trying to do .

mellis said:

This topic comes up every so often...

Here's a brief summary of my input.
The OTL and OTU instructions are not evil, they are ok to use.
If you code something so that it operates in an unsafe manner, your code is to blame - not the instructions you used.
If you code something so that it is difficult to maintain or troubleshoot, your code is to blame - not the instructions you used.
The OTL and OTU instructions can be used to make programs easier to maintain and troubleshoot.

Click to expand...

I agree with that sentiment.

doctord said:

Upgrading from a SLC to a Compact or ControlLogix can affect how the program operates. OTL and OTU can make this worse. It should have been addressed when upgrade was done, but that does not always happen. I have seem many upgrades that were not done right. You can do an update of I/O in code by using new bits instead of the actual I/O and updating the new bits to the actual I/O at the start and end of the logic. Cheezy but it will make it work like it did before the upgrade.

Click to expand...

Moving real I/O to and from buffers is not cheezy. It's a legitimate solution for a program that requires synchronous I/O updates in order to operate properly. What can happen sometimes with asynchronous I/O is that part of the logic sees one state of a particular input while other parts of the logic see a different state for that same input during the same program sweep. Scan sequence can be critical with latch and unlatch functions.

I use OTL/OTU (or the equivalent depending on PLC brand) as little as possible. Here are a couple of problems that they can create if used indiscriminately:

Troubleshooting headache - If a bit is ON when you want it OFF (or vice versa), and it's latched and unlatched in multiple places in a program, it can be difficult to figure out which rung is the culprit. If I use sealing logic with an OTE, it's very easy to see the problem. When I have to use OTL, I try to put all the logic in one place.

Stuck bits - I've seen plenty of cases where a bit was latched on, then for some reason the conditions to reset it never happened (someone hit an E-stop, or a limit switch stopped working) and then the sequence would get stuck. If the bit is retentive (all of them in AB, and address/parameter dependent in other brands) they stay latched even when the PLC is power cycled. So once a machine is stuck like this it takes a PLC programmer to reset it. Again, sealing logic with an OTE means even if something in the logic sticks, a power cycle will reset it. Meaning the plant can wait to call you until morning... If I have to use OTL because I need the state to remain the same during a power cycle, I try to give some way for the operator to reset it if there's a problem.

I've seen plenty of programs that used a lot of OTL/OTU that worked just fine. And I've seen programs that didn't use many at all that worked poorly. So no, it isn't which it instruction you use, it's how you use them. However, I find that avoiding OTL/OTU makes me think harder about the logic and therefore write better programs that are easier to troubleshoot.

I seen specs that completely disallow latches. It's one of those thing that can get new programmer in trouble that's why often the rule of thumb exists.

My feeling, based on observation and my own experiece transferring from a DCS world is that new programmer often treat ladder like other high lever scripting language. Thus, they see latches as a godsend to make ladder look like a sequential scanned code. Of course, this is not how ladder works and this gets into them into big troubles. It's similar to the problem of using sub-routine incorrectly in ladder programming.

So, I often tell new PLC programmer not to use them until they figure out how to structure things properly and have a good feel for ladder.