Thanks for the feedback in post #8! So you don't really have a counter, and when it are running at a cycle interval of 0.5s it is counting by twos in the 0-1000 range, because the clock is counting to 500 and the timer.ACC-to-count scaling factor is 2.
Since you are scaling the timer to the 0-1k range, why not use a scan count i.e. increment an INT by 1 and bit-wise AND it with 003fh (1024) at the start of each scan. Individual steps will not have consistent time durations but then neither will the continuous process that is reacting to them, and the mean time per will be pretty consistent.
The only other option is to GSV the WallClockTime to get μs and scale to that, as @PeterN suggested i.e. free-running clock.
Also, it will be more efficient to calculate, once, the base counter offset (e.g. ms of the timer's .ACC value) for all of the outputs' transitions when you select a new interval, than to scale the timer's .ACC value to the 0-1000 range every scan.
Rather than a LIM instruction on the ranges, requiring up to two compares per range, perform single GRT compares, one per rung, against decreasing counter values at increasing rungs. The first GRT which is satisfied sets a bit that disables, via an XIC at the start of each rung, for all later GRT results. There should be a slight performance improvement as the XIC on that bit will make later rungs run faster. I think it has to use latches which may slow things down some.
Another possibly faster approach would be a binary search to find which range the "counter" is in at any given time: 16 count ranges can be tested with only four compares, plus some integer index math. That said, if there are only a few ranges* it may be slower.
Also, memory is usually cheap, so if there are only 1001 values to be tested, then create an array with 1001 integer values representing the output bits, and a simple lookup into that array is used to get the output states, with no compares required. This is similar to an SQO/SQO implementation, and might work really well with a MicroLogix where the chosen integer could be COPied directly to an output file.
I am suggesting all of these things to try to enhance performance because it seems you may be on the edge of what is possible, but I think @PeterN is right, you may be trying to do an overly-specialized task with a general-purpose tool, like a Swiss Army Knife a.k.a. the wrong tool for every problem.
* I would guess of order 15 or so, but the actual limit would need to be determined empirically; PLCs are not exactly know for their optimizing compilers.