Can't reach server/slave! Check TCP/IP and firewall settings

hi,

I'm trying to read data from a device.
Protocol is modbus TCP and I connected it to Ethernet. It supports SCADA TCP interface.

I'm using modpoll master simulator from my computer. But I get a response "Can't reach server/slave! Check TCP/IP and firewall settings" again.

Response is below.

..............
~~~>modpoll -mtcp -r1 -c10 -1 10.180.121.114
modpoll 3.6 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright (c) 2002-2018 proconX Pty Ltd
Visit https://www.modbusdriver.com for Modbus libraries and tools.

Protocol configuration: MODBUS/TCP
Slave configuration...: address = 1, start reference = 1, count = 10
Communication.........: 10.180.121.114, port 502, t/o 1.00 s, poll rate 1000 ms
Data type.............: 16-bit register, output (holding) register table

Can't reach server/slave! Check TCP/IP and firewall settings.
..............

Both my computer and the device are in same network, and I can ping it by IP and status is fine.
Also I set modbus slave simulator at another computer and tested. It was successful.

I can't figure it out what is going on.
Plz let me know how.

Thanks.
 
I am not a network guy and more than once it's taken a real IT/network guy to figure out what was blocking the Modbus comm. But I have encountered the following issues when troubleshooting Modbus over Ethernet. I'm sure some do not apply to you, but it's a list, so ignore anything that doesn't apply.

Getting Modbus/TCP connections to work

- The Modbus Client/Master is not polling the Modbus Server - not configured, misconfigured, not enabled.
- The Modbus Client/Master is polling a different IP address.
- The Modbus Server has been assigned an IP address other than that being polled.
- An Ethernet cable (or serial cable) is not plugged in, or cable is bad
- RJ-45 is not an Ethernet port, it's some other connection
- damaged RJ-45, pins bent
- PC on wrong subnet (point-to-point testing)
- subnet mask mismatch
- PLC server not programmed properly or non-existent Modbus functionality
- gateway IP address issue
- gateway lost its power (stupid coax power connectors)
- field device uses only static IP, it can not be found via DHCP
- field device configured for DHCP, no DHCP server in point-to-point (peer-to-peer) connection
- IP address conflict - field device static IP duplicates a DHCP assigment or another static IP
- Modbus port 502 is closed or blocked by Firewall
- Modbus configured for some port other than default Modbus port 502 on one end
- Modbus traffic is being blocked by the network - managed switch . . .
- field device does not recognize comm setting changes until the power is cycled (needs cold start from power reset)
- field device (like a gateway) has a setting for limited range IP address recognition. If enabled, the target IP address might be out-of-range
- log-in/PIN required on field device to enable Modbus comm
- 'write enable' command required by field device before field device accepts write Function Codes via Modbus
- older 10Mb field devices can choke on full duplex 100Mb host comm
- if connection works for some period and then dies, an idle time can close the socket on the layer 3 devices (routers, NAT firewalls). Need to poll more often or enable TCP keep-alive RIP.
- field device overwhelmed by gross amounts of UDP traffic and can't get a break
- field device (PLC) is in program mode (not RUN mode) and it won't respond to any comm
- long initialization time for field device, initial polls cannot connect until initialization is completed
- non-commercial code - any sort of uP Raspberry PI device using custom programmed Modbus functions - they're the hobbyist, not me
Modbus gateway
- misconfigured for ASCII instead of RTU on the serial side; Client polls wrong serial node ID or fails to include node ID, Gateway configured to time-out.
- BOOTP used to enter a single static gateway in the bootp file; other gateways ignored.
- RS-485 issues: serial comm settings (2 stop bits), A/B driver line polarity, node address, lack of signal ground, common mode, noise,
 
Hi,

One of your moderators here. It might help others to troubleshoot your problem if you tell them what type (manufacturer and model) device you are trying to connect to.
Thanks. The device is data logger for PV plant. Manufacturer is Meteocontrol and model is bluelog XM-1000. Hope to figure it out with your help.
 
I am not a network guy and more than once it's taken a real IT/network guy to figure out what was blocking the Modbus comm. But I have encountered the following issues when troubleshooting Modbus over Ethernet. I'm sure some do not apply to you, but it's a list, so ignore anything that doesn't apply.

Getting Modbus/TCP connections to work

- The Modbus Client/Master is not polling the Modbus Server - not configured, misconfigured, not enabled.
- The Modbus Client/Master is polling a different IP address.
- The Modbus Server has been assigned an IP address other than that being polled.
- An Ethernet cable (or serial cable) is not plugged in, or cable is bad
- RJ-45 is not an Ethernet port, it's some other connection
- damaged RJ-45, pins bent
- PC on wrong subnet (point-to-point testing)
- subnet mask mismatch
- PLC server not programmed properly or non-existent Modbus functionality
- gateway IP address issue
- gateway lost its power (stupid coax power connectors)
- field device uses only static IP, it can not be found via DHCP
- field device configured for DHCP, no DHCP server in point-to-point (peer-to-peer) connection
- IP address conflict - field device static IP duplicates a DHCP assigment or another static IP
- Modbus port 502 is closed or blocked by Firewall
- Modbus configured for some port other than default Modbus port 502 on one end
- Modbus traffic is being blocked by the network - managed switch . . .
- field device does not recognize comm setting changes until the power is cycled (needs cold start from power reset)
- field device (like a gateway) has a setting for limited range IP address recognition. If enabled, the target IP address might be out-of-range
- log-in/PIN required on field device to enable Modbus comm
- 'write enable' command required by field device before field device accepts write Function Codes via Modbus
- older 10Mb field devices can choke on full duplex 100Mb host comm
- if connection works for some period and then dies, an idle time can close the socket on the layer 3 devices (routers, NAT firewalls). Need to poll more often or enable TCP keep-alive RIP.
- field device overwhelmed by gross amounts of UDP traffic and can't get a break
- field device (PLC) is in program mode (not RUN mode) and it won't respond to any comm
- long initialization time for field device, initial polls cannot connect until initialization is completed
- non-commercial code - any sort of uP Raspberry PI device using custom programmed Modbus functions - they're the hobbyist, not me
Modbus gateway
- misconfigured for ASCII instead of RTU on the serial side; Client polls wrong serial node ID or fails to include node ID, Gateway configured to time-out.
- BOOTP used to enter a single static gateway in the bootp file; other gateways ignored.
- RS-485 issues: serial comm settings (2 stop bits), A/B driver line polarity, node address, lack of signal ground, common mode, noise,
Wow. Really appreciate it. I'll check all list and test. Thank you. Also I wrote the device information above. Please check and if you know the device, let me know. thank you.
 
