iQ Works Q & A, For discussion of all parts of iQ Works Options

[DR.MMPLUS]

secret/

Dear All!

I'm a new member. I got the new GXW2 version from the German My Mitsubishi page. I think you must be a registered member and the you are able to download all demo software from there. I had some bad experience with the newest version. If you delete a task all POU's related to this task are also deleted. That couldn't be. The German Hotline told me that this a still a demo version. The new final iQ Works (Include the new navigator like ProjXStudio, GT Designer 3 and MT developer) will be ready for sale late October 2009. Let's see.

This post has been edited by DR.MMPLUS: Jul 14 2009, 02:46 AM

[KAZAH]

http://wwwf2.mitsubishielectric.co.jp/melf...works/index.htm

[Crossbow]

Some of us can't read Japanese... And that page wasn't there 2 weeks ago.

[Mitsu]

From the brief time we had with pre-release versions, some thoughts on GX works 2 (keep in mind that i'm only used to Gx Developer, not IEC):

positive:
- better implementation of the intelligent function modules, including the intelligent function module monitor. Far more user friendly than in gx dev
- windows environment (at last!) with multiple windows open, dockable, movable,... feels like a modern programming environment. Drag and drop, environment preferences (fonts, colors,...)... good work there
- watch windows: very useful for monitoring
- mixing of 3 different languages in one project possible (gx ladder, iec ladder, structured text)
- the gxdev ladder has been improved (things like easy edit with CTRL+cursors, the editor guessing what you want to do, dropdown with instructions, dropdown with label names...). Again, good work.
- multiple global label lists: ability to divide global labels lists into smaller, more manageable lists
- anything within a project can be copied easily to another project (things like plc parameters, pou's,...). Just copy and paste
- ability to open a project as read only
- device memory has been reworked: custom dwr's,...
- very neat library implentation, with the ability to put structured datatypes, global labels and such within a library. Once imported into a project, everything within the library becomes available within the project.
- cross reference (never used it in gx developer)
- program feels quite fast
- ability to make and save different connection setup's to the plc (usb, rs232, ethernet,...). Very useful

There are probably others i forgot.

negative:
- only one gx dev ladder can be assigned to one task and one task to one program file. In other words, the limitation to divide gx dev ladder into smaller chuncks is exactly the same as in gx developer. Gx dev programs can only be divided into program files. Program files = loss of steps (due to 512 byte chunks of memory size for each program file) + more difficult to manage in the plc. Please Mitsubishi, fix this and allow more gxdev ladders into one task (as with the iec ladder)! Let the compiler join them together and put an END in.
- using labels, the instruction size in gx dev ladder becomes wider which means you can't put much code into one line (a line is still limited to 11 contacts wide). Give us the ability to use more contacts per line or divide the label name into two lines.
- profibus is still unknow as intelligent function module.
- gx dev ladder: still no way to document the code more. I understand the 64 char limit but personally, i have never written any statements to the plc. I don't see the use. Just get rid of that and do it like the iec ladder
- gx dev ladder: no multiple undo's

This post has been edited by Mitsu: Sep 9 2009, 03:32 AM

[Crossbow]

Some comments on your post...

1. Program blocks are not 512 steps. The step count depends on the CPU memory size. Like a Q02H uses 256 step blocks. The iQ processors uses 1 step blocks, so no memory loss.

2. Profibus is known, but GX Configurator-DP is not built in the way the other intelligent module utilities are. It can be imported in the Project menu.

3. You can use more than one statement on a rung, so you have limitless documentation options. Also keep in mind, if you put the statements and notes in the CPU, the next programmer to have to upload will have documentation without the original GX Developer files. I ALWAYS do this on my Q projects, as the next programmer will want all the documentation he can get to help explain my programs.

[KAZAH]

half-assed product.

[Mitsu]

Some comments on your post...

1. Program blocks are not 512 steps. The step count depends on the CPU memory size. Like a Q02H uses 256 step blocks. The iQ processors uses 1 step blocks, so no memory loss.

2. Profibus is known, but GX Configurator-DP is not built in the way the other intelligent module utilities are. It can be imported in the Project menu.

3. You can use more than one statement on a rung, so you have limitless documentation options. Also keep in mind, if you put the statements and notes in the CPU, the next programmer to have to upload will have documentation without the original GX Developer files. I ALWAYS do this on my Q projects, as the next programmer will want all the documentation he can get to help explain my programs.

1. On a regular Q-cpu, program memory is divided into chunks of 512 bytes (128 steps). If you program file is 4 steps (bad example) you loose 124 steps. If you program file is 130 steps, you loose 126 steps. Granted, it was worse in the older Q-cpu's (each chunck was 4096 bytes, iirc). And even without the loss of steps, managing 20 program files in a cpu is annoying. The system of tasks is nice. Why not use them for gx dev ladder?

2. When you open a project with a profibus card in it, Gx works examines the iparam file and detects and "unknown module". It shouldn't be an unknown module because it's a profibus module. Furthermore, it uses the same mechanism of autorefresh, just like any analog module and such. For years, there have been promises of better integration of profibus. But since profibus is mostly an european thing, Mitsubishi doesn't care a lot for it (their A5NP/A7NP profibus protocol for frequency converters is the weakest of all the freqeuncy converters i had the opportunity to use).

I'm curious: what exactly can you import in the Poject menu? A profibus config file? How does it work?

3. Don't really understand or see the use at all. The next programmer will have the project on harddisk anyway? I assume you manage and keep your projects on disk/on a server/...
Also, for more complicated code, a couple of lines of statements, limited to 64 chars wide, just isn't enough. And it's annoying to type.

Forgot a negative point:
- after so many years, still no multiple undo's in the gx dev ladder.

[Mitsu]

half-assed product.

Can you be a bit more precise as to why you don't like it?

[Crossbow]

half-assed product.

This thread is to provide Mitsubishi and users with some feedback and tips/tricks on the product. 'Half assed product' doesn't really add anything of purpose to the discussion.

[Crossbow]

1. On a regular Q-cpu, program memory is divided into chunks of 512 bytes (128 steps). If you program file is 4 steps (bad example) you loose 124 steps. If you program file is 130 steps, you loose 126 steps. Granted, it was worse in the older Q-cpu's (each chunck was 4096 bytes, iirc). And even without the loss of steps, managing 20 program files in a cpu is annoying. The system of tasks is nice. Why not use them for gx dev ladder?

2. When you open a project with a profibus card in it, Gx works examines the iparam file and detects and "unknown module". It shouldn't be an unknown module because it's a profibus module. Furthermore, it uses the same mechanism of autorefresh, just like any analog module and such. For years, there have been promises of better integration of profibus. But since profibus is mostly an european thing, Mitsubishi doesn't care a lot for it (their A5NP/A7NP profibus protocol for frequency converters is the weakest of all the freqeuncy converters i had the opportunity to use).

I'm curious: what exactly can you import in the Poject menu? A profibus config file? How does it work?

3. Don't really understand or see the use at all. The next programmer will have the project on harddisk anyway? I assume you manage and keep your projects on disk/on a server/...
Also, for more complicated code, a couple of lines of statements, limited to 64 chars wide, just isn't enough. And it's annoying to type.

Forgot a negative point:
- after so many years, still no multiple undo's in the gx dev ladder.

Regarding 1, tasks is an IEC concept. Mitsubishi just can't change the way ladder is managed, as it ruins the backward compatibility of the code. Simple projects in GX2 will always follow the same rules which have always been followed in Mitsubishi format ladder logic.

Regarding 2, I haven't done it, nor do I have programs with Profibus which I can import to see. It imports something from the GX Configurator-DP configuration file.

Regarding 3, how can it hurt to put documentation in the PLC? I'ev been on hundreds of jobs without source code, and with an old floppy disk left in a control panel years ago by the manufacturer which can't be read anymore. To assume you always have a copy of the original files is crazy. I worked as a service tech, and many people didn't even know what a PLC was, let alone have copies of the code. They had no idea it had a program. Now in a controlled environment like a large automotive plant, I would expect that backups exist of all PLCs. But in the small shops and farms and such, that's rarely the case, as they don't worry about it until it doesn't work.

[Mitsu]

Regarding 1, tasks is an IEC concept. Mitsubishi just can't change the way ladder is managed, as it ruins the backward compatibility of the code. Simple projects in GX2 will always follow the same rules which have always been followed in Mitsubishi format ladder logic.

Regarding 2, I haven't done it, nor do I have programs with Profibus which I can import to see. It imports something from the GX Configurator-DP configuration file.

Regarding 3, how can it hurt to put documentation in the PLC? I'ev been on hundreds of jobs without source code, and with an old floppy disk left in a control panel years ago by the manufacturer which can't be read anymore. To assume you always have a copy of the original files is crazy. I worked as a service tech, and many people didn't even know what a PLC was, let alone have copies of the code. They had no idea it had a program. Now in a controlled environment like a large automotive plant, I would expect that backups exist of all PLCs. But in the small shops and farms and such, that's rarely the case, as they don't worry about it until it doesn't work.

1. I never suggested that tasks should be in a simple project. But how about a structured project? I hoped that with bringing both languages into one program, gx dev programmers would benefit from the structured approach if they decide to choose that path (structured project). Seriously, having 40,50k step programs without the ability to divide it into smaller chuncks other than program files is pure madness.

2. Ah, you probably mean the i/o mapping ascii file for iec developer or the iparam file...

3. Never considered it from that point of view. We never do anything else than our own programs so it's not an issue for us.

[ushidayo]

Something I discovered when installing the navigator part of IQ works:

Navigator has an updated tag database (modified MXChange?) that doesn't like the MX Change installed with IEC Developer 7.03 and crashes during install.

No useful message was given during the crash just "path not found".

This might just affect the Japanese version. But if anyone has trouble when Navigator is released globally, try uninstalling the old MX Change database (you might also need to remove registery entries that refer to MX Change).

Also I found that the MX OPC Server version 6 can't import tags from the new Navigater database. I hope they issue a new OPC Server compatible with Navigator...

[Crossbow]

I would expect that MX OPC Server 6.0 cannot talk to Navigator, since Navigator wasn't even written when MX OPC Server 6.0 was released. I would expect there will be updates to the MX OPC Server at some point, but who knows.

[Mitsu]

I was just wondering: did someone ever program using labels (global/local variables) in GX Developer? Since the label name can't be divided into several lines (unlike IEC) and since the contact size is limited to 11 contacts wide, the number of instructions on a line is very limited, to a point of being almost unusable.

This is one of the few things i hoped they would have fixed in GX Works 2 but that isn't the case. Which is a shame. Since it makes using labels+structures totally unusable yet again. Apparently, from what i've heard, Mitsubishi knows it's a problem but they are in no hurry to fix it. Frustrating.

This post has been edited by Mitsu: Oct 23 2009, 02:18 PM

[KenE]

Does anyone have any issues monitoring a converted IEC Developer project in GX works 2? I converted a project as a test and have it running on a machine, but I am unable to monitor the project. It acts like it is monitoring, but nothing is highlighted, even though I know these bits are turning on and off. I can't turn bits on or off either. Thank you in advance.