Topic: SetUnits_V Now GetUnits_V In Latest DLL Version

[andrewjwhall]

Hi to the Forum!

Please have a look at this post from a while back to get the history of the reason for this new post!

http://www.wxforum.net/index.php?topic=4074.0#lastPost

I have just downloaded from Davis the latest DLL Version Tool kit as I have updated the frameware on my VP2 to the latest 1.90.

This has created a new problem for me with my little .exe file that I created with help from the forum with regards to the prevision old post.

Now my .exe file works with cmd line on windows xp/vista. For the returned values to be in metric I added the following in a C++ file:

WeatherUnits Units;
            Units.TempUnit = CELSIUS;
            Units.BaromUnit = HECTO_PASCAL;
            Units.RainUnit = MM;
            Units.WindUnit = KPH;
            Units.elevUnit = METERS;

 WeatherUnits SetUnits_V(WeatherUnits Units);
           
            if (SetUnits_V(&Units)==0) {
               // Success
            }

This has worked fine and still does with the new DLL with one exception that when the .exe runs for the first time the read out on the VP2 console gets changed from Metric to Imperial!

How can I change the above so it still does the same without messing with the console?

Here is the quote from the Davis Tech file re SetUnits_V and GetUnits_V:


short void GetUnits_V( WeatherUnits *units)
Description
Fills the structure WeatherUnits with the units currently being used in the Dll.  For DLL

version 2.42 and later, this value is actually obtained from the console firmware settings.
All weather data will be read and reported by the DLL in these units.
The default DLL units are:
Temperature FAHRENHEIT
Barometer INCHES
Rain  INCHES
Wind MPH
Elevation FEET

short int SetUnits_V( WeatherUnits *units)
Description
The Dll sets the units used to read and report weather data to the values specified in the

WeatherUnits structure.  For DLL version 2.42 and later, this actually set the console firmware settings.
 
Parameters
units -  WeatherUnits structure to set the weather units.
Return Values
0 if successful
-1 if invalid data


I would be most grateful too anyone who could help me solve this problem as I have now run

out of ideas and need someone with a bit more knowledge than myself!!

Most Kindest Regards,

Andrew Hall.

Leipzig, Germany.

[wuhu_software]

Can you please clarify what you mean when you say "When it runs for the first time"? Subsequent executions of the program do not result in this problem? I have not yet seen that problem but I have seen a perhaps related issue caused by the functionality of SetUnits_V() in the new DLL. Davis did make a radical change there that does affect all weather applications that use the new DLL. This is especially true if you are using multiple weather applications using VPLive.

Originally, the SetUnits_V() affected only data returning from the DLL. Now when you call SetUnits_V() this does indeed change the console's non-volatile memory and the console display is affected. In addition when SetUnits_V() is called, even if your units match the console units, the precision of variables that you may of customized on the console are "reset" to the defaults which would require that the user go back to the console and change the precision again manually. While I have not scanned the DLL extensively, I did not find a method to set the precision of the console display using the DLL, this seems to be only available at the console, at least on the Vue.

I am not sure why Davis made this fairly radical change. It seems that this decision was made with no consideration of the existing legacy weather applications already deployed. Personally I find it a bit offensive to change the legacy API but that is life, you cannot control what these companies do. In my personal opinion, they should have created a new API called SetConsoleUnits_V() or something to that effect and they should have left the legacy API SetUnits() alone. I cannot think of any justification for what they have done. Again, such as life.

The only way I have found to work around this problem is to never called SetUnits_V() since the end user will not have their console affected. You could work around this from a software perspective by forcing the user to specify the units in advance, then the console would be forced to match those settings. This however is not an ideal method because now all weather applications that you use would need to have this feature. Even if you did implement this in all weather programs, and they all used the same units, when you call this function, it resets any customizations to precision that you have made at the console. So there is no clean work around to continuing to use SetUnits_V().

