LabVIEW
waveform chart does not show time properly
Solved!
Almost there.
If you use tick count inside the loop, your initial measurement of start time that you are subtracting needs to also be tick count. And just for completeness sake, it needs to also be divided by 1000 because the call outside the loop is also ms. Even better, do the subtraction with the raw tick count output (ms as a type U32) first and THEN divide the difference by 1000 to get seconds as type dbl (this will avoid a possible 32-bit integer wrap around problem that will crop up every 50 days or so if you never reboot your computer)
See, you're calling tick counts and getting a large number like 112310012. If you call tick counts again 1 second later, you get 112311012. The 112310012 is essentially meaningless to you (I'm pretty sure it usually resets to 0 on reboot, so it's actually ms since you rebooted, but that may be system dependent and not guaranteed behavior). The 1000 difference between the two numbers is what you're trying to extract as it represents 1000ms.
Same mathematical trick works with Get Date/Time in seconds, but the oddly large number you get on a single call to the function is not time since reboot, it's time since midnight, Jan. 1 1904. Either start time will work for simulating the behavior of a stopwatch by subtracting it away, but you cannot mix them. The main point of picking a fixed date for Get Date/Time in seconds is that you can count on start time always being Jan 1 1904 and therefore calculate the current date and time from a single call. Tick counts starting point is not constant across machines or systems or when you come back the next month and rerun your vi, which is what the LabView help is refering to when it says "the base reference time (millisecond zero) is undefined". It does stay constant during a single run of a vi except that it wraps around to 0 when it reaches 2^32 ms (~50 days).
On the sampling rate, wiring 50 to wait (ms) or wait until next multiple is the correct approach to setting your desired sampling rate, but it only works if the rest of your code is capable of running that fast. If you're cycling slower than that something else in the loop is holding you up. My bet is on the "ke2000 read data single.vi". If it takes 100ms to get a reading from the multimeter, that's where program will hold up, and the wait vi will do nothing until you set it slower than the multimeter can keep up. Updating graphs in real time can sometimes hold things up when you're trying to loop quickly, but 20 samples / second shouldn't be hard, even on an older computer. If you want to check it, wire 200 to the wait vi and I'll bet you do get a very reliable 5 samples / second. It's not what you want, but you can confirm wait vi is doing what you expect.
