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?