Hi,
I’m having issues with a CR1000 and a NL16 module trying to poll data from a modbus server via TCP/IP.
Sometimes the logger manages to read data from the Modbus server and everything works fine for a long time, but there are times when it fails and the result code of ModbusMaster() is -11 which means “ The specified TCP socket is not opened. There is no connection to the Modbus slave”. Sometimes it’s only for few seconds and sometimes it gets stuck for hours. Whenever I notice that it gets stuck with -11 code, I restart the program manually and it works again temporarily.
I don’t know if the problem comes from my code or my device configuration or if it’s a network issue that causes loss of communication.
I’ve configured the datalogger with a static IP address 192.168.101.101 that theoretically it’s not being used by any device on the network.
This is part of my code:
'IP address and TCP port of the Modbus slave device
Const IP_address As String = "192.168.xxx.xxx"
Const TCP_port As Long = 521
Public Socket
Public Result
Public FirstVariable as Boolean
Public SecondVariable as Float
Public ThirdVariable as Float
[…](Datatable, etc)
BeginProg
SlowSequence
Scan(1,Sec,0,0)
'TCPOpen(IPaddress,TCPport,buffer,timeOut)
Socket=TCPOpen (IP_address,TCP_port,1,30)
'ModbusMaster(Result,COMPort,baudrate,address,fn,variable,start,length,tries,timeOut,option)
ModbusMaster (Result,Socket,-9600,1,2,FirstVariable,10,1,1,15)
ModbusMaster (Result,Socket,-9600,1,4,SecondVariable,18,1,1,15,0)
ModbusMaster (Result,Socket,-9600,1,4,ThirdVariable,46,1,1,15,0)
TCPClose (Socket)
CallTable Data
NextScan
EndProg
At a first time, the code didn’t include the TCPclose function, as I understood that if the connection was successful, the function wouldn’t do anything, and if not, it would try to establish the connection. But latter I read in the function help that the logger is “unable to ensure the connection is functional as it does not know the frequency or nature of the expected data. If possible, […] simply close and reopen the socket at regular intervals.“ So I opted to open and close the socket with every scan, thinking that might be the solution to the problem. It’s working sometimes but again the problem still happens.
Here is my first question, now that the program is opening and closing the socket with each scan, the TCPopen handle variable increases by one each time, since it creates a new connection. Can this variable increase indefinitely without causing issues or is there a point when it will reset to 101 again?
Back to the main problem, this is what I can see through terminal with Comms Sniffer when the problem happens (Ignore the xxx):
01:44:19.45 tcp_write handle 5678 len 90 01:44:20.00 trying to connect with 192.168.xxx.xxx on port 521 01:44:20.03 tcp_write handle 5678 len 123 01:44:20.15 tcp_open timed out 01:44:20.15 failed to connect with 192.168.xxx.xxx on port 521, Connection aborted. 01:44:20.36 Recv pakbus on handle 5678 len 12 01:44:21.00 trying to connect with 192.168.xxx.xxx on port 521 01:44:21.05 tcp_write handle 5678 len 291 01:44:21.15 tcp_open timed out 01:44:21.15 failed to connect with 192.168.xxx.xxx on port 521, Connection aborted.
When it works you can see how it opens the port successfully, read modbus registers and closes the port (again ignore the xxx):
01:57:37.00 trying to connect with 192.168.xxx.xxx on port 521 01:57:37.01 Handle 230 TCP client 192.168.101.101:49282 192.168.xxx.xxx:521 opened 01:57:37.05 tcp_write handle 230 len 12 01:57:37.07 Recv pakbus on handle 142 len 24 01:57:37.08 Recv modbus on handle 230 len 10 01:57:37.09 tcp_pcb 002316B0: TCP modbus 192.168.101.101:49282 192.168.xxx.xxx:521 service 01:57:37.11 Recv pakbus on handle 110 len 24 01:57:37.12 tcp_write handle 230 len 12 01:57:37.13 Recv modbus on handle 230 len 13 01:57:37.13 tcp_pcb 002316B0: TCP modbus 192.168.101.101:49282 192.168.xxx.xxx:521 service 01:57:37.15 tcp_write handle 230 len 12 01:57:37.16 Recv modbus on handle 230 len 13 01:57:37.16 tcp_pcb 002316B0: TCP modbus 192.168.101.101:49282 192.168.xxx.xxx:521 service 01:57:37.18 Handle 230 TCP 192.168.101.101:49282 192.168.xxx.xxx:521 closing
Maybe it’s worth mentioning that I’m communicating with the logger through an RS-232 modem over PPP, but I don’t think that could be interfering, otherwise please let me know.
I’ve thought about an insufficient TCPOpen timeout, but it is set to 300 ms which I think is enough, and I’m not able to increase it much more since the total timeout of the scan would exceed the slowscan interval. Anyway, I don’t know how that could explain the fact that restarting the program temporarily solves the problem. I also wonder if the problem could be caused by a conflict of IP address in the network.
I added a line in the code to ping the IP address of the Modbus server, so I’m observing that when it works, the response time is about 10-30 ms. Obviously, when the problem arises, the response time is 0.
SlowSequence
Scan(1,Sec,0,0)
PingResponse=PingIP (IP_address,100)
NextScan
Any help would be highly appreciated, I need to know if I’m doing something wrong, or if it’s caused by a network issue which at the moment is out of my scope, thank you in advance.
When you have two IP interfaces(PPP and Ethernet) good practice is to include IPRoute() instructions in your program to indicate which interface to use. Without IPRoute() all outgoing connections will use the default interface. Default interface is usually Ethernet.
Hi, long time since I posted this. Thank you anway for the help. It turned out to be an electromagnetic interference problem with the ethernet cable and the environment where the logger was set up, and nothing related with the code. Apparently it was solved with a ferrite core. So this thread can be closed or deleted if necessary.