Showing results for 
Search instead for 
Did you mean: 

Timestamp time/date browse button

I'm seeing some odd behaviour from the time/date browse button on the timestamp control - this is in LabVIEW 8.6.1 on WinXP


I have an application in which I wish to start a sequence of unmanned tests. Upon clicking the button to start a sequence I have a sub-vi pop up which has a numeric for the user to enter the number of tests to complete, and a timestamp control to enter the time at which the sequence should start.


The application connects via tcp over the network to a third party data logger. So far this has worked well.


The timestamp control (new feature in the application) has an associated time/date browse button. when this is used the application crashes, reporting that the tcp connection has been shut down by the peer. At the moment i am doing nothing more with the timestamp than displaying it in an indicator - I haven't got as far as using the result.


If the timestamp is changed manually (without using the browse button) then the application does not show an error.


If I call the sub-vi from seperate test wrapper code not linked to the original aplication and use the browse button again the original applcation crashes.


I cant find anything like this on the forum.


Due to browser issues I can't post code or screenshots from the development machine. I'm actually having to post this from a standalone machine. Should I manage to get a browser update on the development machine I'll post some code/screenshots.


Any help greatfully received - I'm stumped.









0 Kudos
Message 1 of 17

First, based on your description, I'm assuming that the program does not crash. By default, if you do not wire an error out terminal and it has an error, LabVIEW will display a pop up with the error and allow you to abort or continue. I'm assuming that's what happening.


Which raises the question why the connection is closed. My guess is that the TCP primitives require root loop access, which is apparently blocked when you open the browse dialog. Then, because your program does not send a proper response to the other side in a reasonable amount of time, the other side times out and closes the connection. You can verify this if you open a menu and leave it open instead of using the browse dialog. You can see more about this issue here -

Try to take over the world!
Message 2 of 17

Hi tst, thanks for taking the trouble to reply.


No, the program doesn't crash. It exits gracefully, via some error handeling code that notes the error in an error log text file - in this way I hopefully have some clues when a user calls me to a problem on the system. So though I don't see the standard LabVIEW error pop-up, I do record the error code and description.


In this case...


Error 66 occurred at TCP Read in MB Ethernet>MB Ethernet Master>MB Ethernet Master Query Read Holding Registers (poly).vi->Main - H-logger

Possible reason(s):

LabVIEW:  The network connection was closed by the peer. If you are using the Open VI Reference function on a remote VI Server connection, verify that the machine is allowed access by selecting Tools>>Options>>VI Server:Machine Access on the server side.


BTW, Comms over the tcp uses the modbus library found here...


While the browse dialog is open I can see in the background the readings continually update over tcp. I only get the error when there is a mismatch between the timestamp in the dialog and the system time when the dialog closes.


Following your sugestion I tried opening (as an example) tools>>options and get the same error. My code stops recieving data and on closing the menu item the same error is generated and the code exits.


I'll take a look at the link you included and see if it offeres any help (tried twice while writing this and crashed the browser both times!)


Best Regards,



0 Kudos
Message 3 of 17

Looks like I will have to view that link from home - every time I try here I get some form of flash error. :o(



0 Kudos
Message 4 of 17

After reading around this...


1. Tried disabling the browse which solved the immediate problem, but I found it was possible for the user to misenter data when typing in directly and end up with a wildly eronious date.


2. Removed the timestamp control from the front panel, added numeric controls for hours and minutes, and then interpreted these on the block diagram as required to advance the date. i.e. if Hours:minutes is less than current Hours:minutes, advance the date by one. This works for me because I am only interested in entering a start time within the next 24 hours, and a time that has already passed is invalid.


tst, thanks again for your assistance, kudos given.



0 Kudos
Message 5 of 17

Hello Bandit,


I get exactly the same problem on one of my application.


My application is divided in 2 part : A windows part and a CRio part.


When i click on the date browser button in the windows part, my custom TCP/IP communication with my CRio stops in error.
0 Kudos
Message 6 of 17



its me again ...


Just a little more about my application ...


-> My TCP/IP connection works in an asynchronous, and autonom VI.  At the moment of the problem, the TCP/IP process only send and receive Watch dog frames !


-> The date browser button hit is done in a "modal popup VI" which doesn't block my TCP/IP asynchronous VI. (I have other similar modal popup which doesn't generate the same problem !)


The problem occurs only when i click on the date browser button. (2 to 5 seconds after the button hit)

(TCP/IP error 66)


Does the calendar popup have an interaction with the network timestamp brodcasting ? (ICMP, NTP ??? )

Does it get information by listening NTP frames ?
0 Kudos
Message 7 of 17



I'm one of the Applications Engineers at NI in the UK office. Do you have an example project that demonstrates this behaviour and allows me to replicate it? It'd be great if you could create a copy of your project, stript it right down to only the problematic part, and then post it in a zip file here. We can then look into it further and see if we can replicate the same behaviour.


Imtiaz Chowdhury
Project Manager
Green Running / Austin Consultants

0 Kudos
Message 8 of 17

Hello Alpha1,


I think it will be difficult to extract the problem out of my big application.


I have made some more research about the problem with the help of Ni Support in France.


I can explain you the general architecture of my application.


  • My application is created with a home made framework
    • The HMI is based on multiple subpanels, loaded as needed using custom events 
      • Every screen is created as a separatly VI, running asynchronoulsly
    • The hardware interfaces, drivers ... demons ... are build with asynchronous VI's
    • All elements are talking together with custom events, fifos, FGV ...
    • This modular way of programming allow to work with more than one person at a time on the same project.


So, in my buggy application i have,


  • A screen, (asynchronous VI running in a subpanel) build with an event loop, without any link to the rest of the application.
  • An asynchronous VI, managing TCP/IP communication.


When i drop a "date/time" control on the VI, and i run the application ... when i click on the calendar button, this generates an error in my TCP/IP VI.

To be sure that there is no link between the 2 VI's, i created a VI only viewing a date/time control (Without any link to the data of my application !

I don't use the value of the control ... the date/time control is only dropped on the front panel.) When i click on the "calendar" button, this generate a TCP/IP error.

  • TCP/IP error 56 on the host : (Host executing the HMI with the date/time control)
  • TCP/IP error 62 on the TCP/IP target.


With the help of the NI support, we get a look to the VI which is launched when you click on the button : .../Labview/resource/dialog/ .

But this VI contains "password blocked" subvis ! There is a "debug VI" called ... perhaps you could search in that way !


So. I hope this will help a little more.
0 Kudos
Message 9 of 17


What version of LabVIEW are you using? I saw the error in LabVIEW 8.6.1, but I've just thrown some scratch code together in labVIEW 20011 SP1 and can't reproduce the issue I had.

I hope NI France are proving helpful for you.



0 Kudos
Message 10 of 17