Unknow error 275 using RTA Automation 515RTAENI

[bachphi]

Glad it's working for you!

[Archie]

Thank you very much Archie!! I tested it with a basic label reading a string and reading a bit, so far so good! Let me check with writes and will report back.

That patch removed the route path which is normally used on ControlLogix platforms. The Micrologix controllers and the ENI module would ignore it since it doesn't mean anything, but apparently the RTA module must try to process it.

Just and FYI, if you are only using AdvancedHMI, you can use a generic Ethernet to serial server as long as it passes the raw data back and forth, then use the SerialDf1OverTCP driver. Those devices are typically about $50USD which I am sure is much cheaper than the RTA or ENI modules.

[bachphi]

Cool info, Archie.
speaking about cost, why did you not replace it with ML1400, it cost a couple hundred dollars which is far less than RTAENI and give you more capability.

[Noe]

Cool info, Archie.
speaking about cost, why did you not replace it with ML1400, it cost a couple hundred dollars which is far less than RTAENI and give you more capability.

Bachpi, I remember I checked this a some months ago (this is a really big project with more than 14 different machines and only this one has a ML1500) and what I remember is that ML1400 expansion I/O modules are not compatible with ML1500. And we 6 of them, between digital and analog.

[Noe]

Thank you very much Archie!! I tested it with a basic label reading a string and reading a bit, so far so good! Let me check with writes and will report back.

That patch removed the route path which is normally used on ControlLogix platforms. The Micrologix controllers and the ENI module would ignore it since it doesn't mean anything, but apparently the RTA module must try to process it.

Just and FYI, if you are only using AdvancedHMI, you can use a generic Ethernet to serial server as long as it passes the raw data back and forth, then use the SerialDf1OverTCP driver. Those devices are typically about $50USD which I am sure is much cheaper than the RTA or ENI modules.

Archie, I was doing some more tests (writing to a string), I made a change in the project in VB to add a keyboradinput control then started it in debug mode, and now I was not able to read or write anything. The basic label shows the error "unknown code 275". I tried several times and same result. After some time started to communicate again. I kept running my test app, is just an empty project with a basic label and after some time looses connection with PLC for a couple of senconds (connection timeout) and then re-enables by itself.

I attached a couple of wireshark capture, one for the "unknow code 275" and other for the comm loss during the runtime execution.

[Phrog30]

(this is a really big project with more than 14 different machines and only this one has a ML1500)

Even better reason to upgrade.  Now you have an odd ball.  Standardization to me is really important.

[Noe]

(this is a really big project with more than 14 different machines and only this one has a ML1500)

Even better reason to upgrade.  Now you have an odd ball.  Standardization to me is really important.

We have in this network basically 12 Siemens PLC's 1200 and 1500's. All are new machines, just two are previously existen machines that one has a 1400ML and this one with the RTA-ENI has the ML1500. Production  volume does not allow to stop more than a day.

[Archie]

Archie, I was doing some more tests (writing to a string), I made a change in the project in VB to add a keyboradinput control then started it in debug mode, and now I was not able to read or write anything. The basic label shows the error "unknown code 275". I tried several times and same result. After some time started to communicate again. I kept running my test app, is just an empty project with a basic label and after some time looses connection with PLC for a couple of senconds (connection timeout) and then re-enables by itself.

I attached a couple of wireshark capture, one for the "unknow code 275" and other for the comm loss during the runtime execution.

The capture with the code 275 is caused by being out of connections. In an AdvancedHMI application it is important to "dispose" all form before closing the application because this is what tells the driver to properly close the connections. Otherwise the connection are consumed until timed out which is typically about 15 seconds. The ENI module has a known issue in which it will not timeout and close an improperly closed connection, therefore needs to have the power cycled.


If you look at the code behind the MainMenu you will see the proper way to ensure all forms are closed.

[Archie]

Archie, I was doing some more tests (writing to a string), I made a change in the project in VB to add a keyboradinput control then started it in debug mode, and now I was not able to read or write anything. The basic label shows the error "unknown code 275". I tried several times and same result. After some time started to communicate again. I kept running my test app, is just an empty project with a basic label and after some time looses connection with PLC for a couple of senconds (connection timeout) and then re-enables by itself.

I attached a couple of wireshark capture, one for the "unknow code 275" and other for the comm loss during the runtime execution.

In the ComLost capture, I see at 6 seconds, the communications abruptly stop, then at 26 seconds it reconnects without a proper closing. Did anything happen at 6 seconds after starting the Wireshark capture such as closing the app or opening another form?

[Noe]

Archie, I was doing some more tests (writing to a string), I made a change in the project in VB to add a keyboradinput control then started it in debug mode, and now I was not able to read or write anything. The basic label shows the error "unknown code 275". I tried several times and same result. After some time started to communicate again. I kept running my test app, is just an empty project with a basic label and after some time looses connection with PLC for a couple of senconds (connection timeout) and then re-enables by itself.

I attached a couple of wireshark capture, one for the "unknow code 275" and other for the comm loss during the runtime execution.

In the ComLost capture, I see at 6 seconds, the communications abruptly stop, then at 26 seconds it reconnects without a proper closing. Did anything happen at 6 seconds after starting the Wireshark capture such as closing the app or opening another form?

Not really, I left the application running and did not touch anything wire capturing.

[Noe]

Archie, I was doing some more tests (writing to a string), I made a change in the project in VB to add a keyboradinput control then started it in debug mode, and now I was not able to read or write anything. The basic label shows the error "unknown code 275". I tried several times and same result. After some time started to communicate again. I kept running my test app, is just an empty project with a basic label and after some time looses connection with PLC for a couple of senconds (connection timeout) and then re-enables by itself.

I attached a couple of wireshark capture, one for the "unknow code 275" and other for the comm loss during the runtime execution.

The capture with the code 275 is caused by being out of connections. In an AdvancedHMI application it is important to "dispose" all form before closing the application because this is what tells the driver to properly close the connections. Otherwise the connection are consumed until timed out which is typically about 15 seconds. The ENI module has a known issue in which it will not timeout and close an improperly closed connection, therefore needs to have the power cycled.


If you look at the code behind the MainMenu you will see the proper way to ensure all forms are closed.

Great information, something else to care about.

[Archie]

Not really, I left the application running and did not touch anything wire capturing.

This is just an application with a single BasicLabel?

[Archie]

In your ComLost capture, look at Packet number 53. The time stamp is 6.53s. The next packet 54 has a timestamp of 18.16s. There is a very unusual 12 second pause of communications, which is basically unheard of in Windows unless the network connection is dropped. Then look at the next 100 packets and you will see typical packets that occur when a PC boots up or a network connection is first plugged in. From this I would conclude the network dropped for about 12 seconds.

[Noe]

Not really, I left the application running and did not touch anything wire capturing.

This is just an application with a single BasicLabel?

Yes

[Noe]

In your ComLost capture, look at Packet number 53. The time stamp is 6.53s. The next packet 54 has a timestamp of 18.16s. There is a very unusual 12 second pause of communications, which is basically unheard of in Windows unless the network connection is dropped. Then look at the next 100 packets and you will see typical packets that occur when a PC boots up or a network connection is first plugged in. From this I would conclude the network dropped for about 12 seconds.

I am in front of the machine once again, let do more test and see what is happening. I will check if by any chance the connection drops.