Hello everyone

I am having a hard time diagnosing an intermittent Ethernet Connection Failure.

I am using some Lenze SMV Frequency Drives and communicating to them over EthernetIP from a Control Win soft PLC and compiler V3.5.17.20.

I am noticing two different behaviors:

1. If am varying the speed command, the VFD will function normally until the speed is held at a constant value after which a timeout fault will occur. This seems to indicate that the speed command is only transmitting 'on change' however everything seems to be set up for cyclic transmission, even under connection settings of the EthernetIP device.
2. A connection failure occurs every 10 seconds or so regardless if the enable command or speed commands are changing. According to the attached log, a second connection is attempting to open.

Do you have any ideas what could be causing this issue? It does seem to be a Codesys error however this is the first time I am using EthernetIP and am learning about this protocol as I go.

Thank you

if cyclic, I guess your network is not setup correctly for UDP Multicast. The easiest solution is to switch to unicast:

• Open the editor for the remote adapter.
• Go to Connections tab. Edit the connection.
• Make sure both connection types are set to Point to Point.

Thanks @i-campbell

Your suggestion solved one of the issues: I no longer get a connection failure every 10 seconds or so.

However I still have this issue:

• If am varying the speed command, the VFD will function normally until the speed is held at a constant value after which a timeout fault will occur. The VFD documentation labels this as an "IO Message Timeout Error". This seems to indicate that the speed command and enable command is only transmitting 'on change' however everything seems to be set up for cyclic transmission, even under connection settings of the EthernetIP device.

Please see details of the connection in the picture attached.

Do you have any further suggestions on how to eliminate the IO Message Timeout error?

Thank you

Seems like it would work.

Do you have a link to the user manuals for the servo drive?

Can you obtain a wireshark?
If you like the filter can be
tcp.port == 44818 || udp.port == 2222

Hi @i-campbell

Still no improved results after more troubleshooting.

The VFD still gives an IO message timeout fault if I am holding a constant speed command. I can also see in the Codesys Mapping that the

Link for EthernetIP module:
https://download.lenze.com/TD/COM__ESV__SMV%20EtherNet-IP%20module__v2-0B__EN.pdf

I've followed the commissioning procedure with no luck.

I've attached the Wireshark results.

One thing I am noticing is that the feedback from the VFD doesn't match exactly what Codesys is outputting. For example Bits 5 and 6 of Inp_Param0 should be identical to bit 5 and 6 of Out_Param0. They are only identical if I am varying the speed. See snip attached.

Any other suggestions?

Here is a snip of the Input and Output assembly mapping with Bit 5 and 6 that I was mentioning.

The wireshark misses the connection building section, so it does not show the detail of the cyclic packets being sent. However it does show data being sent by both the codesys scanner and the VFD every 10ms.

Now, the EtherNet/IP messages have two sequence fields

• encapsulation sequence number - increments every message
• CIP sequence count - increments every time data is changed

This CIP sequence count is very handy for small devices, because they only have to process the data when the data changes. But it seems in this case your drive interprets this as loss of communication.

If you want to see this better in wireshark:
1. Start wireshark capture
2. Stop and start the control win service.

You should then send this to the VFD manufacturer for a bug report.

As a dirty hack workaround, see if there is some portion of the data which you could be constantly changing. From the manual I think the default timeout is 2 seconds.

Hope this all makes sense.

This now makes complete sense and validates the behavior I was observing.

Thank you for your help. I have issued a bug report to the manufacturer and have found a work around for now as per your suggestion.

Thank you

This now makes complete sense and validates the behavior I was observing.

Thank you for your help. I have issued a bug report to the manufacturer and have found a work around for now as per your suggestion.

Thank you