1734-aent-c Error 16#0203

[LuisGonzalez 0]

I'm having troubles with a 1734-AENT-C module, I'm new in the company and last week me started to have this communication issue with this module, communication between the module and PLC began to fail and in RSLOGIX apears 16#0203 (Connection timed out), but this code appear and disappears, the connection is stablished for a few seconds and then it returns the same error, I have a little experience in PLC's, I don't know what could be happening, can someone help me with this issue?

[pturmel 106]

That's a basic network failure between the PLC and the module.  Sometimes that's faulty switches, or power problems on a switch or on that device.  Can also be marginal cables.  Consider putting a power monitor on the adapter.  Consider also doing a packet capture on each end of the connection, preferably simultaneously, to see if packets are being dropped.

[LuisGonzalez 0]

I talk to the IT department, they did everything but it seems there is no problem in the network

[pturmel 106]

Then assume it is a hardware problem and replace the adapter.  But without a detailed explanation from IT as to what they checked and how they checked it, I'm skeptical of their assurance.

[dumdum 1]

Go to the web interface of the module and post pictures of the diagnostic page. It would help troubleshooting. 

[BobLfoot 272]

On 2/16/2023 at 1:51 PM, LuisGonzalez said:

I'm having troubles with a 1734-AENT-C module, I'm new in the company and last week me started to have this communication issue with this module, communication between the module and PLC began to fail and in RSLOGIX apears 16#0203 (Connection timed out), but this code appear and disappears, the connection is stablished for a few seconds and then it returns the same error, I have a little experience in PLC's, I don't know what could be happening, can someone help me with this issue?

Since the problem started last week.  1-How long was it running before the problem occurred?  2-What changed in the subnet of the module in the last two weeks?

[LuisGonzalez 0]

Excuse me if I did not explain myself correctly, I am new to this whole world of automation, we are a water treatment company, in one of the water storage towers we have a pressure sensor with which we monitor the water level of the tower, it is It communicates by radio frequency antennas with the main plant where the PLC that receives the sensor signal is located. Last Sunday we had one. The values that we began to receive went to zero in fractions of seconds, then we had the correct reading, preceded review the PLC data and I saw that this fluctuation was there, I went to the tower and proceeded to check the sensor but everything was correct there were no voltage or current drops, but I realized that the 1734-aent-c module was blinking on red (point bus status and network status), IT connected to the router that is in the tower and pinged the module which responded to all with minimal losses, from the same router it pinged the PLC and there was still minimal losses of a large number of pings that were made so it cannot be some communication, I attach the screenshots of the RsLogix diagnostics.

https://files.fm/u/r3s7tzwy5

Edited 20 February by LuisGonzalez

[pturmel 106]

13 hours ago, LuisGonzalez said:

there was still minimal losses

There should be zero losses.  WiFi is really hard on most PLC comms protocols.  Most likely, some other wifi device has been installed and interfering with the older one.  Or there is some radio interference on some nearby device that is interfering.  You should eliminate WiFi from the data path if this signal really matters to you.

Consider lengthening the RPI if you do not need super fast updates.  That can help EtherNet/IP ride through interference.

[LuisGonzalez 0]

Yesterday I change the RPI of the 1734-AENT/C, and the problem seems to be solved, does anybody knows why this fixed the error?

[BobLfoot 272]

Page 86 of this manual -https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm094_-en-p.pdf should give you a good start to understanding RPI.

To have a chance at fully explaining we'd need to know your OLD RPI and your NEW RPI.

[LuisGonzalez 0]

43 minutes ago, BobLfoot said:

Page 86 of this manual -https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm094_-en-p.pdf should give you a good start to understanding RPI.

To have a chance at fully explaining we'd need to know your OLD RPI and your NEW RPI.

Thank you very much.

 

My las RPI was 30 and I changed it to 750.

[BobLfoot 272]

3 hours ago, LuisGonzalez said:

Thank you very much.

 

My las RPI was 30 and I changed it to 750.

So my basic reading of the manual @pturmel will correct me. 

Means your before RPI was actually 16 ms {rule of 2s} and after was 512 ms.

So before you were sending 62.5 level readings per second over the wifi after your sending 2 level readings per second over the wifi.

1/30 of the wifi traffic so a much more stable system.

[pturmel 106]

2 hours ago, BobLfoot said:

Means your before RPI was actually 16 ms {rule of 2s} and after was 512 ms.

Well, no.  (RPI is expressed in microseconds on the wire--Rockwell rounds to the nearest 100 microseconds, with a 1 millisecond minimum.  I'm pretty sure that power of two stuff is out of date.)

30ms RPI is a packet in each direction every 30ms.  750ms RPI yields a packet in each direction every 750ms.

The key is that Rockwell products select 4x RPI as the connection loss timeout.  Upon timeout, a Rockwell product waits five seconds before attempting reconnection.

A 30ms RPI on a flaky or busy WiFi is very likely to drop four data packets in a row.  Flaky WiFi is unlikely to drop four in a row when 750ms apart.