Sign in to follow this  
Followers 0
Mitsu

Array index in GX developer

23 posts in this topic

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.) Edited by Mitsu

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
That is the simplest/only way I can think of. It just means you can't define the array in the header.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :(

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Arrays can be created in GX Works2 when using structured projects and label programming.

Share this post


Link to post
Share on other sites
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. Edited by Mitsu

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Don't mention it. Moreover, I understand that my answer do not comforted you and unfortunately did not solve the problems.

Share this post


Link to post
Share on other sites
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? Edited by Mitsu

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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. Edited by Mitsu

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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). Edited by Mitsu

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
@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) Edited by Mitsu

Share this post


Link to post
Share on other sites
The ladder + label programming that Mitsubishi introduced at some point in gx developer (and that is again included within gx works 2) is the weirdest programming "language" i have ever seen. The compiler seems completely unaware of any datatype. It just translates a label into a device address but doesn't check your code. If you define a label "itest" (device address D10 for example) which is an INT (they changed the INT to word again in gx works 2), you can code this: [DMOV K0 itest] or even [EMOV E0 itest]. It's all fine for the compiler because he just translates it into: [DMOV K0 D10] or [EMOV E0 D10] In reality though, such code should not be allowed at all (you're doing doubleword and floating point instructions on what you defined as an integer/word). This is really weird. I have never seen a programming language which lets you define datatypes but doesn't actually use that datatype definition. It is, in fact, pure "label" programming, in that you put a label instead of a device address. Nothing more. Strange stuff... Edited by Mitsu

Share this post


Link to post
Share on other sites
Hi Mitsu, In fact, GX IEC Developer also does not check data type, if you write a POU in Melsec IL language. I.e. you can specify any type of data, for example, an array of INT, and to use that start address in commands, where is used a double word or a pair of double-words as operand. In some cases it is even better because it helps avoid unnecessary commands which clearly would have appeared when compiling in Ladder Diagram. An example, I have to calculate a ratio with an integer input and with an integer fraction (multiplier/divider) and to write the result output of integer type too: Input = INT = D0 Multiplier = INT = D1 Divider = INT = D2 Output = INT = D3 Temp = ARRAY OF INT [0..3] = D512 LD TRUE MUL Input Multiplier Temp DDIV Temp Divider Temp MOV Temp Output After compilation: LD M8000 MUL D0 D1 D512 DDIV D512 D2 D512 MOV D512 D3 Edited by Inntele

Share this post


Link to post
Share on other sites
@Inntele: hmm... interesting. I can see how this can be convenient in some cases but i still find it very strange and confusing. It would be interesting to learn why both Mitsu Japan and Europe decided to do it this way. It isn't allowed in IEC ladder (probably iec regulations?) Edited by Mitsu

Share this post


Link to post
Share on other sites
Yes, if you work in IEC Ladder, you can not use a variable other type which different from type of variable, appointed for input or output of the instruction (or function, or function block). Therefore after compiling you'll get a code with MELSEC commands that are matched to type of variables. From other hand, such "mistake" in MELSEC IL compilator lets me to do own function blocks for any instructions. Often this is necessary if software developer did mistakes in manufacturer library or in standard library.

Share this post


Link to post
Share on other sites
Hello all, I wanted to reply to this old post just to give my opinion about GxWorks software. I tried the IEC programmer and then switched back to the simple old style project for some reasons. IEC project is surely more powerful than simple projects and makes code simpler to maintain, but using simple project is faster to develop and less PLC resource consuming (simple timers require calls to function blocks and devices for input/output, for example). IEC development requires an additional drawing effort in order to put FBs and wire them to devices. IEC programs can't be correctly read back from PLCs. I can't understand why Mitsubishi is disregarding the development of the simple project with labels. Really there's no much more work to do: - Allow indexes for labels in the form LABEL[V0]. It's really simple to develop. - Allow access to bits in word labels (LABEL.1). It's really simple to develop, again. - Do not enlarge the ladder size when displaying long labels. - Allow more than 11 or 17 devices per ladder row. - ST programming with more support for labels. CX developper for OMRON PLCs is a good example for a non IEC ladder editor. Maybe someone from Mitsubishi could read this post... Regards

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0