FIFO getting off by one position rejecting the wrong bottle

[Peter Nachtwey]

The way this is done in hardware is to use D flip flops. For instance an encoder decoder will require the input phase to be high or low 3 times in a row before is says the input is high or low. Timers are not required. A BYTE can keep track of up to the last 8 inputs. If all the bytes are 0 then the output is a 0. If all the bits are one then the output is a 1. If 8 samples aren't required then use a mask to mask off unwanted bits. Typically a encoder decoder chip uses only the last 3 inputs.

 

[daba]

..... If the vessel is full I should not have a closed LL switch, your point is moot.

Yes you should, and you should have an open HL switch.

Are you just arguing for the sake of it, and you really can't see the point of the PLC restarting where it left off ?

I've put that debounce logic into ALL the projects I've worked on over the last 20 years or so with ZERO "problems" or "issues" to code around. In Logix5000 it's one of my staple AOI's, where EVERY input is "debounced" whether it needs it or not (zero timer preset parameters). It makes a job "clean", knowing that a tried and tested piece of logic is used for everything, and it synchronises the inputs to the scan as an added bonus.

You sound sceptical, but why don't you give it a trial and see if you get any problems from it. 5 brewhouses, 3 fermentation tank farms, 3 filter jobs, a stone cutting saw, an aggregate delivery system, and host of other smaller systems, have proven the idea of retentiveness on inputs that are "debounced"

There will be no further comment, we have hijacked the OPs thread enough.....

 

[daba]

The way this is done in hardware is to use D flip flops. For instance an encoder decoder will require the input phase to be high or low 3 times in a row before is says the input is high or low. Timers are not required. A BYTE can keep track of up to the last 8 inputs. If all the bytes are 0 then the output is a 0. If all the bits are one then the output is a 1. If 8 samples aren't required then use a mask to mask off unwanted bits. Typically a encoder decoder chip uses only the last 3 inputs.

Using hardware in the way you suggest is neat, but won't that impose the same debounce "time" depending on the sampling rate ?

Using timers in the PLC allows you to "tune" the debounce time for the specific input. As an example a Low-Level probe in a vessel may not indicate the vessel is "empty" at all, especially during CIP when there will be a substantial volume of fluid cascading down the sides of the vessel to be scavenged out, whilst the LL probe shows "uncovered" regularly.

In cases like that it is not uncommon to extend the LL Probe's debounce OFF time to 30 or even 60 seconds. I don't think a hardware solution can practically cut it.

 

[drbitboy]

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.

I think @daba makes a fair point; OTOH, Latched and Unlatched bits may also cause unintentional actions on a PLC restart of a RUN mode. There is also the approach below, which might (might) make the OTE-based debounce equivalent to latch. I freely admit to a personal bias against latch/unlatch for no particular reason. OYA3.H (On Yet A Third Hand), the symmetry and simplicity of @daba's approach, compared to what I called a "Cadillac," has its attraction.

By Cadillac I meant that often a 100ms TON for 0-to-1 transition is enough to debounce a switch and move on, while that circuit, functionally identical to @daba's for continuous operation but rung- and instruction-heavy, covers both transitions, and might be suitable e.g. for "switches" based on comparisons of analog process variables. OYA4.H, if there is analog noise for a process-based "switch" comparison, then instead of a debounce I might characterize the noise and offset the trigger 3σ instead of using a debounce, which is essentially the same idea in the actual domain (process variable) for which the debounce timeout is a proxy in the time domain.

Bottom line message to the programmer: thou shalt know thy process and make the call based on sound judgement.

 

[Peter Nachtwey]

I am trolling now.

Using hardware in the way you suggest is neat, but won't that impose the same debounce "time" depending on the sampling rate ?

Yes, if you want a longer time use a DWORD. If you need a longer time then there are other problems and you may be causing problems.
The forum only seems to be interested in de-bouncing ONE input ( HINT! )

Trolling

Using timers in the PLC allows you to "tune" the debounce time for the specific input.

When "tuning" the delay time, what do you consider?

In cases like that it is not uncommon to extend the LL Probe's de-bounce OFF time to 30 or even 60 seconds. I don't think a hardware solution can practically cut it.

There is a HUGE difference between detecting a level and an encoder.

The are a couple of 'teeth' you haven't extracted from the OP! What are they?

I really wish the OPs would post more in their first posts so I don't need to play 20 questions.

 

[daba]

Yes, if you want a longer time use a DWORD. If you need a longer time then there are other problems and you may be causing problems.
The forum only seems to be interested in de-bouncing ONE input ( HINT! )

Trolling

When "tuning" the delay time, what do you consider?



There is a HUGE difference between detecting a level and an encoder.

The are a couple of 'teeth' you haven't extracted from the OP! What are they?

I really wish the OPs would post more in their first posts so I don't need to play 20 questions.

My approach is suitable for ALL situations, is tunable to the application, and allows for the timing parameters to be changed "at will" by the program. win win, with no external hardware.

 

[daba]

I think @daba makes a fair point; OTOH, Latched and Unlatched bits may also cause unintentional actions on a PLC restart of a RUN mode. There is also the approach below, which might (might) make the OTE-based debounce equivalent to latch. I freely admit to a personal bias against latch/unlatch for no particular reason. OYA3.H (On Yet A Third Hand), the symmetry and simplicity of @daba's approach, compared to what I called a "Cadillac," has its attraction.

By Cadillac I meant that often a 100ms TON for 0-to-1 transition is enough to debounce a switch and move on, while that circuit, functionally identical to @daba's for continuous operation but rung- and instruction-heavy, covers both transitions, and might be suitable e.g. for "switches" based on comparisons of analog process variables. OYA4.H, if there is analog noise for a process-based "switch" comparison, then instead of a debounce I might characterize the noise and offset the trigger 3σ instead of using a debounce, which is essentially the same idea in the actual domain (process variable) for which the debounce timeout is a proxy in the time domain.

