Syncing Omron Vision with ejector pusher

[AK5fa]

Dear Experts,

I need a little help with a project that involves an Omron Vision used for quality control of cylindrical products (arranged in 2 lanes) on a servo motor-driven conveyor belt. Each lane of the belt ends with an ejector rod (air solenoid vale) which should kick out the product that did not pass the QC. I'll try to provide as much details as possible and I hope someone would be able to give me some new ideas to try.

The details are as follows:
There is an Omron FH-5050-10 Vision system with 4 camera aligned in a 4x2 configuration. That is, 4 cameras placed sequentially and are looking at the product passing underneath them on the conveyor belt. The products are cylinders which are fed into the conveyor with a minimum distance of about half of its length (e.g. 170 mm long cylinders come in with at least 70~80 mm space between them). There are 2 optical sensors at the beginning at the end of the conveyor belt. The sensor at the end is followed by the ejector rod, which can be extended and retracted quite quickly. The ejector is controlled by a S7-1500 series PLC, linked to the Omron Vision system by a RS232 serial link. Obviously, the PLC gets an info about the product condition via this serial link. It checks the data, decides whether the product is OK or NG and activates the ejector based on that. The belt is driven by the servo motor with an encoder of 8000+ ppr. The PLC gets the encoder feedback (actual position) via a Profibus connection to the servo drive. The belt speed is controlled by the PLC and is constant, but can vary slightly depending on external factors. Normally, it takes about 500~600 ms for each product to pass through the entire conveyor belt. Finally, the belt has 2 identical lanes, left & right, so let me focus on the Left lane only. That's the basic setup.

Now, the tricky part is, the Omron Vision cameras are operated based on a
a fixed cycle of 280 ms. That cycle time gives all 4 cameras a chance to take 1-2 snapshots of the product. The PLC can measure this cycle time, but the cycle itself is not synced to the signal from the sensor at the beginning of the belt. That cycle runs as long as the belt is moving, regardless of whether the product is present on it or not. At the end of every cycle the RS232 interface on the PLC gets a 32-byte message containing coordinates (4x 32-bit integers in camera pixels x1000) of the defect found. If no product is present, or no defect found, there is 0 or another pre-defined number if sent. Also, as the product passed under each of 4 cameras, there is no way to tell which camera may spot the defect. Sometimes, it could be 2, 3 or even 4 cameras which spot the defect in the same product. The data (1D pixel coordinates of the defect) can be translated to the number of encoder pulses at a fixed ratio. The position of the object is always known from the moment its beginning passes the 1st (entry) sensor to the moment it passes the 2nd (exit) sensor and then (maybe) gets by the ejector rod.

Thanks for reading and considerations this far!

Now my ultimate questions are:
1. What would the best (100% error-proof) algorithm to track the be location of each product as it passes through the belt under the cameras, get the RS232 data from the Vision and activate the ejector at the time as the product marked as "bad" passes by it? (preferably, around the mid-point of its length).

2. How can I "attach" RS232 data messages (coming in at fixed intervals) to a specific product on the conveyor?
Please keep in mind that there could be any number (from 1 to 5) of products on the conveyor passing by cameras each of 4 camera at rapid succession. 1 or more of them could be marked "defective" by 1 or more cameras.

3. Would it help to increase the RS232 link speed between the Omron Vision and the PLC (from current 9600 bps to 38400 or even 115200)?


I would greatly appreciate any help you could provide! Feel free to ask me any questions or to request more details.

Thanks a lot in advance,
AK

[drbitboy]

Originally Posted by AK5fa

2. How can I "attach" RS232 data messages (coming in at fixed intervals) to a specific product on the conveyor?
Please keep in mind that there could be any number (from 1 to 5) of products on the conveyor passing by cameras each of 4 camera at rapid succession. 1 or more of them could be marked "defective" by 1 or more cameras.

This is the key question.

Background

Any computer program is a model of something in the real world. Bits (e.g. encoder pulses, or proximity sensors), numbers (e.g. 1D position of a defect), etc. represent some state or quantity in that model.

PLC programs are about time i.e. how the program model changes over time, as measured at discrete moments called scan cycles.

Cylinder defects

With those statements in mind, let me restate the key question in a slightly different way:

• When the center of a 170mm cylinder is at the ejector rod, how can the program know whether there is a defect within 85mm (=170mm/2) of the ejector rod?

Stated that way, the task is reduced to two sub-tasks

• Detect (or know or predict) when a 170mm cylinder is centered at the ejector rod
  • This can be derived from "Track the position of the lead edge of each 170mm cylinder"
• Track the position of all detected defects

So, if the program detected the rising edge of the entrance proximity sensor of the leading edge of a cylinder some N encoder pulses ago, then the program should be able to predict where that leading edge is now, in units of encoder pulses from the entrance prox.


Likewise, if some time ago the cameras detected a defect that was located at a distance of M encoder pulses from the entrance prox, and there have been K pulses since then, then the program should be able to predict where that defect is now, again in units of encoder pulses from the entrance prox.

Note that we no longer associate the defect with a cylinder, but rather we associate independent 1D positions of both cylinders and defects relative to the entrance prox/ejector rod line.

Model assumptions

1. The cylinders do not move relative to the conveyor belt
2. Any defect does not move relative to the cylinder on which it is detected
   1. By implication, if Assumption 1 above is also true, the any defect also does not move relative to the conveyor belt
3. The interval between successive encoder pulses represents a fixed increment of motion of the conveyor belt, along with any cylinders and/or defects
4. The PLC does not miss any encoder pulses
   1. or at least knows the count of encoder pulses since the last scan
5. The 1D position of the ejector rod, relative to the entry proximity sensor, is known, in units of encoder pulses from the entrance prox.

[drbitboy]

Here is a model for the PLC that uses two bit-FIFOs to keep track both of cylinders and of defects. By using a FIFO that is triggered by conveyor encoder pulses, almost all scaling, other than knowing how much distance one encoder pulse represents, is eliminated. This model essentially keeps track, for each encoder increment in position past the Entrance Proximity Sensor, of two binary states: [1=cylinder] or [0=no cylinder]; [1=defect] or [0=no defect].

In the diagram below, one encoder pulse represents 17mm, or one-tenth of a cylinder length, so ten consecutive 1s in the upper bit-FIFO represent the presence of 170mm of cylinder, and five consecutive 0s in the upper bit-FIFO represent ~85mm of space between cylinders.

Those bits are placed at each rising edge of the encoder:

• The bit-FIFO is shifted one bit to the right
• The current state of the Entrance Prox Sensor, 1 or 0, is placed in the left-most bit of the bit-FIFO.

A similar sequence is performed for the defect bit-FIFO on each encoder rising edge:

• The bit-FIFO is shifted one bit to the right
• A 0, indicating no defect, is initially placed in the left-most bit of the bit-FIFO

Then, whenever a defect is detected:

• Its position, in units of encoder pulses, is calculated as an index into the defect bit-FIFO, and
• A 1 is inserted at that index, and
• All such 1s (defects) are then subsequently shifted along the bit-FIFO with each Entrance Prox rising edge.

   ==> direction of conveyor motion ==>

   ==> direction of cylinder motion ==>

   ==> direction of defect motion ==>

   ==> direction of bit motion ==>



                                                              Ejector    Ejector

   Entrance                                                    Defect    Ejector

   Prox                                                         Check    Rod

   Position                                                     Index    Position

   |                                                                |    |

   000001111111111000001111111111000001111111111 0000111111111100000111111111100000  <= "time" history of Entrance Prox

   ^                                                                     ^

   |                                                                     |

   WHEN the Prox has a rising edge,                                      Cylinder

   i) Shift all bits to the right by 1, and                              Midpoint

   ii) place the current Prox bit here                                   at Ejector Rod





                           Defect                                Defect     Defect

                           |                                          |     |

                           v                                          v     v

   000000000000000000000000100000000000000000000 0000000000000000000001000001000000  <= "time" history of defects

   ^                                                                |

   |                                                                Ejector

   WHEN the Prox has a rising edge,                                 Defect

   i) Shift all bits to the right by 1, and                         Check

   ii) place a 0 bit here                                           Index

Re-drawn with [.] instead of zeros:

   ==> direction of conveyor motion ==>

   ==> direction of cylinder motion ==>

   ==> direction of defect motion ==>

   ==> direction of bit motion ==>



                                                              Ejector    Ejector

   Entrance                                                    Defect    Ejector

   Prox                                                         Check    Rod

   Position                                                     Index    Position

   |                                                                |    |

   .....1111111111.....1111111111.....1111111111 ....1111111111.....1111111111.....  <= "time" history of Entrance Prox

   ^                                                                     ^

   |                                                                     |

   WHEN the Prox has a rising edge,                                      Cylinder

   i) Shift all bits to the right by 1, and                              Midpoint is

   ii) place the current Prox bit here                                   at Ejector Rod





                           Defect                                Defect     Defect

                           |                                          |     |

                           v                                          v     v

   ........................1.................... .....................1.....1......  <= "time" history of defects

   ^                                                                |

   |                                                                Ejector

   WHEN the Prox has a rising edge,                                 Defect

   i) Shift all bits to the right by 1, and                         Check

   ii) place a 0 bit here                                           Index

[drbitboy]

And here are the guts of the ladder logic. I don't know Omron or how it does a bit-FIFO shift or how it addresses individual bits, so the actual syntax is again left as an exercise for the user.


Front end

• Shift cylinder bit-FIFO (cylFIFO) and defect bit-FIFO (defFIFO)
• Set entrance (left-most) bit accordingly

    Encoder

------]P[------+------[Shift cylFIFO]-----------+--

               |                                |

               |   EntranceProx    cylFIFO.0    |

               +-------]/[------------(R)-------+

               |                                |

               |   EntranceProx    cylFIFO.0    |

               +-------] [------------(S)-------+

               |                                |

               +------[Shift defFIFO]-----------+

               |                                |

               |                   defFIFO.0    |

               +----------------------(R)-------+

Middle

• Mark one-camera's defect at FIFO position <index>
  • There will be four of these
• N.B. Calculating <index> is left as an exercise.

  DefectDetected        defFIFO.<index>

------]P[--------------------(S)--------

Back end

• 85mm before ejector rod is position <ERminus85>.
• Yes, that is the canonical Start/Stop Circuit pattern:
  • (not-)Stop condition is a contiguous sequence of cylinder presence bit values of 1 at bit location analogous to 85mm before the ejector rod
  • Start condition is a defect presence bit value of 1 at that same position
  • Run/Seal-in condition is whether to reject the current cylinder that is enabling the (not-)Stop condition.
• N.B. Bit [InitiatePushEjectRod] will be true for one scan, so it might need to trigger a TOF (Time-Delay-Off) or similar logic.

   cylFIFO.<ERminus85>   FoundDefect       InitiatePushEjectRod

----------]/[---------------] [----------------( )--------





   defFIFO.<ERminus85>      cylFIFO.<ERminus85>   FoundDefect

-+----------] [----------+----------] [----------------( )--------

 |                       |

 |       FoundDefect     |

 +----------] [----------+

[AK5fa]

Dear drbitboy,

First of all,

Thank you so much for a very quick and very detailed reply!


I'm now in process of digesting your posts before converting them to the actual PLC logic (BTW, it's a SIEMENS S7-1500 PLC series, not Omron). A few notes and comments along the way.

Originally Posted by drbitboy

Cylinder defects

With those statements in mind, let me restate the key question in a slightly different way:

• When the center of a 170mm cylinder is at the ejector rod, how can the program know whether there is a defect within 85mm (=170mm/2) of the ejector rod?

Stated that way, the task is reduced to two sub-tasks

• Detect (or know or predict) when a 170mm cylinder is centered at the ejector rod
  • This can be derived from "Track the position of the lead edge of each 170mm cylinder"
• Track the position of all detected defects

Here are some additional details which are important to consider:

