V700 Modbus TCP communication with Exlar Servo

[VFU1076]

Hi all, 

I am running into a communication issue that I am not over familiar with. 

My customer has a V700 communicating via Modbus TCP with an Exlar Servo motor. Once the run bit is high the equipment starts operating and then it sporadically stops due to a communication failure between the controller and servo drive. 

I have replaced cables, checked wires and everything seems to be normal. As mentioned, it does not happen frequently, the equipment runs for an hour or so and then it stops. 

At times, it seems to be happening more often so I'd say every 10 minutes or so. 

After speaking with my customer, they said they have been building the same equipment for a long time and the program has never changed. I was confused as I thought that there was probably something in the code causing the issue, but it seems like it could be hardware too. 

Anyhow, I uploaded the program and everything seems to be correct in it. I would personally do a few things in a different way, but as my customer said the program has never changed and they have been building the same equipment for years. 

I noticed that the programmer used socket # 3 (TCP/IP Sock init) for the TCP communication, however the local port linked to that socket is the port 20259 which is stored in a MI 215 operand.

In the help menu says that port # 20257 is the default port for socket # 3.  

Would this be causing the communication issue my customer is experiencing?  

I have attached a pdf of the vlp  project and hopefully that helps. 

The routine is called "COMMS MODBUS TCP"  which is the routine that uses the socket for the TCP communication. 

 

Thanks in advance for your help. 

 

Cheers!

COMMS MODBUS TCP.pdf

[kratmel]

I have observed communication problems in the V700 controller if the servo or frequency converters are not properly grounded.

Also, in this case, connecting the PLC negative power wire to machine ground helped.

I cannot predict all the reasons, but in such cases, I have observed that a slight change in the internal program (firmware) of the servo manufacturer can change the state of affairs for the worse. To test this hypothesis, it is necessary to go back to the previous versions of the servo drive from previous working installations.

[VFU1076]

Thanks for the reply, Kratmel. 

There is only one power supply in the panel and the 24C(negative) is grounded so that is the same common going to the PLC. I checked all ground connections, voltage levels and everything is alright. I will double check to make sure though. 

In regard to the socket port # , do you think that could be an issue? 

Cheers!

[Ausman]

Is SB168 on?  And what does SB167 show during the failures?  Others here will likely chime in with their favourite settings for other SI settings.

And as it looks like there's a gateway in the mix, that's another thing that might be suspect.  Have they changed that?

cheers, Aus

[VFU1076]

Gateway is still the same as far as I know. 

So PLC IP : 192.168.0.100 / 255.255.255.0 Subnet and Gateway 192.168.0.1

Servo gets: 192.168.0.101  

Not sure if the SB 168 or/and 167 is being used in the code. I will have to check.

One thing I noticed was, the failure only occurs when the machine is running so if the equipment is energized and in stop mode there is no communication issue (PLC & Servo are up and ready). 

I will double check the ground situation as it could be an interference issue as mentioned by Kratmel.. 

 

Cheers, 

 

[kratmel]

One more tips. Is it in new installation the same power supply model used?

Some times wrong type power supply make problem for all installation.