search

ottowayi / pycomm3

A Python Ethernet/IP library for communicating with Allen-Bradley PLCs.
MIT License
377 stars 88 forks source link

CIPDriver Insufficient Packet Space #285

Open Afropick07 opened 1 year ago

Afropick07 commented 1 year ago

I'm getting an error: ERROR:pycomm3.cip_driver.CIPDriver:Generic message '_read_template(instance_id=519, object_definition_size=1466)' failed: Insufficient Packet Space

Can't find any mention of "Insufficient Packet Space" anywhere. Can you guide me to where I should look?

baja2k9 commented 1 year ago

same issue here:

ERROR:pycomm3.cip_driver.CIPDriver:Generic message '_read_template(instance_id=4089, object_definition_size=6408)' failed: Insufficient Packet Space

But the read command did get me the data.

ottowayi commented 1 year ago

Unfortunately there is not enough info here for me to help yet. The instance ids are determined when the program is compiled, so there isn't any way for me to know what it is failing to read just by the id number. Can you post a log (the verbose level is most helpful). Or email one to pycomm3@ottoway.dev if not comfortable posting it publicly. Also, what platform (controllogix, etc) and firmware are you seeing this happen on?

mlecours commented 9 months ago

Hello, I noticed the same behaviour (Insufficient Packet Space) and I have sniffed the packets with wireshark to figure it out. It seems that the headers (service, request path size and request path) are sent twice and in wireshark, the packet is flagged as "malformed". Captured data from wireshark in hex: Top line: pycomm Bottom line: existing software image

nunchuckBoP commented 8 months ago

Same issue here. It doesn't affect data transfer when I read and write tags, only when I try to get the complete list of controller tags. MicrosoftTeams-image

ccscpanici commented 8 months ago

@ottowayi, I just sent you an email with my controller information and my log. Please let me know if this can be fixed, or maybe it's not "really" an issue?

ottowayi commented 8 months ago

Is anyone actually having an issue with the driver not working? or just that these ERROR logs are showing? If it's just the ERROR logs, I think that is just a mistake in the logging level on my part. Responses that don't fit in a single packet use that error code to indicate that you need to issue more requests to get the complete response. So, not really an error, but it's being logged as one.

@mlecours do you have more of that packet capture available? I don't see any duplications of the header in my testing, but I think it could come from using the multi-service request which does multiple individual service calls in a single message.

I can change the level to be DEBUG for this and add in the offset so that it's more clear that it's taking multiple requests to get all of the data: image