Advice: Tracking a reject on a conveyor

Drbitboy: Just found a typo in the reject window of your conversion you have two B11:3/3 one should be B11:3/4 or you could miss a beat. don't understand the heavy logic for the pulse timer simpler form is
AN First Scan AN Txx.DN TON Txx, Pre xxms will work I have had in RSL where the timer on first scan does not like it's own DN contact to start it (I can only assume that this is a quirk) so if I did a self resetting timer I add a not first scan to reset the timer on first scan. Not had that on any other PLC however.
But the rest looks good. Personally I would put all the variables that may need adjusting in retentive memory so I could adjust them by forcing them while monitoring, if an HMI was used this could be an engineering setup screen. Even if fixed values are preferable I would put them on memory for commissioning and change them at the end for fixed values but did not do this as it may look too complicated. To be honest, I would even indirectly address the window bits for reject so that I could adjust the window position & length via a couple of retentive variables but that is going too far unless the OP is fluent in programming.

parky said:

Actually I was thinking ahead on that timer, the delay was done with the latch so that if the PE was a little before the reject it could reset the timer if the box left the PE so the latch was used to say yep I have the box in position on the reject even if the box left the PE.

Click to expand...

I think you are referring here to rung 6 in the FBD in Reject_Test.pdf. It made sense to me that the input (bit [Reject_Time_Bit]) to the [Reject_Time TON] is latched: we want [Reject_Time TON] to complete in all cases. I am pretty sure my RSL ladder logic is consistent with this idea.





My confusion is on rung 5: if the box leaves PE02, i.e. if bit [PE02_Pack_At_Reject] transitions from 1 to 0, before the 2 seconds of the [Reject_Delay TON] is complete and Q goes to 1, then [Reject_Time_Bit] will never be latched. At 1m/s, 2s is equivalent to 2m, so it would have to be a big box to keep [Reject_Delay TON] running to completion.


Maybe the [Reject_Delay TON] was meant to be a debounce, or noise filter, on bit [PE02_Pack_At_Reject] and the T#2s delay is meant to be less e.g. T#200ms?


Let me know.


My brother said photo-eyes are finicky; he had a label stomper foot randomly putting labels onto an empty conveyor i.e. when no package was present. Then he noticed it was not so random, but happened when someone walked through the photo-eye line-of-sight wearing green jackets with reflective stripes, or with a white hard hat. When maintenance declined to adjust the PE sensitivity, he ended up coloring a piece of cardboard with a black sharpie and taping it to the rail opposite the PE at a 45degree angle to eliminate the noise.


Oy weh!

parky said:

Drbitboy: Just found a typo in the reject window of your conversion you have two B11:3/3 one should be B11:3/4 or you could miss a beat.

Click to expand...

Nice catch, that's fixed now.

parky said:

To be honest, I would even indirectly address the window bits for reject so that I could adjust the window position & length via a couple of retentive variables but that is going too far unless the OP is fluent in programming.

Click to expand...

Yeah, I like that idea too. To make it simpler I can switch to BSL so the new bit (reject status at PE01) is pushed at B11:0/0, and then we check a <N>-element window starting at B11:0/[<window_start>], where <N> and <window_start> are set from that engineering screen on the HMI.


Shoot, if we did that, we could code the engineering screen to work in units of seconds (Multiply By One(tm)), so someone could use a stopwatch (or stopwatch app) to compare the process to the program.

This is very helpful, appreciate both of your time and for the PDFs drbitboy!

parky your post about the HMI parameters is a good idea, there is already an engineering parameter screen I can add to.

parky: aren't the timers redundant? We already have a constant stream of 100ms pulses, so position in the FIFO bit array is the analogous to time, and the position of the window where the current implementation does its ORs is really a function of time in the model, not position or distance.



So why not instead do an AND of bit [PE02_Pack_At_Reject] with some position <N> in the FIFO bits, and perhaps a extend few more besides as a window after a falling edge, and then the diverter window is some number of positions beyond that?

Yes that's another way of doing it, I had thought about that myself just as extending the fifo at the infeed into the packer, but thought it would be easier for the OP to understand. As we did not have any real info at the start on types/lengths of boxes, gaps etc. and where the PE's are located the times I used are purely arbitrary (and for me to see on the monitoring) I do agree on using the fifo extended as if the conveyor is stopped it will freeze the effective reject window whereas the timer would keep timing out and trap the box halfway in the reject & conveyor (should of thought of that one had that same scenario a few years ago doh.). As for the reject time itself, I think that should stay as why make it complicated a pusher or divert is going to be pretty fast. The other point I thought about regarding the window is if the PE is on the actual reject it would probably be used as a reject confirmation to check the box has been removed which makes the tracking rather than the delay even more of a plus.

