*Onsite right now* RSLogix500, Unlatch with no contact on the rung???

[Aardwizz]

Should have been written with just an OTE instead.

Not necessarily.

There can be many places where different parts of the program need to command the cylinder to extend or retract.

The programmer has the option of:
A) each instance having its own OTE, and then branching all the OTEs together to do the extend command;
B) have a common "Extend" bit (B10:5/14) that they all OTL, to send a "message" to the cylinder, and then the logic that does the actual handling of the cylinder clear that message after it has been acted upon.

Option A is easier to troubleshoot, because you can trace back to which sequence is making the "extend" call.
Option B is easier to program and maintain, because there is only the one place that any sequence needs to write to. If the code is well organized (as it looks like this one is), then each word in B10 controls a different device, and bit 10 is always the mode (Auto/Man), bit 14 is always be the "Open/Run/Extend" command for that device, and so on.

 

[Nova5]

IF the program wasn't changed and its not operating now.. dont worry about the program logic. Use it to see what input isn't acting to make the cycle run. Is there a bit or word level MOV writing to that binary bit or whole word? The unlatch wouldn't suggest so unless the mov is on a timer to keep it from hitting every scan cycle. Plus I don't know of a cyclinder than can fire in a scan cycle unless the cylinder has its own controller than can detect a single scan cycle long output pulse.

 

[celichi]

Plus I don't know of a cyclinder than can fire in a scan cycle unless the cylinder has its own controller than can detect a single scan cycle long output pulse.

That is an excellent point you have made there.

Post the acd file somewhere.

 

[nyanpasu]

You could use the Auto Request XIC to latch a test bit with no unlatch and see if it ever comes on if you think the problem is that the command is just not requested.

Sometimes if you rely on just the interface the results can be counterintuitive.

 

[Phrog30]

You could use the Auto Request XIC to latch a test bit with no unlatch and see if it ever comes on if you think the problem is that the command is just not requested.

Sometimes if you rely on just the interface the results can be counterintuitive.

I would have a fit if I had to work with code like this...

 

[AutomationTechBrian]

Well... nothing dramatic about the solution today. I got there and just focused on the I/O. I found a section of "enable" bits for different components. I methodically went through several of the suspect components, and when nothing seemed to be wrong, I called a time-out and asked their PLC tech if he could call a machine operator over to try it out again. She came over, set the machine up, pushed start, and voila... it worked! We don't know what went wrong earlier this week, but it went away. They'll call if it happens again.

Thanks for the posts, everyone.

 

[nyanpasu]

Those are the best ones. Sometimes a component just on the verge of total failure that is acting up. Other times it's a code 18 and someone looking over their shoulder was enough to get them to operate as God (ie. the original programmer) meant them to. Other times it's just a total mystery and they never call again.