Communication is considered unidirectional in my view: there is a logical 'master' and a logical 'slave', or in network terminology
master = client
slave = server
The client initiates a TCP network connection to the server, and then issues Modbus requests or queries. Good reference is the
Modbus spec, which is an easy read in a couple of hours. Get the protocol and the Modbus TCP/IP documents. If you have ever used Wireshark, it might be useful to run at the same time as you are reading the document/testing the system as you can watch the protocol in action.
In your test, the client is IOScanner and the server is the simulator package. The client can read and write registers, but it controls what happens. All the server will do is execute the operation that it is instructed to do - read or write. The slave does not issue Modbus queries on this connection. It could act as a client and connect back to the PLC, but I am not sure this particular simulator has the capability. The PLC can act as both client and server, at the same time.
The ETY is a Premium module so configuration should be consistent with the screenshot posted. Since IOScanner only deals with %MW memory, or 16-bit words, you would have to manipulate any bits (%M) in code and aggregate them into words. The %M and %MW are different memory areas that you can use to store information. The Unity helpfile, in the early chapters, has a good section on describing the different memory types.
These memory areas in the PLC map directly to Modbus memory areas. The specification will detail these, but they are very simple because there are only a few of them, and they are flat. The Holding Registers area is denoted by a 40000 series address, so starting at 1,
Register 1: 40001
Register 2: 40002
....
Register n: 4nnnn
etc.
There are other memory areas, such as for bits. These would start with 0xxxxx, and 1xxxxx, and there is an input register area for 16bit words that has a 3xxxxx series address. The mapping for Premium appears to be, for what we need:
%MW0 -> 40001
%MW2 -> 40002
...
%MW10 -> 40010
....
In my example, IOScanner is setup to READ (see columns and settings in blue box from screenshot):
RD Master Object: %MW0
RD Ref Slave: 0
RD Length: 1
This means start at register 0 in the slave (Ref slave), read one register (Length), and place in %MW0. So when running, if you change the simulator register 0 - notice the change in nomenclature - sorry about that, but it's not my design - it will show up in the PLC in %MW0. If you wanted to read, say, 20 registers, change the length to 20 and the read will start at the first register in the simulator (40001) and read the next 20 registers, and store them starting at register %MW0 in the PLC, out through %MW19.
For the WRITES, it is the same concept of offset/length:
WR Master Object: %MW1
WR Ref Slave: 10
WR Length: 1
So whatever value I put in %MW1 will be written to slave register 10, which is 40011 in the simulator. In fact, in an animation table in UnityPro, I put in the value 123 into %MW1 and it shows, as it should, in this register in the simulator.
IOScanner supports function codes:
fc3: Read Holding Registers
fc16: Write Multiple Registers
fc23: Read/Write Holding Registers
So it only operates on the 4xxxx series Modbus addresses. The other memory areas are not available to you with this particular tool.
The tool will choose which function code(s) to use depending on what you enter for configuration, and what the server supports. If you only enter READ configuration, then only function code 3 will be used. If you only enter WRITE configuration, then only function code 16 will be used. If you enter both READ and WRITE configuration, then the tool will attempt to use fc23. Upon error, it will fallback to a separate WRITE with fc16, then an immediate READ with fc3.
