Reset Modbus after cannot bind Socket


Recommended Posts


While using DaqFactory as a slave on modbus and this error occurs "Ethernet Server failure: Unable to bind listening socket."


We are able to run 2 instances of DaqFactory ( one as a slave and one as a master ) and have yet come across the error above.

However, when we use DaqFactory as a slave connected to a "Third Party" Master, on occasion we get the above error. So far the only way we have found to have communications restored is to close DaqFactory and re-start it.

We can catch the error using OnAlert, and as a temporary solution we stop all sequences, save the document and reboot the computer when we come across this error.

Is there a way to correct this issue other than our current solution?

I know when we have an issue with our serial communication and we catch it, a re-initialization of the port seems to work ( initcomm())

Thank you

Link to comment
Share on other sites

Unfortunately, no we do not have a cause/affect here. Communications are running fine between the one system and DF and for some reason communications stop ( hours later ). If we have have DF in development mode we can see the error come up in the command window.

I have been able to "re-create" the problem by:

-Starting a Modbus communications setup

-Once successful communications between the units is up and running.

I type this into the command window


This provides us with the Ethernet popup. Once this appears you just hit save and do not change the port #. If you do that you will also get the error.

Another way is to open a second instance of the same program.

It appears to be coming from the third party program, but I would like to be able to ( if possible ) code something to "fix" the issue.

Other information:

The third part program continues to send.

Link to comment
Share on other sites

That error means the port is in use. The same thing happens when you try and fire up the DF webserver when another server is using port 80. The ConfigureComm() window may be doing it because its unable to close the socket fast enough before trying to reopen it. Its all asynchronous and sometimes it takes 45 seconds for some ethernet items (think about how long Explorer sometimes takes to open a network resource). This is a windows deficiency, and we get around it by doing stuff in the background so you can still use DAQFactory.

The thing is, once a listening socket is created, DAQFactory should hold it unless you reinit the port. Once it grabs the port, no other software can take it from DF. But, if you init the port, another piece of software could grab the port in the time between release and reinit.

My first thought would be to consider using a different port, say 501 instead of 502, that is if your client supports it, but if restarting DF fixes it, its probably conflicting with itself. Are you re-initing the port anywhere in your sequences?

Another fix might be to, in the OnAlert, fire up a sequence that sets the port to 500, reinits the port, waits 30 seconds, then sets the port back to 502 and reinits. You'd want a separate sequence so OnAlert doesn't get delayed 30 seconds as well. Use beginseq() to start it. If this works, then we'd also have a better idea of the cause.

Link to comment
Share on other sites

We are not re-initializing the port in our code, and we have not been able to determine what is causing the conflict, other than we have only ever seen it with the third party Master.

We were going to do as suggested, and change the port from the default 502 to another and back again but it is not offered as an option we can see for the server side, only client side.


device.ModbusTCP_Client.Port ( is offered )

device.ModbusTCP_Server ( no option for port )

Perhaps it is something I am missing or need to download an update.

As always so very appreciative of your support that has been above and beyond!

Link to comment
Share on other sites

The master is another piece of software running on a separate computer/server ( redundant servers ). We are waiting for for a runtime of this software to help in diagnosing the problem.

Thank you

Link to comment
Share on other sites

  • 2 weeks later...

Just to let you know this has not been forgotten about on our end, we are still waiting for the runtime to re-create the problem.

They are currently in the field (out of country ) and should be back shortly.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.