V700 Socket Behavior - locking on

[Joe Tauser]

We're troubleshooting a Modbus IP slave application on a V700 and the PLC is locking out the Master.  Using "V700 Read Socket Status" with code #22 results in a reply of 23, which means a connection is established with something.  When we turn off the Master (a remote Weintek display) SDW 61 stops incrementing but Status remains at 23.  When we turn the Master back on we get a no connection error on it.

When we reboot the PLC the status goes to 20 (Listening).  Then we turn on the Master and everything works.

Is there a way to make the socket disconnect after a period of inactivity without code?

Joe T.

[HigHTech]

Hi Joe:

Do you need the Weintek remote display to run as a Master? Since the launch of Unistream and always I need a master I choose one of them, the communications are so stable and easy. I think the problem you are having is the way Weintek manage the comms. Try to change an use the V700 as master and check.

[Cam]

Joe does it take rebooting the PLC or would simply re-initializing the ethernet port take care of this?

Could you set up a timer so that if SDW 61 doesn't increment for a period of time while your status is 23,  the timer output will re-init your ethernet card.

 

[Henny]

Hello

 

The problem is that when you have a Modbus master slave communication between Unitronics and another device established,  that if the communication is interrupted by means of disconnecting the Ethernet cable or rebooting the master the Ethernet socket on Unitronics site maintains in status “connected”.

So you have to check if the SDW,s are changing to determine if data is exchanging.

When these SDW,s are not changing then you have to do a socket disconnect to allow the master to reestablish the connection again.

 

So I think Joe,s question is , is there another way to eliminate this problem without adding the code for disconnecting the particular socket?

 

Kind regards

Henny

[Isakovic]

I had a similar problem with V700 just stopping Ethernet communication.

It wouldn't communicate with SCADA through UniOPC and couldn't be accessed by VisiLogic from any port. It responded to pings. Socket status was the same as with Joe's case, 23 when it locked, 20 after restart. It happened after 20 or so days of continuous work.
It started working again after everything was restarted.

I never had any problems with controllers that require Ethernet cards.

[HigHTech]

I work a lot with Modbus TCP/IP. I solved the problems you were talking about configuring SI (103-106). And also writing some code to close the socket or reset the card. Now I don´t have any experience with V700. So we need Unitronics people to help. 

[Isakovic]

On 1.9.2016. at 9:28 AM, Isakovic said:

I had a similar problem with V700 just stopping Ethernet communication.

It wouldn't communicate with SCADA through UniOPC and couldn't be accessed by VisiLogic from any port. It responded to pings. Socket status was the same as with Joe's case, 23 when it locked, 20 after restart. It happened after 20 or so days of continuous work.
It started working again after everything was restarted.

I never had any problems with controllers that require Ethernet cards.

It happened again.

It's locked and socket status is 20 on all three ports I use. Still responds to pings. SB 154 and 167 for Ethernet errors are 0.
How would code for resolving this look like? I think of something like: If status is 20 for 5 minutes, close the socket and init again in next scan.

[Joe Tauser]

This question was kind of directed toward the Creators.

@HighTech - The Weintek (also known as Maple, KEP, or Rohtek here in the US) is always a master.  These have been a go-to solution for most PLCs for many years.  Your suggestion of setting a value in SI 103 - 106 is right on the mark, but these don't apply to the V700.

@Henny - I don't think there's a way around coding error handling for now.

@Isakovic - I'm only using Modbus IP so I can watch SDW 61 for a changing value if the socket is connected and close the socket after a timeout if the data stops changing.  If you're using other sockets you'll have to retrieve the recieved transmission count when that socket is open using request 42 and then watch for that value to change, cycling the socket if the count stops changing.

Joe T.