Unable to Read from Allen-Bradley 1756-L73 A ControlLogix PLC about libplctag HOT 10 CLOSED

Hi,

Can you please share your inputs on above mentioned issue.
I am blocked due to this problem.
Thanks

from libplctag.

Newer PLCs, and Ethernet modules, support the newer extended Forward Open. Older ones do not. This is how the library finds out what it can do when talking with the PLC. It will try the extended version first and if that fails with an unsupported error, it will fall back to trying the older version.

I have not seen the TCP retries like that though. Can you capture log output with log level 4? I need to see what the library is doing here. Thanks for bringing this up.

from libplctag.

Hello Kyle,

Thanks for responding.
I have tried to run simple.c from the example, below logs captured with log level 4.
Find find the attached text file for your reference.
LogOutputWithDebugLevel4.txt

from libplctag.

Thanks for the logs. Here is what I see the library doing:

• it sends the ForwardOpenEx.
• it receives an Unsupported service error from the PLC or network module.
• it sends an old-style ForwardOpen.
• it waits for a response.
• and waits...
• and waits...

What kind of network module are you using for these communications? Is there any firmware upgrade you can apply? I have L55, L61 and L81 CPUs with a few different network modules. The L81 has a built in module. I have never seen this behavior.

I am going to call this a bug as the library should be able to handle this. From your Wireshark dump, it looks like the PLC/module drops the TCP connection after sending the Unsupported error. However, it drops it in a way that almost looks like the network module is crashing. The TCP connection is not closed by the network module. It simply disappears. The packets after that are from the PC/library's TCP stack trying to contact the PLC.

from libplctag.

Hi Kyle,

Thanks for the detailed explanation.
I have tried to collect information which is requested by you.
The CPU and network module which is used during the test is as below :

CPU : Logix5573 (CAT 1756-L73)
CPU Firmware Version : 34.01
Network Module : 1756-ENBT
Network Module Firmware Version : 6.006

Sorry for the late response.
Please let me know if you need any other details.
Thanks

from libplctag.

This might take a little longer than I thought. I thought it would be fairly straightforward to change the state machine here, but it looks like I did not follow good coding practices and have logic smeared across multiple states.

from libplctag.

This is still in progress. I am really getting confused by this. None of my PLCs do this. I have a PLC/5, a MicroLogix 1100 and some ControlLogix including ENBT modules and a L81 with built-in Ethernet.

from libplctag.

I still do not have a good answer for this. I have had others do some testing and no one can recreate this problem. However, I do not know of anyone with your exact combination of hardware and firmware versions.

I think one way to fix this is to add an attribute that suppresses use of the extended ForwardOpen command. You would put that into your tag string. I will update this when I have an idea what this will look like.

from libplctag.

I am removing the critical label as no one else seems to have this issue. It is still a bug!

from libplctag.

I added a new attribute conn_only_use_old_forward_open. If you set it to 1 in your tag string, it will prevent the library from using the new extended ForwardOpen command.

protocol=ab-eip&gateway=10.1.2.3&path=1,0&plc=logix&conn_only_use_old_forward_open=1&name=TestBigSINTArray[0]

This will be out in the next release. Probably v2.5.7.

from libplctag.