Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Photo

time of LabJack


  • Please log in to reply
3 replies to this topic

#1 KEN77

KEN77
  • Members
  • 3 posts

Posted 05 November 2013 - 09:55 PM

Hi,

We have a problem concerning the time of the system.

Our system is;

(1)measuring the signals of production line through the LabJack U3-HV.

(2)processing the data on a PC by a ctl file, which runs on the DAQFactory Express.

(3)the ctl file is always kept on, as well as the PC

The problem we have is that the time of the "Graph", one of the Components of the DAQFactory Express,differs more and more greatly from the PC time as time passes.
(see the attached pictures;20131006.jpg,20131105-1.jpg)

It seems that the time difference increases proportionally to the working time of the file.
(see the attached pictures;Difference.jpg)

The PC time is almost equal to the actual time.

So my questions are;

(1)Does the system consisting of LabJack U3-HV and the DAQFactory Express have a different clockother than the PC clock?

(2)If so, is there any way to cancel the difference?

Concerning (2), we closed the ctl file and re-opened it by chance, and found out that the time difference was canceled, which may suggests one of the solution.
(see the attached pictures;20131105-1.jpg, and 20131105-2.jpg)

Thanks in advance.

Attached Thumbnails

  • 20131006.jpg
  • 20131105-1.jpg
  • 20131105-2.jpg
  • Difference.jpg


#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 06 November 2013 - 09:39 AM

If you are using stream mode, the U3 acquires data at a rate determined by the U3 clock, which is only 1.5% accurate.  When you then put stream data on a graph, I am not sure if DF is displaying it's time or the time based on the U3 stream clock.

 

If you are using normal command-response mode, all timing is controlled by software.  The clock for DF is the computer clock, so they should agree.

 

Are you using stream mode?



#3 AzeoTech

AzeoTech
  • Admin
  • 323 posts

Posted 06 November 2013 - 12:00 PM

Actually, that's not completely true:

 

If you are using stream mode, DAQFactory records the start time of the stream and receives back from the UD the actual deltaT between scans.  It then uses this to calculate the time stamp on all subsequent data points from the stream using simple math.  I'm not sure how precise that deltaT that the LabJack UD driver returns to us is.

 

If you are using non-stream mode, then the time stamps are determined from the clock, however DAQFactory, by default, does not use the system clock.  It instead uses the high precision clock.  The system clock in Windows is only precise to about 15ms, and since many applications of DAQFactory require a more precise clock, we use the high precision clock.  On some computers, and I have yet to figure out which ones exactly, the high precision clock drifts a lot.  Most people don't see this, but some do.  For this reason we have a dll you can use that causes DAQFactory to use the actual system clock instead of the high precision one. This is fine if you can deal with 15ms of jitter in your time measurements (including delay()).  You can get it here:

 

http://www.azeotech....oadUserTIme.php

 

Make sure and read the entire page before using it as it has some important warnings about the system clock, especially in relation to daylights savings time which can really mess up your data logging and automated scripts.


Main Web: www.azeotech.com
Express Web: www.daqexpress.com

#4 KEN77

KEN77
  • Members
  • 3 posts

Posted 06 November 2013 - 06:22 PM

Dear Mr. AzeoTech administrator,

 

Thank you  for your quick reply and the suggestion for the solution of the problem.

 

We will install the "usertime.dll" on the system and see the results.

 

Best regards.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users