KyleH

MrPLC Member
  • Content count

    4
  • Joined

  • Last visited

Everything posted by KyleH

  1. I have an open source library for Ethernet/IP and Modbus PLC communications.   It also support PCCC-type PLCs like PLC-5, SLC and MicroLogix via encapsulation in CIP/EIP (Ethernet/IP).   I just had a user let me know that they have a PLC-5/80 that apparently never got fully updated to support Ethernet/IP.   It appears to only support CSP (port 2222).  I have most of the code already, so I want to support CSP. I have a converted PLC-5/30 with a 1785 sidecar.   It shows open ports on port 2222 and 44818, but if I connect to port 2222 using Ron Gage's code, it immediately closes the connection.   I read somewhere (here? I think it was a comment from Ken Roach) that this was used to tell RSLinx to try the other protocol. I want to use some sort of PLC that "speaks" CSP in order to write up support for it in my library.   Is that something that I can do with my old PLC-5?  I looked around in RSLogix 5 to see if there was something obvious to re-enable CSP on my PLC-5 but I could not find anything.   Anyone have any pointers?  I might think about going on eBay to find some old hardware, but how could I even tell if something supports CSP?   Even a simulator would be fine.
  2. I think BobLfoot is on the right track.   You have the MSP packet overhead (the command header and the sub-packet offset list).  Then each sub-packet has its own CIP header.   Exactly how the overhead is calculated is something of a mystery to me.   I add some fudge factors based on experience.  I created a tag that was big enough to fill the entire packet (1000 DINT), and then did a read to see what I got back.  The I counted backward 4002 bytes to see where that lands in the protocol layers.
  3. Bad form replying to myself, but there is also a limit due to ControlNet.   When you use UCMM (unconnected messaging) you get a ~500 byte packet size too.   That is because the largest size you can route through ControlNet (so I understand) is about that.   If you set up a connection with some variation of ForwardOpen, then you negotiate the packet size across all hops of your route. So I am not sure which one of these applies.   Using UDP packets larger than ~500 bytes is a bad idea as many networks will mangle them (fragmentation occurs and then if you lose one of the fragments...).
  4. Sorry for the late post, I just joined. There are two types of connections: explicit MSG-type and implicit IO-type.   If you use IO or produced/consumed tags you get the IO-type.  My guess is that the remote slave sync is done the same way.  Those are sent via UDP and appear to be restricted to the UDP maximum non-fragmentable size (576 bytes IP minimum - overhead, in practice about 500 bytes of payload).  That's where the 125 DINT (4 bytes per DINT x 125 = 500 bytes) limit comes from.  If you send explicit messages and you have negotiated a connection (forward open or large forward open) you can negotiate up to ~4000 bytes (4002 in my experience).  Those are generally sent via TCP which layers on a completely different set of packet size restrictions. It seems like the underlying mechanism to transfer your data for mapping might be UDP.  There does not seem to be anything inherent in the Large Forward Open command to limit it to TCP but I have never tried to set up that type of connection in my AB comms library. Using implicit IO has proven to be a huge benefit for some projects I've been on, but the size limitations are a pain.