CLX CIP Custom message - any ideas what this is?

Second question similar to my last one, but this one isn't as easy :/

I've got the following CIP Generic MSG instruction, but it's a Custom one and having no CIP reference manual I've got absolutely no idea what it's trying to do:

Message Type: CIP Generic
Service Type: Custom
Service Code: 4
Class: 69
Instance: 1
Attribute: 0
Source Length: 6 Bytes

All I know is that it fails with a 16#000f code which means access denied according to Help. The only comment in the code says that this is to "inhibit" the other PLC (there's a PLC pair, hot standby, but a DIY solution). The source / destination tags are related to a routine, it's 6 bytes / 3 INT tags which hold values like 1,7,0 and 1,7,5, but no idea what those mean and also no idea what the direction of data is.

I know this is a long shot, but any help would be very much appreciated!

Cheers!

This is from a Rockwell Technote (748424):

Note: The messages described in the referenced technotes are all we can provide to the customers for particular tasks.
There is no "full list" of all possible combinations of Service Code, Instance, Class, and Attribute and what they can do in a CIP Generic Message.

Click to expand...

I poked around and could not find Class #69 in the processor-related messages. Unfortunately many of the examples are screen-shots of the MSG set-up, and therefore do not respond to text-based searches.

Yet again huge thanks Mispeld!


From what I've heard this has been coded up by RA engineers, so I reckon they had unlimited access to all internal docs. Huge shame that they decided not to comment anything and their detailed spec holds no extra info :/

Just a thought usually a Generic CIP massage is to a device other then Rockwell
usually to communicate to another Rockwell processor they provide a caned message for that.
I would look for a device that is now missing

Here are a few pieces to the puzzle:

The message is setting an attribute (though class 0x69 is undocumented)
The values being written
- [0] = Attribute count (1 in your case)
- [1] = Attribute being set (attribute 7 in your case)
- [2] = Value the attribute will be set to (0 or 5 in your case)

It would be interesting to know what device the message is targeting on the connection tab.

Another thing to know is that starting at v20, these types of commands are restricted to only RSLogix/LogixDesigner. Take the example of sending a CIP command to change the controller mode to program mode. In v19, you could send one simple command to switch to program mode. Starting at v20, the command would be rejected and return a privilege violation error. If this is in fact trying to inhibit a module, this would also get rejected.

Okay, a little more. My CLX rack has a few modules that exist, others that don't....

This appears to be manipulating the state of all the devices in the I/O tree.
When 0 is written, the I/O tree looks "normal" the devices that exist are happy and running, the devices that don't have a hazard for obvious reasons.

When writing a 5, all of the devices that exist have a hazard and into a "waiting" state. The I/O LED turns red momentarily, then turns of.

Again, this message is only accepted by the CLX if it is v19 firmware or earlier. Privilege violation if the firmware is newer.

Maybe this is someone's makeshift way to attempt to "inhibit all", even though it is not actually inhibiting the modules? I don't have any actual I/O modules to test if you can toggle the I/O points in this state like you can if a module is inhibited. I suspect that you probably could.

What you're looking at is probably a relic of an RA Commercial Engineering project, maybe fifteen years ago.

At the very beginning of the ControlLogix Redundancy system, there were some hand-rolled backup and standby systems that did not use the Redundancy firmware or RM manager modules. The reasons varied, from "we have to compete with Quantum / DeltaV on a spec sheet" to "we have to cut the hardware cost but aren't eligible for commercial concessions". I'm sure there were technically valid reasons as well.

The systems I participated in were sold with the very clear condition that if you modified them yourself, the warranty was void. Some even wisely wrote into the contract that once the proper Redundancy system was available, the customer would buy an upgrade at a fixed price.

The excellent investigation from my colleague DMRoeder supports the idea that this was originally done with v13 or v15 firmware, and that once Redundancy was really good at v19.5, Rockwell intentionally disallowed those old features so they would not have to keep validating firmware to run on those systems.

I think you can imagine why Rockwell wants to keep the low-level processor functions unavailable to general purpose users; I've fiddled with sabotage software enough to agree with that decision.

I hadn't dusted off the ol' sharktap in a while, seemed like a good opportunity.