• The cylinder length detected by the entry prox. is not fixed. Due to the shape of the end of the cylinder, it may be detected as in a range between 165 to 175 mm. Also, it's possible that the machine could be handling another batch of cylinders with slightly different dimensions (somewhat shorter or longer). So, we can't assume any certain fixed length of the cylinder. Likewise, we can't assume any fixed distance between cylinders. There is certain minimum distance, which is about 70 mm and that's about it.
  
• There is a prox. sensor at the end (exit) of the conveyor belt. It's located between 50 and 80 mm before the ejection rod. Sorry, I don't have the exact distance figure right now. But we can assume it is being slightly less than half of the cylinder length. I believe, it would be a proper timing to activate the ejection rod on the trailing edge of that prox. Anyway, hitting the cylinder with the ejector rod at exactly half-length point is not the issue right now. Deciding on whether to hit it or not is the issue at hand.

I really hope this helps and doesn't break your algorithm apart.

So, if the program detected the rising edge of the entrance proximity sensor of the leading edge of a cylinder some N encoder pulses ago, then the program should be able to predict where that leading edge is now, in units of encoder pulses from the entrance prox.

Yes, it surely does. As per your assumption, the PLC gets a new value of the "actual position" of the servo motor (in units of encoder pulses) every cycle. The actual PLC cycle time fluctuates slightly, but it's in the 1.7 to 2.9 ms range.

Likewise, if some time ago the cameras detected a defect that was located at a distance of M encoder pulses from the entrance prox, and there have been K pulses since then, then the program should be able to predict where that defect is now, again in units of encoder pulses from the entrance prox.

Note that we no longer associate the defect with a cylinder, but rather we associate independent 1D positions of both cylinders and defects relative to the entrance prox/ejector rod line.

In my opinion, that's the trickiest part. Firstly, the PLC doesn't know the exact M value that you mentioned above. Also, there could be up to 4 of these M-values, since each camera may find its own defect in the same product.
The Omron Vision system reports the exact pixel value (1D coordinate in range from 1 to 1600) of the defect for each camera. If there is no defect (or no product on the belt) a certain known "default" value is sent instead. However, this information comes to PLC in the form of serial communication messages which are fixed in time but are not synced to the entrance prox edge. It is typical for the system to receive 2 or 3 of these messages during the time it takes for the cylinder to pass through the belt. Also, please consider that other cylinders would enter the belt before the cylinder that we are "focused" on leaves.

Model assumptions

1. The cylinders do not move relative to the conveyor belt
2. Any defect does not move relative to the cylinder on which it is detected
   1. By implication, if Assumption 1 above is also true, the any defect also does not move relative to the conveyor belt
3. The interval between successive encoder pulses represents a fixed increment of motion of the conveyor belt, along with any cylinders and/or defects
4. The PLC does not miss any encoder pulses
   1. or at least knows the count of encoder pulses since the last scan
5. The 1D position of the ejector rod, relative to the entry proximity sensor, is known, in units of encoder pulses from the entrance prox.

These assumptions are correct with the following clarifications:

1. 4.1 => The PLC can't get the edge of every encoder pulse, but it knows the count of the encoder pulses on each normal program scan.
2. 5 => The position of the ejector rod is at a fixed distance from both entrance and exit prox. sensors. The ejector rod can be activated at the trailing edge of the exit prox.

I am still looking at your algorithm in detail and will reply to them later on.

Thank you so very much again for your help and all the time you put into following this issue!

[drbitboy]

Originally Posted by AK5fa

• The cylinder length detected by the entry prox. is not fixed. Due to the shape of the end of the cylinder, it may be detected as in a range between 165 to 175 mm.

Assuming we use the mean distance of 85mm from the ejector rod to the position monitored for 0s, 1s, then 0s, that means the lengths of cylinder on either side of the ejector rod, when the last 1s at the end of the cylinder shift past the <ERminus85> position being monitored in the cylFIFO bit-FIFO, will be 80mm/85mm to 90mm/85mm, so it's always within 2.5mm of the center which is less than 2%.

Originally Posted by AK5fa

