#MELSOFT GX WORKS2 VIEW THAT I CAN SEE THE 16 BIT WORDS SOFTWARE#
#MELSOFT GX WORKS2 VIEW THAT I CAN SEE THE 16 BIT WORDS CODE#
#MELSOFT GX WORKS2 VIEW THAT I CAN SEE THE 16 BIT WORDS DOWNLOAD#

#MELSOFT GX WORKS2 VIEW THAT I CAN SEE THE 16 BIT WORDS SOFTWARE#

Maybe someone from Mitsubishi could read this post.Today I would like to share to everyone the GX-Works2 V1.560J software which is the latest versionДЄlthough Mitsubishi has now released GX-Works3 software, but if you do not need to use FX5U PLC programming, this GX-Works2 software is sufficient and its advantage is that the configuration requirement is much lower than that of GX -Works3 CX developper for OMRON PLCs is a good example for a non IEC ladder editor. ST programming with more support for labels. Allow more than 11 or 17 devices per ladder row. Do not enlarge the ladder size when displaying long labels. Allow access to bits in word labels (LABEL.1). Really there's no much more work to do: - Allow indexes for labels in the form LABEL. I can't understand why Mitsubishi is disregarding the development of the simple project with labels. IEC programs can't be correctly read back from PLCs.

IEC development requires an additional drawing effort in order to put FBs and wire them to devices.

#MELSOFT GX WORKS2 VIEW THAT I CAN SEE THE 16 BIT WORDS CODE#

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).

I tried the IEC programmer and then switched back to the simple old style project for some reasons. Hello all, I wanted to reply to this old post just to give my opinion about GxWorks software. It is, in fact, pure 'label' programming, in that you put a label instead of a device address. I have never seen a programming language which lets you define datatypes but doesn't actually use that datatype definition. It's all fine for the compiler because he just translates it into: or 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). 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: or even. It just translates a label into a device address but doesn't check your code. The compiler seems completely unaware of any datatype. 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. to change index at run time, on Step7 platform, one must use another language because S7 ladder simply doesn't cut it.

#MELSOFT GX WORKS2 VIEW THAT I CAN SEE THE 16 BIT WORDS DOWNLOAD#

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. you enter the value by hand, save the block and download it to S7 CPU - that's it, the address is fixed. on the other hand, if you are to use Step7 ladder, you have to use number (literal) which cannot be changed at runtime. 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.). I see but - i have to disagree: in GX you can use MOV D0 D100Z0 with Z0 being the index. Interestingly though, you have to harcode the array index in the gx dev ladder also (which is what this topic was about). So in short, i was just talking about the ladder editor itself. But i'm very slow in putting code on screen in the iec ladder compared to the gx dev ladder or step 7 ladder. Maybe it's just an adjustment period though. In the iec ladder, you need to do it all yourself. Iirc in the step 7 editor for example, you don't have to draw lines or at least not that many. In short, i find the iec editor a bit too 'loose'. I tried guided mode (which is more about keyboard use) but didn't find it all that useful either. The fact that you need to switch from selection mode to interconnect mode + auto connect and whatnot seems far too complicated to me. Also, every big line is treated as a collection of small lines which i find very annoying at times (especially when moving stuff around). Particulary the fact that you actually have to draw each connection line with the mouse. 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. (i actually find the mitsubishi instruction set quite impressive and the device addressing easy and simple).

I'm not talking about the instruction set, memory layout. I'm merely talking about the editor itself: the manner in which instructions are put on screen (with the mouse, keyboard).

Melsoft gx works2 view that i can see the 16 bit words