Remote DF Modbus/TCP Server won't open TCP connection

[SteveMyres]

At a customer site, I have an instance of DAQ Factory running, that's serving about 20 variables via Modbus.    The plant SCADA integrator is trying to read these variables from two Wonderware Intouch instances, but can't make a connection to the DF server.   Until recently, I could poll the DF slave registers with no issue, both with ModbusPoll and an instance of DF at my location, so I was inclined to blame the SCADA, perhaps the firewall settings on the machines.

Now, however, I'm unsuccessful reading the registers with either ModbusPoll or DF (either in channels or sequence).   I get

P-ModbusTCP 0010: Timeout
05/25/20 12:55:01.140

Both the SCADA guy and I can ping the DF machine, and I'm not aware of any changes that have been made to the DF PC (firewall, for example)  between when I could read and now, nor have any idea why I could read before when he could not.

[AzeoTech]

I'm assuming Ethernet Server?  I would first try putting the server on a different port, like 501 and see if that helps.  That will tell you whether there is some other software in the background using the standard port. I'd also test locally first, then from a remote computer.

[SteveMyres]

Wellp, can't test locally.    Could try another port, though it hasn't changed since it worked [for me but not for him], but it means I'll have to edit the CTL and resend.   That's doable.

Oh, and the SCADA guy hasn't physically been local when he's testing but requests have been sent from his WW machines which are local, in addition to using Modbus clients local to him via VPN like I'm doing, and the local ones did no better.

 

[SteveMyres]

OK, so changing the port worked, partially.    Can't imagine what could have been added to the DF PC using port 502, but changing to 510 allows both my DF test client and Modbus Poll to connect.   However, DF polls successfully and Modbus Poll does not.   It times out, even though both clients have generous timeout setting far longer than the typical response delay of 80ms.   Baseblock ComTest Pro also times out and claims not to have received a response.   DF and the other two clients have all worked in the past.

I've been at this point before, as well as the case where all clients I used would work, when the plant SCADA guy could not get a response with Wonderware or Modbus Poll.   I'm baffled.

 

[SteveMyres]

Another curiosity.    My remote access is via a Cisco  Anyconnect VPN administered by the customer.   Wireshark lists the Radmin VPN virtual adapter I use for remote access sites I manage, but does not seem to be aware of the Cisco one.    If I could Wireshark the queries, I could see if there's any difference between the DF ones and the Modbus Poll or Baseblock ones.

[AzeoTech]

I'm not sure.  The easiest solution is to simply get a serial to Ethernet converter and have DAQFactory act as the Modbus slave on a serial port, then use the converter to put that comms onto Ethernet on 502.  Then you are no longer using Windows networking and all the issues (i.e. firewall, etc) that come with it.  You are using Windows serial ports which are quite straight-forward.  DAQFactory and Windows won't know that you are then going Ethernet.  Since DAQFactory supports any protocol on any transport layer, you can still use the ModbusTCP protocol without having to use a protocol translator, so you are talking a $200 or less device.