There is however a work around to SetUnits_V() but that will require a bit of work on your part. What you need to do is to never use SetUnits_V() to change the units and instead use GetUnits_V() to read the console settings, then make use of the data regardless of the end user console settings.

What this requires then is for your application to call GetUnits_V() to determine the units that are currently in use by the console. You must retain these settings for later use. After you read the data from the console, you then need to translate the data from the console configured units to the units that you want to use. So basically, you need to do what SetUnits_V() was doing for you automatically. While this is a bit of work, and it will take some time to translate from any unit to any unit, it is not an impossible task.

Unless Davis sees the error in their ways, and retracts this modification to their API, all weather applications must make this change if they want to play nicely with other weather applications and they do not want to reset the customizations that the user has made at the console.

While I have not heard of anyone really complaining about the above, this certainly does seem to be the situation as I see it.

[andrewjwhall]

Hi wuhu_software,

To answer your question I use sleep.exe to run the .exe every 5 minutes and on first start up the read out changes on the console from Metric to Imperial! After the first time there are no further changes, however I then use WeatherLink to reset the readout only for my .exe to change it to Imperial again when it next runs.

My knowledge of C++ is very very basic and I fear I my be at a lost with out someone of high knowledge rewriting my code, which I am am a bit upset about!

Here is my code which just runs in the cmd window:

#include "VantagePro.h"
#include "WeatherDataID-DLL.h"
#include <iostream>
#include <iomanip>
#include <sstream>
#include <fstream>
using namespace std;
       


int main(int argc, char *argv[])
{
                   
            WeatherUnits Units;
            Units.TempUnit = CELSIUS;
            Units.BaromUnit = HECTO_PASCAL;
            Units.RainUnit = MM;
            Units.WindUnit = KPH;
            Units.elevUnit = METERS;
           
                       
           
            short int comPort = 4;

            int baudrate = 19200;
           
                       
            CloseCommPort_V();
           
            OpenCommPort_V(comPort, baudrate);
           
            SetVantageTimeoutVal_V(TO_STANDARD);
           
            InitStation_V();
           
            WeatherUnits SetUnits_V(WeatherUnits Units);
           
            if (SetUnits_V(&Units)==0) {
               // Success
            }

           
            LoadCurrentVantageData_V();
           
                                   
            cout << fixed;
            cout << setprecision(1) << GetOutsideTemp_V() << "\tTemperature (C)" << endl;
            cout << setprecision(1) << GetBarometer_V() << "\tBarometer (hPa)" << endl;
            cout << setprecision(1) << GetWindSpeed_V() << "\tWind Speed (km/h)" << endl;
            cout << setprecision(0) << GetWindDir_V() << "\tWind Direction (degrees)" << endl;
            cout << setprecision(1) << GetDewPt_V() << "\tDew Point (C)" << endl;
            cout << setprecision(0) << GetOutsideHumidity_V() << "\tHumidity (%)" << endl;
           
           
                             
            stringstream cmd;
            cmd << "c:\\rrdtool\\rrdtool update vp_temperature.rrd N:" << GetOutsideTemp_V() << endl;
            system(cmd.str().c_str());
           
            stringstream cmd2;
            cmd2 << "c:\\rrdtool\\rrdtool update vp_barometer.rrd N:" << GetBarometer_V() << endl;
            system(cmd2.str().c_str());
           
            stringstream cmd3;
            cmd3 << "c:\\rrdtool\\rrdtool update vp_wind.rrd N:" << GetWindSpeed_V() << endl;
            system(cmd3.str().c_str());
           
            stringstream cmd4;
            cmd4 << "c:\\rrdtool\\rrdtool update vp_wind_dir.rrd N:" << GetWindDir_V() << endl;
            system(cmd4.str().c_str());
           
            stringstream cmd5;
            cmd5 << "c:\\rrdtool\\rrdtool update vp_dew_point.rrd N:" << GetDewPt_V() << endl;
            system(cmd5.str().c_str());
           
            stringstream cmd6;
            cmd6 << "c:\\rrdtool\\rrdtool update vp_humidity.rrd N:" << GetOutsideHumidity_V() << endl;
            system(cmd6.str().c_str());
               
           
           
            CloseCommPort_V();
           
            system("pause");
                       
            return 0;
                       
           
}


