Flat-lining

[DaveNZ]

Hi Steve

Occassionally the data and graphs 'flatline' during live data collection.
This morning I got up to see that is what happened shortly after I went to bed and every consecutive data point stayed the same afterwards.
First I closed cumulus and then deleted all the 'bad' data from jan10log, opened again and it downloaded the right data from the logger this time, but this data was not plotted on the graphs (I got a straight line joining the points at 0:50 and 8:30.
I closed and opened again but the graphs were still doing that.
I deleted that freshly downloaded data to try another download but now I can't get it to download

Is flatlining a communication issue with the station?

[steve]

Could be caused by a number of things. Are all the data flat-lining, or just external ones? Zip up the diags folder and attach, please; might show something.

[DaveNZ]

All the data flat-lined from what I remember, but can't confirm as couldn't get cumulus to download from data from that period from the logger a 2nd time.

Here's diags folder, several entries for today. The time of interest (when flat lining began) will be somewhere about 10/01 01:00

[steve]

Some errors here:

2010-01-10 01:00:29 : Writing todayfile, LastUpdateTime = 10/01/2010 1:00:00 a.m. raindaystart = 7.40000009536743
2010-01-10 01:00:36 : Access violation at address 00489346 in module 'cumulus.exe'. Read of address 81EC8B55
2010-01-10 01:00:36 : Access violation at address 00404AAE in module 'cumulus.exe'. Read of address 00000001
2010-01-10 01:01:00 : Writing todayfile, LastUpdateTime = 10/01/2010 1:01:00 a.m. raindaystart = 7.40000009536743

Unfortunately I don't know what they are as the error messages aren't very useful, as you can see. Presumably nothing was written to the log file after this because of the errors.

If you restart from the backup from before the problem, it should be able to download the data from the logger. You will need to do it before you do many more starts, though, as there are only 10 sets of backups.

[DaveNZ]

If you restart from the backup from before the problem, it should be able to download the data from the logger. You will need to do it before you do many more starts, though, as there are only 10 sets of backups.

Awesome thanks, don't know why I didn't think of that - all good now

[jjocsak]

I had the same thing happen yesterday. Here is a clip from the log.

2010-01-09 09:53:15 : Writing todayfile, LastUpdateTime = 1/9/2010 9:53:00 AM raindaystart = 36.310001373291
2010-01-09 09:53:27 : Writing todayfile, LastUpdateTime = 1/9/2010 9:53:00 AM raindaystart = 36.310001373291
2010-01-09 09:54:00 : Writing todayfile, LastUpdateTime = 1/9/2010 9:54:00 AM raindaystart = 36.310001373291
2010-01-09 09:54:02 : Access violation at address 006878B7 in module 'CUMULUS.EXE'. Read of address 0000202C
2010-01-09 09:54:02 : Invalid pointer operation
2010-01-09 09:55:00 : Writing todayfile, LastUpdateTime = 1/9/2010 9:55:00 AM raindaystart = 36.310001373291
2010-01-09 09:56:00 : Writing todayfile, LastUpdateTime = 1/9/2010 9:56:00 AM raindaystart = 36.310001373291
2010-01-09 09:57:00 : Writing todayfile, LastUpdateTime = 1/9/2010 9:57:00 AM raindaystart = 36.310001373291
2010-01-09 09:58:00 : Writing todayfile, LastUpdateTime = 1/9/2010 9:58:00 AM raindaystart = 36.310001373291

All data and dials froze until I restarted Cumulus this morning

I have a VP2 and am using Windows 7 32 bit.

This happens at least once a week

Jeff

[steve]

You also seem to be using a 1 minute logging interval? I wonder if that is relevant. It maybe just increases the chances of it happening.

[steve]

I've had a look at all of the places where I log the exception message like that without any further text (and while I was doing it I changed them so I know where they're coming from in future!) and I've deduced that the place that these occur has to be in the thread communication system which passes data from the thread which reads the data from the VP2 to the main thread that updates the GUI. So if that's fallen over, it's not surprising that it then stops updating.

Unfortunately I don't know why the threading component would fail like this. It's open source, I'll have to see if I can get some help from the author(s).

[steve]

I've found a possible problem with the way I use the threading component which is related to the length of the forecast strings. I've done a change and I'll run with it overnight to see if it causes any new problems, and if not I'll upload it tomorrow for you guys to try.

[jjocsak]

Thanks Steve.

Jeff

[steve]

See Announcements for new build.

[DaveNZ]

See Announcements for new build.

Thank you Steve...
Have installed the new build, will let you know of course if it happens again

[jjocsak]

See Announcements for new build.

Thank you Steve...
Have installed the new build, will let you know of course if it happens again

Thanks, me too.

Jeff

[DaveNZ]

It's been over a week now and this issue hasn't occurred again. Good stuff

[steve]

Great - thanks.