What would cause difference in the data of a Citadel database in 1 process?

[Dan@NIST]

The on Columbus Day weekend the laptop I have been using to run my LabVIEW DSC program completely froze and the only way to recover on Wednesday was to do a hard boot. After the computer rebooted, I checked to find out when the PC crashed. My first thought was to look at the database to see when the data flow stopped. Unfortunately, It was not completely clear the exact time the database stop receiving updates. The time range of when data stopped was about 40 minutes. Meaning one of my shared variables,flow, showed no data at 4:40 and another shared variable, temperature went on until 5:20 then stopped. Why would this happen? How can I prevent this?

[Eric A.]

Hi Dan@NIST,
It is always difficult to determine the cause of a crash.  Has your VI  ever worked correctly without causing your computer to crash and if so, for how long?  When you restarted LabVIEW, did it give you an option to investigate the error?  There are a lot of things that could result in a crash.  Tell us more about what your VI does and what functions it uses.

[RavensFan]

Is it possible that the flow value would have been relatively consistent between 4:40 and 5:20?  My understanding is that the shared variables only log a new data point if they change by a given amount.  (That amount can be set in the properties of the shared variable.)  This is to save space in the database.  So if the value did not change more than the threshold, a new value would not have been before the PC crashed.

Message Edited by Ravens Fan on 10-18-2007 12:01 AM

[Dan@NIST]

First of all thank you Eric A and Ravens Fan for your responses to my problem. This was the second crash with this laptop. The first time I end up getting the dreaded "blue screen of death," but it recovered after a hard boot. Back then I was not using it with LabVIEW as I am now. All in all, it is a pretty good laptop and I am happy with it. The VI I have on it for this project has been running on and off for a couple of months. I believe the longest run-time has been two weeks. After that run-time I found I was not always logging data as I thought. As Ravens Fan has pointed out, if the data does not exceed the threshold it is not logged. Previously I had the default of 1% set for the threshold, but changed it to 0% to ensure all data is logged. That should fix the problem of logging not being consistant. Plus it is possible that flow did not change. As of this response I had not verified that all the threshold was set to 0%. 

I will response soon on what the VI does and what is loaded.

Resonses are welcomed!

[Dan@NIST]

Well like everything else I am pressed for time so I will make this description brief, but hopefully to the point. I am using a third party OPC server (KEPDirect OPC Server) to create the tags I use to interface LabVIEW with the PLC. I use Real-Time Trend.vi to display the data for the user and feed that data into other subVIs to do some control logic. I also use the readAlarms.vi, which I noticed I did not wire any timeout variable. There is one possible hang-up, perhaps the SharedVariableEngine took a nap and did not feed the readAlarm.vi. In the DSC module I have created and configured the shared variables to log data every second, regardless of the threshold. The variables are linked via Network published variable AKA the shared variables. Communications look good, but I only have set up a way to account for comm errors with my serial device. Otherwise the communication is via TCP/IP.

Again thanks for taking your time to read and add to this thread!

[Eric A.]

Hi Dan,
Were you able to determine if you serial communication was a factor in your application freezing?

[Dan@NIST]

Unfortunately I have been home most of this week with pneumonia. I have not proved it was the serial communications that caused the hang up. I am not 100% sure how I would do that. I guess a VI to monitor serial data or some kind of timeout default so if communication stops I could escape the WHILE loop. I guess I should go into what the WHILE loop does... and without it in front of me I can not give all the details of the different functions I call. I know out side of the loop I have a buffer to hold the data. The WHILE waits until the number if bits is equal to 2 or an communication error occurs. Once I have two bits I do the necessary math to convert the data to more understandable data.

How could I use a timeout to solve a potential problem in the serial communication?

[Jason_Whaylen]

Hi Dan!

Thank you for contacting National Instruments.  From what you have mentioned, it looks like you are on the right track in that you should monitor the serial timeout from within a While Loop.  Also, I would try running this program in Highlight Execution in order to determine if the problem is occurring from the serial connection portion of the block diagram.  Any information you might run across when you are able to access the program could be helpful in locating the problem.  I hope this helps!  Let us know if you find any additional information or have any other questions.  Have a great day!

Jason W.