FIFO getting off by one position rejecting the wrong bottle

[floyd2904]

I have a bottle capper that is using an encoder and FIFO logic to track the free standing bottles passing through a bottle capper. I have checked the encoder and found no issues with the encoder. The PLC is a compact logix 5370. There is a product sensor that loads the FIFO and no issues found with the product sensor.

 

[Steve Bailey]

When you say you're "off by one position", are you missing an element in the FIFO or getting an extra one?
An extra element suggests your logic might need a debounce timer to prevent multiple triggers from the same bottle.
A missing element suggests the placement of the sensor relative to the bottle might need adjusting.

 

[drbitboy]

Is it always off by 1?


Show your code, please; PDF is best.

 

[Phrog30]

Has it ever worked correctly? If so, what's changed?

 

[JTCat]

There is a product sensor that loads the FIFO and no issues found with the product sensor.

Floyd,

how did you verify that the sensor is working correctly? Do not judge sensors by the indicator light. You need to make sure the signal is actually being relayed .

Much of the process where I am employed uses OSF instructions and debounce timers to prevent unintended counting.

As the others have stated, please post the logic so that it can be examined for any issues.

 

[drbitboy]

Btw, the Cadillac of Debounce circuits is available at this link.

 

[daba]

Btw, the Cadillac of Debounce circuits is available at this link.

I beg to differ on the Cadillac of Debounce circuits. That one uses an OTE for the debounced state, and A-B PLCs will reset that on a Pre-Scan. This may cause unintentional actions.

It is much better to use two timer ON, each driven from opposite states of the input being debounced, each timer DN bit Setting or Resetting a retentive bit. That way the PLC will restart with the debounced bit in the same condition as when it went "off".

 

[Phrog30]

A-B PLCs will reset that on a Pre-Scan. This may cause unintentional actions.

So. Give an example on how this would cause an issue.

 

[daba]

So. Give an example on how this would cause an issue.

Think about it ... You are telling the rest of the logic the incorrect state of the input until the respective time has "timed out". In some cases that could be several seconds, minutes or even hours, by then the operators would have restarted processes or sequences, which will be given bad information about the state of the inputs. The PLC must remember the previous state, it's obvious.

The pic shows how I do it (Logix5000 allows this, SLC etc. would need two extra rungs.

 

[Phrog30]

Think about it ... You are telling the rest of the logic the incorrect state of the input until the respective time has "timed out". In some cases that could be several seconds, minutes or even hours, by then the operators would have restarted processes or sequences, which will be given bad information about the state of the inputs. The PLC must remember the previous state, it's obvious.

The pic shows how I do it (Logix5000 allows this, SLC etc. would need two extra rungs.

That's not an example. What system have you dealt with that kept "moving" while the processor wasn't running? You mentioned prescan, not enablein false. I have never seen anything that needed to remember the last field device state from power up or transition. Remember steps, states in sequences, yes.

 

[daba]

So. Give an example on how this would cause an issue.

Say an automatic background process that "tops-up" a buffer tank that has a high-level probe with a 30 second debounce ON time. The time was chosen to get the tank as full as possible before overflowing.

The PLC restarts, and you are not going to see high-level for 30 seconds, during which time the automatic background process kicks in, and the buffer tank will be re-filled, even though it is close to the overflow. That could be an expensive chemical going into the bund. My logic overcomes that issue, by having the previous state remembered.

 

[Phrog30]

Say an automatic background process that "tops-up" a buffer tank that has a high-level probe with a 30 second debounce ON time. The time was chosen to get the tank as full as possible before overflowing.

The PLC restarts, and you are not going to see high-level for 30 seconds, during which time the automatic background process kicks in, and the buffer tank will be re-filled, even though it is close to the overflow. That could be an expensive chemical going into the bund. My logic overcomes that issue, by having the previous state remembered.

The PLC was off scan for two hours, as an example... your example is not logical, at all! Using a timer to prevent overflow is dangerous, no matter how you do it. For all you know, the level is 10 seconds higher than it was before stopping scan.

Latching states isn't a terrible idea, but you haven't shown the necessity either.

 

[daba]

That's not an example. What system have you dealt with that kept "moving" while the processor wasn't running? You mentioned prescan, not enablein false. I have never seen anything that needed to remember the last field device state from power up or transition. Remember steps, states in sequences, yes.

What happens if you are on the step in the sequence that says the low-level probe in a vessel has gone uncovered, and it ends the current sequence and starts the CIP sequence ? What if the vessel is full of product at that time ?


All issues solved by using retentive states for your debounce logic.

 

[Phrog30]

What happens if you are on the step in the sequence that says the low-level probe in a vessel has gone uncovered, and it ends the current sequence and starts the CIP sequence ? What if the vessel is full of product at that time ?


All issues solved by using retentive states for your debounce logic.

Daba, last time I reply because you are just making **** up now, for your question I would not use a debounce, it would be a delay, most likely TON. Low level are typlically NO, so once high and timer done, I advance step. If the vessel is full I should not have a closed LL switch, your point is moot.

 

[daba]

The PLC was off scan for two hours, as an example... your example is not logical, at all! Using a timer to prevent overflow is dangerous, no matter how you do it. For all you know, the level is 10 seconds higher than it was before stopping scan.

Latching states isn't a terrible idea, but you haven't shown the necessity either.

It was an example I dreamt up to highlight the "window of misopportunity" that can occur with time delays.

What is so wrong with the PLC restarting where it left off ?

Whatever times you have in your "debounce ON" and "debounce OFF" timers will be totally irrelevant if nothing has moved, but even if things have moved, the logic catches up without signalling the reverse state, which in my opinion is the worst thing to do.

I have been doing that debounce logic for over 20 years, it was written that way because frequent brown-outs caused havoc at one plant, due to the process seeing the incorrect state of level probes etc. an a restart. So much logic was added to overcome the problem that it was like spaghetti. Fixing the debounce was the way to go, and not had a single issue since.