Deryck,
We spoke last Friday about a customer having an issue talking to between two PLC’s on the WAN side.
I received a little more detail in the attached emails. They are still not able to communicate, any additional ideas ?
Rich
SL1035Support.tar (11.5 KB)
SL1035.tar (11.5 KB)
SL1035Support.tar (11.5 KB)
SL1035.tar (11.5 KB)
Hi Rich,
Looking at the backups the nat 1:1 looks to be configured correctly. To get a better understanding and identify the root issue we need to find out where the communication is being lost.
From a pc on the WAN, can you ping the WAN mapped ip addresses?
From a pc on the each LAN can you ping the LAN IP on that network?
Can you ping the remote WAN IP address from the LAN side?
Deryck
Hi Deryck,
Sorry I missed your email. Somehow you were filtered in my outlook.
I have reached out to the end user to try to get some answers.
I appreciate the follow up.
Rich
Hi Rich!
Good news! We are communicating. Several dumb things I did / didn’t do:
· I didn’t need to have the extra line to assign the WAN side PLC (192.168.1.90 – 10.10.4.1). The eWON already had that line covered, and the settings allowed the LAN PLC to talk to the WAN PLC. Once this line was removed, their RSLinx was able to see my PLC. I never did see their PLC on my RSLinx, but that didn’t matter
· On the configurations inside my (AB) PLCs (both LAN and WAN), I needed to remove the default Rack Optimization for the Ethernet Card set up. I almost always forget that, since I don’t have to do this too often. The IP address for the WAN PLC is its true 10.10.4.1. The IP in the address for the LAN PLC is also its WAN IP 10.10.4.30 (or 31, depending on the unit). 
See above for the remote PLC Ethernet card configuration in the LAN PLC.
We did have some issues with the produce / consume tags that we were trying to use. The live status indication on either PLC for the remote Ethernet card kept cycling through “Connecting…” and “Timeout…” (or something like that). We ended up using messaging, with each PLC reading the others source file (produced tags – but we changed the tags to base instead of produce type). We even had to pulse the message statements on short timers to allow the devices in the NAT to keep up with each other.
The end result, although I would have loved to keep the produce / consume function (AB website states that it should work, but I had to get in a taxi to start heading home) is that we are now communicating, and I am writing up this experience so that our office won’t have to bother you with THIS problem again, although I will probably be in touch before you want me to be. I am also sharing this with you in hopes that it will help you guy, the guy in eWON who was helping, and maybe someone else will share how to get that darn produce / consume working in this format.
Thanks to you and Deryck for helping as much as you did. Your information and questions helped guide us and move forward in our trouble shooting (we sat in a hole without email / Internet support while we worked this crud out). I look forward to an easier time, next time. If there are any manuals to help us work out the settings for the advanced eWON settings, please feel free to forward it (them – or their links).
Our next project should be right around the corner…
Best regards.
**Glen
Hi Glen,
I would recommend the Reference Guide for the best overview of the configuration. You can find that and several other docs on the support page. https://websupport.ewon.biz/support/docs/cosy-131#5
Regards,
Deryck
