Siemens s7-1200 periodic "IO device failure"

Hi All!
I am having an issue with my Siemens s7-1215C communicating with my Mettler Toledo IND560 scale. The protocol being used is Modbus TCP and the instruction being used in TIA Portal v13 is MB_CLIENT. The problem is happening once or twice a day, sometimes more often. When the problem occurs the Mettler controller is not faulted and is displaying the correct values. However, the Siemens s7-1200's above mentioned MB_CLIENT block is not updating the values, and is frozen on the last good value received. So I am thinking the issue is in the Siemens somewhere.

I reviewed the diagnostic buffer and it appears I am receiving several errors each time this occurs. Some of the errors are

Error: IO device failure - Timeout in RPC application
internal AR error code 16#15

Error: IO device failure - Data transfer fault (no frame received)
internal AR error code 16#0

Error: IO device failure - IO device not found
internal AR error code 16#13

I have attached the log below as well as a screen shot of the network view.

I sure would appreciate any insight you folks might have!!

Respectfully,
Shane

Are you getting any kinds of errors from the MB_Client block?


Profinet errors shouldn't affect Modbus TCP communication unless A) it is a PLC error or B) it is a physical network error.


It's almost never an internal PLC error, and if it is you need to talk to the Siemens tech support.


My guess is that you have a bad network cable out in the system, which is causing an error every so often, possibly based on vibration or something.

mk42,
Thank you for the speedy response!! Yes from time to time I have been receiving errors, the last error captured was 80C8. In reviewing the help documentation associated with this error. It would appear that no response was received before timing out. That makes sense, but the second part of the help did not. "If the "MB_CLIENT" instruction does not receive an answer with the originally transferred transaction ID (MB_TRANSACTION_ID tag) within the defined period, this error code is output."

I totally agree that a Profinet error should not affect the Modbus TCP. However, reviewing the diagnostic buffer online this morning I found that every event logged was from the module named "fill station"(Profinet). Which is completely unrelated to the Mettler Toledo scale on "Tank C", other than both devices use the same ethernet switch. I decided to ping the IP address associated with the "fill station" while simultaneously pinging the IP address assigned to the Mettler Toledo. I had a 5% loss on the fill station IP which explains the diagnostic buffer log entries. Now this is where it gets weird, with the MB_client instruction in the "frozen" state I had 0% loss on the Mettler IP address.

To make a long story short, I found a seperate switch that was connecting the fill station to the main ethernet switch. I replaced the switch and I haven't had an diagnostic buffer error nor has the MB_CLIENT instruction froze since... I am not sure if I fixed anything lol.

Has anyone ever ran across a situation where one networked device negatively affected another one? Is there some kind of underlying network interconnection between devices I am not aware of happening in the network layers.

Shane
Go Blue!

I'm going to pretend your signature never happened, so i can keep helping you with a clear conscience

Shane.platt said:

Has anyone ever ran across a situation where one networked device negatively affected another one? Is there some kind of underlying network interconnection between devices I am not aware of happening in the network layers.

Click to expand...

Oh god, this happens all the time, even though it theoretically isn't supposed to. I'd have to see a general network layout to comment on the specific of your fix, but at the least yes, it is possible that swapping a switch might have fixed the problem.


While the MB_Client is frozen, are you trying to reset the connection? or are you just coming back later and resetting things manually?

Sorry I was pulled off this issue for awhile, but i am back on it. So it appears swapping out the switch did solve one issue, unfortunately not the issue with the MB_Client block.

mk42 said:

While the MB_Client is frozen, are you trying to reset the connection? or are you just coming back later and resetting things manually?

Click to expand...

I have some logic in place to reset the issue automatically, but it doesn't always work. I have attached a screen shot of the Modbus_CLient Block as well as the automatic reset logic.(I didn't write that for the record). Even with the reset logic, I am still manually going into the block and either toggling the disconnect bit, resetting the "ModbusErrors".TankAErrorCTR = 0 or in the worst cases stopping and starting the plc again.

Ok ok no more Go Blue. Go Sparty???

Are you quering all tanks same time (6x Modbus TCP querys same time)?


Thinking that it is possible that you use all communication resources of 1200 and modbus won't work if there isn't free resource for last TCP.


Check at online view how many communication resources are used and how many is possible on your PLC.

Lare,
This is some very good information. Thank you!!!

Lare said:

Are you quering all tanks same time (6x Modbus TCP querys same time)?

Click to expand...

I will check, but I am pretty sure we are quering all the tanks every scan.

Lare said:

Thinking that it is possible that you use all communication resources of 1200 and modbus won't work if there isn't free resource for last TCP.

Click to expand...

This sounds promising, but I am not quite sure what you mean? Sorry I am not well versed in networking.

Lare said:

Check at online view how many communication resources are used and how many is possible on your PLC.

Click to expand...

Could you elaborate on where in the online view I could look at the resources?
I have been doing some error trapping from the MB_CLient block and have seen 80C4, 8200, and possible 80A* something. I don't have my notes in front of me.

Shane.platt said:

Lare,
This is some very good information. Thank you!!!


I will check, but I am pretty sure we are quering all the tanks every scan.

Click to expand...

I thinkt that this leads to error. You should make new query (request) only if previous query is done or error.

(Usually there is some time pulsing on reguest input.)


If you query new request before previous answer from slave, you get busy error from block (8200).


1200 have 8 (it depends of CPU type, so check manual) open TCP connection resources, so you can't have more that that querys enables simultanously. All over that is abonded before sending and you get error. (Connection resources are showed under CPU properties)




https://support.industry.siemens.co...tions-of-modbus-tcp/189626?page=0&pageSize=10




Also look this thread and post 31 by ASF.



http://www.plctalk.net/qanda/showthread.php?t=93134&page=3

The IO Device errors refers to some problem in the Profinet system.
That the Modbus data transfer is faulted may possibly not mean that cause has to do with the Modbus data, but there is a common cause affecting both Profinet and Modbus.

How is the system physically connected ?
Is there a switch or switches in the system ? If so which types ? Only Profinet rated switches prioritizes the Profinet data. Inexpensive unmanaged switches are easily overwhelmed.

You can either use Profinet rated switches, or you can connect the system by daisychaining so that non-Profinet data does not pass via the Profinet data.
I.e.:
HMI-PC -- Mettler Toledo Scale -- S7 CPU -- IM155-6 -- IM155-6 -- IM155-6 etc.

If the Profinet IO Errors persists, then you can try to setup the Profinet system by topology. The advantage is that it will give you better diagnostics, possibly telling you exactly which port or which cable is affected.

Dont know if S7-1200 actually supports Profinet Topology. Would like to know.