Topic: Weatherlink DLL under VB

[johnd]

Just curious: Has anyone here been successful in getting, for example, archive downloads to work within VB.Net programs (eg VB2010) using the WL DLL v2.42 and the Davis-supplied module that declares all the DLL functions?

I can get quite a few of the general and real-time functions to work so I know that the VB environment I'm using is generally OK, but as soon as I try to call one of the download methods (eg DownloadData_V(timestamp) ) there's an 'Unable to find entry point' error pointing at the DLL. I'm starting to wonder if the v2.42 doesn't have a complete implementation of all the methods accessible from VB. But maybe there's some other explanation - could well be my code but I can't spot the problem!

Edit: Hmm, it's not all download functions - GetMemoryArchiveRecordCount_V() seems to work fine! So why doesn't the one I actually want to use for a block archive download work???

Further Edit: OK, got it working (at least on a first test)! There's an error in the Davis declarations module.

Apologies for the superfluous post, but I guess I'd better leave it as is.

[ntrimble]

Hi there, I am having the same issue.  Could you tell me what the error was in the declarations module.  I'm not seeing it.

Edit:  I think I figured it out.  Changing the DateTimeStamp members from long's to Integer did the trick.  I figured that out by looking at the header file for the dll...

[iisfaq]

Hi there, I am having the same issue.  Could you tell me what the error was in the declarations module.  I'm not seeing it.

Edit:  I think I figured it out.  Changing the DateTimeStamp members from long's to Integer did the trick.  I figured that out by looking at the header file for the dll...

Do you find that everytime you get it to read from the dll that you incure a quite high CPU spike?

Chris

[johnd]

Edit:  I think I figured it out.  Changing the DateTimeStamp members from long's to Integer did the trick...

Yes, that was the issue I picked up. I think who ever wrote the declarations module was remembering an old VB version when Longs were 4-byte integers etc (was that changed after VB2002/3 or maybe it dates back to VB6 or before - can't remember now?). There may of course be similar instances of using the wrong integer type in other variables/structures in the module but I haven't picked up on anything else as yet.

[iisfaq]

Yes, that was the issue I picked up.

I did not like it so I ended up writing my own code to read from the serial port - runs in < 0.2% cpu

Chris

[johnd]

... so I ended up writing my own code to read from the serial port...

Yeah, that's obviously an option. But using the DLL does save quite a lot of coding work if you need to use more than one or two logger calls. I think the DLL itself is pretty robust, the error that we're talking about here is just in the VB declarations module, which is obviously provided as a jump-start for VB users to access the DLL and not checked nor documented with the same care as the main DLL

And are you sure that the CPU spike you saw was not just the .Net environment starting up?

[iisfaq]

And are you sure that the CPU spike you saw was not just the .Net environment starting up?

Nope everytime I make a call to update the data it spiked - maybe not large - 5% or so but far too high for me.

Chris

[jruys]

I have all of the DLL calls wrapped in c#.  I believe I have tested all of the functions and they do work.  There is an oddity in the download data that I never get the last archive record when doing a download.  This may be a function of going through Virtual VP though.  I have not tried it going strait to the console.  If anyone is interested I could post the wrapper.

[johnd]

I have all of the DLL calls wrapped in c#.  I believe I have tested all of the functions and they do work.

I would have expected them too - the actual DLL itself does seem fairly robust. It's just the VB wrapper that Davis themselves provide that I was referring to here as having incorrect integer types.

Do you think you've got all the weatherDataID values worked out for the GetCurrentDataByID_V and string calls? That would be an interesting table to see or at least a little tutorial on how the ID values are constructed. I did start to look at those but ran out of time for now on that project.

There is an oddity in the download data that I never get the last archive record when doing a download.

That's interesting too. I'm wondering if there's a similar problem when downloading archive data from a web station - I seem often to be missing a final record that I think ought to be there, but I've always put it down to clocks not being properly synchronised or a DST issue though without ever having made time as yet to check it out rigorously.

[jruys]

If anyone wants, you can download my C# project for wrapping the Vantage Pro DLL here:

http://www.ruysfamily.com/weatherdownloads/VantageProCSDll.zip

Do you think you've got all the weatherDataID values worked out for the GetCurrentDataByID_V and string calls?

Yes, there is a class called WeatherIDs in the project references above that works out the IDs for GetCurrentDataByID_V.

[sunghui]

can you share this dll for me to use on an educational purpose !

http://astro.km.edu.tw/

[jruys]

can you share this dll for me to use on an educational purpose !

By all means use it for whatever you want.  I just kind of did it for the fun of it and to see if I could do it.  Have fun!

[pfletch101]

I know this is an old thread, but it is one that I suspect anyone looking to use VB.NET to interact with and/or get data via Weatherlink will look at. I am in the process of integrating the data from a Pro 2 Plus into a fairly comprehensive domestic energy monitoring system written in VB.NET. When I started working with the Vantage DLL files, I realized that the attempt that Davis had made to produce a VB.NET interface was seriously flawed - it appeared that the person who had produced it did not understand a lot of the more complex aspects of getting VB.NET programs to talk to 'foreign' DLLs, and had done little or no testing. In addition to the incorrect integer types in many of the Structures (referred to in the earlier part of the thread), there is a naming conflict with the VB.NET DateTime type which was introduced for VS 2008 or 2010, and some major errors and omissions in the handling of strings and arrays in many of the larger and more important structures (some of which had been inappropriately renamed as Classes).
My version of the VantageProDll.vb file is zipped and attached. It can be used instead of the original file if you are writing for the Weatherlink in VB.NET and should work much better. 

Additional note - I have updated the attached file one more time (4/23/2014 22:45 CDT) to correct a couple of incorrect DLL Function calls in the original.

[pfletch101]

Once again, I know that this is an old thread, but I also know that people are reading it occasionally. I have updated my version of the Vantage Pro DLL header file to work with Visual Studio 2013 and above without causing its Code Analyzer to emit (literally) hundreds of warnings. This is not just a plugin replacement for the old version, since the fix required that all the DLL calls be enclosed in a Class - see the comments at the beginning of the new version of the file for more information. The new version of the file is zipped and attached.