There are a few different options for this, which one is best for you depends on a few things!
[B]The officially recommended way… [/B]
(and most likely the answer you’d get if you asked support @ opto22.com) is to use the [B]Scratch Pad [/B]area of the memory map. This method is described in Chapter 10 of form 1700, the PAC Control Users Guide. Essentially you write data from controller A into it’s scratch pad, which could then be read by controller B. This method is very fast, especially if you’re needing to share hundreds of values at a time. It’s tried and true and lots of people use that method.
But since you asked here on the OptoForums, where we just LOVE to ponder and share all sorts of alternative and creative ways of doing things…
[B]Weather in Particular[/B]
You’re talking about Weather, so I’m guessing that speed isn’t a particular concern – maybe you want to check it every hour or so – and you might be just reading a few values? Yes?
BTW, since you mention a weather station, we actually have one of those on the roof here at Opto 22 headquarters and beam the data to a wunderground.com for all the world to see (it’s station ID is [U][B]KCATEMEC23[/B][/U]). I’ve included some examples here in the forums to scrape web pages like that from a PAC. But I’m guessing that’s not what you want to do exactly…
[B]Speaking of clouds…[/B]
I’m actually beaming a handful of data from a PAC-R controller at my house up to another website called dweet.io which is easy to “scrape” (read/parse – and some other PACs around here are doing that). You can see [U][B]that JSON data from my house here[/B][/U] if you’re interested.
[B]What I’d recommend in this case…[/B]
I’m guessing you DON’T want to have to rely on Internet access (or someone else’s website) for this application, and you might like one little command to just go grab a float variable from yonder controller. If that’s the case, I have just the subroutine for you! Not sure what subs are about? Check out [U][B]this 101 Post[/B][/U] on the topic.
The subroutine I have in mind is one called [B]FetchFloat[/B] which you can get at [U][B]this peer-to-peer post[/B][/U].
Essentially you’ll just add the command/sub into your strategy (double-click on “Subroutines Included,” click Add to browse to the file called [I]FetchFloat.isb[/I]).
Then you can include this Subroutine command in your strategy like a regular command. In this example, the IP address of my “yonder controller” is that first parameter passed, 22001 is the usual port used for accessing the “control engine,” the third parameter is a string that’s the name of the tag on yonder controller.
In this case, I used [B]fTempAtOtherController[/B] for the variable that will be filled in if all goes well.
The OptoScript might look something like this:
FetchFloat( "10.192.57.38" , 22001, "fCurrentTempDegreesF", fTempAtOtherController, nFFError);
If all does NOT go well, I’ll get a non-zero value back for my Return Error, here I used [B]nFFError[/B]. For example, I’ll get a -50 if this controller can’t connect to that controller at 10.192.57.38. If I can connect, but there’s no tag on that controller called [B]fCurrentTempDegreesF[/B], I’ll get a different (negative) number.
Of course, you could also have controllers connected to a database using OptoDataLink, if you already had a database in the mix, and share values that way.
I know there are other people sharing data other ways, especially if you have unique network topologies… I hope you’ll share!