Multiple 'Execute PCCC' requests in one TCP packet

Hi guys,

The last time I posted something, I got severely told off for not giving a full background as to what I wanted to know and what I was trying to achieve. It was an honest mistake on my part which I apologised for, but I got a rough ride, including one reply containing a 3-letter acronym containing a swear word, which I thought was against the ethos of the forum.

Nevertheless, I'm going to ask another question, in the hope that I'll phrase it correctly, and won't give responders too much work to do -- I accept you are busy people.

So here goes....

I have been sending Execute PCCC requests to both an SLC/5-05 and an ML/1400 over Ethernet.

The screenshot attached shows an example of Wireshark whilst working with the ML/1400. The top line of capture (in a darker blue) shows one TCP request packet of 399 bytes containing multiple (5, to be precise) Execute PCCC payloads.

If you then cast your eye to the bottom of the screenshot, you will see the 5 matching return arrows in the No. column.

In other words, the ML/1400 clearly has the capability of splitting the entire 399-byte incoming TCP packet into its 5 constituent Execute PCCC request payloads, and is able to send a response for each one.

On the other hand, if I send a similar TCP packet to the SLC-5/05 (i.e. containing five Execute PCCC payloads), it only picks out #5 in the series of Execute PCCC payloads, responds to it, but ignores #1 to #4 inclusive.

The command data I'm sending to both PLCs is EXACTLY the same.
Is this a restriction of an SLC-5/05 compared to the ML1400 ? Is there a way of changing that behaviour ?

Thank you

You definitely ask some interesting questions !

Are you certain that each of the PCCC commands in the packed five has a different TNS ? I know that the SLC has a setting for "duplicate packet detect" on the serial port but I don't think it applies to the Ethernet port.

In the SLC-5/05's Controller Status window, go to the Channel 1 tab and examine the value of S:2/15 "Comms Servicing Selection".

When that = 1 (the default) the SLC-5/05 will only process one PCCC command from the network port per PLC scan (or SVC instruction in the program). When that bit =0, it will service all the messages it receives during the PLC user program scan, before starting to solve the PLC user program again.

In the MicroLogix, you will find the "Comms Servicing Selection" and the "MSG Servicing Selection" for all three comms channels in checkboxes on the Comms Configuration window.

The MicroLogix 1100 and 1400 operating systems were a fresh-sheet design; they are completely different hardware than the SLCs and even the older MicroLogix, designed and coded by a different development division. They don't support the old CSPv4 Ethernet protcol at all, while the SLC-5/05 is a "dual stack" machine.

So it's entirely possible that the MicroLogix 1400 responds to packed PCCC Execute commands differently than the SLC-5/05 does.

There are also settings in RSLinx to limit the number of simultaneous CIP Connection (Communications -> Configure CIP Options). But I don't think that would affect the comms you show here, since you're not running RSLinx.

Ken,

Appreciate the reply. In answer:

Ken Roach said:

Are you certain that each of the PCCC commands in the packed five has a different TNS ? I know that the SLC has a setting for "duplicate packet detect" on the serial port but I don't think it applies to the Ethernet port.

In the SLC-5/05's Controller Status window, go to the Channel 1 tab and examine the value of S:2/15 "Comms Servicing Selection".

When that = 1 (the default) the SLC-5/05 will only process one PCCC command from the network port per PLC scan (or SVC instruction in the program). When that bit =0, it will service all the messages it receives during the PLC user program scan, before starting to solve the PLC user program again.

Click to expand...

(a) The TNS instances are all definitely unique

(b) S:2/15 was, in fact, the default of '1'. I changed it to '0' and also checked that S:33/7 was '0' as well. I downloaded, then tried my driver again, but still no splitting out of any multi-segmented TCP packets. Oh well, worth a try...

One last thing. I'm working from home right now, but TeamViewer'ed into Logix 500 for that SLC. I noticed that the Channel 1 Ethernet config was showing 'No Auto-Negotiate' and '10 Mbps Half Duplex' which would clearly slow things down compared to our other test PLC equipment. Someone has very recently informed me that we may have an earlier SLC that only supports this limited Ethernet config, but just before I knew that, I took the SLC offline, ticked Ethernet Auto-Negotiate, and added Channel 1 diagnostics via a new data file N77 -- then managed to corrupt NVRAM when I hit 'download' with my amended program.....

So for my sins I'll have to ride to the office tomorrow to attach a serial cable and download a clean program. When I'm there, I'll check the firmware version on the product sticker to confirm its Ethernet capabilities.


Thanks for everything.

Cpu frn

Ken,

Just by way of confirmation, I got the SLC going again and, in so doing, discovered that it's CPU is 501 Series C and, specifically, FRN 6. The SLC manual does have a note somewhere that for anything less than FRN 9, we are stuck with an Ethernet that cannot auto-negotiate and is limited to 10 Mbps Half-Duplex. In addition, there's no 10/100 sticker against the Ethernet port. I think I've got conclusive evidence now, therefore, that this SLC Ethernet port ain't gonna go any faster !

Thanks.