Advice: Tracking a reject on a conveyor

instruward said:

I know I can make it work with timing, but it won't be robust.

Click to expand...

[I see just before I post this that you are going the timer route first - good!]


Don't give up on the timing solution; parky says it is robust, and he has a lot more time in this industry than me. Also, apparently it works in Meccano!



Also and primarily, timing will be much quicker to implement, and frankly it is a lot easier to grok. Quickly getting any solution working reasonably well might impress management and get you the latitude to justify trying the other; doing it the other way 'round (i.e. taking longer to do the hopefully better solution first) might instead erase attaboys and put you in the hole. That said, I expect you know your own political situation.



Finally, you will almost certainly learn some things about the process by doing the timing approach that will make the boxes-as-encoder approach coding go quicker (if you ever get there ).


I think boxes-as-encoder will work and is possibly more robust*, but there are too many fiddly bits:

• checking that that bit from left field is 0 before doing this other thing - I'm not convinced I caught all of these
• a lot of latching, explicit and implicit
  • Not a bad thing per se, but easy to get wrong, and downright ugly to debug
• The ordering of the rungs is critical to ensure correct operation, because certain states have to be known before other steps can be taken
• KISS: parky did it in six rungs; I have almost twice that and they are laden with (snow-covered) branches.

* though once it's tuned, the timing approach with windowed rejection is going to be solid as well, as long as conveyor speed is constant. Also, boxes-as-encoder will be sensitive to closely-spaced boxes; the timing approach I suspect not as much.




[Gosh I just read this again; too many qualifying statements to count, and multiple levels deep. Is there a simpler way to say "ugg. me engineer?"]

parky said:

I have not tried Drbitboy's code but there is another angle and I trust his skills and that it works.

Click to expand...

Dang it, Kombucha all over the keyboard again!

instruward said:

I still need time to read through all the replies.

Click to expand...

Nah, parky wrote up a solid solution with a high probability of success: read his PDF; get it working.


Then you can start sub-optimising (inside joke between me, my brother, and my late father).

Funnily enough, while I was talking to my colleague, he reminded me of a project we was working on in the early 80's, a de-watering plant & sludge conveyor system, we were given a spec for a elevated conveyor that rotated across an arc where a number of skips were placed, the skips were loaded in the arc on weigh stations the idea being that when one was full it would move onto an empty one. The spec was full of holes you could use it as a cullender. We had not even seen the system but were expected to write the control based purely on the spec given. We actually placed an order for a Meccano set a motor etc. and mounted them on a board the skips were simulated with pots & switches (Weight & skip present), On pre-installation testing with the customer we were able to demonstrate all the problems that could happen. we were paid to re-write the spec based on the demonstration, that is how the conversation the other day led to borrowing the Meccano set. While on the project in the 80's I was called in to the accountant's office to explain why I ordered a Meccano set. It took some convincing them I can tell you.

parky said:

in the early 80's, a de-watering plant & sludge conveyor system,

Click to expand...

Heh, in 1982 I worked at a refinery in Hampshire, off Southampton waters. There was a DAF - Dissolved Air Flotation - unit to reduce the oil content of waste water, or vice versa. It was an interesting thing to watch, and if anything went wrong there was hell - and fines - to pay.

Fyi

Don't stop working on the timer solution, but later you can look at the CTU/CTD solution my brother came up with. The use of CTU/CTD, which have internal edge detection, eliminated almost all of the one-shot and latching folderol in my approach, so it's much cleaner: 4 rungs and 23 instructions (non-first-pass).

It is in that same github repo as REJECT_TRACKING_B.*.



You'll need to fiddle with the last rung to do the MSG logic that is specific to your actual process.


https://github.com/drbitboy/PLC_reject_tracking





He also said he has seen situations similar to yours: the process hardware is unsuited to the task but already in place, and you have to make it work; it's a pity that, when you do succeed, few outside this forum will recognize the accomplishment.

So I have half of it implemented, but I am running into a few issues. I have a BSL which monitors a rejected box entering the zone between my two PE. But I don't really understand the rest of the code.

If I have a stream of boxes, Good, Bad, Bad, Good. Are they not all going to get rejected? I'd like to do this with timing, so it's done but I don't understand how it would work correctly.

There must be a way to read in a stream of good/bad reject status at one PE and then act on the reversed stream leaving the other PE right before the reject conveyor...

Edit: drbitboy, I've just seen your post today. I'm going to read it right now over lunch. Thanks,

instruward said:

