CIP Generic MSG - Powerflex 525

Hi All -



I am trying to communicate between a Micrologix 1100 and a Powerflex 525 via CIP MSG. There is a great Knowledgebase and TechNote download on the subject. I did it and it worked just fine. The note number is 721115


I am having some trouble understanding the "scatter" reads and writes. How does the controller/drive know which parameters you are looking for? For instance the scatter read looks at parameters b003-b007. How does it know to look at those parameters and not others? If I wanted to look at parameter b006-b020 what would I change? It know that it must be staring me in the face but I just don't see it. Maybe it is an advanced programming thing that I don't understand?


Any help would be greatly appreciated.
Chuck

Hi,

It is staring you in the face!
But that technote can make for confusing reading?

When you use "Custom" service "32", the MSG instruction configuration options change to allow you to enter both Send & Receive addressing for a Scattered Read. Here, the Send addressing is used to send the parameter numbers to the drive for the values the user wishes to read. You manually enter these parameter numbers into your Send addresses (every 2nd word as per example). The MSG then reads the values from these specific parameters in the drive into the assigned Receive addresses in the controller. The Receive addressing will populate the parameter numbers in a similar sequence to the manual sequence you use in the Send addressing (every 2nd word). The values of the parameters to be read are stored in every other word address.

Likewise, when you use "Custom" service "34", the MSG instruction configuration options change to allow you to enter both Send & Receive addressing for a Scattered Write. The difference here is the Send addressing is used to send both the parameters to be written to, and the values to be written. Similarly, the 1st address is the parameter number and the following word is the value to be written. The Receive addressing is used for confirmation. The parameter numbers to be written to are automatically populated in the Receive addressing in a similar sequence to the Send addressing. Each following word represents the reply from the write command. This will be either a 0 or a 1. A value of 0 means the write was successful. A value of 1 means there was some error.

However many parameters there are between b006-b020, you require double that number of words in both your Send and Receive addressing. That is assuming all those parameters are 16-bit values.

Example:
There are 15 x 16-bit parameters to read
You create/assign Send Data File N10 with 30 elements (words N10:0 - N10:29)

Send:
N10:0 = 6 (user assigned value representing param b006)
N10:1 = 0 (leave blank)
N10:2 = 7 (user assigned value representing param b007)
N10:3 = 0 (leave blank)
...and so on up to...
N10:28 = 20 (user assigned value representing param b020)
N10:29 = 0 (leave blank)

You create/assign Receive Data File N11 with 30 elements (words N11:0 - N11:20)

Read:
N11:0 = 6 (MSG assigned value representing param b006)
N11:1 = 5 (param b006 value read from drive)
N11:2 = 7 (MSG assigned value representing param b007)
N11:3 = 10 (param b007 value read from drive)
...and so on up...
N11:28 = 20 (MSG assigned value representing param b020)
N11:29 = 3 (param b020 value read from drive)

The size in bytes you enter for Send and Receive will be double the number of words (1 byte = 1/2 word).

If you are following the example, then the parameter numbers for the scattered Read are assigned in the Send N13 Data File in every 2nd word address. Note though that there are only 10 elements available. If attempting to read more parameters than the example 5, then you can increase the number of elements for the Data File while changing the parameter numbers to suit. You must likewise increase the number of elements in the Receive Data File to match but do not need to edit any values in this Data File.

The "skipping" of the addresses for the parameter numbers, leaving every other address at 0, is the tricky, or possibly confusing part here. So I advise you to pay close attention to that aspect of the configuration.

capisce?

Regards,
George

Thank you so much. I will experiment with it in the AM.


My next question is...how did you know that?? Is it written in a book somewhere? My knowledge is slim but I would love to learn. If you know of a source (book, website, etc.) that would explain the intricacies of messaging and/or other advanced programming techniques please let me know.


Thanks again!

As I said, it's staring you in the face!

But joking aside, it is all explained in the technote you referenced above. The only thing I tried to draw your attention further to is the fact that when you change the "Service" to "Custom" both the Send and Receive fields become active. Having both fields available for a scattered MSG is the key here. For a more commonly used CIP Generic "Get Attribute Single", only Receive is active, and for a commonly used "Set Attribute Single", only Send is active. i.e. Custom Service Codes "32" & "34" are special in that they give us "open" access to the DPI Parameter Object (vendor-specific Class ID 93) in the drive so we can pick and choose which parameters we want to perform scattered MSGs on.

Normally, say for Service: Get Attribute Single, we will see that the Service Code is predefined as "E" and cannot be changed. Using this Service Code, we must specify the Parameter Instance (number) and the Attribute (value) to be accessed.

Se we have...

Service: Generic Get Attribute Single (read specified attribute)
Service Code: E (code to invoke Get_Attribute_Single)
Class: 93 (specific to Drive Peripheral Interface (DPI) Parameter Object Class)
Instance: 2 (specific Parameter Object to read - d002)
Attribute: 9 (read "value" attribute for the specified Parameter Object)

Similar for a single parameter write (Set Attribute Single) we must specify down to the Attribute or value we want to write to.

But for Custom Service 32 and 34, we only specify the Class 93 DPI Parameter Object, but leave the Parameter Instance (number) and Parameter Attribute (value) fields at "0" within the MSG configuration. We then use the user-defined addresses (N Data Files) to instruct the Custom Services for the MSG which parameters/values we want to read or write.

Are you more new to RSLogix 500 messaging in general, but you are OK with the CIP Object oriented protocol, or are you new to both? They are two very different topics within the automation industry, which just happen to meet up here to do "business". CIP Explicit Messaging would be considered a more "advanced" method of messaging for RSLogix 500 controllers. It was only introduced at RSLogix 500 v7.20. Prior to that we only had the older PCCC N-File method or Modbus protocol.

If not familiar with RSLogix 500 messaging in general then I'd advise you to read here for starters (Chapter 21 - Communications Instructions - Page 341)...

1763-RM001D-EN-P MicroLogix 1100 - Instruction Set Reference Manual

That Chapter is about 85 pages long. There is a lot of details in there, but just take your time and ask here if you have any questions.

If unfamiliar with CIP (Common Industrial Protocol), then have a read here...

The Common Industrial Protocol (CIP™)

It's an industry-wide Standard and is not specific to AB/Rockwell, although widely developed and implemented throughout their CIP communications portfolio. One particular publication on the subject is an excellent resource, I've found, and was written by ex Rockwell Automation Engineering Manager, Viktor Schiffer. He's been involved in and around CIP nearly as long as I can remember and would be considered a Global Expert in his field...

The Common Industrial Protocol (CIP™) and the Family of CIP Networks

Lots of "light" reading material to be had on these subjects. Unless you're "YOYO", I'd advise you to just dip in and out as there is a lot to digest.

Regards,
George