This is a hardware limitation. In xPC, the sample time for your model is as close to your requested time as the hardware will allow. The problem is that the hardware doesn't allow infinite precision in setting the spacing between the timer interrupts.
The timer used to generate interrupts based on the 1.1925Mhz frequency that is present in all PC hardware. This odd value originated with the original IBM PC. The CPU clock was initially 4.77Mhz. This value, 1.1925Mhz, is one-fourth of the original value. Since all PCs must satisfy legacy compatibility, this timer is present on all machines. It is also the only timer that can be used to generate an interrupt.
In xPC, the timer is set to a fixed number of ticks of this frequency between interrupts. The sample time of 1/10000 = 100 us is not an exact number of these ticks. It is 100e-6 sec * 1.1925e6 Hz = 119.25 ticks. This is rounded to the nearest value of 119 ticks. The actual sample time is then 119/1.1925e6 = 99.79 us which is .21% faster. The measured frequency of 50.145 is .29% higher than 50 Hz. This is off by about roughly .04% from the expected value.
With a sample time of 1/10200 = 98.039 -> 116.96 ticks -> 117 ticks when rounded should give a frequency of (116.96/117) * 50 = 49.983 Hz. The observed value of 50.002 is .037% higher than that.
We can conclude that the 1.1925Mhz timer in this particular machine is running .037% fast. This amount of error is common and varies from machine to machine.
Most high level operating systems, such as Windows or Linux, have mechanisms to insert extra long intervals every once in a while to compensate for errors in the timer. In xPC, this does not occur, because, generally speaking, close repeatability is more important for most models than exact timing. There is still residual jitter on the order of .5 us from interrupt to interrupt that seems to be inherent in the design of the Pentium.
Now that you know how the actual sample time is derived, you should be able to get pretty close to what you need.
