CLX to SLC Messaging-Source Format ??

Hello,

I was ticking along at improving some data reading from a SLC to CLX earlier today, and could not get it to work as I wanted 1st time...

Originally I had 2 separate MSG instructions reading from 2 different areas in the SLC, but after trawling through the RS5K examples, decided to use the one 'messaging to multiple controllers' example.

There are also 2 1769-L32's on site, so I started with these first, and had no problems, when I tried to do the same to the SLC, I had to think a bit more.

The problem was, in the original MSG instruction, I simply entered the data table address that I wanted to read from "B10:5" for example.
With the multiple controllers example, you now enter the data table address, or .RemoteElement as it is known, in a different format. So B3:10 became $1$85$05$00, & F12:0 became $p$8A$00$00

What I would like to know, is how does one work out what the .RemoteElement format of a given memory area is, or is there an easier way, possibly in a manual somewhere that I dont have?

I sort of cheated, and looked up the .RemoteElement from the original MSG instruction.

Ach. I'd strongly suggest you go back to using simple reads, even if multiple. Or move the data in the SLC into a block, and read the blocks. Troubleshooting low-level messaging can be a nightmare and a half, but if you MUST know, the .RemoteElement string is formed of direct DF1 protocol commands (see AB publication 1770-6.4.16) and are different for the different PLC types.

In your example, uhh, is the B3:10 representation correct? That one makes no sense.

The first "Field" should be the file number, the second "Field" is the type (BYTE, FLOAT, etc), the third "Field" is the offset into the file, and the fourth is the sub-element (as in timers, PID's, etc).

So, the F12:0 makes sense:
$p = 0x12 in hex, File 12.
$8A = Floating Point Format
$00 = Offset into file of 0
$00 = SubElement 0.

The $1$85$05$00 looks odd all around, basically, it looks like a single bit read, of file 1 (Input file?) at address 5.0, so it should be reading I1:5/0 from what I see.

For efficiency sake, you should have all your data that needs to be in a particular processor in a continuous data block. Then you can do a single read and get it all.

Scott:
Here my two cents, in this case i´m sending data from a Compactlogix to a SLC 5/05 thru ethernet.
My sourde data is a real number Datos_Flujo[1] and F8:49 is receiving this data on the SLC.

Thanks all for your replies.

In your example, uhh, is the B3:10 representation correct? That one makes no sense.

Click to expand...

Sorry, was supposed to be B5:10. But your comment about it reading the input file makes a bit of sense, as I am getting some strange readings. Thanks for the breakdown and manual reference though.

I have attached the original instruction, and the value in the .RemoteElement field

Ach. I'd strongly suggest you go back to using simple reads, even if multiple. Or move the data in the SLC into a block, and read the blocks.

Click to expand...

Will go back to multiple reads. I do not have access to the SLC code, as it is locked due to regulations. I have only been given certain areas to read from the service tech, so cannot group it all together as would be the most practical. When I'm next on site, I will enquire with the tech to see if he can give me a contiguous block to read!

Here my two cents, in this case i´m sending data from a Compactlogix to a SLC 5/05 thru ethernet.
My sourde data is a real number Datos_Flujo[1] and F8:49 is receiving this data on the SLC.

Click to expand...

Thanks Bill, I will go back to the original method of 2x Read instructions.