• Also, it's possible that the machine could be handling another batch of cylinders with slightly different dimensions (somewhat shorter or longer). So, we can't assume any certain fixed length of the cylinder.

every 2mm of extra length shifts the off-center offset by 1mm. Maybe we need to keep track of the length of each cylinder as measured by the entrance prox and use that to select which bit position in the cylFIFO bit-FIFO to watch, or maybe not.

Originally Posted by AK5fa

• Likewise, we can't assume any fixed distance between cylinders. There is certain minimum distance, which is about 70 mm and that's about it.

As long as there are contiguous sequences of 1s modeling cylinder presence, and likewise a contiguous sequences of 0s modeling the gaps between cylinders, the algorithm should be robust to variation in the lengths of cylinders and gaps.

Originally Posted by AK5fa

• There is a prox. sensor at the end (exit) of the conveyor belt. It's located between 50 and 80 mm before the ejection rod. Sorry, I don't have the exact distance figure right now. But we can assume it is being slightly less than half of the cylinder length. I believe, it would be a proper timing to activate the ejection rod on the trailing edge of that prox. Anyway, hitting the cylinder with the ejector rod at exactly half-length point is not the issue right now. Deciding on whether to hit it or not is the issue at hand.

I really hope this helps and doesn't break your algorithm apart.

The exit prox is not needed for this algorithm, because what needs to be monitored is the combination of 1s at some position in cylFIFO indicating cylinder presence, and 1s or 0s indicating defect presence or absence, respectively, at the corresponding location in the defFIFO. That said, the exit prox could be used instead of that position in cylFIFO, which makes one less FIFO to keep track of, and it may be even more useful if there is an issue with the encoder moving more than one position per scan (cf. next quote: ).

Originally Posted by AK5fa

Yes, it surely does. As per your assumption, the PLC gets a new value of the "actual position" of the servo motor (in units of encoder pulses) every cycle. The actual PLC cycle time fluctuates slightly, but it's in the 1.7 to 2.9 ms range.

We may want to sub-sample the encoder e.g. 1 FIFO bit per non-unit number of encoder counts.

Originally Posted by AK5fa

In my opinion, that's the trickiest part. Firstly, the PLC doesn't know the exact M value that you mentioned above. Also, there could be up to 4 of these M-values, since each camera may find its own defect in the same product.

The Omron Vision system reports the exact pixel value (1D coordinate in range from 1 to 1600) of the defect for each camera. If there is no defect (or no product on the belt) a certain known "default" value is sent instead. However, this information comes to PLC in the form of serial communication messages which are fixed in time but are not synced to the entrance prox edge. It is typical for the system to receive 2 or 3 of these messages during the time it takes for the cylinder to pass through the belt. Also, please consider that other cylinders would enter the belt before the cylinder that we are "focused" on leaves.

Yes this is the tricky part, but the time sync of the camera message relative to the entrance prox edge, does not matter, because we are modeling by distance; distance is linear with encoder pulses and encoder pulses are linear with FIFO index: since the first bit position is distance-synced with the entrance prox, and also the distance from the entrance prox to the pixel location of any defect from any camera at any time should be known (assuming known camera positions and camera parameters), that means the location (i.e. index i.e. offset) of the defect in defFIFO should be known at the time* the defect message arrives, and it is the bit at that index in defFIFO that is set at that time* to a value of 1.


* Remember that PLC programs are about detecting when events happen (are measured) and when to act on those events.


As noted earlier, we are keeping track of cylinder presence and defect presence independently in two different FIFOs, but those FIFOs are aligned (starting at the entrance prox) and shifted synchronously (i.e. together) via the encoder input, so if a contiguous sequence of 1s in cylFIFO, indicating a length of cylinder, is aligned with a corresponding contiguous sequence of all 0s in defFIFO (i.e. at the same indices as the cylinder 1s), then that cylinder has no defects. If even one of the defFIFO values at those indices is a 1 i.e. not a 0, then there is a defect in that cylinder.