There must be a way to read in a stream of good/bad reject status at one PE and then act on the reversed stream leaving the other PE right before the reject conveyor...

Click to expand...

You don't have to reverse anything; use BSR so the bit of interest to every downstream PE2 event is popped off the FIFO from position FIFO[0]; also, you are going to have 0-valued bits in the FIFO for every non-reject, not-to-be-diverted box as well. In other words, there will be one bit in the FIFO per tracked box. Also, you do not put the 1- or 0-valued bit at the head of the FIFO with the BSR, you put a 0-valued bit there and change it later when it is closer to the tail of the FIFO. Also, the PE2 event triggers the BSR; the PE1 event does not trigger a BSR. It could be done the other way, but the concept is the same.




Details



The key is that there is a bit in the FIFO for every tracked box, whether rejected or not, plus some extra bits for un-tracked upstream boxes that have not yet hit PE1.



A tracked box is a box that has triggered PE1 but not yet PE2.


The FIFO of bits is bigger than the number of tracked boxes.


The BSR triggered by a downstream PE2 event adds add a 0-valued (future box is assumed okay - for now) bit at the head of the FIFO i.e. bit index 63 in the FIFO, and that index 63 is way beyond any tracked box the system will ever see, so it represents a future box that has not yet made it to PE1.



You also keep track of number of tracked boxes in the range [PE1E2), we call it BIT_INDEX_AT_PE1.



Then one of two things happens:


1) A new box triggers the PhotoEye PE1
1.1) If that box is a reject, rite a 1-valued bit for that new box at index BIT_INDEX_AT_PE1 of the FIFO
1.2) Increment BIT_INDEX_AT_PE1, to maintain the model of the number of boxes in the range [PE1E2).


N.B. in our latest implementation REJECT_TRACKING_B.RSS, we reverse those two steps and do the increment via CTU first, which means the bit that is written is at index (BIT_INDEX_AT_PE1 - 1).



2) The next box to divert, or to not divert, triggers the PhotoEye PE2
2.1) Pop (BSR) the oldest bit from tail of the FIFO
2.1.1) If that popped bit is a 1, divert that next box
2.1.2) If that popped bit is a 0, do not divert that next box
2.2) Decrement BIT_INDEX_AT_PE1




Say index BIT_INDEX_AT_PE1 is zero, so there are no tracked boxes, and a box A triggers PE1*. At that time, the reject input is 0 (box A is okay and not a reject, and it should not be diverted). So you leave FIFO[0]=FIFO[BIT_INDEX_AT_PE1]=0 and increment the index to 1.


Then a box B triggers PE1, but the reject input is 1 so box B is a reject and should be diverted. So you latch FIFO[1]=FIFO[BIT_INDEX_AT_PE1]=1 and incrment the index to 2 (two tracked boxes).


Note that you did not trigger a BSR for either PE1 event; you only wrote a bit into the FIFO somewhere after the head of the FIFO.



Then box A triggers PE2: you trigger the BSR to pop the zero from FIFO[0] and shift the rest of the bits down 1, so FIFO[0] becomes 1. You decrement BIT_INDEX_AT_PE1 to 1, and the popped zero tells you to not divert box A.


Then box B triggers PE2: you trigger the BSR to pop the 1 from FIFO[0] (placed there by the previous BSR for box A) and shift the rest of the bits down 1. You decrement BIT_INDEX_AT PE1 to 0 (no more tracked boxes), and the popped one tells you to divert box B.


So there are only two events: new box triggers PE1; tracked box triggers PE2.


The rest is housekeeping: increment or decrement BIT_INDEX_AT_PE1 so you know how many tracked boxes there are and where the next okay/reject bit goes in the FIFO; write a bit at FIFO[BIT_INDEX_AT_PE1] for a new box or pop (BSR) a bit from the tail of the FIFO to tell you what to do for a box that just triggered PE2.





* nothing can hit PE2 at that point, because the index is 0 so there are no tracked boxes, and a box has to trigger PE1 before it can trigger PE1

