Generic, Assembly Instance write format

[czmorris]

I have an EIP device that I am having trouble writing back to via generic message. Reading is working fine with assembly instance 100 On each attempt to write with the correct number of bytes I am seeing "Too Much Data" service error.

I know that my device expects exactly 36 bytes at assembly instance 150 Interesting enough I only see the error "too much data" if I send exactly 36 bytes or more. If I send 35 or less I get "insufficient command data"

below is what the generic message code looks like.

`
driver = CIPDriver(path) driver.open()

vb = b"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
print(len(vb))
    
msg = driver.generic_message(
    service=b"\x10", #0x10
    class_code=0x04,
    instance=0x96,
    attribute=0x03,
    data_type=BYTE[36],
    connected=False,
    request_data=vb)


print(msg)

` Any ideas what I could be doing wrong? Or if something else is going on?

Added an image of the MSG config from a MicroLogix 1400 for reference.

[czmorris]

I was able to get it "working" with one oddity. I always get a "Failed to parse reply -"

I had to change the connected= to True. Before doing that it was sending 38 bytes instead of 36. (Observed with WireShark). I wound up using the following logic to get it working:

`

test = UINT[18].encode(values)
print(len(test))
print(test)   
    
msg = driver.generic_message(
    service=0x10,
    class_code=0x04,
    instance=0x96,
    attribute=0x03,
    data_type=UINT[18],
    connected=True,
    request_data=test,
    name='HMS_Write')

print(msg)

`

[ottowayi]

I have seen some devices that certain services only work with connected messages, but I'm not sure if this is a case of that. Unfortunately, without more details I'm not sure I can tell you exactly what was going on. Those extra bytes may be related to it being unconnected and a Micro800, but I haven't seen a bug with that before. What is your CIP path? with unconnected messages, you have to get the route_path and unconnected_send options right or it may not send it where you think. If it's just a direct connection (only ip address), then probably not the issue, but if you're behind a backplane it could be related.

[czmorris]

In this case the device is an HMS Anybus Communicator. Programmable network interface adapter. The path is just the IP Address.

It's working well for my purposes now. It just didn't make sense to me why pycomm3 would be sending 38 instead of 36.

Not sure if I should close this out or leave open as a possible bug?

[ottowayi]

it's possible this is a bug, leaving the issue open is fine with me. I haven't had much time to look into it, so leaving it open will help remind me to come back to it

[aawilliams85]

I was seeing a similar behavior with messages configured for "connected=False" until I also added the option "route_path=None". That allowed me to keep my messages configured as unconnected while writing the correct length!

I don't know if that is the expected behavior or not but from what I was seeing in the source code, it seemed like the route_path was being appended to the end of the packet, so I'm guessing somewhere it is getting set to 0x00 instead of None.