From my customer:
I am using a Mitsubishi FX3U processor with an Ethernet adapter card. I’m getting communication errors when trying to read tags. In the EWON I am using the MELSEC I/O server and getting communication errors.
Backups moved to staff note
His IO Server config looks to be the same as the last reply in this thread: Mitsubishi FX3 to eWon flexy
But I don’t have a Mitsubishi PLC to test with unfortunately.
Any ideas?
Edit: He’s going through an N-Tron switch from Flexy to PLC
Update: I asked the customer what the specific error was on his tag and he said “It just says no communication”
That topic is definitely a great source of information for the FX3.
–
Is your customer able to ping the PLC when connected to the eWON or a switch connected to the eWON?
Has your customer tried reading other tag addresses, possibly D registers?
From customer: I can ping the PLC and have tried reading I/O and D registers. Still get no communication on all tags. Also tried taking the switch out and hooking the PLC directly to the EWON with no good results.
Can your customer customer check his PLC settings to ensure they match what is set in the eWON?
Confirm that the PLC is using TCP / port 5001 and that the IP matches topic A’s address
If not, change the eWON settings to match.
Try the default poll rate (2000 ms)
Ensure that the PLC’s default gateway is the eWON’s LAN IP
We’ve tried both 2 and 3 and customer has confirmed the IP addresses.
Is the PLC set for TCP port 5001 or UDP? UDP uses a different port.
The settings appear correct in the eWON so you may need your PLC programmer here to diagnose your controller.
Could we set up a three way call with the customer? We could probably do a VNC session of some kind
Yes, absolutely. If you can, send over a time that works best for you and your customer.
Update:
The eWON configuration was correct, and the customer ended up switching over to CH2 in his PLC and then power-cycling the PLC to get this working.
Ensuring the Ethernet diagnostics IP address matched the CH2 IP address helped here as they were different IPs before the PLC reboot.