[I pusned updated comments in the program to Github to duplicate this query]





One last (hah!) thing (rehash of earlier post):


Do you agree, that in Reject_Test.pdf on Rung 5,

• assuming bit [Pack_Reject_Detected] is 1, that
• if [PE02_Pack_At_Reject] goes to 0 (Box leaves PE02)
  • before bit [Reject_Delay.Q] goes to 1,
• then we miss the Set/Latch of bit [Reject_Time_Bit],
  • so [Reject_Time TON] does not start,
    • and the diverter does not kick?

More important, was that behavior intentional?


Update: I just realized that, if timer [Reject_Delay TON] does not complete, then timer [Reject_Time TON] will not start, and bit [Pack_Reject_Detected] will never be Reset/Unlatched to 0; so this is no longer a "did I understand your code?" query, but a "will it work?" query.



Because that is why I put the seal-in using bit [Reject_Delay.EN], to ensure timer [Reject_Delay TON] will complete; this ensures any rising edge of bit [PE02_Pack_At_Reject] will, if bit [Pack_Reject_Detected] is 1, eventually turn on timer [Reject_Time TON].

Actually yes & no, The window for the checking of the bits will be while the box is still covering the PE and the PE is on the reject station. but I do see a small problem if this is not the case, so if I was to change it based on the PE could become uncovered while not fully in the reject position I would just set another bit on pack detection and use that to drive the timer and reset it on the last rung. Perhaps I'm getting a bit in front but had I designed the system I would have used the PE on the station positioned to trigger the reject if the fifo window had a bit in it, this way it would eliminate the delay timer, also act as pack jam alarm if not cleared and conveyor running.

parky said:

Actually yes & no

Click to expand...

Yes you agree Reject_Test.pdf Run 5 would act like that, and no that was not intentional, right?

parky said:

...
had I designed the system I would have used the PE on the station positioned to trigger the reject if the fifo window had a bit in it, this way it would eliminate the delay timer, also act as pack jam alarm if not cleared and conveyor running.

Click to expand...

So eliminate the timer [Reject_Delay TON]? If so, then I would suggest that having the bit [Pack_Reject_Detected] starting the timer [Reject_Time TON] and that timer sealing itself in would accomplish the same thing (the sealed- and seal-in bit [Reject_Delay.EN] is then a proxy for a Set/Latched bit [Pack_Reject_Detected]).

the logic was written in the thought that the PE would be on the reject station so would not move off the PE while the reject delay was running and the reject would take place while the PE was covered. If this was a real system, the delay before reject would be very short or even zero, it is only there to allow positioning of the box by a small amount. This is all subject to unknown factors to be honest it would be pure luck to get it right without knowing the physical layout. Again it's down to how you would normally do a project, you get a spec, hopefully see some sort of layout or the equipment and discuss your proposals with the customer. we don't get that on here and it is just an idea for the OP to look at and adjust it to suit. After all, most posts here are very vague if not downright unintelligible. This is an example of what happened to me some years ago: I was asked to modify a strapping machine to automatically detect the length of the pallet, position it in the strapper and move it back or forward if the sensors could not see the opening in the pallet for 3 tries then alarm (the parts where a fork lift would normally put it's forks). the spec told me that depending on pallet length it would either use one or two straps and the positioning would be done by toothed wheels and proximities on the conveyors for measurement & position. Fine, what they did not tell me that there were a shed load of strapping patterns, single strap (ok length of pallet) double strap (ok again) cross strap (rotating to give straps both ways ok) under strap if no runners on bottom of pallet (Uh...), swords for straps if runners (Uh..), When I got to site it turned out there were over 20 strapping combinations, ability to override an auto strap pattern the list went on. so any prelim work I did on someone else's software I had to bin and start again oh and one other thing they had added they did not tell me about was the ability to override the head compression photocell and use the newly installed load cell for compression of the product.

parky said:

the logic was written in the thought that the PE would be on the reject station so would not move off the PE while the reject delay was running and the reject would take place while the PE was covered. If this was a real system, the delay before reject would be very short or even zero, it is only there to allow positioning of the box by a small amount.

Click to expand...

Good. I mainly wanted to make sure I was accurately representing the algorithm.

No problem, but as I said it's the idea not the code so beating it up a bit often produces new ideas you know the saying two heads are better than one (well in some cases lol).

And a final note to our OP: please tell us what ended up working and what did not, when you have time and it is convenient.

Yes it would be nice to hear some feedback, hope he has read all posts & hopefully he has found them useful.