Hi!

We have CPU 314-2DP with CP 343-1 that do it's job and communicates with PC via DELFI <-> PLC  function communication block, this is some TCP communication that sends and receives known memory words.

The program and the CPU itself have some "ping" logic inside to analyze the link quality. The Delfi written program sends some memory bit to PLC and receive an answer, second memory bit from PLC, calculates time value on display.

We have a problem that sometimes this "ping" logic shows unacceptable delay of 1000+ ms and machines behind the CPU may slow  down or even stop just because slow data connection.

What we have tried to do is to replace everything except CPU and this delfi written program, our programmer told that he does not see anything on PC or network that can cause those delays. Plain ping test from windows command line gives always good values, even that time when delfi communication test shows values from 2000ms and above, windows ping to PLC gives only 1-2ms. SO I suspect that the problem is in communication between PLC and network CP 343-1. I found that Siemens released at least 5 generations of 314 CPU and we have the first one, that is unsupported anymore. But in second or third generation I found that some firmware version corrects problem and instabilities with CP 343 communication module and now I have a question, is it possible that our first generation PLC have some problems with communication module due firmware lack or whatever and those could not be fixed just because support ended?

Hello,

also my recommendation can be check PLC code for communication. You can know which device is Server and which Client. Via this info you can monitor request timer and possible respons delays. I'll be check this for sure. Other question can be if Client in case of succes received answer will continue with strictly defined timer or automatically send another request due quick respons from Server. Check this options and give us info.

dchartier

Hello Vlad;

To be able to provide you out with more detailed information, we need to know the exact part number of the CPU you are using.

Here, as an example, I have a link to the firmware upgrades of the 6ES7 314-6EH04-0AB0 CPU:

Operating System Updates for CPU314C-2PN/DP (6ES7314-6EH04-0AB0)

https://support.industry.siemens.com/cs/fr/en/view/51466769

Even if this is not the part number you have, please read the accompanying information: there are elements here that apply to all upgrades.

-it is recommended to always upgrade to the latest version possible;

-unfortunately, upgrading the firmware requires you purchase a MMC (8MB).

Hope this helps,

Daniel Chartier

CPU is 6ES7-314-6CF00-0AB0 with firmware 1.03.

I have seen 1.05 but there is no major changes listed regarding this issue directly.

Since it first generation it can be upgraded via MMC. But we do not have an PROM adapter is there possibilities to buy MMC with OS upgrade for this PLC? I am not sure if it helps anyway as I mentioned I don't see workarounds for this CPU and CP 343 compatibility.

 I can check it later, but we have similar code working without any issue on another production line with different CPU. But I'll double check this, may be we have some code pieces that differs, thanks for the tip.

Duris_I

Hello,

also my recommendation can be check PLC code for communication. You can know which device is Server and which Client. Via this info you can monitor request timer and possible respons delays. I'll be check this for sure. Other question can be if Client in case of succes received answer will continue with strictly defined timer or automatically send another request due quick respons from Server. Check this options and give us info.

I have compared the code used on subject PLC with other working PLC 313C-2DP, the code is the same, there are some minor differences that should not  affect connection quality. The other thing I have found in hardware configuration on that production line, we have other PLC connected to PROFIBUS and there is communication block in code also translating some memory words between PLCs. But I don't see how it can affect overall connection quality on ethernet side.