Advice: Tracking a reject on a conveyor

instruward

Member
Join Date
Jul 2019
Location
Prairies
Posts
27
CompactLogix PLCs

I'm tasked with getting a box packing machine to MSG (ethernet) another plc that handles a diverter gate/reject conveyor.

My issue is when the packer decides a box should be rejected, the time is variable from when it gets to the diverter gate. The easiest solution maybe to give the operator a way to adjust the timing as needed...

So far I have 2 proxes I can use, one to count the box as it leaves the packer reject area and one prox before the diverter gate. I was trying to use counters to track the reject boxes. But I am realizing what I have done won't work if there are several rejects in a row, or some variety. It's possible for 10 boxes to be between the two proxes.

My latest attempt, I've discovered I can't use a counter's accumulated value as an array index because it's type DINT instead of INT.

tl;dr I'm looking for advice tracking rejected boxes with 2 photoeyes. I've only been attempting to use counters.
 
A FIFO in each PLC and Produced and consumed data to pass the information from the first PLC to the 2nd.
I don't think messaging would be reliable
I would have to see details to get deeper into it
 
I agree with the thought of using produced and consumed tags. In addition to the reliability point, I just think it is all-around easier.

However, I would handle the data model differently. I would use an array in the packer reject plc to maintain a circular queue of boxes. The packer side array index would be incremented by the packer exit photoeye. The whole array would be produced by the packer plc for the reject plc along with the packer index (you'll see why later). The reject plc would keep track of its own index, which would increment on the reject infeed photoeye. The reject would then just act on the array location it is indexed to.

The one reset case I can immediately think of is when the whole thing starts empty. If you know the system is empty set the reject index equal to the packer index and let it start from there. You don't even need to clean up the array contents since the packer will be setting those locations as boxes leave anyway.

Keith
 
I'm not able to use produce/consume because one of the plcs can't be downloaded for quite sometime.

I've never used the FIFO, it can't be used with messaging?

I haven't noticed issues with messaging, as soon as I write a message to the plc with the diverter gate. I just can't figure out how to track rejects.

I was trying to use counters and move the .acc count into a DINT array index but it appears I can't use the acc as an index. I'll need to read up on FIFO later.
 
I agree with the thought of using produced and consumed tags. In addition to the reliability point, I just think it is all-around easier.

However, I would handle the data model differently. I would use an array in the packer reject plc to maintain a circular queue of boxes. The packer side array index would be incremented by the packer exit photoeye. The whole array would be produced by the packer plc for the reject plc along with the packer index (you'll see why later). The reject plc would keep track of its own index, which would increment on the reject infeed photoeye. The reject would then just act on the array location it is indexed to.

The one reset case I can immediately think of is when the whole thing starts empty. If you know the system is empty set the reject index equal to the packer index and let it start from there. You don't even need to clean up the array contents since the packer will be setting those locations as boxes leave anyway.

Keith

This sounds similar to what I was trying to do, I need to take a break and re-read this a few times.

Am I off track trying to use counters to index the array? That's what I've been trying to use, but I'm stuck because array indexes don't like counter acc data types.
 
In the past I have had similar situations, and unless you need to pass more options than 1 or 0, then I would use Bit Shift Left.
 
...Am I off track trying to use counters to index the array? That's what I've been trying to use, but I'm stuck because array indexes don't like counter acc data types.


Can you move the value of the DINT to an INT, and use the INT as the index?


Although if you go with the circular queue (buffer, array), then you don't want counters; it is trivial to increment a counter by 1, and to wraparound the circular queue index choose a queue size that is a power of 2*, then a bit-wise [AND instruction] does the wraparound.


* e.g. 16 or 32; as long as it is bigger than the number of boxes that can be between the photoeyes


I see only a few operations:

(Assume queue_size is the size of the queue, and is a power of two)

  • Upstream PLC detects a [next box] edge on the upstream photoeye (PE) and increments upstream index with rollover
    • Rollover is a bit-wise AND with queue_size-1
  • Upstream PLC detects a reject box in the PE, and sends the current upstream index in a MSG to the downstream PLC
  • Downstream PLC receives a non-negative value, which is the index of a reject box in a MSG, and puts a 1 in that index's location in the circular queue
  • Downstream PLC detects a [next box] edge on the downstream PE and increments downstream index with rollover
    • Downstream PLC checks circular queue value at the just-incremented downstream index
      • If that value is 1
        • Divert the box in the downstream PE
        • Set that index's value to 0 (for next time)
  • (Re-)synchronization
    • Upstream PLC sends the value (ds_index-queue_size), where ds_index is the index of the next box that will generate an edge in the downstream PE as a negative value
      • probably by operator intervention, with conveyors stopped
      • (ds_index-queue_size) is a negative value
    • Downstream PLC receives a negative value
      • Subtracts 1 from it
      • Performs bit-wise AND with (queue_size-1)
      • Places the result in the downstream index
      • Clears all values to 0 in downstream circular queue
The re-synchronization step will attract an off-by-1 error in its implementation, but there are only two possibilities so it should be resolvable empirically.

This is a 1-minus system i.e. it assumes all boxes are non-rejects except for boxes that have their index sent by the upstream PLC in a MSG to the downstream PLC. A missed MSG would not reject a box that should be rejected.

An analogous 0-plus system is an alternative i.e. it assumes all boxes are rejects except for boxes that have their index sent, and a missed MSG would reject a box that should not be rejected.


Which way to go depends on your process requirements: is it better either to reject a (hopefully) few good boxes, or to accept a (hopefully) few bad boxes.



Caveats
=======

This approach has a problem if
  • if a box is added (malicious operator?) between the PEs
  • if a box is removed (or falls off) between the PEs
  • if the "next box" does not trigger a PE edge after the previous box e.g. if boxes overlap
  • if MSGs are lost
If any of those things happen, or happen too often, then this system may not be an acceptable solution.
 
Last edited:
I just re-read the OP again.


Which PLC gets input from which PE? The solution I outlined assumes the main PLC that sends the message gets input from the upstream PE, and the diverter/reject PLC gets the input from the downstream PE.


If the upstream PLC has both PE inputs, then the same logic applies but finding a 1 in the downstream index on a downstream PE edge will trigger the message to the diverter/reject PLC.


Also, if the number of boxes between the PEs can vary, then a straight FIFO/Bit Shift will not work unless you can adjust the index where the next 1 is added, which basically reduces the problem to the equivalent of the circular queue.
 
Last edited:
I had a similar problem, however, the system also tracked the box bar code the plc that detected the box to be rejected also ran the conveyor so the solution was to fit a proximity & flag to the conveyor drive, this was only a rough count as there was no way of adding an encoder. The rejects & bar codes (simple 1-999 converted into integers)were tracked by the plc in a shift register where a reject was 1000- 1999 so any value above 999 was a reject, there were 15 stations for diverting, one being reject. each divert station had a PE so even though the shift register was crude in respect of number of positions the pulse values gave a window for the box i.e. when the register value was equal to the required value for example divert station 3 diverted all boxes with a bar code of 101 and reject station diverted all boxes between 1000 & 1999 when the box reached the station PE the register was compared with the required bar code value and diverted it. The pulses from the conveyor were designed to be a space ratio of about a metre appart this was ok as the box size & separation was large enough to cater for the slow pulses and any higher would have required such a large shift register that the PLC scan time would cause it to fault. not a perfect solution but it worked without fault, just a little bit of timing & PE positioning to align the shift register to the divert.
 
Also, if the number of boxes between the PEs can vary, then a straight FIFO/Bit Shift will not work unless you can adjust the index where the next 1 is added, which basically reduces the problem to the equivalent of the circular queue.




I was wrong when I wrote that: a shift register essentially combines the two indices of the circular queue solution into one index, which index is analogous to the difference between the indices, because with a FIFO/BSR the downstream index is always zero.


With a FIFO/BSR and one index,

  • the upstream PE edge increments the single index,
  • the downstream PE edge decrements the single index and BSRs one bit out which tells the diverter what to do (1=divert; 0=not divert),
  • the BSR always shifts in a 0 at the left end of the FIFO, which left position is always greater than the index.
 
Last edited:
Packer-Reject-Diverter-1.png


Give me your best shot w detail. Ill have a reward for you
 
Last edited:
BachPI: The problem is if there is a difference in the gaps between boxes it could lose it's w within a given window. Do not use a high speed as this would require a massive shift register but if it sensed 4-10 times within the length + gap of the box and in combination of a PE on the entry to the reject station it would work pretty well.
 
BachPI: The problem is if there is a difference in the gaps between boxes it could lose it's w within a given window....


I thought the FIFO BitShift was triggered by PE2 edges, so each bit represents the status of each box ([reject+divert] or [okay&not-divert]), and the gap size between boxes would not matter as long as there was a gap such that each box generates one edge at PE1 and one edge at PE2


So

  • the size of the FIFO is queue_size
  • new bits are always 0, and added at the end of the FIFO i.e. at index value (queue_size-1).
  • index1 (the upstream index) is the number of boxes that have
    • triggered a PE1 edge
    • AND
    • not yet triggered a PE2 edge
  • index1 increments with each PE1 edge
  • index1 decrements with each PE2 edge
  • a reject box at PE1 puts a 1 at FIFO[index1],
    • or maybe FIFO[index1-1],
      • depending on when index1 is incremented
  • index2 (the downstream index) is effectively always zero
  • A PE2 edge BitShifts one bit out of the FIFO
    • If that bit is 1, Packer PLC sends a MSG to diverter PLC
  • If diverter PLC has time to reset between contiguouse reject boxes, then it should reset
  • If diverter PLC does not have time to reset, then Packer PLC will need to send a message for every change (edge) in FIFO output bit
    • Send [divert] MSG for rising edge i.e. on first 1 after 0's
    • Send [not-divert] MSG for falling edge i.e. on first 0 after 1's
there was a recent thread about a finger diverter, with a great video, although it was time-based with a (presumably) constant-speed conveyor; I'll see if I can find it ... here it is: https://www.plctalk.net/qanda/showthread.php?t=124400 running that at 0.25 speed worked best for me.
 
Last edited:
It seems to me that this project is being made unnecessarily difficult by dividing it up between two PLCs. Back in 1980 I did my first lumber sorter. We used an encoder to keep track of the delay between events. This way if the chain moved at a different speed there was no problem. In the OP's example that can't be done unless both chains are running at the same speed and the time or counts can be synchronized which may be hard to do with the delays caused by the MSG block. If both PLCs used the same encoder then a message could be sent with the encoder count at which to fire the diverter.
 

Similar Topics

Hi everyone id like to start by saying im not a PLC programmer so my technical terminology is limited. i would like advice on what software is...
Replies
4
Views
269
Connected Components Help Hi there everyone, I’m recently new to the PLC world and was hoping somebody might steer me in the right...
Replies
3
Views
394
Hello, I'm struggling to learn something on Wonderware, and the distributors are taking days to get through the email chains. I was hoping for...
Replies
1
Views
343
I'm currently working on a PLC setup and could use some advice on the best way to manage my power supply units (PSUs). Here's the configuration...
Replies
3
Views
369
Hello all, I am looking for advice as I set myself for this new career path. I need advice on a couple of things. What sort of tooling will I...
Replies
9
Views
599
Back
Top Bottom