Bottom line message to the programmer: thou shalt know thy process and make the call based on sound judgement.

View attachment 60003

My concern is the incorrect status of debounced inputs until the relevant timer has timed out. My approach negates that. No call to be made, it's "built-in" ...

 

[drbitboy]

My concern is the incorrect status of debounced inputs until the relevant timer has timed out. My approach negates that. No call to be made, it's "built-in" ...

And I agree with that concern.

There could also be an equal concern for the incorrect status of latched or unlatched bits until the relevant timer has timed out; maybe you have never seen it but that does not mean it could not happen; it all depends on knowing the process.

 

[daba]

I think some people are under-thinking this.

The harm that can be caused by a total misrepresentation of a field input is way greater than letting the field input handler drive the logic.

In most cases, the situation will not have changed, so no harm done with my logic. In some cases field data will have changed, my logic captures it after the prescribed delay.

Telling your sequence or state machine that a level probe or sensor is opposite to what it was when the power went off is suicidal, unless you code around it.

I said I'd post no more, that's the last words I have on the subject.

And please, no more PMs calling me a freak ....

 

[Peter Nachtwey]

What input are we de-bouncing? I am assuming the encoder.

Is the encoder a single phase or dual phase?
What is the pulse rate?
How can you "tune" the delay if you don't know the pulse rate? Trial and error. OK but what if the delay is longer than the pulses every once in a while?
Also, we are not told if this is a dual phase or single phase encoder. A single phase encoder can generate multiple counts by rocking back and forth across an edge.
Now I am playing the part DMD pulling teeth.

 

[parky]

Hold on you guys, one thing that nobody has mentioned (I think only had a quick scan of the comments), is the bottle detector sensor seeing through the bottle occasionally, this is quite common, for example on the 90 Deg. angle a bottle thickness & edge will block the sensor but if adjusted wrong then when it reaches half way through the bottle effectively the thickness of the two walls may cause the sensor to see through, this applies even to special bottle sensors, had this a few times, the sensor detects the leading edge of the bottle, as it passes it may sometimes see through the two walls then see the bottle at the trailing edge. Of course this will depend on the bottle, is it clear, has it got some kind of embossing on it has it got label, does the colour vary over the bottle, slight variations in colour or thickness, all these can lead to spurious detections.
Perhaps it's as simple as slight adjustment of sensitivity, or angle etc.
Once had one on a bottle inspector, the sensor for the tracking would occasionally do exactly what the OP describes, it would on occasion throw the wrong bottle out.

 

[drbitboy]

Here is the original problem statement:

FIFO getting off by one position rejecting the wrong bottle
I have a bottle capper that is using an encoder and FIFO logic to track the free standing bottles passing through a bottle capper. ... There is a product sensor that loads the FIFO

As @Peter notes, it's been twenty questions since then, with zero answers.

Dear OP/@floyd2904,

Your PLC program is a model of this bottle capper process. The design of the sensors on the process and the program instructions infer some level of the fidelity of the modeled process with respect to the physical process. For example, the model may not know about bottles upstream of the product sensor, nor may it know about bottles downstream of the reject station. The PLC-modeled process has many assumptions, explicit and/or implicit, in its representation of the physical process. The level of fidelity of the model determines the accuracy, and validity, of those assumptions, such as

• how much the process moves a bottle for each encoder pulse
• whether, and how much, the bottle can slide or shift on the conveyance device
• how far the reject station is from the product station
• how to interpret the signal from the product sensor
• etc.

From the minimal information provided to this point, it is all but certain that one or more of those assumptions is either incorrect or not accurate enough to allow the PLC to reject the correct bottle; every response about your process in this thread has been an expression of some form of that concept.

So the answer to your request (which is at best implicit in the context of this forum, or perhaps the original post's purpose was merely to tell a story or anecdote to an audience you thought might appreciate it), all you have to do is collect all assumptions made by the model that are implicit in the PLC program and its input sensors, then evaluate them individually and in toto to deduce which assumption or assumptions are not up to the task, and finally use that deduction to determine how to fix the model.

Given the information provided, that is probably the most detailed response you will get that actually answers your (implied) request; the other answers are certainly fairly likely to help, and if I were you I would see if adding a debounce to some of the input signals improves operation, but without more information we cannot be sure.

If you would like a more detailed response, try providing more information, e.g. the PLC code, a full description of the process and its sensors, a sketch, photo, or video of the process. There have been nearly two dozen responses to your original post, and although some of them have been a riveting side-debate regarding a few approaches to debounce algorithms, I am not sure much has been accomplished to help you solve your implied problem.

Good day,

drbitboy, DMD

 

[parky]

I think first the OP needs to tell us is this a new system or if this is an existing system that did work & now is causing a problem, if the latter then PLC code is unlikely to be the problem (unless it has changed), on the face of it with little information & it is an existing system that has developed a fault then it is either faulty hardware or set up.
As others have iterated, if the OP wants some help then they must be more forthcoming with relevant information, we are here to help not do the job for them.

 

[Phrog30]

I think first the OP needs to tell us is this a new system or if this is an existing system that did work & now is causing a problem

+1. For all we know it has never worked correctly.

 

[daba]

Bottle sensing, in any attitude, with or without labels, clear or coloured, glass or plastic, full or empty, has been done for many years by many people, it is NOT rocket science.

Plenty of vendors out there would be willing to demonstrate their kit.

You pays your money on what they can offer in terms of reliability and cost.

Once you have sensing sorted, it's only a stone's throw to getting the software sorted.

Unreliable sensing is always gonna be a killer...