... struggle with some of the stuff you guys are saying.
...don't have a lot of the components you guys are saying.
Okay, let's step back a bit.
I) Any computer program is a model of something in the real world.
That is, the computer program manipulates bits (a.k.a. variables a.k.a. memory), which bits represent entities in the real world.
For example, if Sensor1 measures a box and determines that box is 30.48cm long, it might put the 30.48 into a variable (memory) that represents a floating point value; call that variable LEN. Then, if a second box came long that was 60.96cm long, it might put the value 60.96 into that same variable, LEN, overwriting the previous value (30.48). The point is that the rest of the program can check that variable LEN to determine the length of the last box measured by Sensor1.
II) The model implemented by the program does not need to keep track of every piece of the real world
For example, there is no need to model
- the orbit of Pluto,
- or oxygen and nitrogen molecules in the conveyor room, individually or in toto,
- or the state of the light switch in the room
III) The program needs to keep track of every modeled piece of the model, but not to infinite precision
For example, if all of the boxes are at least 30.48cm long, and the pusher is 20.32cm wide, then the model does not need to keep track of what is on every cm of the conveyor; probably 10.16cm should be "good enough."
Another aspect of this is the discrete nature of the model: the conveyor is moving continuously, but the PLC scan happens every few ms, and during any one scan it generally assumes all variables are as last measured i.e. static or constant. Also, the model of what is at each modeled station on the conveyor will only move to the next modeled station for every 10.16cm of conveyor motion; there is no "box overlaps two stations" indication. The programmer always be evaluating whether the model is "good enough," sometimes by engineering judgement, sometimes by experiment.
IV) The program cannot use tools its processor/language does not have, but it can build more complex tools from simpler tools that it does have
For example, one way to represent boxes on the conveyor is as bits in an integer. Each bit's position (0, 1, 2, ..., 31) in the integer could represent each 10.16cm section of conveyor from Sensor1 to the pusher. A 1 bit could indicate that a long box was detected, and a 0 bit indicates that no long box is present*.
* Note that a 0 bit could represent
EITHER a short box
OR no box; the program doesn't need to discern between a short box and no box, because it does not need to push either; this is an application of principle (
III) above.
To represent the motion of the conveyor, the program would move (shift) all of the bits to the next (more significant) position. Most PLCs have a bit-shift instruction to do this; if they do not, the program could multiply the integer by 2, although that gets messy if multiple integers are required. Both techniques (bit shift or multiply) presume the program can assign and examine an individual bit of the integer, specifically the bits that represent the conveyor positions at Sensor1 (to assign a 1 or a 0) and near the pusher (to examine and detect a 1 or a 0).
As an alternative to using bits to indicate long/no-long boxes, a functionally equivalent construct would be an array of numbers: the position in the array represents the conveyor positions; the value in each array element represents the length of the box at the corresponding position, e.g. 60.96, 30.48, and 0.0 for long, short, and no box, respectively. Again, most PLCs have some sort of FIFO (First-In-First-Out) instructions that could be used to shift the integers to the next position to model movement of the conveyor. If not, then the program could leave the array values in place and increment indices into the array to model conveyor motion; one index represents Sensor1 position, another the pusher position.
PLC Fiddle appears to have neither bit shift nor a simple way to examine individual bits in an integer, nor does it have an array, so another way must be found. If you look at @parky's example in post #18, rungs 9 through 14 in the PDF attachment nicely implement a brute-force FIFO: the variables Shift_Reg_0 through Shift_Reg_6 compose a shift register, and it takes six instructions to model conveyor movement i.e. to implement the shift.
Another issue to deal with is modeling the movement of the conveyor itself. There might be a proximity sensor monitory a sprocket's teeth or spokes, which would be best. If not, then if the conveyor speed is nearly constant, the movement can be modeled with a timer. In that case the model moves from the spatial domain (e.g. length from Sensor1) to the time domain (time from Sensor1), and there might need to be some padding or fuzz placed around the various decision points in the model to deal with variations from the assumption of constant time and constant time (PLC timers are non-deterministic) and constant speed, as noted by JTCat.
Conclusion
The essence of programming is to look at the process, and look at the tool (PLC implementation), and then figuring out how to model the former with the latter, including (i) what does not need to be modeled, (ii) what does need to be modeled, and (iii) to what precision.
You kindly said in your OP that you did not want anyone to do this for you, but also that this is new to you. I strongly suggest you check out Ron Beaufort's excellent series of beginning videos
here; also study the content at
this link, which is one of many places that provides ladder patterns you will use over and over.
Finally, I leave you with some simple patterns as PLC Fiddle rungs below, suitable to the current task. The first is a bit shift triggered by a pulse; the second is a FIFO number shift triggered by the same pulse; there would need to be more of these to shift 1 to 2, 2 to 3, etc.; I leave it to you to determine the order. The third rung assigns zeros to bit and number at the head of the bit shift and number FIFO registers, and only one is needed i.e. to assign the element at position 0; the fourth is a repeating, self-resetting timer, that will work with most, but not all, PLCs.
Note that the pulse
MUST have a duration of exactly one scan. I provided the bit shift to show that the MOV to accomplish the number shift is much simpler. You would only use either the bit shift or the number shift, and of course you do not have to use either of these as you may come up with something better.
