I’m using the standard windows XP scheduled task to firstly start wxsimate just before the scheduled download time, then 10 miniutes later another scheduled task opens wxsim to do the forecast 5 mins later. I’ve set both tasks to time out after 75 mins and also wake up the comp if needed. Each program auto closes when the task at hand has finished.
I’ve now created a new text file (makeitso.txt) with just a 0 in it. Another scheduled task about 15mins after the forecast run finished launches a batch file to copy the makitso.txt to alreadyopen.txt.
The command I use is:
xcopy c:\wxsim\makeitso.txt c:\wxsim\alreadtopen.txt /y
Despite all my changes to the scheduling and updating to the latest version of SSS, WXSIM has failed to run overnight. The previously mentioned error “another copy…blah” is back…additionally the “alreadyopen.txt” file has a “0” Thus, for my particularly heavily loaded setup, the change from 12.7.2 to 12.7.5 has caused a real issue.
In the meantime, before using other solutions, I will again return to leaving WxSim NOT auto closing after scheduled runs and disable SSS…grhhh 
I’ve set up a little test to see whether I can isolate the problem. I’ve removed my work around and I’m trying to get a fail again. I’m running wxsimate constantly with wxsim starting every hour and running a forecast. Opening with XP task sheduler and closing automatically. I’ve also cleared the event logs to see whether any errors are logged.
So far (I set this up at 10.30 last night) I have not had any issues. I’ll leave it running with just wxsim opening and closeing to see whether I get the error.
Regards
Rob
I tried yet another test overnight with my system to make absolutely sure about the “alreadyopen.txt” file and the error caption.
With the error caption showing on screen(anothy copy still open etc…blah…do you want to continue? yes/no boxes)…the alreadyopen.txt file is definitely showing as being a “0”.
So far, I have not seen the error. The only difference in my set up is that wxsimate is running constantly and I have just 1 task repeating, every hour, the opening of wxsim. Previously I had 3 separate tasks running at 6am, 1pm and 7pm to start wxsim. I’m not going to change anything just yet, but I would have expected to see the fault appear by now !?
I got the error on my 15:00 forecast run today.
alreadyopen.txt had a ‘1’ in it when I looked and yet there was only one WXSim open.
I also noticed today that the System Scheduler doesn’t actually close WXSim as I have the “Send normal close signal to window” selected. This just throws up the “can’t close using the red X” error message and doesn’t actually close anything. #-o
I did try setting up a button push style close using use {ALT+F} {DOWN+DOWN+ENTER} but that didn’t seem to work either. What are others using for the close signal?
I use SS as backup too for closing both wxsim and wxsimate, in both i use “terminate application” as i suppose they should close by itself and its just a backup to be sure they are closed. seems to works quite well.
My setup is:
SS starts wxsimate at .45
wxsimate runs at .46 and close itself when done
SS terminate wxsimate at .49
SS starts wxsim at .50
wxsim runs at .51 and close itself when done
SS terminate wxsim at .59
SS runs a batch-file at .59 what copy needed files for website to an out-folder so Fling auto-FTP picks them up and upload them to the site (Tom, could we have an out-folder where files of choice could be saved for this types of autoFTP’ing? I upload latest.txt, latest.csv and plaintext.txt)
Minutes there are not true but the scheme is that.
Henkka
Hi
I had the same problem here too… For now i have created a delete alreadyopen.txt BAT file and i run the event using scheduler before the scheduled forecasts
Nikolas
One other thing that’s come to light after the error today is that the next run (21:00) failed with an Error 62 and I found that the custinit.txt was blank again. So I copied the data over from the custinit backup.
Update: Despite me changing alreadyopen.txt to ‘0’ last night, I woke this morning to find that WXSim hadn’t run the 03:00 or 06:00 forecasts and there were two instances of the “already open” errors on the screen. I checked alreadyopen.txt again and once more it showed a ‘1’ in there and not a ‘0’.
Now that it’s completed a run (started manually) alreadyopen.txt now shows ‘0’ so I’ll see what happens at 09:00 & 12:00 today.
I had my forecast fail at 8pm last night. Although it is not directly connected to the issues here, it may have some bearing.
I had a .net error relating to wxsimate. It stated that the file city.fdt was being used by another process. This caused the data to not download, but did not cause any error in wxsim.
I’ve included a text file with the error details pasted in, just in case.
Anyway, I’ve now changed the test scenario to have wxsimate starting every hour (and closing automatically) with a scheduled task. I’ll see whether that has any effect.
Rob
mictosoft.net error.txt (3.18 KB)
I have also seen that error. In my case, I keep both programs (WXSIMATE & WXSIM) running all the time. After I increased the interval between WXSIMATE downloading data and WXSIM running, my problem stopped.
ED
I see this is an active thread! I thank all of you for the trouble-shooting you’re doing. I’ll be interested to find what, if anything you all can figure out. Meanwhile, I’ve been running 12.7.5, with it being booted up by SS, but closing itself, for a few days with no errors, except there was an apparent power outage Friday. I saw from home that the forecasts weren’t updating, so I went up to the school and found the computer off - that’ll do it!
After I booted back up I did experience one WXSIM-related error. I tried running wret.exe to update the “learning” factors (I’ve done this roughly once a month, and the correction factors fluctuate a bit with the season). I got the “error at line 1909” thing. This is diagnostic of a corrupted latest.wxf file, which in turn can happen if WXSIM is closed improperly or some error aborts the run. In this case, it was because the power went out!
There’s an easy cure for this one: just run a quick forecast (even just a one day “fake” one) and there should then be a good .wxf file for wret.exe to see.
Tom
Well…it would appear that even without using System Scheduler that it is still possible to get the problem…it failed to run overnight as WxSim Scheduler had required, but interestingly at the same schedule time as all the other previous fail to run times…Same caption and this time a 1 in the alreadyopen.txt msg…I’m going to use WxSim ver 12.7.1 for a while.
Mine has gone quiet and acting normal after I shifted the shut time for Wxsim closin using SS out another minute, but that may just be a red herring as it seems to happen with 1 in the file and 0 in it…
Graeme
OK, now I"M the one reporting crashes!
I’ve always had almost flawless auto runs, but just “upgraded” to 12.7.5 on the school computer (dedicated to the auto runs and other weather stuff), and have had two failures in two days (with several successful runs in between). It looks like I’ll have to go up there and see what happened tomorrow. I did that today (had some work to do anyway) and watched four perfect runs, went home, and then found it failed on the next one!
This is strange, and I know I’m supposed to be the one solving these problems (and I will!!!), but your continued feedback is vital here. I need to know what the difference is between those of you getting highly reliable runs and those getting problems.
I will say this. The error message I saw yesterday was a WXSIMATE one “cannot access the file wmatelog.txt because it is being used by another process”. It looked also as if WXSIM stopped dead in its tracks, about halfway through a forecast (which was looking good up to that point). WXSIM had no error message.
Anybody seen that???
Thanks! 
Tom
I have seen some strange graphs being produced with vst I think going up and down rapidly, I have an image of it attached here. It was still a complete and valid run but…
Added the wxf file too… as a txt
f10072018B.txt (125 KB)
<<I have seen some strange graphs being produced with vst I think going up and down rapidly, I have an image of it attached here. It was still a complete and valid run but…
I’ve seen this sort of thing with auto cumulus and auto stratus, and perhaps with the sea breeze, but it doesn’t look (from the text at the bottom of the screen) like those are checked (please confirm).
Another thing to check: your output interval and iterations per interval. I think a good choice is 30 minute output with about 6 iterations per interval (these are under parameters). Sometimes if the interval is too big (or not enough iterations per interval), things can get “choppy” like that.
Tom
Yes, auto-cumulus amd auto-stratus were checked… but I have also set the iterative to 6 times from 3 so that should make a difference.
Thanks
Graeme
Tom for the first time ever I have had a problem with the alreadyopen.txt file containing a 1 when no WXSim was running. It had failed I think this morning at the 07:40 run and probably because of the error message I get when I try to start it manually. It says that the stored water temp differs from climatological norm by more than 4.5 degF or 2.5 degC please visit Diurnal Breeze and click yes. Now the water surface temp showing is 15.5 degC and the actual at present shown by a buoy in the Channel is 17.2 degC. I get this message everytime I try to open WXSim. The current value I had was 15.5 degC which is a bit low. Having reset this to 17.2 it now has gone away.
I believe I mentioned before that the actual temp is available from a buoy and it would be good if WXSimate could retrieve the current value and use it which would save this error happening if I use a user entered value which seems to override the WXSim climatological value.
Stuart
Edit:
I’ve been thinking about why the alreadyopen.txt file contained a 1 in this case and I believe that when the system scheduler closed WXSim after it was still running after some hours it does not shut down correctly because of the outstanding message. I just wonder whether this could be happening to others, that is an outstanding message stopping the program closing properly. If this message is a transient error condition (unlike mine which happened on every program start) you would be unlikely to see it when you came to start the program again but the alreadyopen.txt stops it because of the 1 value. I dont know if there is any way for Tom to trap a close like this when there is an outstanding message and close normally zeroing the alreadyopen.txt, if not I suggest this is a potential problem and maybe another way of determining another copy running should be investigated.
