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.
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 - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Calendar-control-that-does-not-block-the-GUI/idi-p/141...
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 Receive.vi:2->MB Ethernet Master Query.vi:1->MB Ethernet Master Query Read Holding Registers (poly).vi->Main - H-logger full.vi
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... http://sine.ni.com/nips/cds/view/p/lang/en/nid/201711
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!)
Looks like I will have to view that link from home - every time I try here I get some form of flash error. :o(
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.
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.
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 ?
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.
Green Running / Austin Consultants
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.
So, in my buggy application i have,
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.
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/picktime.vi .
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.
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.