Open tlf30 opened 1 year ago
Oh, it appears when I ran my test to get the output to post here that it simply did not connect this time. I will get an updated output and capture, one minute.
OK, I see my confusion. I am using pycomm3 to verify the results I am seeing with a java cip library.
Let's just start over: My original issue was as described, and I thought I had replicated the behavior in pycomm3. I no longer think I was able to replicate the behavior though. Pycomm3 fails to make the forward open connection all together (as shown in the output above).
I expected (and was attempting to verify if this behavior is correct) the failure to close the forward open connection that I am seeing in this PCAP: eweb_failure_to_close.zip
For pycomm3, perhaps the difference is that it is trying to make a large forward open first, but in the java library I am using I explicitly specified to not use large connections. Other than that, I'm not sure why it would fail to connect all together, especially since pycomm3 fails back to a normal connection but still cannot connect.
I thin you may be right with attempting the large one first causing the issue. I've seen some weird bugs in these really old modules, specifically certain firmwares on ENET and ENBT modules straight up not supporting required protocol features. It's also possible that the connection parameters for the forward open are causing the problem too. First I would try skipping the large forward open by adding driver._cfg['extended forward open'] = False
before calling generic_message
and see if that succeeds. If not, we'll have to compare the connection params between your other library and this one to see what the differences are.
edit: another option would be trying without the forward open. e.g.:
with CIPDriver('192.168.1.12') as driver:
resp = driver.generic_message(
service=Services.get_attribute_single,
class_code=ClassCode.identity_object,
instance=1,
attribute=7,
route_path='1/8'
connected=False,
unconnected_send=True,
data_type=SHORT_STRING,
)
print(f'... Got: {resp.value if resp else "EMPTY"}')
Thanks, I'll play with it some more. I has some attempts a few weeks ago at modifying the config and setting the extend forward open to false, but it kept getting set back. But I will give it another go, maybe I overlooked something.
It may be handy in the future to be able to explicitly set the connection size, and if the connection size is 500 or less not use the large connection.
Pre-checks
Description Hello, I am thinking this is an issue in the 1756-EWEB firmware, but wanted to confirm. When opening a forward open connection to an 1756-EWEB, then to the backplane, then back to itself, it fails to close the forward open connection.
This is the easiest situation to replicate this, I have found others, but they are more difficult to replicate. All situations I have found are through the 1756-EWEB and it not closing the forward open connection. My other ethernet modules ENET and ENBT work fine in these situations.
Target PLC Model: [e.g. 1756-EWEB] Firmware Revision: 5.1 Other Devices in CIP Path: N/A
Code Sample Minimal reproduceable code sample
Additional context See attached pcap. eweb.zip