The returned values are entered into a Round Robin Database where I call the graphs to be made when I need them. I think I may have bitten more off than I can chew as the file I use is very simple but it does do the job for me! Unless someone is willing to help with the code I guess I will have to revert back to an earlier DLL version. Like you said, that's life!

Most Kindest Regards,
Andrew Hall.

[wuhu_software]

Andrew,

I do not believe that the line:

WeatherUnits SetUnits_V(WeatherUnits Units);

In your code is needed or wanted.

Try removing it.

[andrewjwhall]

Hi wuhu!

I removed the line with the same effect happening! I then also removed the follow line:

if (SetUnits_V(&Units)==0) {
      // Success
}

This resulted in the returned data in Imperial and no change to the console.

Why can't Davis do a DLL with Metric as default so you can chose between DLL's for your default settings? Most likely a silly question to ask for a hundred reasons no doubt!

Most Kindest Regards,
Andrew.

[wuhu_software]

Try adding the lines in bold:

See if the SetUnits_V() is succeeding or failing after you make these changes.

...

InitStation_V();

GetAndSetRainCollectorModelOnStation_V();


if (SetUnits_V(&Units)==0) {
      // Success
      cout << "Units set succesfully." << endl;
}
else
    cout << "Units set failed." << endl;

[andrewjwhall]

Hi wuhu!

I put in the code and it came back "Units set successfully". The returned data was in Metric but the console was changed to Imperial again!

Most Kindest Regards,
Andrew.

PS Will check back tomorrow if you have any further ideas! I am most gratefully for your help on this matter!

[wuhu_software]

The console changed to Imperial units after the program exited or when you ran Weatherlink again?

[andrewjwhall]

Hi wuhu,

The console changed to Imperial straight after my .exe was run for the first time but I changed the console back to Metric using WeatherLink.

Regards,
Andrew.

[wuhu_software]

That is very odd.

To rule out the simple possibilities, you are not using VPLive are you? If so, do not use it during testing until you figure out what is going on.

In your link, are you linking with the 2.4.0.3 version of the lib versus the older versions (2.4.0.2 or less)? You must be sure that you are using the up to date version of both, when linking and also when executing.

When you execute this program you want to make sure that the VantagePro.dll is located in the same directory as the executable otherwise Windows may be running an older version of the DLL that might exist elsewhere on the HD (like in C:\Windows\System\) or folders included in the Path.

If you are sure that you are using the latest lib and DLL, it would be interesting to run your program in the debugger to see at which point the console reverts to Imperial units. I would suspect that this would happen at the CloseCommPort_V() call.

[andrewjwhall]

Okay!

I am not running VPLive.

I have the latest DLL etc. I double checked but this was download from the davis website 2 days ago.

DLL etc are all in the same folder as my .exe file.

With regard to debugging I don't know how to use it really which is why i keep things simple for myself.

Regards,

Andrew.

[wuhu_software]

Andrew,

Which version of the MS Visual Studio are you using?

[andrewjwhall]

I'm not!

I am using DEV-C++ version 4.9.9.2 from bloodshed.net.  Has been a lovely little program and I have all extras installed for linking etc.

[wuhu_software]

I just noticed something in your program that I had not see.

Delete the bold line. Attempting to close the port that is not opened yet may have some ill effect:

            short int comPort = 4;

            int baudrate = 19200;
           
                       
            CloseCommPort_V();
           
            OpenCommPort_V(comPort, baudrate);
           

[andrewjwhall]

No joy!

The same still happens!

Regards,

Andrew

[wuhu_software]

Andrew,

Write an email to wuhu_software at yahoo.com. We can take this off the forum and try to solve it.

[andrewjwhall]

Hi wuhu,

I have sent and email as requested.

Regards,

Andrew.