Strange RSlogix 500 data addresses

[Mikemator]

Hi.

I'm doing an upgrade of an old 1400e to a new panel view plus 7 standard using ftv studio v 12,which will be communicating to a slc 5/04 via 1761-net-eni.
I came across this unusual data address F8:[N7:113] and several other similar ones used in a ariety of different instructions, I have never seen ythis before.

Does anybody know what this address means.

The old hmi was using DHRIO 1747-SN for comms to 1400e.

Thanks in advance.

 

[parky]

F8:[N7:113] is an indirect address of a float in F8 pointed to by the integer in N7:113 so if N7:113 had 10 in it then this would point to F8:10
It is the equivelent of pointing to an array for example My_Float[10] would point to the 10th var in the array of My_Float. or by using a pointer
Mov 10, Pointer
My_Float[Pointer]

 

[A_G]

As parky says, this is called Indirect Addressing. THis old thread has a similar example:
http://www.plctalk.com/qanda/printthread.php?t=113230

 

[Mikemator]

Hi Guys.

Thanks for the really clear response Parky, I understand now.Thanks for the link AG.

 

[robertmee]

Hi Guys.

Thanks for the really clear response Parky, I understand now.Thanks for the link AG.

A lot of the old Panelviews were limited on memory, so you may be seeing indexed values based on which screen you've navigated to on the panelview. For example, Screen 1 has 10 floats for temperatures and Screen 2 has 10 floats for pressures. The Panelview tells the PLC which screen it's on, and the PLC creates an Index into the F8 table. So maybe N7:113 equals 10 on screen 1, but 20 on screen 2. So the two screens can point to the same Float[Index] but display different values depending on the screen it's on. It is maddening to troubleshoot this. I have a plant I support that has a dozen panelviews done like this all using the same registers but modifying the value based on which panelview and which screen.

If you're converting the app, don't just do a one for one conversion. Take the opportunity to divorce this methodology and create individual tags.

 

[JTCat]

Indirect addressing also hammers scan times. Use sparingly if at all

 

[dmroeder]

Indirect addressing also hammers scan times. Use sparingly if at all

I'd have to see the data behind this one. Perhaps you are thinking about loops?

A simple thought experiment puts this in doubt. Let's say I have a very simple recipe system, which is changing a single timer preset. N10 holds 500 values to be used for timer presets. The operator, from a HMI, chooses recipe 1-500 by entering an integer (N7:1).

Your options are, 500 rungs of "N7:1 = #, MOV N10:# into T4:1/PRE". Or one single rung of: "MOV N10:[N7:1] into T4:1/PRE". Certainly the indirect address would use less scan time than brute force.

I've been wrong plenty of times before though...

 

[I_Automation]

Your options are, 500 rungs of "N7:1 = #, MOV N10:# into T4:1/PRE". Or one single rung of: "MOV N10:[N7:1] into T4:1/PRE". Certainly the indirect address would use less scan time than brute force...

I don't think he's comparing the brute force to a single rung. For that indirect addressing would be better and is basically what it was included for.



Using indirect address does use quite a lot of CPU clicks.


I just did a test in a SLC5/05
50 MOV instructions in each of 2 ladders


The first was MOV N12:{N7:0} N7:20 (N7:0 = 3)

The second MOV N12:3 N7:20 (same end result on each rung)


Using the RHC instruction the 50 pointer rungs took over 300ms where the 50 direct address rungs took 7 to 8ms (40x less)



A lot of indirect addressing in a large program (on a SLC, not comparing CLX) will greatly impact scan time.


Also needlessly using data file tags where a specific value can be used that won't need changed by the HMI (I.E.- LIM 0 N7:10 59 when checking for a minute entry vs LIM N7:5 N7:10 N7:6) increases scan times.


EDIT: Don't worry about value in one pic being 5 and the other 9, I changed the value during adding the second test

 

[JTCat]

Idk man my though experiment is this;
You have to go to the mailbox to retrieve a letter that tells you what mailbox your letter is in, and now you have to go to that mailbox to get your letter when it could have just been delivered to the first mailbox.

 

[plvlce]

Idk man my though experiment is this;
You have to go to the mailbox to retrieve a letter that tells you what mailbox your letter is in, and now you have to go to that mailbox to get your letter when it could have just been delivered to the first mailbox.

But everybody else wants their letters in the first mailbox as well, and it can only hold one letter. Why should your letter get preferential treatment?

 

[I_Automation]

I was wondering how much the scan time would be if there was a second indirect addressing in my test, so I just tried it.


The results for scanning 50 rungs with basically the same MOV instruction:


Direct addressing - 7 to 8 ms
1 indirect - 300+ ms
2 indirect - 600+ ms

 

[Operaghost]

Curious what the results would be for indexed addressing. Less flexibility might make it slightly more efficient. Though the extra logic for moving your value into the index register would have to be factored in.

OG

 

[I_Automation]

Curious what the results would be for indexed addressing. Less flexibility might make it slightly more efficient. Though the extra logic for moving your value into the index register would have to be factored in.

OG

Well, I had to find out myself.



Turns out 50 indexed addresses takes about 125ms


Interestingly - the register needed to have a MOV 3 S2:24 EVERY scan or it reverted to 0
EDIT: I also tested it with the MOV to the register before and after the start time recording and it didn't change the result any noticeable value - still staying right around 125ms



Interesting & dishearteningly - monitoring online it shows the value for #N12:0 as the N12:0 value and not N12:[0+3] value so it doesn't look like the MOV operated and anyone troubleshooting might get lost/confused/or just melt

 

[Operaghost]

Yeah the way Logix software displays the base value instead of the indexed value was always a drawback to indexing. Because other instructions can manipulate the index register we were always told to move the pointer value to the index immediately before referencing the indexed address.

OG

 

[I_Automation]

On the SLC I didn't have to set the register every instruction, just once at the beginning of the scan.


But in real world use it will probably be written to every use, unless it's for reading a recipe across multiple data files. Something like S2:24 = 23 reads the recipe in N20:23, B21:23, B22:23, F23:23, etc


EDIT: I know that wouldn't be a good way of doing it, but working in the field on other's programs I have encountered all kinds of [trying to think of a word that won't get censored, but so far every one has been]