NIST Server issue

[GDash]

Hi all,

I have downloaded VerneD's code from https://decibel.ni.com/content/docs/DOC-13527

However when I try to run the code, even in an isolated VI I just get an error 42. I'm running LabVIEW as an administrator but no permission requests have appeared.

Currently using LabVIEW 2011 SP1 and windows 7, so I don't know if this would cause an issue.

The aim is to be able to update the system time in order to be able to use Get Date/Time vi to produce date stamps from a UTC synchronised time/date.

Many Thanks for any advice on how to rectify the issue and get me running. Alternative methods are welcome as well.

Giles

[josborne]

Seems like it is the call to Kernall32.dll that is geneating the error, correct?  Not sure why that would happen.  Could it be a 32 vs 64 bit issue?

You might want to post a comment on that page with the example.  Then maybe the author can assist.

BTW:  Windows has built-in functions for doing exactly this.  I don't see the need to use LabVIEW.  Just go to Control Panel > Date & Time.

[GDash]

Thanks for getting back to me, as far as I can tell it's the call function library node that is producing the error, whether its related to kernel32 I don't know, just wondering if anyone has had similar issues when running the code.

As far as using the inbuilt windows functionality, if only it was this simple. The VI needs to be placed on a deployed machine that will be halfway around the world, and updated every half hour to ensure correct time, so manually updating isn't viable unfortunately.

Giles

[josborne · Accepted solution]

"so manually updating isn't viable unfortunately."

Just to follow up on the Windows thing.  You  can setup Windows so it automatically updates.  Not manual.  So you set it up once, and then Windows will continually update its system clock every X seconds through a remote NIST server.

In any case, the error is definitely from the call library node (which makes a call to the kernal32.dll).  Do you have a 64 Bit operating system?  Just wondering if there is some kind of conflict there.

Also, that example code is somewhat flawed.  The error should flow through the Call Library function.  That is probably not the cause of this issue.  But worth a shot to see if the error is from the DLL or the Call Library function itself.  See attached.

[GDash]

I hadn't considered changing the registry so I was assuming only once weekly updates were possible. Thanks for the help, that should have solved the issue.

Many Thanks

Giles