In addition, if a defect is detected, it is probably worthwhile setting some buffer bits 1 or 2 indices to either side of the nominal defect index as well; as long that buffer is small enough and the gaps between cylinders is big enough, the buffer bits will not affect the adjacent cylinders upstream or downstream.

Originally Posted by AK5fa

These assumptions are correct with the following clarifications:

1. 4.1 => The PLC can't get the edge of every encoder pulse, but it knows the count of the encoder pulses on each normal program scan.
2. 5 => The position of the ejector rod is at a fixed distance from both entrance and exit prox. sensors. The ejector rod can be activated at the trailing edge of the exit prox.

Clarification (1/4.1) means there may not be a 1:1 scaling from encoder count to FIFO index, but it is linear which is good enough; sub-sampling may be the way to go. The important thing is that there are contiguous sequences of 1s for cylinder presence and contiguous sequences of 0s for gaps (cylinder absence).

Clarification (2/5) means we may not need cylFIFO if we use the trailing edge of the exit prox to choose when to trigger (or not) the ejector rod, but in any case we will need to know the index in defFIFO that corresponds to that exit prox, because any 1 at that index in defFIFO, while the exit prox is 1, means that cylinder should be rejected when the exit prox has its falling edge to 0 at the trailing edge of that cylinder.

[parky]

I agree with Brian, as we have discussed this many times on this forum (suggest you search the forum for conveyor or part tracking).
The only thing I will add is that an encoder will probably give too many pulses per x distance, this would require a massive shift register & probably would increase the scan time & possibly shut it down.
Other methods could be add a separate cogged wheel & a proximity to give for example a pulse every x mm (does not have to be exact but enough pulses to give a reasonable registration of the position of a defective part it would depend on the length of the conveyor from the detection to the reject station).
For example, using Brian's nice picortial of the shift the number of pulses could be as little as 3 or 4 per width of the part, also a window i.e. if the reject sat at a relative position 100 pulses from the detection area, then the reject window could be position 98 to 102, if a sensor was also used at the reject station then then the front end of the part was detected & shift one of the positions 98 to 102 was a "1", then reject, this ensures the part is in the exact position for reject in other words the window is just the width of the part. or smaller but not a single register position if it spanned more than the part width.
Trying to do it with maths i.e. take the actual encoder value at detection then add an offset for the reject position then move them along a shift register would be processor hungry, also would have to detect roll over of the encoder count this becomes a little complex well for my old brain anyway.

[drbitboy]

Originally Posted by parky

I agree with Brian,...

+1


And I agree with @parky.

One way to deal with this, assuming the encoder rollover is a power of 2 (e.g. 8192 = 2¹³), is to use one of the bits of the encoder that will always take at least one or two PLC scan cycles to change.


Simple calculation of encoder rate

