CLX CIP Custom message - any ideas what this is?

Sure. It looks to me that the destination tag will be populated with the first 2 parameters of the source ([0] Attribute Count and [1] Attribute) plus the status in [3]. For the status, it seems that you will get a value of 0 or 9, success and invalid attribute, respectively. So when it's successful, your destination array will have 1, 7, 0. If it's unsuccessful, you would probably see 1, 7, 9.

All of this no longer matters I suppose since it doesn't even work with newer firmware and the MSG will just error.

dmroeder said:

All of this no longer matters I suppose since it doesn't even work with newer firmware and the MSG will just error.

Click to expand...

This precisely :/ still it's good to understand the principle.

I have a feeling there's no other way to achieve the same effect ie. inhibit / un-own the modules but not from the running PLC. I think that if I inhibit them from the running PLC it won't change their ownership status, they will still be owned by the PLC in program mode, the one that took ownership of them originally. Only other way to avoid any possibility of a useless PLC pair is to atick all PLC in Run mode via keyswitch and take away all the keys...

I have to wonder if the message is to change the output module's master from one processor to the other.
Under normal the output module would only respond to it's master but it may still respond to a CIP message only the running plc can send a message so if it is not running it can't send a command
the source would be a data to be sent the destination would be the address of the module.
the destination would be required change of master
the additional information should be available from Rockwell should be a matter of a phone call

I missed your question dmroeder, you asked if there's a unique tag used as the source in the MSG and the answer to this is yes, there's two one for "inhibit" which is [1][7][5] and one to "uninhibit" which is [1][7][1]. These are sent out depending on what's being requested ("inhibit" or "uninhibit"), the interesting bit is that there's no checking what return status is written back by the source device (I think this would be good to include in the code just in case the source device rejected the message for some reason, or perhaps someone manually modified the values inside those source tags and in effect broken the mechanism).

I agree with your guess re what this MSG does, it might just be "shaking off" it's ownership and thus making the output device not-owned and available to the other PLC.

Also, interestingly I've found the same MSG used elsewhere in the code, but going to the same PLC ie. sending the MSG to itself. This still works fine, so it seems that the MSG is blocked when being sent out to other device, but can be used within the boundaries of the same PLC.

And just to wrap up, I agree Gary that it might be a good idea to get in contact with Rockwell, very curious if their tech support knows much about this service class.

I figured that would be the case, including each PLC messaging itself.

I had a thought last night, you may be able to make this work again. While a MSG over the network/backplane of this type would be rejected, a PLC MSG'ing itself is allowed. So rather than one PLC messaging the other, each PLC could have it's own "own" and "un-own" messages, pointing to itself. You could trigger the swap over from the other PLC using produced/consumed tags between them.

Hopefully that made some sense, it sounded good in my head.