I think that some A/B platforms require a constant when using copy to move blocks of words around. Sometimes, in those cases, a FFU/FFL pair can be a good choice instead. But only if you don't need to insert or delete records from the "middle of the pile", but, rather, you want to preserve a list of alarms, or data changes without losing the order in which they occurred.
So, in my practice, the advantage to the FFU/FFL pair is that the length can be variable. You can do that with pointers too, but you may end up with more code to recreate what the FFU/FFL instruction has built-in.
For example: You want a PLC record of the state of 16 consecutive fault bits, for the most recent 100 alarms since power up, and you power up everyday at about 7:00 a.m. So, every time the word containing those 16 consecutive alarm bits changes, you FiFoLoad it into your data area.
I always program the FFU jsut before the load, and only unload the stack when it is full. If there 123 alarms today, I lose the oldest 23 of them. Gotta set a limit somehwere. So the FFU just above the FFL in the scan, conditioned by the done bit will keep room in the stack and utilize all 100 locations.
If there are only 23 alarms all day, you don't have to move 100 words around to track them all. But, when you want to see the oldest, you look at the file:[control.POS] location for the oldest, it won't always be located at position 100 unless the alarm queue is full (DN bit will be on...)
I have seen some cases where a guy unloaded the stack right after it got done, and made his file one element larger to accomodate that, but in his case, the DN bit was never set past that point and it makes more sense to use only the number of elemnets you need and unload just prior to loading the stack. Then, your done bit will be useful later in the program.
Only as many elements as exist in the "stack" (the control.POS value) have to be manipulated aduring each FFL execution.
Again, Redael, are you just expanding your knowledge or do you have a potential application?