Logix500 bit Latched and Unlatched Simultaneously

I am using bit B3:50/1 as a trigger for my data logger in crimson3.

When B3:50/1 goes active on, B3:50/2 is set to 1 by crimson3. This unlatches B3:50/1. When B3:50/1 goes active off, B3:50/2 is set back to 0 by crimson3.

The past two mornings both the unltach and latch rung have shown as green. When I toggle it back to off, it begins working again.

I have the exact same setup running on another machine and it has not had any issues.

I started to write a reply then realized I made bunch of assumptions... so back track a bit, which address did you toggle? and what is I:1/11, why was it stuck on?

The I:1/11 is a push button and I want to record data from a bunch of sensors every time it is pressed.

I think what happened was B3:50 1 was never unlatched so that means B3:50/2 was never set to 1 by redlion.

I'm not sure why.

Again, which bit(s) did you toggle? Also, was the physical push button stuck? When you said both run were "green" I assume bit B3:50/2, I:1/11, B23:12/0, and B3:4/0 were all true, is that correct?

Putting all that aside for a second, I would do thing differently. "typically", for something like this, you don't need a handshake from your HMI. Say the operator presses the physical button, you just want to send a momentary pulse to the HMI saying - LOG THIS then move on to be ready for the next "LOG THIS" command, even if the HMI didn't get it that one time. That way, one momentary blip in com won't stop you from logging the following events.

The button was not stuck. I meant to say that I toggled B3:50/1 back off. The next time the button was pressed it started working again. The data log bit latched, the unlatch bit turned on, and the data log bit unlatched again. My data logger was triggered and the values were recorded.

If I don't include this handshake then the data logger never triggers because it occurs to fast for the hmi to register.

Think of this way, eventually you want to the PLC to give up getting the HMI to log the data.

Use a self-latch timer circuit to hold the "LOG THIS" bit for XX seconds.

Thanks I'll give it a shot.

How's this look?

That should work. You can extend the time out if you want.

Make sure you understand the difference between a highlighted instruction and a true rung. You said:

"both the unltach and latch rung have shown as green"

The rung itself does not show a true or false status. The rails turn green when the controller is in run and that is pretty much it.

Outputs (OTE, OTL, OTU) highlight when they are on. That does NOT necessarily mean the rung is true.

In the case of the OTU, if the output has been latched on, the OTU will show highlighted even if the rung itself is false. That doesn't mean the OTU is true, it means the output is on (technically it means there is a "1" in the address). The OTL and OTU will always appear to match. They will either both be highlighted or both will not be highlighted.

OG

Operaghost said:

In the case of the OTU, if the output has been latched on, the OTU will show highlighted even if the rung itself is false. That doesn't mean the OTU is true, it means the output is on (technically it means there is a "1" in the address). The OTL and OTU will always appear to match. They will either both be highlighted or both will not be highlighted.

Click to expand...

I think this is probably the crucial bit of information explaining your confusion. It sounds to me like the Red Lion simply didn't unlatch the bit, and so as OG explained, both the OTU and the OTL "coils" will be highlighted in green to indicate a "true" status.

Most likely there was just a brief glitch in the comms, and the message from the red lion saying "Set B3:50/2 to 1" didn't make it back to the PLC. It happens from time to time.

FWIW, my usual method here is to have the PLC set a bit when I want a data log to take place, and have the HMI reset that same bit. Then I just throw a timer on that bit, and if it's on for more than, say, a couple of seconds, I raise the alarm, because either the data log has failed, or the HMI comms have been lost, or something else has gone awry.