SLC 500 Changing MSG block transfer IP on the fly!

[Lakee911]

I'd like to change the IP of a MSG instruction on the fly. I've identified the bits that change in the control block when I change the IP in the setup dialogue.

I'm cycling through a bunch of message block transfers that go through a DH+/Ethernet bridge. In the event that it goes down, I'd like all communication to continue using another bridge (which is identical, except for the IP).

Does anyone see any problems in doing this?

As an example, one of my MSG blocks looks like this:

MSG
Read/Write Message
Type                  Peer-to-Peer
Read/Write            Read
Target Device         PLC5
Local/Remote          Local
Control Block         N11:55
Control Block Length  51

I've identified N11:74 as 13619 when my IP (setup via Multihop) is 10.102.1.235 and as 13875 when my IP is 10.102.1.236. In otherwords, when the 235 changes to the 236 N11:74/8 & N11:74/9 go from 10b to 01b. Can someone confirm this is correct?

I have 7 message block transfers, so I thought this would be easier than creating 7 more. I'll just alernate the bits after each cycle of the blocks. If one bridge goes down, the communication will just be half as fast (which is okay).

Jason

 

[Ken Roach]

You can do this, but you should consider how hard it will be for a future troubleshooter to understand, versus having a separate set of MSG instructions.

The IP address is encoded into the MSG control block in ASCII. The order of the characters is tricky because they are presented low character first, while you're accustomed to reading left-to-right in ASCII.

13619 decimal = 35 33 hex = "53" ASCII
13875 decimal = 36 33 hex = "63" ASCII

These correspond to the last octet in your IP address, ".235" versus ".236".

If the IP addresses were ever changed, you would have to re-write your code to tweak different bits.

If I were going to pursue this programmatic IP address change, I would find the whole string and move an "ST" string datatype into it, so a future programmer would see that I'm moving an entire IP address.

Unless you're very short on memory in this SLC, I would do this the simple way with seven more MSG instruction blocks. This also reduces the risk of any unanticipated OS problems cause by performing this sort of undocumented, unsupported tweak inside the MSG control block.

 

[Lakee911]

I actually did think of the future troubleshooter and it was of concern. That said, I think that moving the IP address as a string might be the best way to do it. It'd be easier to troubleshoot and it would be more self documenting.

How would I get started using that approach?

 

[Ken Roach]

A cardinal rule of MSG instructions is that modifying the Control Block takes you straight to unsupported territory.

But still, if you want to give it a try, you can copy the String to a storage buffer, then skip past the first element (the Length) and copy the eight Words that hold the IP address string into the Control Block (Nxx:14 through Nxx:11).

Because the String displays characters backwards from their sequence in the storage Word, you need a SWP instruction to swap bytes in there between copying the String data and then copying the String text characters.

Attached is an untested example in RSLogix 500.

 

[Peter Nachtwey]

Why not use a multiple MSG blocks each with a different IP address?

If you change the IP address then what happens to all the data in the queues and the current connection status. How do you close a connection before openning and new connection?

 

[Ron Beaufort]

it seems that you're missing one very important part of the argument against doing it this way ...

it's not just the interpretation of the IP address that's going to complicate things for future troubleshooters ...

suppose that all of a sudden the message to one particular node quits working correctly ... normally we'd look at the "error bits" and so forth for an indication of where the trouble might lie ...

oops! ...

we can't examine the error bits, etc. in this "rolling message" arrangement – because the bits will be instantly overwritten by the bits from the rest of the messages ...

the fact is that the processor will NOT execute this arrangement of "X" number of messages any faster if they're all on ONE rung – or if they're on "X" number of rungs ...

in fact, the processor will take MORE time – because it will have to manipulate the extra data for the "pointers" that will be required ...

my vote: rungs are cheap – troubleshooting time is expensive ...

feel free to ignore me – other people do ...