OK, I tried this approach, but I find that this requires an additional cycle to reset the TON function so as you can see, after 10 seconds the pulse only executed 3333 times instead of 44998 times.
I corrected the timing at which I was calling my clock administration subroutine. Now I can confirm I get the pulse every two msec. As drbitboy says, since the program is executing every msec a bit toggle would achieve the same objective of providing a pulse ever two msec, but I will leave the program as it is, as I can adjust the period of the TON function to get slower pulses.
Thanks so much for sharing your expertise.
OK, so this does not work for T#2msec. And also the main ladder executes 10,002 times in ten seconds. So I guess I will have to use T#1msec, which gives me a reliable 10,000 executions in 10 seconds and use a counter to workout slower times.
Hmm, the logic in this thread is essentially counting scan cycles, assuming each scan period is 1ms. Given that assumption, the scheme below (A-B mnemonics) would do the same without the TON folderol, and also allow changing the period of the b_Exec via the periodHMI integer:
periodHMI would be the target period for the b_Exec pulse i.e. 2 for 2ms, not (N-1) for Nms.
The only advantage to using TONs would be if the scan period were less than 1ms, but then the cycle to do the reset and put a 1 in b_Exec would not be 1ms, so the formula for b_Exec cycle time is [TON preset] + [scan period], so using a preset of 2ms and a scan period of 500µs would give a b_Exec period of 2.5ms.
I would agree that if you are running the POU at 1ms, I would not bother with a 1ms timer. I would use counter or increment a DINT. The timer jsut seems superfluous