[Update: I had it backwards; FFL Loads new values at the end of the FIFO array and FFU Unloads them from element 0; but the basic idea is the same. I tried to edit the text here, but I am not sure it is correct now, so
caveat emptor.]
@Chavak mentioned BSL, and that works if the information being measured at station 1 and read at station 2 is one bit (e.g. present or not).
Now that we know that the information is more involved e.g. an INTeger, then a FIFO is probably the way to go. A FIFO is basically the same concept as a BSL, but with more bits being moved in parallel. A FIFO is implemented with the FFL and FFU instructions, plus an array of some atomic data type, more or less the same as in RSLogix 500; see
this link and
this link.
A search for the term "FIFO" on this forum should provide multiple examples.
TL;DR
A FIFO is an array of data, which models the process:
- The size measured at station 1 is placed at the tail of the array (element [.POS-1]).
- A rising edge, in this case probably driven by a timer*,
- If FIFO array is full (.POS equals .LEN), then FFU instruction
- unloads the size value at the head (element [0]) of the array
- Shifts every element of the array to one position toward the head position in the array,
- decrements .POS by 1
- FFL instruction
- inserts a value into the tail position ([.POS]) of the array, and
- increments .POS by 1**
* A possibly more reliable (deterministic?) system would generate rising edges from a fixed proximity sensor detecting teeth of the sprocket that drives the chain, but either way the distance from station 1 to station 2 is modeled by some count of rising edges. If each edge is based on time, then the increment between consecutive edges represents distance as (time_between_edges * known_speed), so a reasonably constant and known speed is a precondition for that approach to work; if each edge is based on sprocket teeth and a proximity sensor, then the increment between consecutive edges represents distance as (teeth_pitch * gearing_ratio).
** I think the flowchart in the manual may be wrong - it shows .POS being incremented before inserting the new value at position [.POS] in the array. It also has a test for .POS>.LEN after a negative result of a test for .POS>=.LEN, which latter test would preclude the former from ever being performed.
If timing is used, there are better approaches than a simple self-resetting TON e.g. [XIO Timer/DN TON ...], as that technique has some noise in the actual time increment, although for a short time between stations it could probably be calibrated empirically to be good enough (e.g. a "half-second" repeating timer that actually has a .PREset of 497).
The actual implementation will depend on how the process detects when parts are at station 1 and/or station 2. For example,
- the FFL instruction could always load an invalid size (e.g. -1) by default at the tail element of the array after it does the shift, and the station 1 process could overwrite the tail element whenever it makes a size measurement.
- the FIFO could be oversized i.e. represent far more distance than is actually between the stations, and when station 2 detects a valid size at the known location in the array that represents the distance between stations, it could initiate the spray operation based on that size
- This would require an FFU to unload the head element in the array once the FIFO is full (.POS equal to .LENgth), before each FFL, to avoid overflow.