Hello all,
I am trying to “share” values between controllers. Is there a way to retrieve a variable value from another controller via PAC Control? If so, could someone point me in the right direction? The scenario is that I have a weather station wired into one controller and I would like to share those values with another controller (to avoid installing a second weather station). Thanks in advance 
There are a few different options for this, which one is best for you depends on a few things!
The officially recommended way…
(and most likely the answer you’d get if you asked support @ opto22.com) is to use the Scratch Pad 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…
Weather in Particular
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 KCATEMEC23). 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…
Speaking of clouds…
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.
What I’d recommend in this case…
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 FetchFloat which you can get at this peer-to-peer post.
Essentially you’ll just add the command/sub into your strategy (double-click on “Subroutines Included,” click Add to browse to the file called FetchFloat.isb).
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 fTempAtOtherController 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);
Action block:
If all does NOT go well, I’ll get a non-zero value back for my Return Error, here I used nFFError. 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 fCurrentTempDegreesF, I’ll get a different (negative) number.
ODL?
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.
Others?
I know there are other people sharing data other ways, especially if you have unique network topologies… I hope you’ll share!
-OptoMary
Excellent response, Mary! The FetchFloat is [B]exactly [/B]what I was hoping to find. Time to start writing subs . Thank you…
Yay! I’m glad that helped! Just to be clear – YOU don’t have to write any subs if you don’t want to. But the lovely thing about them is you can use one someone else wrote without even knowing how the sausage (or catchup?) is made.
I hope that set of subs on [U][B]this post I mentioned above[/B][/U] can work as something like a “library” of additional commands that will expand our built-in set of commands. (My ulterior motive: hoping if enough folks like my additions I can convince our Engineering Team to build them in officially.)