I have a Strategy that runs on a PAC R controller. I’m writing a simulator that will talk to this strategy while the strategy is running in SoftPAC via Winsock. I read in document #1465 that OptoMMP allows you to write directly to the controller’s Memory Map via the MMP protocol. If I run my Strategy on SoftPAC, can I use OptoMMP to write directly to I/O points?
Mark.
Hi Mark,
You certainly could, but I’m not sure why you’d want to do that. Why not configure an I/O unit in your SoftPAC Strategy for that PAC R? Then you could just use the regular Analog or Digital commands to read/write to those I/O Points by name (and let your PAC calculate mem map addresses for you) rather than doing all those mem map calculations yourself. Perhaps I’m missing something here?
Thanks,
Mary
Actually there are I/O units defined in the strategy, and they are all set up with “names” for the individual I/O points. They’re there to represent the I/O for the “real” system (i.e. when I run this strategy on the actual PAC R and have all the hardware hooked up). So when I run the Strategy on the SoftPAC and debug it with PAC Control Professional I see the “I/O Units” tree and all the points and racks and such (just like on the real thing). (see picture). Are you saying there’s a way to talk via Winsock directly to these points? Like read/write these I/O points from my stand alone Windows program? Or are there MMP commands to do this directly?
Mark.
Let me take a step back here and clarify a few terms here to make sure we’re on the same page.
Both SoftPAC and PAC-R or –S controllers (even EBs) have a variety of mem map address. In an –R or –EB, some of those addresses will correspond to actual I/O. You can think of this memory map as the glue between the Control Strategy and the I/O.
For example, in your strategy here, you have a digital input called RF_FPOWER on a rack called Rack1. That digital input has an IVAL and an XVAL associated with it (where the I stands for “internal” and the X stands for “external”). If you refer to this RF_FPOWER input somewhere in your strategy, the controller will actually attempt to send a (mem map read) command to the IP address of that Rack1 I/O Unit – ASSUMING both the I/O Unit and the Point are enabled. If all that’s true and there was no problem going over the wire (via a UDP packet in this case), then the XVAL will get updated with whatever came back from the I/O Unit, and the IVAL will get updated with that XVAL, and your command will get that same value to use how it wants.
If that I/O Unit does NOT actually exist, or if it’s disabled, or if the RF_FPOWER point itself is disabled, then your command will get whatever is currently in the IVAL. This value could be adjusted using the PAC Control debugger or programmatically using the “Simulation” Commands.
Having this extra IVAL layer makes it fun & easy to test your logic even if you have no real hardware.
Perhaps you could clarify what your “stand alone Windows program” is for? (You don’t mean the SoftPAC Strategy?) Or why, since you have SoftPAC to do it for you – including calculate mem map address and build the appropriate UDP packets – you’d need to write anything else?
That makes sense – Thanks, I now understand the IVal and XVal concept, and now understand when each is used.
What I am trying to do is a bit complicated to explain, and may be confusing but it is a geniunely necessary configuration. (so as Yoda said to Luke “…there is no “why”…”).
There are two modes in which I need to use the same strategy, one in which it’s running on a real PAC Controller with its respective I/O units connected to a real device our company sells and receiving real Digital and Analog input; One where it’s running on SoftPAC with all the I/O disabled such that the IVAL’s are all that’s being used and the hardware is replaced by a very complex graphical simulator program that “looks” and “acts” just like the real device we sell (i.e. this sim needs to SET these same Digital and Analog I/O points as though they were really hooked up). In this case I need the graphical simulator to write into the IVAL’s of I/O points, etc., so that when I tell the Strategy “Do this silly and complicated series of actions” the I/O values that the real device would normally have caused to happen in the Strategy will be forced to their associated values by my simulator program and the Strategy will think “huh…the device just did this silly and complicated series of actions…I’m happy”. Here’s a picture of what I’m trying to describe:
Mark.
I guess all that being said…if there’s some simple command I can use in my Windows program that via TCP/IP Sockets or OptoMMP Toolkit like:
“SetDigialNamedObjectValue( “RF_FPOWER”, 1.8 );”
I’d be happy as a clam, but I don’t see anything like that so I thought maybe the only way to do this is write the value “1.8” (formatted in whatever format necessary) into the actual memory location that RF_FPOWER lives at using OptoMMP.
Let me know if that makes it clearer.
Thanks 
Mark.
Ah. Okay. Well, the short answer is NO, not yet. RF_FPOWER does not have an OptoMMP address. Sorry. The only I/O OptoMMP addresses are those on the real I/O Units accessed indirectly via that XVAL read I mentioned earlier. Strategy tag values don’t have OptoMMP addresses. The YET is about that simple command you mention. There is an SDK in the works which will include commands like that. Not sure how soon it will be available.
However, (you knew there’d be a however, right?), there are a couple of options. If I recall correctly, you were experimenting w/running more than one copy of SoftPAC via a VM? How did that work out? Because I can tell you have to get one PAC to read/write to a tag on another PAC. Sounds like, though, you need this tag manipulation to happen via a Windows program. Is it just a handful of tags you want to manipulate (I hope)?
It’s actually quite a lot of data that I need to manipulate. I was originally thinking maybe I could just read/write entire blocks of memory from Windows to the Strategy running on SoftPAC. The idea being when the user manipulates the “virtual hardware”, all the I/O that would normally happen on the real I/O modules, would be set/read by this Windows program. To be honest, I don’t know how much information that is, or how fast.
If I think in terms of the current strategy, there are 2 racks of I/O modules. For example, one rack has:
(2 ea) SNAP-IAC-16: 13 digital inputs configured on one, 10 digital inputs on the other
(9 ea) SNAP-ODC5: 6 are totally populated, so 6x4=24 digital outputs + 4 others totaling: 28 digital outputs
The other rack has:
(10 ea) SNAP-AVI: 20 analog inputs there
(5 ea) SNAP-A0V-25: 9 total analog outputs
That’s kind of a lot… but perhaps these would be polled every 500 ms or so.
I currently have a solution which is to use legacy communications that were built into our strategies from the LCM4 controller. Namely, the previous developers implemented HostWords communication, so on my Windows program now I have written an interface that allows you to specify a point’s name “RF_FPOWER” and assign a value to it. Basically it writes a HostWords command over Winsock. This works…it’s just that I’d be bombarding the socket and the chart that’s processing it. Still, it seems that is my only solution - correct?
Mark.
By “HostWords” do you mean commands that look like this: “1.8 ~RF_FPOWER @!” (and similar other ones, like those documented in page 226 for form 1700, the PAC Control Users Guide, in the section on “Setting Initial Values in Variables…”)?
Actually, I was wondering about that chart you have pictured above, could you tell me what you mean by “the chart that’s processing it”? (Aren’t you just sending those commands, with a CR at the end, to your host port, 22001?)
How about having a chart run on the controller that moves values from pre-assigned Scratchpad values to I/O points IVALs? We do almost exactly the same thing, and that works for us…
MMP protocol talks to Scratchpad really well.
Yes, that’s what I mean by hostwords. We have to talk to a legacy piece of software which communicates via hostwords packets, so there is a chart that has a communication handle at a specific port. It receives data from the legacy program and treats it like a hostwords packet. Unpacks it and in the example you mentioned above, sends sets RF_POWER to 1.8.
So are you able to write to the Scratchpad in SoftPAC via MMP?
I’m considering doing this, or simply writing a block of data (like a struct) via sockets to a “receiving” chart running in SoftPAC. The chart would take the data in the structure it received and write values to appropriate I/O IVAL’s. I guess that’s the same sort of thing in a way.
Many of those “legacy” commands work the same on a PAC. You might be able to skip that whole comm handle part. Just point your legacy software to port 22001 instead of the (old) 2001. Or, if you can’t change that legacy software, use the command “Start Alt host port” and set a “new” (old) port to “tcp:2001”. Do you see what I’m saying here? Do you know the complete set of commands that the legacy software sends?
The legacy software actually uses Mistic. It was written to talk to an LCM4 using HostWords over Mistic protocol. So for the PAC controllers now, a chart was written which uses a communication handle set to “tcp:2002” (or whatever). The chart receives strings from this comm handle (via sockets). What it receives is the HostWord packet. It parses it, grabs the named object name, type of data, specific HostWord command, etc, and manually reads or writes to that named object location. If data is requested, it creates a similar (correctly formatted) Mistic packet string and sends it back over the socket to our old Unix GUI software.