• 250mm per cylinder (170mm of cylinder + 80mm of gap)
• 5 cylinders can be on the conveyor at any one time
• 500ms for a cylinder to go from one end to the other
• radius of conveyor is 75mm (~3")
  • so 75mm of conveyor movement is 1 radian of conveyor wheel angular rotation
• 1 revolution per 2π radians
• 8192 pulses per revolution
• 3ms per scan cycle

             250  mm        5      cyl   1 conveyor length    1 Radian   1 revolution   8192 counts    3         ms        encoder  counts

Pulse rate = ------- x --------------- x ----------------- x  -------- x ------------ x ------------ x ------------ = 130+  --------------

             1   cyl   conveyor length    500            ms   75    mm   2π    Radian   1 revolution   1 scan  cycle          scan cycle

 

Those are just sample estimates based on earlier posts and a guess at the encoder/conveyor wheel diameter, but it should be illustrative of the process.


If it is close then it means that

• the conveyor moves 7 or 8mm per scan cycle
• bit 8 (value 256) of the encoder count will have an edge every two cycles or so, and no more than one edge every one cycle,
  • so we could use changes (rising and falling edges) in that bit 8 as the trigger to shift the bits in the FIFOs,
  • which would represent ~15mm of conveyor movement (2π x 75 x 256 / 8192).

That 15mm should a small enough fraction of the gap between cylinders, that 1 index of padding on either side of any defect bit location will not spill over to an adjacent cylinder.


If that calculation is not close, then that only means a different bit in the encoder count would be used to trigger the bit shifts; the key is to pick a bit for which the scan cycle never fails to detect an edge.


If the encoder count rollover is not a power of two, then it gets messier, but still solvable.

[AK5fa]

Thank you, @drbitboy and @parky for all your answers and very detailed explanations!

Going through them, I do have a few questions. But I shall first try to find the answers to them myself first, before posting them here... I'm working on that.

Best Regards,
AK5fa

[drbitboy]

Glad to help.


P.S. Siemens does not have a FIFO instruction, so you will have to roll your own. Easiest way is to leave the bits in place (Array[0..2047] of Bool) and shift the position of the Entrance Prox to the left (equivalent of IndexOfEntranceProx := (IndexOfEntranceProx + 2047) & 16#7FF.

[drbitboy]

It works pretty much as expected. Siemens/TIA Portal is missing the convenience of a built-in FIFO, but rolling our own with fixed bits and shifting indices was straightforward.

It would be easier (but boring) to do at least some of this in SCL.

Rename the .zip to .zap14.

In the image below:

• the tall blue spikes upward are emulated defect events for one camera
  • the length of each spike indicates how far from the entrance prox the defect was detected (scaled from 0-1600+)
    • this (emulated) camera covers about half of the 85 elements in the FIFO between entrance and exit proxes
    • Multiple cameras can place defects more or less simultaneously into the same FIFO and the algorithm should still work.
  • Each defect is placed in the lane FIFO to be detected later when that cylinder is activating the exit prox.
    • The biggest problem will probably be the scaling of the 0-1600 pixel location of the defect into a location in the FIFO; any delay in the communication will represent an offset that is proportional to conveyor speed.
• Rhe short blue spikes downward are camera events with no defects, and are ignored.
  • There is a blue camera event, up or donw, every 280ms, roughly.
• The brown spikes are the same defects detected downstream via the FIFO, while the cylinder with the camera-detected defect is passing the exit prox
• The orange spikes are those brown spikes (defects detected as cylinder exits the system) stretched (via the Start/Stop Circuit pattern) to the trailing edge of the cylinder leaving the exit prox
• The purple apikes are the activation of the Ejector rod when the trailing edge of the cylinder leaves the exit prox.

The timings are all guesses based OP's description of the process. The three brown spikes without concomitant orange and purple spikes occur at defects "detected" during gaps between cylinders, which is an artifact of the emulation I chose not to eliminate.

The physical elements (proximity sensors; encoder) are simulated/emulated, so the four program block that start with emu_, out of the ten total, can be ignored.

Everything is running off of encoder counts, so varying the speed of the conveyor, over a range of perhaps 5-150% of nominal, should not cause any problems, although the timing of the ejector rod is at best a wild guess, and could be a brittle parameter at varying speeds.

Untitled.png

[drbitboy]

ejector_conveyor.pdf

[AK5fa]

Dear all,

Sorry, for not informing you earlier. I've been away for a week or so.
I manage to solve the issue with some help from the Omron Vision system (in form of clarification). The missing crucial detail was that the 4 cameras are producing the sequential 1D coordinates of the defects they see. In other words, if the 1st camera may give the coordinates in 0~1600 range (pixels), the 2nd would give the coordinates from 1550 to 3150 and so on.

Brian, thank you so very much again for the wealth of detailed and practical information that you shared with us!

Regards,
AK5fa

[drbitboy]

Originally Posted by AK5fa

The missing crucial detail was that the 4 cameras are producing the sequential 1D coordinates of the defects they see. In other words, if the 1st camera may give the coordinates in 0~1600 range (pixels), the 2nd would give the coordinates from 1550 to 3150 and so on.

Interesting. Assuming the cameras are in fixed positions, that only changes the scaling from [pixel location of a defect] to [the index into the boolean array], i.e. the camoffset and camdivisor inputs of the Camera FB; specifically, it is possible that the camoffset could be negative for the later cameras.