Indexed addressing of strings in AB ML1200

Hi all,

I have an application with a Micrologix 1200 PLC where I would like to be able to use an integer index to access an element in a string file, in other words, a look-up table of strings.

e.g. using the AEX command (ASCII Extract) I want Source=ST10:[N7:1], and for arguments sake Index=1, Number=2, Destination = ST11:0

The help page for AEX says that the source paramater can use direct or indirect addressing using the ST file type, but when I compile I get two errors:
ERROR: Indirection is not supported
ERROR: Element level indirection is not supported

I am pulling my hair out with this, and I would be most grateful for any help.

Thanks

Ashley Dawson

[email protected]

Ashley-

I entered the instruction just as you list it in your post and it verified for me. I don't have a ML processor here to test it on so I can't absolutely vouch for it.

If you register, which is very painless by the way) and you can post your code we can probably have a look.

Keith

One possibility from the ML Users Guide:

You must use Revision 4.5 or later of RSLogix™ 500 in order to use the new features of the Series B MicroLogix 1200 controllers, including the full ASCII instruction set.

Click to expand...

Ashley Dawson said:

The help page for AEX says that the source paramater can use direct or indirect addressing using the ST file type

Click to expand...

I don't see indirect addressing listed in this table...

[attachment]

beerchug

-Eric

From the AEX help file, Rslogix500 Ver. 6.0

Looks like it isn't supported in the ML1200.

Indirect addressing is valid with SLC 5/03 OS302, SLC 5/04 OS401, or SLC 5/05 and MicroLogix 1500 processors only.

Click to expand...

Ken:

I'm looking at a different help file. From version 5.50:

Indirect addressing is valid with SLC 5/03 OS302, 5/04 OS401, and SLC 5/05 OS500 and OS501 and MicroLogix 1200 and 1500 processors only.
RSLogix 500 - Copyright Rockwell Software 2000, 2001, 2002

Click to expand...

---

Ashley:

Like Keith, the logic compiled for me, when I used a series C processor.

When I converted to a series A, I got an error "AEX instruction not valid"

When I converted to a series B, I got the errors you got. (So no, you're not crazy.)

Looks like it's a bug in the firmware. Contact your AB rep for a firmware upgrade (if it's possible - I'm not that familiar with the micrologix line).

As stated above

A bug by any other name has a workaround.

Mikey:

I think you're missing my point.

In a micrologix 1200, series B:

• The AEX instruction is supported.
• Indirect addressing is supported.
• Indirect addressing within the AEX instruction is not supported.

To me, that constitutes an oversight on the firmware programmer's part. I call such oversight a bug.

---

Ashley:

Your work-around is like this:

First make a copy of the indirect string that are interested in:
COP #ST10:[n7:1] #ST11:1 1

THEN, do the string extraction:
AEX ST11:1 1 2 ST11:0

I think this may be a Logix500 issue. I'm running V6.0 and it will let me use indirect addessing in the source of the AEX with both a series B and series C ML1200. At least it verified without errors.

Keith

Thanks for your replies

Thankyou all for your replies,
however I am still not having any luck.

I am using RSLogix 6.20.00 which I believe is the current version.
and I am using a Micrologix 1200 series C processor

When I convert to a series B processor, I get the same two errors, and when I convert to a series A processor, I get the Instruction not supported error.

I am interested as to why several of you have managed to compile the instruction using a series C processor whereas I cannot. Just out of interest, I dug out an old CD with version 6.00.00 and installed that, but got the same results. What exact version of RSLogix are you using?

Unfortunatley Allen, when I try your workaround, I get the same error on the COP instruction:
ERROR: Element level indirection not supported!

It certainly does seem that a lot of the AB documentation is contradictory when it comes to this issue.

Once again, thanks for your replys.

Curiouser and curiouser.

Now (at the end of the day, with more PC memory used), I'm also getting the compile error, even on a Series C.

But only when I Verify Project. If I'm in the file, and I Verify File - no error.

MAYBE I was only verifying file all along, and so didn't see the error.

Or, perhaps I'm not running with enough memory for RSLogix to deal with it. I'll try rebooting and seeing what happens.

---

Nope. Rebooting didn't help. I must have only checked Files when I thought it was working.

Bummer. Definitely a bug. The question is where?

Is it that the micrologix, while it DOES support indirect addressing for integers and floats, DOESNT support indirects for strings.

OR, is the Verify File routine correct, and the Verify Project routine wrong?

It's time for Ashley to contact AB tech support. I wouldn't be surprised if it's a "known issue". It would be nice to find a work-around.

I'm in the same boat as you, Allen. I never tried a verify project before you mentioned it. I'd always used verify file. Now THAT'S not nice!!

Keith

Ah Ha, so I'm not going crazy

Ok, I have been verifing the project all along. I just tried verifing the individual file and got no errors, the same as you have reported.
I've put a call in to the local Rockwell tech support, and I'm waiting for someone to get back to me but it would seem though that it's not looking too good :-(

Official Reply

Just spoke to Rockwell. As I suspected, the official position is that indirect (and offsett) addressing is not supported for strings in any Micrologix or SLC processor.
I am astounded by this. After all as far as I'm concerned memory is memory, who cares if its storing strings or integers, you should be able to use some kind of indexed addressing on it.
It seems like such an abitrary restriction.
While I'm on my rant, 2k maximum data memory in the ML1200 (& only 4k for ML1500) is appalling. Maybe for a $5 microprocessor chip it would be OK, but for this PLC, 2k data words corresponds to only 40 or so strings!

Anyway thanks for all your help.

Workaround

Just in case anyone is interested.
It would seem that the work around for this problem is to store strings in binary files rather than string files. This way you can use indirect addressing. The only complication is that you must convert the binary data into a string before it can be used (eg sent via the serial port).