CIP Message Reference?

Is there a handy how-to guide for configuring a generic CIP message (specifically for RSLogix5000, version 13)? The CIP message itself seems to be a powerful tool for getting a lot of dirty work done. But, there doesn't seem to be any kind of user's guide.

If only there were a table somewhere to explain the various message types and parameters, I have a feeling that users like myself could do some really cool things (or cause lots of damage).

I started on this quest because I found out that my SRM modules have a system clock which is DIFFERENT from the CPU clock. It sure would be nice to synchronize them so the log files make sense. There's a document on the AB site explaining how to synchronize the module using a CIP message, but it doesn't work for me. I'm guessing that the document is missing a key piece of information, like how to actually package the date/time data, or it doesn't apply for the latest version of the module firmware.

While researching this, I found a whole bunch of other uses for the generic CIP message. Again, I tried a few with mixed results.

Does anyone have any tips?

You're right about the "really cool things" and about the "lots of damage". I've done both.

Rockwell's commercial engineering team has access to the internal object definitions via the developers, so when they want to make something happen in the Logix system using CIP Generic messaging they go right to the source. Many of those functions have been written up, and there is a great table of contents technote that Contr_Conn posted a link to last week.

Knowbase Document A41855432 CIP Messaging Reference.

Over the years as these objects become very useful, they are converted to GSV and SSV objects.

I've also found some of these objects definitions for networks in the DeviceNet, ControlNet, and EtherNet/IP specifications.


For the 1757-SRM modules, you're probably going to have to work through RA Support or your local Rockwell sales office. I know you're in Milwaukee, but the Logix development and support is all done down in Mayfield Heights, OH.

There's a document on the AB site explaining how to synchronize the module using a CIP message

Click to expand...

Can you tell us the technote ID please.
I want to try it.

As Ken mentioned in addition to the standard CIP objects (CIP specification supported by ODVA) manufacturers adding their own objects. Some of them are documented, some not.
If you need a specific feature then check technote above first.
If nothing found, then call techsupport.
If they don't have this reference they will try to get it from developers.

Take a look at the redundancy user manual
http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1756-um523_-en-p.pdf page 5-30

It tells you how programmatically set SRM clock.
I did not try it yet, but it is really straight forward:
- Read wall clock time from the controller (use GSV)
- Set SRM clock using CIP generic MSG

OK, I got it working:




Time is DINT[2] array

Message Path= 1,<SRM SLOT> - in my setup 1,1

Contr_Conn said:

Time is DINT[2] array

Click to expand...

That's the document I was trying to use. The only difference is that I was trying to populate TIME with data from a GSV instruction in another subroutine. I'll have to try this out and see what happens.

So what's the format of TIME? I couldn't figure out how to get the clock to read what I wanted no matter what I put into it. Is it BCD or something stranger?

AK

Ken Roach said:

Knowbase Document A41855432 CIP Messaging Reference.

Click to expand...

I did find that. Again, I had trouble with the document that describes how to set the system time in another controller. Probably for similar reasons.

That index needs a link to info on the SRM module.

Format of time is 64 bit time value in microseconds since jan 1 1972.

You probably did not set MSG path correctly. I got it working from the first attempt.

I had trouble with the document that describes how to set the system time in another controller.

Click to expand...

Setting SRM time is exactly the same as settintg time in another controller.

Can you tell us what exact error you got?
Error code
Extended Error code
Error Path

Contr_Conn said:

OK, I got it working:

Time is DINT[2] array

Message Path= 1,<SRM SLOT> - in my setup 1,1

Click to expand...

So this can be used to set the time on another Controllogix?

So this can be used to set the time on another Controllogix?

Click to expand...

Yes, all modules that have internal clock use the same WallClockTime object.

Ok thanks. I always send the values to the controller through Produced and Consumed tags and use the SSV to set the values.

Contr_Conn said:

Can you tell us what exact error you got?
Error code
Extended Error code
Error Path

Click to expand...

I got it working, thanks.

There was no error code when I tried it. The message was completing ok. But, I was tinkering with the values in TIME to try and figure out the Date/Time format because my original message wasn't setting the correct time.

If I'd gotten an actual error code, I know where to look those up.

Here's a new challenge: Is it possible to use a CIP message to reset or disable an ENBT port? I'll be looking into this myself, but I'm wondering if anyone has any success stories already.

Here's the situation:

On one or two PLCs we've taken advantage of the recent firmware update that automatically configures the ENBT IP addresses to neighboring IPs. There appears to be a firmware bug in the ENBT or SRM that causes the CPUs not to resynchronize after the backup chassis takes over.

I've tested the rack and I'm convinced that the two ENBT's see each other briefly before the IP addresses are assigned. One or both sets a flag internally that permanently disqualifies the module. I've tested this by experimenting with disconnecting the ethernet cables, removing the ENBT modules, and powering off the racks. Based on what I saw, I'm CERTAIN of what I've witnessed. I even had our on-site Rockwell guy watch me do it. Incidentally, I upgraded the ENBTs from version 3.7 to 3.9 and the problem became more difficult to avoid because the newer firmware boots faster.

So, I'm left with a number of options:

1. Ignore the problem.

2. Wait for a firmware upgrade that addresses the problem.

3. Write a complicated maintenace proceedure for the customer to follow after each failover and tape it to the inside of the panel. Maybe even add a how-to popup to the HMI when the PLC alarms.

4. Configure the ethernet switch to keep the port occupied when the module first powers up.

5. Write program code to silence or reset the ENBT on redundancy failure.

Options 1 and 2 are unlikey to happen while I'm on this project.

Option 3 will not make our customer happy and we'll have to have a long, boring meeting.

Option 4 and 5 are band-aids. Option 4 is not preferred because all of our switch settings are standard. We'd have to document a special case, and we ALL know what happens to documentation.

Option 5 moves the documentation into the PLC, where the problem resides. This looks like the best solution, if it can be done.

On one or two PLCs we've taken advantage of the recent firmware update that automatically configures the ENBT IP addresses to neighboring IPs. There appears to be a firmware bug in the ENBT or SRM that causes the CPUs not to resynchronize after the backup chassis takes over.

Click to expand...

This is not a bug, this is a feature called IP swap. It is well documented in redundancy manual. There are no issues with ENBT redundancy firmware. If ENBTs correctly configured: both ENBTs have exact same configuration and IP, then secondary ENBT will always get IP+1 from SRM.
After switchover primary chassis ENBTs will swap IPs and primary will always have IP and secondary IP+1.
I am using redundancy v13 on multiple test systems and not aware of any issues with ENBTs.

, I upgraded the ENBTs from version 3.7 to 3.9 and the problem became more difficult to avoid because the newer firmware boots faster

Click to expand...

FW 3.9 was never designed for redundancy systems, only 3.7 can be used.

You can easily reset ENBT as any other module with CIP generic reset MSG, but I would try to avoid it with redundancy.

Did you talk to techsupport about this issue?