If I had to do this from scratch, as a 1-time diagnostic and not a long-term solution, I would write a subroutine to continually, i.e. on every scan, log (MOV or COP or CPW) the relevant tags (bits, ints, etc.) into circular buffers i.e. the largest (256-element) data files the SLC supports, so each logged tag gets its own log file. There would be one INT, "the_index," that is incremented on each call of the subroutine and represents an indirect points to the element of each log file that gets the next datum; the_index would be ANDED with N-1 (255?) to wrap around after being incremented. Then set some triggers, which indicate that the event being diagnosed has occurred, plus perhaps either some additional delay or number of index steps, to either stop calling the subroutine or return from the routine immediate it is called.
Now all I have to do is wait for the trigger event(s), and then go in with RSLogix500 online and look at, or even upload, the buffered data; I would need to look at the_index to see where those data stop and start, but it should be straightforward.
If a single data file is too small, then use multiple buffers for each tag.
There is summat similar
here to evaluate statistics of repeating timers; the guts of the proposed subroutine are on the next to last rung of each of the programs.
There is a multi-file (1024 data = 4 files x 256 data/file) save of data in Rungs 0010-0013
here, to evaluate statistics of a Gaussian/Normal random number generator.
It's a fair bit of yak-shaving, but the algorithm is simple and direct, basically bookkeeping (like most programming), and very unlikely to not provide per-scan data of the event; one possible deal-breaker could be available resources e.g. memory or scan time. This thread is already a few days old, so it will be worth the effort assuming those data will provide insight into the original issue.