Try using a timer & fifo as per my post.
Explanation.
The timer acts as a pulse generator and by default the bit it drives is on for one scan each time so for an example we have a shift register of 100 bits long (or as many as you want for better resolution). All the time the conveyor is running and no reject box then every timer pulse, a zero is put in bit 0 (assume B3:0/1 in your case) When a box arrives at PE01 And you get a message for reject (this could be + or - a few shifts due to coms) this is your window to detect the box on PE01 then put a one in the fifo, the fifo shift will move the 1 along the shift register and any other reject boxes will follow so no need to do any pop on pop off. Assume the conveyor was 50ft long then there would be a 0 or 1 (2 bits of the fifo) every 6 " when a box is at the end of the conveyor as detected by PE02 in there is a 1 in any of the bits (for this purpose bits 90 to 95) then initiate the reject i.e. this could be a delay + a reject time to clear the box.
It is just a matter of getting the pulse timer at a rate that gives you a reasonable resolution at the conveyor speed to have a window large enough for reliable message coms to at least get the message within the time the box is on the PE01. the number of shifts will depend on the speed of the conveyor and the box Min size. The system I did had a prox on the conveyor drive, however I have done one with timers before: to commission it I placed a box on the input, triggered a reject (well in my case it was a word shift either a store number or overweight, I also added a counter that was triggered off the pulse timer that was zeroed at the time of a reject, when the box reached a divert station the PE on that station also moved the counter value into a register so I new that somewhere in that window was the number of the shift register for example Word 0 was the start and word 100 was the reject station I then gave it a window of word 98 to 102 and then watched as boxes were passing the divert PE to get the range window right as a matter of fact, on the one with a pulse timer I started at a shift window of 100, watched and it was found that the window was 99 to 101 but left it at the original for repeatability.

Just another thought, I cannot find my USB stick with my RSL licences on it so could not write in in that format but perhaps drbitboy would be so kind

parky said:

Just another thought, I cannot find my USB stick with my RSL licences on it so could not write in in that format but perhaps drbitboy would be so kind

Click to expand...

huh? I have RSL micro starter lite (micrologix only, basically). what exactly are you asking?


seriously, I can code, but the whole rsl-software-o-sphere is this big amorphous unknowable black box to me.


wait, you want me to code your algorithm?


I WOULD BE BLOODY WELL HONORED!

Well you might be better than me the last time I used it was 2008, had such a run in with Rockwell & their strong arm tactics being the software manager I junked RW in favour of Siemens & Mitsubishi. But if I find my USB I will have a go just for my own satisfaction.

Okay, same repo: https://github.com/drbitboy/PLC_reject_tracking; parky's approach is in reject_tracking_parky_timer.*.



instruward: I buffered the inputs at the beginning and the diverter output at the end, so you could hopefully plug this in to your physical inputs. And obviously you'll have to tweak the parameters (FIFO Length in particular; timer duration would be another thing and that would change FIFO length as well), and replace my silly timer rung with a real timer.


parky: I took your PDF Reject_Test.pdf from here, and I hope I implemented the gist of it correctly, but I did take some liberties, partly because I was not sure I was grokking the FBD correctly, and partly because I "knew better."


Specifically, on your FBD Rung 5 (below), doesn't the XIC(PE02_Pack_At_Reject) before the [Reject_Delay] TON cancel the timer before the timer is done if that XIC goes false? So I sealed in that first timer.



And we'll see how "clever" I was in cascading the timers to eliminate the Reject_Time_Bit (it is now the done (DN) bit of the Reject_Delay TON). Since instruward is sending a MSG instead of controlling the diverter directly, he will likely have to hack away that section anyway.



And please forgive me for building my own pulse timer; I did some work on different timing schemes and have been wanting to try this algorithm out.

At some point maybe I'll get time to add my simulator.


Anyway, let me know if you want anything done a different way; it's got your name on it after all.

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. I suppose I could have used a pulse timer but I tend to always use a turn on even when I want a turn off just my quirky way I suppose.
One other point regardless what type of tracking he uses, he did state that he would be able to do some mods in the packer PLC, if there is a spare output why not just send a digital pulse rather than coms, this would depend on spare I/O & distance. Another thing that comes to mind on my design is the shift register does not have to be limited to the conveyor on the reject line it could extend into the packing machine however, it would mean the conveyor speeds need to be matched, but if the difference was small the windows for reject capture would probably be large enough to cater for a slight variation. The way the timers work in GX Developer are different, a standard timer is like the old style where there is no ACC or TT there are function block timers for FBD that give the same functionality of RW but the naming convention is different. Also, the way that the shift register works on bits is backwards to normal way of thinking so a shift left is used as the bits M0 to M100 work like in 16 bit boundaries so for 1 16 bit array is just like a 16 bit word where the LSB is to the right so in fact as we normally think of the conveyor going from left to right (Right Shift) the shift register goes from Right to left. And yes first time I got it wrong lol. Anyway, Your welcome to do it in any way you see fit after all, it's the concept not the code I'm thinking of.