Also, many PCs on the market today use chip sets that have bugs in some of the timing hardware which cause additional problems. It appears that although the PC hardware is theoretically capable of better resolution, MS-Windows has too much overhead to read this hardware fast enough. To make a long story short, Microsoft blames the problem on the limitations of PC hardware. Resolution: "Although one-millisecond resolution and aperiodic functionalityĪre theoretically possible using todays timer hardware, achieving this level of granularity and taking advantage of this functionality while maintaining reasonable system performance is not possible in reality." Microsoft however has the following to say about timing There is also a special "multi-media" timer which is supposed to offer better performance for a limited number of applications (it is intended primarily for video games). The actual time delay may of course be longer, depending upon what else is happening in the computer at the time.
If you do a normal "sleep" statement or use a standard MS "timer object", then this is the minimum time delay you get (regardless of whether you actually ask for less). This is the best possible resolution of the process scheduler. I just did some research into this though, and found that the actual "nominal" scheduler timer resolution for MS-Windows XP varies between 10 to 15 msec, depending upon various unspecified factors (this is different from MS-Windows NT4 or 2000 which only use 10 msec). This is where the "10 msec" value you refer to comes from. I still cannot find "TestStand "Assemble VIs" tool " in TS 3.In reply to Davis Gentry - "Standard" scheduler timer resolution for all versions of MS-Windows NT (NT-4 to XP) is 10 msec. The target machine has only the RTE's on it. The source machine has the full TS and LV systems on it. In any other combination, on the same machine, with LV 7.1 RTE or DEV, it works. I got rid of any other versions of TS or LV, plus all their folders, re-installed TS 3.1 from scratch, mass compiled etcĪgain, the only time I get the error is when I try to run the vi in TS configured to run with the LV 7.1 RTE. Yet, it is working perfectly from LV dev and as a stand alone executable on the same machine at the same time. If I switch to the LV RTE (configure adaptor) on the same computer (source computer) I get the non-executable error. If I use the same vi (Read Char from File) directly as a specified module it will run in TS as long as I am in the LV DEV environment. exe with just this vi using 7.1 app builder it runs on the source computer, and the target computer (which only has the RTE's on it). It definitely has something to do with your "Read Characters from File.vi" and its sub vi's. It does not appear to be anything you have mentioned so far.
0 kommentar(er)
