Array index in GX developer Options

[Mitsu]

Is there any way to index an array in gx developer (or gx works 2) other than with constants? Assume i make a variable of type array consisting of 10 words. Can i index the array number in for example a loop? The index registers (array[z0]) don't work and i can't input a variable into it either (array[variable_name]). The only thing that works is to access individual members by using [0], [1],...

I don't see much point in arrays if you can't index them in loops and such.

(i'm half expecting the answer to be: you should use the iec editor to do this.)

This post has been edited by Mitsu: Nov 4 2009, 06:40 AM

[JRoss]

I've done this plenty of times. Assuming your "array" is 16bit words, that is. Pick a head address, say D100, and modify it with an index register, say Z0. Then you can call the indexed register like this: D100Z0. The index register acts as an offset, so if Z0 = 3, then you are actually pointing to D[100 + 3] or D103.

If this is what you're doing, and it doesn't work the way you expect, you might be running into some of the limitations of the index register itself. Some instructions won't work properly with an index register, but you'll have to consult the manual to see. If you're doing math for the index, you'll have to do the math with a regular D register, then use a MOV instruction to move it into the index register. If all you're doing is incrementing the index in a loop, then the regular INC instruction works fine on an index register. I've done this before in recipe handling.

Perhaps if you post your code, I could look it over.

[Veganic]

I've done this plenty of times. Assuming your "array" is 16bit words, that is. Pick a head address, say D100, and modify it with an index register, say Z0. Then you can call the indexed register like this: D100Z0. The index register acts as an offset, so if Z0 = 3, then you are actually pointing to D[100 + 3] or D103.

If this is what you're doing, and it doesn't work the way you expect, you might be running into some of the limitations of the index register itself. Some instructions won't work properly with an index register, but you'll have to consult the manual to see. If you're doing math for the index, you'll have to do the math with a regular D register, then use a MOV instruction to move it into the index register. If all you're doing is incrementing the index in a loop, then the regular INC instruction works fine on an index register. I've done this before in recipe handling.

Perhaps if you post your code, I could look it over.

That is the simplest/only way I can think of. It just means you can't define the array in the header.

[Mitsu]

I've done this plenty of times. Assuming your "array" is 16bit words, that is. Pick a head address, say D100, and modify it with an index register, say Z0. Then you can call the indexed register like this: D100Z0. The index register acts as an offset, so if Z0 = 3, then you are actually pointing to D[100 + 3] or D103.

If this is what you're doing, and it doesn't work the way you expect, you might be running into some of the limitations of the index register itself. Some instructions won't work properly with an index register, but you'll have to consult the manual to see. If you're doing math for the index, you'll have to do the math with a regular D register, then use a MOV instruction to move it into the index register. If all you're doing is incrementing the index in a loop, then the regular INC instruction works fine on an index register. I've done this before in recipe handling.

Perhaps if you post your code, I could look it over.

hi Jeremy,

Not exactly what i was looking for. In your example, let's assign a label to the array D100-D109: a_TEST[0..9] of INT/WORD using global labels/variables. In my program, i want to index my array label instead of the device name, so instead of using D100z0, i want to use a_TEST[z0]. In short, i want to use array's defined with labels instead of devices. This is ofcourse only possible in a gx dev program using labels.

I know it is possible in the iec ladder but i was curious to see if it's possible in gx dev ladder.

[JRoss]

I haven't programmed using labels yet, so I can't help you. I just started a Q project with labels, but I didn't get very far. Did you try simply creating a label for the head address and indexing it like in my example, instead of defining an entire array? As in, ARRAY_HEAD = D100, and ARRAY_HEADZ0 = D[100 + Z0]. I tried it like that, and the instruction took it, but it wouldn't compile.

[Mitsu]

I haven't programmed using labels yet, so I can't help you. I just started a Q project with labels, but I didn't get very far. Did you try simply creating a label for the head address and indexing it like in my example, instead of defining an entire array? As in, ARRAY_HEAD = D100, and ARRAY_HEADZ0 = D[100 + Z0]. I tried it like that, and the instruction took it, but it wouldn't compile.

Same here: just starting out with labels (to finally get rid of all that direct device programming and to start using local/global labels + structures) but so far, gx dev ladder doesn't seem like the most label friendly environment (the instructions are getting wider with labels and since the ladder is fixed with 11 contacts, the code is quickly starting to get messy because of the limitation of instructions per line).

To answer your question: ARRAY_HEADz0 addressing doesn't work, which seems logical to me because ARRAY_HEAD only has a link to one variabe. That's where the use of array's come in handy but indexing in arrays doesn't seem to work. Probably a gx dev ladder limitation :(

[Inntele]

I haven't programmed using labels yet, so I can't help you. I just started a Q project with labels, but I didn't get very far. Did you try simply creating a label for the head address and indexing it like in my example, instead of defining an entire array? As in, ARRAY_HEAD = D100, and ARRAY_HEADZ0 = D[100 + Z0]. I tried it like that, and the instruction took it, but it wouldn't compile.

Same here: just starting out with labels (to finally get rid of all that direct device programming and to start using local/global labels + structures) but so far, gx dev ladder doesn't seem like the most label friendly environment (the instructions are getting wider with labels and since the ladder is fixed with 11 contacts, the code is quickly starting to get messy because of the limitation of instructions per line).

To answer your question: ARRAY_HEADz0 addressing doesn't work, which seems logical to me because ARRAY_HEAD only has a link to one variabe. That's where the use of array's come in handy but indexing in arrays doesn't seem to work. Probably a gx dev ladder limitation :(

Hi,

In GX Dev is impossible to use symbolic names if you use index addressing. You should use only operands as, an example, D100Z0.
The possibilities to use an array addressing, which you want, exists in GX IEC Dev. In this software you can use both ARRAY[Index] and ARRAY[Index1,Index2]. If the Index will be represented as constant, the compilator will produce code with the direct addressing, which calculates automatically.

[Crossbow]

Arrays can be created in GX Works2 when using structured projects and label programming.

[Mitsu]

Arrays can be created in GX Works2 when using structured projects and label programming.

Yes, but they have the same limitation as gx dev (in which you could also make arrays if you programmed with labels). It puzzles me how a programming language supports the use of arrays without offering the ability to index them. Since indexing is most often directly associated with arrays.

In short, it seems the only way to access elements of arrays in the gx dev ladder is with constant indexing (array[0], array[1],...) which means that there is basically no point in defining arrays if you use the gx dev ladder. This also means that one can't avoid direct device addressing when doing stuff in loops and such. Which is messy since you are going to mix labels with device addresses within the same program.

@Inntele: thanks for the confirmation.

This post has been edited by Mitsu: Nov 4 2009, 01:55 PM

[Veganic]

var1 INT
ta INT(10)


FOR W1 := 0
TO 9
BY 1
DO
var1 := W1 *2;
ta[W1] := var1;
END_FOR;

I got that to compile in structured text so it looks like you can call an ST subprogram or function block.

[Inntele]

@Inntele: thanks for the confirmation.

Don't mention it. Moreover, I understand that my answer do not comforted you and unfortunately did not solve the problems.

[Mitsu]

It seems to me that Mitsubishi just need to add that functionality to the gx dev ladder (or to the ladder in gx works 2 because gx dev will probably not be developped anymore). The functionality is there for iec and st programs. There are a few areas in which the gx dev ladder is lagging behind compared to the iec ladder. I hope they adjust that balance in the new gx works 2 and bring the gx dev ladder at the same level as the iec ladder.

I assume nobody from Mitsubishi is actually popping in and reading this interesting forum?

This post has been edited by Mitsu: Nov 4 2009, 02:57 PM

[Crossbow]

You assume wrong. Mitsu guys (at least some I know personally in the US) read these forums. But then the development of software is not done in US, it's Japan and Europe.

Keep in mind that you can use the Structured Ladder, which is IEC ladder, in GX Works2. Why would Mitsu redesign their command set to include this when its already part of IEC style ladder, and that's the way the whole world is heading. GX Works2 offers the structured ladder language, as well as the existing Mitsubishi style ladder logic. People are migrating to IEC compliant programming (even AB does it with RS Logix 5000) so why continue to develop vendor specific methods?

[Mitsu]

Keep in mind that you can use the Structured Ladder, which is IEC ladder, in GX Works2. Why would Mitsu redesign their command set to include this when its already part of IEC style ladder, and that's the way the whole world is heading. GX Works2 offers the structured ladder language, as well as the existing Mitsubishi style ladder logic. People are migrating to IEC compliant programming (even AB does it with RS Logix 5000) so why continue to develop vendor specific methods?

That is probably the best conclusion to this topic.

If only the iec ladder editor and me got on better :( It takes me ages to write even the simplest of stuff because i have difficulty with the editor, no matter how much i use it. I find the siemens step 7 editor a lot easier to use.

This post has been edited by Mitsu: Nov 5 2009, 06:44 AM

[panic mode]

I find the siemens step 7 editor a lot easier to use.

hmm..... care to elaborate on this?

I am surprised because of all platforms out there, S7 ladder is far from being one of the S7 strenghts.
Actually S7 ladder is probably the worst ladder implementation ever. (Edit: there is even worse one - Siemens Lego).

Specifically:
The most significant problem of S7 ladder is nothing less but - complete lack of array addressing (symbolic or not).

I don't see much point in arrays if you can't index them in loops and such.

Precisely...

To the best of my knowledge (and I like many others have spent quite a bit of time figuring out just this to get this to work).
The only way to address array element - in S7 ladder - is by hardcoding the array element address.
In other words, if using S7 ladder, one cannot change array index at run time - period. No you cannot use variable (symbolic or not),
the address must be - hardcoded (ouch).

I'd be very happy if Siemens would be able to catch up with the rest of the industry and finally allow something simple like:

MOVE CurrentTemp TempLog.[myIndex]
or
MOVE DB10.DBD4 DB80.[MW100]

If you have found way to achieve above (in S7 ladder), please share it...

Imho the second of the worst offenses commited by S7 developers is memory addressing.
Saddly, it is even more scrambled than numbers in German language (it's a messy and annoying zig-zag
unlike nice linear fashion in Mitsi, Omron, AB and others for example).

[Mitsu]

I find the siemens step 7 editor a lot easier to use.

hmm..... care to elaborate on this?

I probably didn't explain myself enough. I'm merely talking about the editor itself: the manner in which instructions are put on screen (with the mouse, keyboard). I'm not talking about the instruction set, memory layout,... (i actually find the mitsubishi instruction set quite impressive and the device addressing easy and simple).

Coming from a medoc/gx developer background (where ladder could be done almost completely with the keyboard), i have a hard time adjusting to the iec editor. Particulary the fact that you actually have to draw each connection line with the mouse. Also, every big line is treated as a collection of small lines which i find very annoying at times (especially when moving stuff around). The fact that you need to switch from selection mode to interconnect mode + auto connect and whatnot seems far too complicated to me. I tried guided mode (which is more about keyboard use) but didn't find it all that useful either. In short, i find the iec editor a bit too "loose". Iirc in the step 7 editor for example, you don't have to draw lines or at least not that many. It assists the user more. In the iec ladder, you need to do it all yourself. There's virtually no assistence.

Maybe it's just an adjustment period though. But i'm very slow in putting code on screen in the iec ladder compared to the gx dev ladder or step 7 ladder.

So in short, i was just talking about the ladder editor itself.

Interestingly though, you have to harcode the array index in the gx dev ladder also (which is what this topic was about).

This post has been edited by Mitsu: Nov 7 2009, 06:08 PM

[panic mode]

i see but - i have to disagree:

in GX you can use

MOV D0 D100Z0

with Z0 being the index.

the point i was trying to make is that (with Mitsubishi) value inside index can be changed by program (or HMI or whatever):

MUL D1 D3 D6
ADD D6 K100 Z0
MOV D0 D100Z0

in above example value from D0 is copied to one of the D registers that is addressed by Z0 (Z0=D1*D3+K100)
changing either D1 or D3 affects where the value from D0 is to be copied (could be any D register starting from D100...).
it does not need to be fixed address.

on the other hand, if you are to use Step7 ladder, you have to use number (literal) which cannot be changed at runtime.
you enter the value by hand, save the block and download it to S7 CPU - that's it, the address is fixed.
to change it, someone has to use laptop with Step7 installed, open the block, enter new address, save,
download and again - that's it, it is fixed to another value. to change index at run time, on Step7 platform,
one must use another language because S7 ladder simply doesn't cut it. maybe some day...

[Mitsu]

i see but - i have to disagree:

in GX you can use

MOV D0 D100Z0

with Z0 being the index.

the point i was trying to make is that (with Mitsubishi) value inside index can be changed by program (or HMI or whatever):

MUL D1 D3 D6
ADD D6 K100 Z0
MOV D0 D100Z0

in above example value from D0 is copied to one of the D registers that is addressed by Z0 (Z0=D1*D3+K100)
changing either D1 or D3 affects where the value from D0 is to be copied (could be any D register starting from D100...).
it does not need to be fixed address.

on the other hand, if you are to use Step7 ladder, you have to use number (literal) which cannot be changed at runtime.
you enter the value by hand, save the block and download it to S7 CPU - that's it, the address is fixed.
to change it, someone has to use laptop with Step7 installed, open the block, enter new address, save,
download and again - that's it, it is fixed to another value. to change index at run time, on Step7 platform,
one must use another language because S7 ladder simply doesn't cut it. maybe some day...

@panic mode:

Maybe we're talking about different things here? See the entire thread for what i meant: if you use label programming in gx dev and make a variable test, array of 10 integers, you can't index the array with anything other than constants. So test[z0] isn't possible (the editor objects to this notation) . Only test[0], test[1],... are allowed. I know you can solve this by using D100z0 but that isn't label programming anymore. It's direct devices address programming.

You can do it in IEC though: test[z0], test[index],... it's all possible.

But yes, i agree that Mitsubishi is more flexible in it's instruction set and use (for example in loops and such)

This post has been edited by Mitsu: Nov 13 2009, 06:29 AM