From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
How does Tick Count (ms) Function work?
Solved!
@JÞB wrote:
@Ben wrote:
You left out the "PAL" (Processor Abstraction Layer) Jeff.
Ben
Are you trying to laugh at me there Ben? There is not "Requirement" for a PAL (e.g. monolithic kernels on embedded systems) although, it is much more common to find a heiraracal structure where the cores features do load kernel modules based on uP core archetecture.
No Sir!
There should be one on your machine for each version of LV you have installed.
The PAL abstracts away the hardware so that LV can run on a MAC like it runs on a PC.
Ben
@Ben wrote:
@JÞB wrote:
@Ben wrote:
You left out the "PAL" (Processor Abstraction Layer) Jeff.
Ben
Are you trying to laugh at me there Ben? There is not "Requirement" for a PAL (e.g. monolithic kernels on embedded systems) although, it is much more common to find a heiraracal structure where the cores features do load kernel modules based on uP core archetecture.
No Sir!
There should be one on your machine for each version of LV you have installed.
The PAL abstracts away the hardware so that LV can run on a MAC like it runs on a PC.
Ben
Actually, NI-PAL is normally used for NI-DAQmx, NI-488.2 and all the other NI hardware drivers that need to do things like accessing interrupts, DMA or physical memory. LabVIEW except indirectly maybe for the timed loop structure should not have to worry about such things in any way at all.
As to where the Get Tick Count information gets its value from, it is probably a safe bet to assume that it simply calls the Windows API
DWORD WINAPI GetTickCount(void);
It returns a DWORD which is the same as the uInt32 tickcount value and has the same ms resolution. Why should LabVIEW try to second guess what Microsoft already spent many man years of work for?
The only thing Microsoft guarantees about this value is this:
Return value
The return value is the number of milliseconds that have elapsed since the system was started.
Remarks
The resolution of the GetTickCount function is limited to the resolution of the system timer, which is typically in the range of 10 milliseconds to 16 milliseconds. The resolution of the GetTickCount function is not affected by adjustments made by the GetSystemTimeAdjustment function.
The elapsed time is stored as a DWORD value. Therefore, the time will wrap around to zero if the system is run continuously for 49.7 days. To avoid this problem, use the GetTickCount64 function. Otherwise, check for an overflow condition when comparing times.
Of course since the value is an unsigned integer the last part is a bit overexagerating. As long as the interval between two tick counts is smaller than the 49.7 days, unsigned integer arithmetics will guarantee that the difference between the two values is correct!
That doesn't mean they will be accurate though. The timer tick is based on a crystal oscillator in one way or the other, possibly with the 8253/8254 emulation in the chipset but might be implemented by other similar hardware in modern computers. This crystal oscillator will generally have drift caused by temperature as well as the actual accurracy of the crystal itself which can easily be many 100 to 1000 ppms from its nominal frequency.
***UPDATE***
So, The plot thickens.
I still can't believe that the TickCount(MS) can vary so much on one computer between two different VI's.
Ends up when I run these two VI's on any machine (Except my machine) I get the expected results. The TickCount on the reader end is always equal to or greater than the TickCount from the sender.
This is my Sender
And this is the code for reading data:
After much troubleshooting I've managed to narrow the code down to these two very simple VI's; a producer and a consumer.
Why do I get expected results on all computers except for my machine?????
GREAT QUESTION!!!
(Notice the more cynical I get, the more font variations you see?)
Ends up this computer not long after discovering this problem started having some stability issues.
Then it wouldn't boot at all into Windows 7.
No big problem, Lets do a Windows Repair. NOPE!!!! Repair Denied!
I could run Ram checks. All Good there.
I could run disk checks. All Good there.
But, I could never load an OS. Windows just freaks out. Even trying to do a fresh install?
After the standard troubleshooting, I decided to go with a shotgun approach.
I went into BIOS and disabled everything under the sun.
Windows started without a hitch. WHY?
I started enabling components in BIOS one at a time.
After much go around discovered that any time I enabled the Turboboost and/or C-states on the PXI-8119 that windows would fail to start.
I took a video of me trying to start windows with Turboboost and C-States enabled and then disabling these BIOS Settings. I sent this video to NI support.
They soon issued an RMA for the PXI-8119.
They verified that the Intel Core i7-3610QE was the issue. Replaced the microprocessor and now all is fine with the world.
I've hardly used datasocket in my LabVIEW career. It must have been some fate of the universe that I discovered this issue. Otherwise I would have finished the initial integration effort called it good, and sent the equipment to the customer. (weird that my receive data timestamp is before my send data timestamp, but whatever. That's what most would have done anyways. It was only over time; troubleshooting this issue did windows started acting funny.)
I feel somewhat vindicated. I'm not insane. I understand basic programing principles. (I don't want to talk about the random number method I used in my example code, I know, I don't care now) I weathered the ridicule of my peers, and now I stand a leader strong.
Anyways,
Thank you to all for explaining the concept of the TickCount(ms) in Windows world.
Thank you NI for providing outstanding support and standing behind your products.
Regards,
