-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] - 1756-EWEB issue #282
Comments
Oh, it appears when I ran my test to get the output to post here that it simply did not connect this time. |
OK, I see my confusion. Let's just start over: 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: 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 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, 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
The text was updated successfully, but these errors were encountered: