I had a customer report several crashes with Weather Message 3.0. Each time the program crashed, he was asked whether to send debugging information to Microsoft. He tried that a couple of times and asked me if I had received the information. The answer was no. I don't subsribe to that service from Microsoft.
I asked that he snap me a picture of the crash information. After reviewing a couple of those, I could not determine the nature of the problem. That "microsoft box" would not allow him to copy the entire error message. We went back and forth for a couple of weeks to no avail.
I finally asked him to look at the event viewer to see if he could find an entry when the crash occurred. I had forgotten that the CLR (the .net common language runtime) makes entries in the event view for some error conditions. Yes --- he found entries and sent them to me right away.
After looking at the information for 2 minutes, I quickly discovered that the faulting module was mclsp.dll. This dll has nothing to do with Weather Message, but everything to do with McAfee firewalls and tcp/ip. Apparently it has some problem --- the user is now investigating that and promises to give me an update.
All of the Weather Message programs attempt to capture error conditions and report them to the user before shutting down. Most are recorded in a log file, if the program has a log file, or a file with the extension ".log".
In situations where the application is not given the chance to handle the error, remember to look at the event viewer to see if the CLR made an entry. This can make running down an error a lot faster.
Tuesday, October 31, 2006
Sunday, October 29, 2006
Integrated Program Help Update
After discussing the integration of program help with some of the beta users, I am moving ahead in this direction. Considering that the manual would need to be heavily rewritten and updated for version 3.0, the decision was made to move the manual to a windows style help file.
Beta 6 contains windows style help for the Server and Server Setup programs. The F1 key has been enabled on all windows. I can say that the help is more detailed than what you would find in the manual.
The is a big undertaking to say the least. I suspect I will spend the rest of this week and next weekend getting this completed. The current manual is over 150 pages. It will be worth the effort.
I should be able to update this help as I make changes in the software. This will help the beta testers as the notes that I make on the beta page should be reflected in the program help.
The question is whether there will ever be a manual. The answer is yes. I have the ability to print the windows style help as a manual. I will do that after all of the help has been converted.
Beta 6 contains windows style help for the Server and Server Setup programs. The F1 key has been enabled on all windows. I can say that the help is more detailed than what you would find in the manual.
The is a big undertaking to say the least. I suspect I will spend the rest of this week and next weekend getting this completed. The current manual is over 150 pages. It will be worth the effort.
I should be able to update this help as I make changes in the software. This will help the beta testers as the notes that I make on the beta page should be reflected in the program help.
The question is whether there will ever be a manual. The answer is yes. I have the ability to print the windows style help as a manual. I will do that after all of the help has been converted.
Tuesday, October 24, 2006
Integrated Program Help
I am looking at the possibility of integrating Weather Message's manual as a standard windows help file. The manual is now over 150 pages and is becoming more and more of a task to maintain. Breaking the manual down by program function and attaching it to each program's respective help button may make the job easier. The big question is what does a user prefer!
If you have thoughts are comments, drop me a note.
If you have thoughts are comments, drop me a note.
Sunday, October 22, 2006
New FTP Ingest Option
Weather Message 3.0 now has options to automatically ingest the nws ftp files. The first option is to ingest the 3 hour file when the program is first started. The second option is to automatically download the files based on a user selected interval.
The first option to automatically download the 3 hour file when the program starts will help users that do not use the software until a weather event occurs. The second option, just provides a redundant mechanism to download the files.
The option to manually download the ftp files has not changed.
The first option to automatically download the 3 hour file when the program starts will help users that do not use the software until a weather event occurs. The second option, just provides a redundant mechanism to download the files.
The option to manually download the ftp files has not changed.
FTP Ingest Problem
It appears that the emwin archive files on the NWS EMWIN ftp server are no longer being updated. The last update was 9/28/06. The server does contain files with new names that are being updated. The new archives appear to contain both text and graphic products, rather than being separate downloads.
I have sent an email to Santos to inquire about this change. I am updating Weather Message 3.0 with the new file names. I'll update 2.10 after hearing back from him.
The new archives are complete with no missing products. It appears that the files are being created by Weather Message Ingest. The duplicate files contain a numeric sequence. Did I forget to mention that the NWS is using Weather Message Retransmission software at HQ!
I can say that the old archive files were not complete. If two products with the same name were issued during an archive period, only the last file was in the archive. This was not good and basically made those archives incomplete. The new archives, if they stay, will be a welcomed change.
I have sent an email to Santos to inquire about this change. I am updating Weather Message 3.0 with the new file names. I'll update 2.10 after hearing back from him.
The new archives are complete with no missing products. It appears that the files are being created by Weather Message Ingest. The duplicate files contain a numeric sequence. Did I forget to mention that the NWS is using Weather Message Retransmission software at HQ!
I can say that the old archive files were not complete. If two products with the same name were issued during an archive period, only the last file was in the archive. This was not good and basically made those archives incomplete. The new archives, if they stay, will be a welcomed change.
H VTEC Decoding
Weather Message Net now decodes the H VTEC line when present. H VTEC is used in hydrological products. The H VTEC line contains this information; Site Identifier, Flood Severity, Immediate Cause, Flood Record, Flood Beginning Date, Flood Crest Date and Flood Ending Date.
In discussing this capability with a user, I know that the next step will be to add alarm support for Site Identifier and Flood Severity. In addition to alarming, I suspect some users will want short message variables for each of these elements. If you are interested in H VTEC and want to provide some input on how it operates, send me a email.
In discussing this capability with a user, I know that the next step will be to add alarm support for Site Identifier and Flood Severity. In addition to alarming, I suspect some users will want short message variables for each of these elements. If you are interested in H VTEC and want to provide some input on how it operates, send me a email.
Optimization
Weather Message 3.0 is internally different from Weather Message 2.x. The program were practically rewritten for microsoft.net 2005. I have spent countless hours reviewing the code for bottlenecks and ways to increase performance, which reduces CPU utilization.
Changes this weekend have resulted in some optimizations that give a 50% time improvement in some routines. (This resulted in a few milliseconds of improvement) There were also changes that reduced the per message internal memory requirement.
When it seems that I am not turning out alot of new changes, I am still at work on the software. The microsoft.net 2005 environment is new to all programmers. Because of that, I have to double check the code. It has to work, then when it works, I want to determine if there a faster way to get the job done.
A programmer can write code that works, but uses all of your CPU cycles. My goal has always been to write good code that is highly efficient. I guess that goes back to my days of writing code for computers that had 8,000 bytes of memory. Having access to mega-bytes or giga-bytes of memory and giga-hertz cpus is no excuse for poorly written code.
I recently spent 4 hours rewriting the serial ingest data processing routine. The change resulted in the routine being event driven which was supposed to be a good thing. After the changes, the program consumed twice the cpu cycles. I went back to the original code that worked and provided the lowest cpu usage.
Optimization of the Weather Message code will continue for some time as I learn the best ways of accomplishing tasks.
As a side note to optimization, I will start converting the configuration files of other applications to XML. Although there is a small performance penalty for using XML, this standardization is worth the cost.
Changes this weekend have resulted in some optimizations that give a 50% time improvement in some routines. (This resulted in a few milliseconds of improvement) There were also changes that reduced the per message internal memory requirement.
When it seems that I am not turning out alot of new changes, I am still at work on the software. The microsoft.net 2005 environment is new to all programmers. Because of that, I have to double check the code. It has to work, then when it works, I want to determine if there a faster way to get the job done.
A programmer can write code that works, but uses all of your CPU cycles. My goal has always been to write good code that is highly efficient. I guess that goes back to my days of writing code for computers that had 8,000 bytes of memory. Having access to mega-bytes or giga-bytes of memory and giga-hertz cpus is no excuse for poorly written code.
I recently spent 4 hours rewriting the serial ingest data processing routine. The change resulted in the routine being event driven which was supposed to be a good thing. After the changes, the program consumed twice the cpu cycles. I went back to the original code that worked and provided the lowest cpu usage.
Optimization of the Weather Message code will continue for some time as I learn the best ways of accomplishing tasks.
As a side note to optimization, I will start converting the configuration files of other applications to XML. Although there is a small performance penalty for using XML, this standardization is worth the cost.
Tuesday, October 17, 2006
New Purge Options
Weather Message Net Beta 4 contains changes to enable more control over the file / product purging process. You have two global settings "purge time in hours" and "product count".
These two global options work together. Setting "purge time" works just like it has in the past. If you set the purge time to 24 hours, the program will keep products on file for 24 hours after they expire. The new global "product count" option modifies the operation of "purge time". Setting a product count greater than zero indicates that you want to keep the specified count of products on file at all times. For example: Purge time 24 hours, product count 2 - means that you always want to keep unexpired products for 24 hours, however when it is time to delete the expired products, always keep the last two received.
You can also specify purge options by product. This works for graphics and text products. Enter a product identifer - wildcards (? or *) are acceptable. Enter the number of hours for this product and/or product count. For example: Enter RWRAL, 0 hours, 2 count - this would indicate that you always want to keep the last two RWRAL products regardless of expiration time.
Product purging give you three options:
hours > 0 and count = 0
This purges the product based on the expiration time.
hours > 0 and count > 0
This purges the product based on expiration time and product count. The program favors the hours parameter first. That is it will always keep a product until the hours elapses, then it will honor the count setting.
hours = 0 and count > 0
This purges the product based on the count of products. If you set the count to 2 and 4 product have been received in the last 30 minutes, the purge cycle will keep the last 2 product received and the previously received products will be deleted.
Note: Weather Message purges products every 30 minutes. (I have not received a request to make this a user definable option....yet)
Pressing control-u on the Weather Message Server window will force a purge cycle. This will allow you evaluate changes maked to the purge options.
These two global options work together. Setting "purge time" works just like it has in the past. If you set the purge time to 24 hours, the program will keep products on file for 24 hours after they expire. The new global "product count" option modifies the operation of "purge time". Setting a product count greater than zero indicates that you want to keep the specified count of products on file at all times. For example: Purge time 24 hours, product count 2 - means that you always want to keep unexpired products for 24 hours, however when it is time to delete the expired products, always keep the last two received.
You can also specify purge options by product. This works for graphics and text products. Enter a product identifer - wildcards (? or *) are acceptable. Enter the number of hours for this product and/or product count. For example: Enter RWRAL, 0 hours, 2 count - this would indicate that you always want to keep the last two RWRAL products regardless of expiration time.
Product purging give you three options:
hours > 0 and count = 0
This purges the product based on the expiration time.
hours > 0 and count > 0
This purges the product based on expiration time and product count. The program favors the hours parameter first. That is it will always keep a product until the hours elapses, then it will honor the count setting.
hours = 0 and count > 0
This purges the product based on the count of products. If you set the count to 2 and 4 product have been received in the last 30 minutes, the purge cycle will keep the last 2 product received and the previously received products will be deleted.
Note: Weather Message purges products every 30 minutes. (I have not received a request to make this a user definable option....yet)
Pressing control-u on the Weather Message Server window will force a purge cycle. This will allow you evaluate changes maked to the purge options.
Weather Message Net Beta 4
The initial release of Weather Message Net Beta 4 contained a bug that caused WxMap to not load "Other Colors". This problem has been fixed and the beta was refreshed at 9:00 pm on October 16th. If you downloaded beta 4 before 9:00 on October 16th, download it again to get the corrected WxMap.
Sunday, October 15, 2006
Proxy Support
After running into a proxy problem at the EMWIN Conference this year, I have added firewall and proxy support to all of the Weather Message programs. When I arrived at the EMWIN Conference, I quickly discovered that the Jefferson County EMA had an internal proxy. This was not a problem for WxRadar, as it has support for proxies. The other applications that needed to access the internet using HTTP would not work.
All applications that access the internet or local lan using HTTP or FTP now support firewalls and/or proxy servers. Previously each application had their own settings. These setting are now common to all applications. Setting a proxy in one program sets it for all of them. I went ahead and added a button to detect the proxy settings so that you don't have to try and figure out the settings.
All applications that access the internet or local lan using HTTP or FTP now support firewalls and/or proxy servers. Previously each application had their own settings. These setting are now common to all applications. Setting a proxy in one program sets it for all of them. I went ahead and added a button to detect the proxy settings so that you don't have to try and figure out the settings.
Saturday, October 14, 2006
Editing XML Files
Weather Message 3.0 uses xml files to store alarm and other settings. As version 3.0 continues to evolve, more of the setup files will transistion from standard text files to xml files.
A number of users have asked me about editing them manually. Yes - they can still be edited with notepad or any text editor. When using a text editor, you have to be careful to maintain the correct xml syntax. Failure to use the correct syntax can cause the xml file to not load properly.
If you want to edit the xml files in Weather Message, I suggest that you use a program designed for that purpose. There are a number of freeware editors available. I have used XML Viewer by Mindfusion. Here is a link http://www.mindfusion.org/product1.html
A number of users have asked me about editing them manually. Yes - they can still be edited with notepad or any text editor. When using a text editor, you have to be careful to maintain the correct xml syntax. Failure to use the correct syntax can cause the xml file to not load properly.
If you want to edit the xml files in Weather Message, I suggest that you use a program designed for that purpose. There are a number of freeware editors available. I have used XML Viewer by Mindfusion. Here is a link http://www.mindfusion.org/product1.html
Friday, October 13, 2006
EMWIN Conference
The 6th annual Southeast EMWIN Conference was a success. A special thanks goes to my fellow presenters Santos Rodriguez from NWS Headquarters, Brian Peters retired WCM and ABC 33/40 meteorologist and Mark Linhares NWS BMX meteorologist.
Santos gave the group an update on the EMWIN transistion plans and demonstrated the EMWIN software demodulator. Mark discussed weather products and VTEC. Brian and I demonstrated Weather Message.
I think everyone went away with a good understanding of EMWIN and the things you can do with EMWIN data using Weather Message.
Thanks goes to Jason Wright WCM and the leadership at WFO Birmingham for continuing to sponser the longest running EMWIN conference.
Santos gave the group an update on the EMWIN transistion plans and demonstrated the EMWIN software demodulator. Mark discussed weather products and VTEC. Brian and I demonstrated Weather Message.
I think everyone went away with a good understanding of EMWIN and the things you can do with EMWIN data using Weather Message.
Thanks goes to Jason Wright WCM and the leadership at WFO Birmingham for continuing to sponser the longest running EMWIN conference.
Tuesday, October 03, 2006
Purging Products
I have received a couple of requests for different purge options. I am looking at those now.
The software currently purges every file after the globally defined number of hours elapse. If you have it set to 24 hours, then a message is deleted after it has been expired for 24 hours. I have requests to add the ability to specify the purge time and/or number of messages to keep by product.
The change would work like this: You would have the option to specifing a product identifier or wildcard combination. With this product, you would specify the purge time in hours or enter the number of message you want to keep on file for this product. You could set TOR??? to 48 hours or enter 10 to specify that you always want to keep the last 10 TOR??? products on file.
There will probably be some interaction between the hours and count fields. I have not worked out the details at the moment. This option would be entirely optional. If nothing was specified, then the system would honor the current global purge time.
The software currently purges every file after the globally defined number of hours elapse. If you have it set to 24 hours, then a message is deleted after it has been expired for 24 hours. I have requests to add the ability to specify the purge time and/or number of messages to keep by product.
The change would work like this: You would have the option to specifing a product identifier or wildcard combination. With this product, you would specify the purge time in hours or enter the number of message you want to keep on file for this product. You could set TOR??? to 48 hours or enter 10 to specify that you always want to keep the last 10 TOR??? products on file.
There will probably be some interaction between the hours and count fields. I have not worked out the details at the moment. This option would be entirely optional. If nothing was specified, then the system would honor the current global purge time.
Subscribe to:
Posts (Atom)
times.