No comunication between Flexy 205 and PLC S7-1214

Ewon Support
, ,
#1

Hi

For two months I had a Flexy 205 (FW 14.4s0) connected to an S7-1214C (TIA Portal v13 SP1), which communicated correctly.
For two weeks, communication between them was lost and I have not been able to reestablish it.
If I restart or de-energize the Flexy, the problem persists.
When I restart the PLC, communication returns for a few hours, and then it is lost again.

In the “Event logs” of the Flexy it indicates:
26804 stdios-Device ENTERS slow poll mode (S73 & 400 - IP Address: 192.168.10.100)

In the TIA portal I have “PUT / GET communication” enabled.

Are there any other settings that I should take into account in the TIA Portal?

Greetings

#2

How is the FLexy connected to the PLC, is it a direct Ethernet connection? Or does it go through a switch?

The error you posted indicates that the Flexy looses communicaiton on the PLC. As it is not able to get the values. Can you create a Status tag to indicate the communication status?

#4

Hi Kevin

The flexy and the PLC are connected by ethernet connection directly, without a switch.
I can connect to the PLC via TIA portal and eCatcher without problems.

How can I create a Status Tag?

below attached backup of ewon with support files
MOVED TO STAFF NOTE (1.2 MB)

#6

Hello,

YOu can create a status tag by following the IO server documentation.

• Status register:
The STATUS Tag is a special Tag that returns information about the current state of the communication for a given device.
As for other Tags, the status Tag ValueName is composed of:
Status, Global Device Address
• You can define a status Tag for each PLC used.
• If you use the status address, the Tag must be configured as analog.
0 Communication not initialized. Status UNKNOWN.
If no Tag is polled on that device address, the communication status is unknown.
1 Communication OK.
2 Communication NOT OK.

#7

Thank you Kevin,

I was able to create the “STATUS TAG” or S73 & 400 IO server successfully.
The value of “STATUS_TAG” is 2.

Status_Tag
Status_Tag788×139 8.18 KB

Status_Tag_conf
Status_Tag_conf664×569 22.4 KB

Event_Logs
Event_Logs1920×1040 160 KB

This is the latest backup:
MOVED TO STAFF NOTE (1.2 MB)

#9

Given the Status Tag, it shows that the communication is not OK between the PLC and the Ewon Unit.

Can you try swapping out cables, and a direct connection between the Cosy/PLC? Have you checked for any issues on the PLC that would cause it to cut communication. Previously you mentioned that the PLC would need to be reset in order for communication to resume. IT looks lke there could be an issue with the PLC that causes it to stop comms.

#10

The PLC is directly connected to the Flexy, as is the HMI.

We have changed cables and the problem persists.

From the TIA Portal I checked in the section “Online and diagnostics” and there is no warning about communication errors.

The PLC shows no signs of communication errors as it can be connected to the HMI without problems via the Flexy.
TOPOLOGIA

We did the test on another Flexy and another PLC with the same backups (Flexy and PLC) and the problem occurs in the same way.

#11

Hello,

I would move the code from the cyclic section and place it in the Init section. Having BASIC code in the cyclic section of the IDE can cause communication problems. If the problems still persist, stop the code and check the connection again.

#12

Kevin,

You have repeated “cycle section” twice:

A week ago I made a test communicating only one variable, with no code in the “BASIC IDE”, and the problem persisted.

We changed the ethernet cable and the problem still persists.

I just deleted all the code from the BASIC IDE and stopped the Script (and Autorun OFF). I restarted the Flexy from the web and the communication keeps failing.

#13

There is a Socket connection failure occuring on the S7 IO server, so i will escalate the issue.

If you could also provide a wireshark on the LAN side so that i can see if there are any errors from the PLC that would cut communication.

#14

I installed wireshark on a PC connected to the LAN of another PLC and Flexy, connected in my office but with the same backups:

image
image1371×732 323 KB

It’s okay like that? Tomorrow morning I will send you the full report.

#15

I would need the full report so we can see what the traffic is. ONce i have the full report i can have my team look at it

#16

Yesterday when I moved the “Cyclic Section” to the “Init Section” the problem continued but after a while the connection was re-established and so far it has not been cut.

Regarding wireshark, how long does it take for logs? Does wireshark have to be configured in some particular way or should it just keep listening?

#17

Well, the purpose of the logs is to read the traffic for when the error occurs. So I would keep it running, until there is a disconnect. Once you have verified the disconnect in the event logs, look for the period of time that the error occurred and pull those logs.

#18

The previous Friday, after moving the “Cyclic section” and the “Init section” the problem continued but after a few hours the communication was reestablished.
Since then, communication has failed again much less than before in the Flexy that we have installed in the field, and communication was reestablishing itself. Here we do not have the possibility to connect wireshark.
In the Flexy that we have installed in our office (which has the same “restored” backup as the Flexy that is in the field), communication did not fail again. In this equipment we have the PC connected with wireshark, but since there were no communication failures, we could not register any failure event with wireshark.

Does this give us any idea of the problem? By removing the BASIC code the communication improved a lot but it was not the definitive solution in the Flexy installed in the field. I will continue to log with wireshark anyway until the problem occurs.

#19

here is the backup with the support files, of the Flexy installed in the field (with failure of slow poll mode):
MOVED TO STAFF NOTE (1.3 MB)

#21

Hello,

Do you have gateway address on the PLC? The current NATitf parameter is set to 3. This means the the PLC needs to have an empty gateway address. If you would like to keep the gateway address, then you can update the NATitf parameter to 2 in comcfg of the Flexy.

#22

Hello,

The PLC have an empty gateway address.
image

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
In the test Flexy that we installed in the office, the problem did not occur again, even if the BASIC code was enabled.
MOVED TO STAFF NOTE (1.3 MB) //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
In the Flexy installed in the field the communication failure occurs every couple of hours and returns to work after 30 or 40 minutes.
MOVED TO STAFF NOTE (1.2 MB) Is there something in this pattern that has to do with the communication error? I am attaching screenshots of the Event logs where you can see the “slow poll mode” notices.

image
image589×712 77.3 KB

image
image591×771 88.1 KB

#24

Hello,

Not being able to connect a PC with wireShark to the Flexy in the field, I used the eCatcher to connect to it. Attached the wireShark:
wireShark_20210715_2155 to 20210716_0948.pcapng (2.2 MB)

10.35.129.238 (eWON Flexy IP)
10.35.1.57 (Talk2M adapter IP)

During the wireShark registration the communication errors (slow poll mode) occurred at the following times (UTC-3):
07/15/2021 23:01:14 to 07/16/2021 00:01:05
07/16/2021 05:29:41 to 06:04:47
07/16/2021 06:35:29 to 07:05:18
07/16/2021 07:35:55 to 08:05:39

I attach eWON backup with the support files:
MOVED TO STAFF NOTE (1.3 MB)

#26

Hello,

THe issue is occuring on the LAN side of the device between the Flexy and the PLC. I will not be able see the the socket failure in the current wire capture that you are providing. If you can get me the capture, i can escalate the issue.

As of now, there is a protocol communication issue between the Flexy and the PLC.