Ken Posted April 30, 2008 Share Posted April 30, 2008 Condition: While using DaqFactory as a slave on modbus and this error occurs "Ethernet Server failure: Unable to bind listening socket." Background: 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 More sharing options...
AzeoTech Posted April 30, 2008 Share Posted April 30, 2008 Do you have any indication of when this actually occurs? Is there some sort of trigger? Link to comment Share on other sites More sharing options...
Ken Posted April 30, 2008 Author Share Posted April 30, 2008 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 device.ModbusTCP_Server.ConfigureComm() 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 More sharing options...
AzeoTech Posted April 30, 2008 Share Posted April 30, 2008 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 More sharing options...
Ken Posted April 30, 2008 Author Share Posted April 30, 2008 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. ie. 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 More sharing options...
AzeoTech Posted April 30, 2008 Share Posted April 30, 2008 Right, sorry, my mistake. There is no port variable for server. What happens if you just start DAQFactory and not have a master connected to it? Link to comment Share on other sites More sharing options...
Ken Posted May 1, 2008 Author Share Posted May 1, 2008 There is absolutely no problems at all. Actually, if we make a sample program using DaqFactory to be a master we never run into this problem. Link to comment Share on other sites More sharing options...
AzeoTech Posted May 1, 2008 Share Posted May 1, 2008 Is the Master another piece of software on the same PC or a piece of hardware? Link to comment Share on other sites More sharing options...
Ken Posted May 1, 2008 Author Share Posted May 1, 2008 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 More sharing options...
Ken Posted May 14, 2008 Author Share Posted May 14, 2008 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 More sharing options...
AzeoTech Posted May 14, 2008 Share Posted May 14, 2008 No rush. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.