I forgot one - office grade (not industrial) Ethernet switch over heated when installed in an industrial control panel and failed at a temperature just higher than 40 Deg C, its rated temperature limit.
 
You connected a Modbus Slave simulator on a secondary PC and talked to it with Modpoll on the primary PC, correct? That eliminates the PC firewall issue - Modpoll is getting through the PC Firewall.

Can you take the PC with Modpoll and connect it locally to the field device (or bring the field device to the PC) and use a small 4 or 5 port Ethernet switch in order to check the Modbus connection? That eliminates all the networking in-between that can block the connection. Proves the two talk with each other.
 
The only Modbus manual I could find is the 4 page datasheet for the Modbus Power Control license, which I linked to in my last post. That document lists the communication parameters, register format, and register list.
 
Is your device licensed for Modbus? According to the blue'Log XM / XC page on the Meteocontrol website, the "Power Control Modbus" functionality is a separate license.

https://www.meteocontrol.com/fileadmin/Daten/Dokumente/EN/1_Photovoltaik_Monitoring/1_Produkte/blue_Log_XM_XC/DB_Modbus_Power_Control_blueLog_XC_en.pdf
I got a SCADA interface license and installed it.

Here is what I got licensed.
https://www.meteocontrol.com/fileadmin/Daten/Dokumente/EN/1_Photovoltaik_Monitoring/1_Produkte/blue_Log_XM_XC/DB_SCADA_interface_blueLog_XM_XC_en.pdf
 
You connected a Modbus Slave simulator on a secondary PC and talked to it with Modpoll on the primary PC, correct? That eliminates the PC firewall issue - Modpoll is getting through the PC Firewall.

Can you take the PC with Modpoll and connect it locally to the field device (or bring the field device to the PC) and use a small 4 or 5 port Ethernet switch in order to check the Modbus connection? That eliminates all the networking in-between that can block the connection. Proves the two talk with each other.
I just connected primary PC and bluelog only. I didn't connect slave simulator on a secondary PC and bluelog. Would it make a problem?
 
In post #1 you state:
>Also I set modbus slave simulator at another computer and tested. It was successful.

I interpret that as Modpoll on PC #1, slave simulator on PC #2.

In post #13, you state
>I just connected primary PC and bluelog only. I didn't connect slave simulator on a secondary PC and bluelog.

I still interpret post #13 as Modpoll on PC#1, slave simulator on PC#2 - which was successful.

Is that correct?

The reason for my question is establishing whether Modpoll on PC#1 can connect to any Modbus slave (or slave simulator) on the same network.
If so, it proves Modpoll is functional and that the firewall on PC#1 is not blocking Modbus traffic.
 
In post #1 you state:
>Also I set modbus slave simulator at another computer and tested. It was successful.

I interpret that as Modpoll on PC #1, slave simulator on PC #2.

In post #13, you state
>I just connected primary PC and bluelog only. I didn't connect slave simulator on a secondary PC and bluelog.

I still interpret post #13 as Modpoll on PC#1, slave simulator on PC#2 - which was successful.

Is that correct?

The reason for my question is establishing whether Modpoll on PC#1 can connect to any Modbus slave (or slave simulator) on the same network.
If so, it proves Modpoll is functional and that the firewall on PC#1 is not blocking Modbus traffic.
In post #1 you state:
>Also I set modbus slave simulator at another computer and tested. It was successful.

I interpret that as Modpoll on PC #1, slave simulator on PC #2.

In post #13, you state
>I just connected primary PC and bluelog only. I didn't connect slave simulator on a secondary PC and bluelog.

I still interpret post #13 as Modpoll on PC#1, slave simulator on PC#2 - which was successful.

Is that correct?

The reason for my question is establishing whether Modpoll on PC#1 can connect to any Modbus slave (or slave simulator) on the same network.
If so, it proves Modpoll is functional and that the firewall on PC#1 is not blocking Modbus traffic.
Thank you for you help.

Fortunately, I solved the problem. I'll explain everything.

By the way, interface is Modbus TCP.

PC1 : Modbus master pc. It commands request to slave.
PC2 : Slave simulator.
Bluelog : It is RTU and it can be used as modbus master.

What I tried was to read bluelog as a slave from PC1. Because any node can be slave or master over modbus TCP. And what I missed was that bluelog can't be read by itself and I only can read slave which is connected to bluelog. So I registered virtual device at a browser(it is supported) and I could read the virtual device(slave) register well.

Thank you guys for helping me.
 
Top