Get and Set RT System Time Programmatically Using System Configuration API

[James_McN]

Get and Set RT System Time Programmatically Using System Configuration API 

Overview
To set the time on the RT clock you traditionally have two options.  First is to do it manually in MAX or run a VI on the target to set it locally.The System Configuration API now allows you to set the time over the network programmatically without having to do any clever VI server calls as you would have to do previously.

Description
Attached are two VIs to get and set the time based from a System Configuration Session.  This will point to the RT target and the code then finds the appropriate hardware resource to gain access to the clock.This can prove very useful as part of a automated deployment process where you can use this API to identify the target, download an image and then set the time correctly using this VI.This was written and tested using NI System Configuration Driver 5.0 and LabVIEW 2011 however I am not aware of any compatibility issues with previous versions.The system configuration API is supported in LabVIEW 8.6 and later and is a graduate of NI Labs.  You can find the Labs page at Welcome to the NI System Configuration API and download the driver at http://joule.ni.com/nidu/cds/view/p/id/2613/lang/en.

Requirements

• LabVIEW 2012(or compatible)

Steps to Implement or Execute Code

1. Unzip the attached folder to your computer
2. Open the VI "Get System Time 2012 NIVerified.vi" or “Set System Time 2012 NIVerified.vi”
3. Run the program

Additional Information or References
VI Snippet of "Get System Time.vi"

 

VI Snippet of "Set System Time.vi"

 

 **This document has been updated to meet the current required format for the NI Code Exchange.**

[Prabhu16]

It does not work for my cRIO, 9033(Linux OS). The time set is not reflected back.

[CoastalMaineBird]

This doesn't work for me either.  (PXI 8196, LVRT 2013, PharLap). It's a weird one.

"We only one 1 element to respond."  ? ? ? That's like English, only different.

Why have a demo that reads the current time, sets the time to the current time, and then reads the current time again?  What is that supposed to demonstrate?

If I set the SESSION IN to my box name, it does nothing.  If you STEP thru it, the first CREATE FILTER vi simply terminates the program.  No error, it just stops.  It's like there's a STOP function inside that VI.

If I set the SESSION IN to "localhost", it at least executes.  It comes up with the host name correctly.  It goes thru the motions. It completely ignores the time I provide.  No error, it just ignores it.  I changed to set the time to NOW + 30, so I could tell a change.  But the BEFORE and AFTER times are different by either 0 or 1 mSec.

This is a waste of  ... time.

[Cavarval]

Prabhu, CoastalMaineBird,

It works, but depending on a few factors, you will need to switch the third property (Time After) to be executed after the Save Changes.vi. This is, you read the CurrentTime property (Time Before), write the CurrentTime property (Time Stamp), save changes and then, you read it back. I noticed it fails to update if the three properties are executed before the Save Changes.vi.

I tested this on a myRIO, but it is worth to try it in your devices if it failed.

[Mads]

There is a bug in the System Config API that voids all changes if you read a property after the changes, but before the save. I burned myself quite hard on this bug earlier this year...hopefully it will be fixed soon

[nanocyte]

For setting the time, just use the built in function: http://zone.ni.com/reference/en-XX/help/373107N-01/nisyscfg/set_time/