Indirect Addressing

I am using RSLogix 500 to program a buffer system. There are 5 levels that can hold 12 products and each product has 2 parameters associated with them. When I assign a product to a level, I need to load those 2 parameters into the buffer so that it follows the product until it is retrieved from the buffer.

My question is...Can you use arithmetic operations on indirect addresses? For instance, to load the 2nd parameter into the correct position in the buffer for level 1, I would need N11:[N7:50]+11. If N7:50 is 1, would that indirect address read N11:12?

Also, once a product is removed from the buffer (it operates FIFO), is there an easy way to move all subsequent parameters into the preceding location?

TIA
Dan

I think a cleaner way of handling your arithmetic operation would be to perform it outside the addressing and then reference the result register for your indirect address. For example, use an ADD instruction to add 11 to N7:50 and then store the result in N7:51. Then your indirect address would become N11:[N7:51].

As far as the second part of your question, I'm not quite sure how to answer that. Maybe you could provide a little more information on what you mean by subsequent parameters and preceding location. An example would help.

HTH.
Jeff

Thanks for the response on the first part...I'll try that.

As for the 2nd part...Say level 1 is full (12 products), and the first product is removed from the buffer. Now the 2nd product becomes #1, the third becomes #2, etc., and the parameters for those products must appear in the same position as the product they describe. Is there an easy way to move all parameters in one level's buffer up one position?

Take a look at the BSL or BSR instructions (Bit Shift Left or Right) if you haven't already. You should be able to use two of these in parallel to not only shift the products in a FIFO sequence, but also the parameters. Triggering them at the same time will keep your parameters aligned with your products.

HTH
Jeff

Yeah, I looked at those, but the problem is that my parameters are not bits. One is a production line assignment and the other is a color code. They are both stored in the N-file.

Example:

Product 1 Line -> N11:0
Product 1 Color -> N11:12

Product 2 Line -> N11:1
Product 2 Color -> N11:13

When Product 1 is "picked" from the buffer, I need Product 2's parameters to move to Product 1's locations automatically.

That's easy. Since you want N11:2 ==> N11:1 (and so on), just use the COPy command:

COP #N11:2 #N11:1 11
COP #N11:13 #N11:12 11

This "load from the top" FIFO is very handy. Most folks try to do it the other way, wanting N11:1 data to move to N11:2, etc. To do that, you have to use an intermediate buffer (COP #N11:1 #N21:1 11, COP #N21:1 #N11:2 11).

Since you are indirect addressing anyhow, take the next step. Make up a rotary queue. Place the products in your queue based on one pointer and pull them out with another. Once a product description is in a location (N11:0 / N11:12, for example) it stays there. The pointer value is what is incremented. Five levels with 12 products gives you 60 possible items. Make your rotary queue at least that long and you should be set.

Keith

Allen,

It would be tedious and memory intensive to have 24 copy commands every time a product was removed (12 products, 2 parameters). Thanks for the response though.

Keith,

I'm going to be displaying these parameters on a PanelView, so the addresses where they are stored must remain constant (Product #1's parameters must always be in N11:0, N11:12, for instance.) Given that information, is it still possible to do a rotary queue? I'm almost close to understanding how to implement a rotary queue, but I don't think it will work in this case.

It's the COP instruction, not the MOV

wilheldp said:

Allen,

It would be tedious and memory intensive to have 24 copy commands every time a product was removed (12 products, 2 parameters). Thanks for the response though.

Click to expand...

No, no, no. It's only ONE (well, maybe two) copy commands. That's what the length is all about. With that one command, the data that was in N11:1 is transferred to N11:0, the data in N11:2 is transferred to N11:1, and so on.

The only reason why I broke it up into two chunks was so that the old N11:12 (Product 1 Color) didn't overwrite N11:11 (Product 12 Line).

Ahhhhh...COOL!

I had forgotten that the # meant indexed addressing.

So
COP #N11:1 #N11:0 11
COP #N11:13 #N11:12 11
will take care of rotating through N11:0 to N11:11 and N11:12 to N11:23?

Thanks!

If you need to display them all on the PanelView at once the rotary queue is not a good fit. If you just need to display one at a time then it wouldn't be so bad.
However, I think Allen's suggestion is the winner. It's straightforward and easy to implement.

Keith

When I read the help file on the COP command, it says that the # is a file indicator, not an indexed address. Have you guys used this to actually shift integers by one location?

If it will actuall work, I would like to confirm that I'm using it correctly. The source should be the 2nd position (N11:1 in this case) and the destination should be the 1st position that was recently vacated by a retrieved package (N11:0 in this case) and the Length should be the number of positions per level (12 in this case). Is that right?

I really appreciate your help. I think this was a little over my head for my first assignment on a PLC.

Dan

I use it all the time, for just the kind of FIFO that you describe.

The '#' in this case isn't so much an "indexed address" marker as it is a "file" indicator (although the COP command does use indexed addressing as its internal mechanics.

Normally when you do a COPy, you copy a block of data from one set of registers to another (EX: COP #N11:0 #N21:0 15) will copy the data in N11:0 thru :14 into N21:0 thru :14.

But copying the registers on top of themselves, and going DOWN has the effect of building a FIFO. If you were to copy the registers going UP, you would be reinventing the FLL instruction. If you're interested, I'll post exactly what's going on in the PLC when this command is executed.

So yes, your Source is N11:1. The Destination is N11:0. The length, however, is the number of registers you are MOVING. Although you have 12 products, only 11 are moving. One has already been "plucked", and the data will be overwritten. So your length should be 11.

And this trick is definitely not one you're likely to come up with on your first PLC program job. It was years before I used it (and I didn't invent it - I found it posted on some forum like this on, just as you)

Alright, I trust you...this just seem deceptively simple for a problem that I thought would take a ton of code to solve. I really appreciate the help on this problem.