malcolm58,
You only have to make a NetEdit peer-to-peer configuration if the H0-ECOM100 is going to be the master. If the H0-ECOM100 is merely to be the Modbus TCP slave (and therefore never initiate communications), then no NetEdit peer-to-peer configuration is necessary.
Here's the way it works if ECOM100 is master.
Normally, using ECWX/ECRX, there is only a place to put "Slave ID". This is a number that can only be 0-255. Yet this is the only way that the DL PLC instruction has for addressing his communication partner. In other words, there is no place to put a TCP address. As you can see, it is impossible to refer to an IP Address with only 0-255 numbers available. This is why, in the ECOM100, you have make a peer-to-peer configuration. The configuration is so that when you do an ECWX/ECRX using a particular Slave ID (e.g. 4), then this number 4 can be mapped to a real IP Address. The 4 has no other meaning. In other words, the 4 doesn't go out on the network. It is merely a means for the ECWX/ECRX instruction to be able to address an entry in the peer-to-peer table and therefore a real IP Address of a slave. The slave could be another ECOM100, or a 3rd-party device.
Thus, when an ECWX/ECRX instruction executes naming, e.g. 4, as the Slave ID, then the ECOM100 hears the request, looks to see if he has an entry for 4 in his peer-to-peer table, and if he does, then he forms the packet into a Modbus TCP telegram using the IP Address named for the #4 entry in his configuration. What leaves the ECOM100 going out on the wire is merely a Modbus TCP telegram with that IP Address (the Slave ID is no longer needed and is not present in that telegram; i.e. it means nothing anymore).
If there were no peer-to-peer configuration in the ECOM100 at all, then when the ECWX/ECRX tried to use Slave ID 4, the ECOM100 would notice there is no entry in his peer-to-peer table for a #4, and therefore would realize that he needs to find out exactly who 4 is. Normal ECOM100 behavior for this would be to send out a broadcast telegram (that only other ECOM100s understand) onto the network querying for any ECOM100 on the network with a Module ID of 4. In this case, if there is another ECOM100 on the network that has his Module ID = 4 (i.e. either by his dipswitch setting, or software setting via NetEdit), then he will recognize the query broadcast, and answer back, "I'm #4". In this response will be that slave ECOM100's IP Address, and MAC Address. Now the master ECOM100 "knows" who 4 is. Knowing this, he can now talk directly to that device using his IP and MAC Addresses. In other words, the Slave ID of the ECWX/ECRX instruction, in this case, points directly to a Module ID of another ECOM100 on the network and has therefore has meaning on the network. But you can't use this method to talk to 3rd-party devices... only ECOM100s.
As far as an example goes, in your DirectSOFT5\Projects\Examples folder, there is a project called ECOM100_ECRX_ECWX_Help_Example. This isn't specific for Modbus TCP, but that doesn't matter. The only difference would be that for the Modbus TCP to work you would only have to have a peer-to-peer configuration corresponding to the Slave ID you use as I described above.
The document I named above also tells you how to address a particular Modbus Register you want to read/write from/to (e.g. an ECWX to V0 would cause the ECOM100 to send out an FC16 to Modbus Holding Register 1 [or 40001, depending on how you are used to referring to Modbus Addresses]).
Does this help?
I hope I haven't further muddied the waters!
Topic: Modbus TCP (Read 24315 times)