Main Site Documentation

Out of connecting Modbus TCP / IP


#1

Hello all,
First, I want to thank everybody because I posted several topics and it has been solved! :clap:
I just have a little problem, I’m still working on G120HDR I realized a TCP / IP Modbus connection that works very well, I can retrieve data, all goes well.
The only problem is that after a certain time I get an error that appears on this line of code:

  while (pos < 6)
            {
                pos += _Socket.Receive(buffer, pos, 6 - pos, SocketFlags.None);
            }
            telegramLength = (short)(ModbusUtils.ExtractUShort(buffer, 4) + 6);

By reporting to me that the existing connection was forcibly closed by the remote host. But this problem is disturbing because the card must operate for several hours autonomy.

Thank you in advance!


#2

@ andre.m - Oh I was wrong board? Yet there is well written program.gadgeter where I insert the modules?


#3

@ andre.m - Okay, so I have to do?


#4

@ andre.m - The problem appears on the client so it’s the server closes the connection if I understand, I especially like that this problem can not do it but if a break should exist so I just want the connection between the client and the server redo.


#5

Is the G120 a Modbus Master or Slave?

if it’s the slave, then it is a TCP server.
In this scenario, if the other side (the Master) has closed the connection for some reason, it has to open it again.

If the G120 is the Master, then you have to reconnect to the slave when you get this exception.

btw. I made several optimizations/bug fixes to the Modbus library.
I’ll see if I can update everything in the near future.


#6

@ Reinhard Ostermeier - The G120 is a modbus Slave. But he pointed out it was closed by the remote host, it is not the slave who has closed the connection?


#7

remote always means the other side.
So if your G120 says the remote host has closed the connection, then it’s the Master who closed the connection.


#8

@ Reinhard Ostermeier - But the error appears on the program of the master.
Because the side of the board programming G120

The connection should automatically resume?


#9

@ MVeloso4 - Please make some things clear again:
What device (G120 or PC) is your slave, which is master?
Which side throws the “remote host closed connection” exception?


#10

@ Reinhard Ostermeier - So it is the G120 card is the slave.
But the exception is thrown from the master.


#11

That’s strange. I didn’t had this issue before, but I also made some minor changes to the TCP code.
I really try to get the latest version uploaded this week.


#12

@ Reinhard Ostermeier - I’ll re-download the latest version of your program to see if the problem still exists.
To see if it is not me who is changing the program.
I’ll let you know.


#13

@ MVeloso4 - SO far I havn’t uploaded a new Version.
But there is a good Change I can do tomorrow. Home Office day :dance:


#14

@ Reinhard Ostermeier - Oh great ! I expect that ! :slight_smile:


#15

I have finally added the 2nd version of the library to CodeShare.


#16

@ Reinhard Ostermeier - I tried your code everything works for me except I get an error on this line:
get { return _Socket != null && _Socket.Connected; }
He did not know _Socket.Connected;


#17

@ MVeloso4 - Have you copied the code into your project?
Socket.Connected does only exist in Windows, not NETMF.
That’s why it’s surrounded by #if NETMF #else #endif
The NETMF project needs to have ‘NETMF’ defined in the project properties.


#18

@ Reinhard Ostermeier - I made many test and I noticed that whenever the problem occurs after about 300 seconds and it systematically.
I took the new version, now the error that appears every time is the timeout .
The request is made by a master timer that every second is return of the proofing information from the slaves:

  private void Timer1(object sender, EventArgs e)
        {
            TrameReçu = master.ReadWriteMultipleRegisters(248, 0, Trame, 0, 17);
            VerifTrame(); 
        }

#19

@ andre.m - it’s a switch: NETGEAR 5-Port 10/100 Mbps Switch.
The problem comes from the switch?


#20

The default timeout for all Modbus transaction is set to 2000 milli sec. (2 sec.)
When your timer has an interval of 1 sec. this might get a problem.
Also you should surround all Modbus calls with a lock, using the same lock object everywhere. I tried (and actually do) this internally, but I found out that this seams not always to work as expected.
If I remember right, m< Modbus device class only handles one telegram at a time. This is what all devices I used so far do as well, even in Modbus TCP.