Huuuge thanks dmroeder, your reply was mighty helpful! I've not played around with those 1, 7, 0(5) values yet, but from what the system does on "switch" over (and from the very brief comment in the code) I could gather that it is used to inhibit IO. What actually happens is that one PLC takes ownership of the modules and that remains in control, with the other PLC in the pair being standby, on switch over the first PLC releases ownership and the other PLC grabs all IO modules (we are talking Flex IO here). The MSG described above is only used if you switch one of the PLCs into Program Mode, it effectively forces the non-running PLC to inhibit all it's IO, so that the other running PLC can take ownership. With this MSG constantly in error, "control" switches over to the running PLC, but ownership remains with the non-running, which gives you a rather useless PLC pair. If both PLCs are running and are switched over the PLC which owns the IO can release it by simply running some code, but this of course is not possible if it's in Program mode, which is why this Class 69 MSG was used.

Some extra info here (Ken you might like this, you were almost spot on with your 15 year estimate): this is what I would call a DIY redundant solution (very ****e, switchovers can take minutes) and was infact delivered by RA around 10-12 years ago. It was running on v16 firmware and L6# family CPUs, but a hardware upgrade is now being done and everything is shifting to L8# and v30 :/ which explains the privilege errors. There was a huge emphasis to keep the code the same and testing was left to the very end...

This is a rather big deal as I don't think the same can be achieved any other way, unless RM modules are used (which requires a lot of work to move modules around to keep racks the same) and half the code can then be canned (FAT is a couple weeks away so too late for this).

Just as a reference there is an article on KB about sharing input modules
you can have 3 plc's read the same input modules but you can only have 1 plc (Master) write to an output module.
A question I never look up
if the plc is powered but not in run mode dose it still read the IO ?

It's the writing that's the issue here Gary, the owner needs to inhibit it's output modules for another PLC to take ownership of them (or so it seems from what I've seen on this system). Normally all you need is an SSV from the owner and the switch over to the other PLC which can now take ownership, but if the owner switches to Program mode, it can't inhibit it's output modules, so this Class 69 was used on the running PLC to inhibit the modules but from the non-running PLC side.

One potential fix would be to inhibit them briefly from the running PLC side, maybe that "wipes" the ownership altogether and then if I uninhibit them, they might be able to take ownership from the running PLC. I've not worked with FlexIO much so if this is a silly idea do let me know.

First of all, another demonstration of the unbelievable repository of knowledge that Ken has!

Thanks for the update on the details dscish, what I was seeing makes a lot more sense now. Learned some mew stuff today.

Agreed on the knowledge comment, Ken is on another level !

Just a quick question regarding those tests that you've ran dmroeder, what was your source and destination tags? I'm asking as in my case this is linked to UDT tags - the UDT is called the same as a routine in one of the programs and the tags used for the source and destinations are of ControllerDevice - arrays of 3 INTs each. But the strange thing is that they are not referenced anywhere else in the code, the reference tool just finds them inside the MSG and nowhere else. What I'm trying to understand is how those link up to the IO and the fact that writing a 0 into one of those INTs inhibits all IO. Is it simply the fact that they are of ControllerDevice type (I assumed the fact that they are in a UDT was simply a developer choice)?

EDIT: forgot to add, the comms/path tab in the MSG is pointing at the other PLC in the redundant pair, it's just a name from the hardware tree.

I just had an array of 3 int's for the source, array of 3 int's for the destination. I manually typed the values for my test. The fact that they are UDT was a developers choice and the scope which they are defined wouldn't matter either.

Is there a unique source tag for the inhibit and another unique source tag used to un-inhibit? If that's the case, then someone just manually typed the values into those tags. The values are taken from the source tag, put put into the data portion of the CIP packet and sent out. The MSG receives the response, pulls the response data form the packet and puts them in the specified destination tag.

From my experiment, it didn't really inhibit/uninhibit anything. Maybe what it was doing, after hearing your description of the system, was "owning/un-owning". A value of 0 seemed to "own" the I/O where a value of 5 seemed to "un-own".

I may be wrong on some of the specifics, just reporting what I saw with the limited experiments.

Yet again, much appreciated dmroeder!