So my question is, what is the best recommended practice here? Are unique module IDs still needed in this case for the masters, even though I'm running Modbus for the RX//WX comms? Or is there a configuration option that I missed? Thanks
First, I'm not sure why you switched to using Modbus TCP. You could still, for example, use just peer-to-peer comms between the ECOM100s. That would use UDP instead of TCP, which is, generally speaking, faster, since it doesn't have to maintain a TCP connection.
Previously, when your slaves utilized Module IDs, the master ECOM100 would use Ethernet II broadcast with embedded HAP (Host Application Protocol) to ask who has a particular Module ID. The ECOM100 slave that had that Module ID would respond and in that response would be its MAC address. The master ECOM100 would utilize that slave's MAC address and use a regular Ethernet II telegram with embedded HAP to communicate. The limitation here is most network administrators didn't appreciate the broadcast telegrams on the local network. Also, the ECOM100s couldn't communicate across bridges, routers, and some managed switches because the broadcast is blocked by default.
To get rid of broadcasting requires that the Module ID parameter (contained in the 1st LD instruction of the LD, LD, LDA, RX/WX ladder logic) which can only be a number from 0-90, be converted to an IP address. So, the first thing you must make sure of is that all your ECOM100s now have unique IP addresses and that they are on the same subnet, or if not, they all have access to a Gateway on the network. Secondly, you have to configure a peer-to-peer table in the master ECOM100s to convert the Module ID parameter in the LD instruction to an IP address. This peer-to-peer table can utilize UDP or Modbus TCP; your choice. Using UDP makes it easy because then there is no crazy Modbus Function Code and address mapping conversion needed.
Thus, when the LD, LD, LDA, RX/WX is executed in ladder logic to the proper slot number where the ECOM100 master resides, the ECOM100 receives this Module ID and checks to see if it has a peer-to-peer table entry for that Module ID. If it does, then it simply creates either a UDP telegram (with embedded HAP), or a Modbus TCP telegram. There is no need for a broadcast to discover the slave's Module ID. In this way, the slave's Module ID doesn't come into play at all. So it is OK for them all to be zero. Also, the Module ID of the master doesn't come into play at all either, because the response coming back from the slave is either going to be a UDP acknowledge telegram, or a Modbus TCP acknowledge telegram. The Module ID is not used.
I said all that to say this: It makes no sense that giving the master ECOM100s non-zero Module IDs should matter unless there is something else going on on the network that would use these Module IDs (HMIs? DirectSOFT links?).