Crossbow

iQ Works Q & A

277 posts in this topic

Hi, hope you can help. I'm using GXW2 ver 1.48A. GXW2 isn't available in the UK yet (My colleague in the US gave me this copy) so support isn't available. The problem I have is the finding of unused variables to tidy up a program. In GX IEC Dev there is a function to find unused vars. This appears to be missing from GXW2. Does anyone know how to find vars that have been declared, but aren't actually used within a project? I spoke to Mitsi UK and the answer was "we don't know". I could search for them using the find tool, but I'd need to know the names of the vars that I'm looking for. Seems quite an omission if that tool has been removed. Cheers.

Share this post


Link to post
Share on other sites
Dont think it 'has been integrated yet. But why don't you switchover to structured programming than this wouldn't be an issue. As a workaround you could export to "GX Developer format file" and check it in GX Developer. Edited by Gambit

Share this post


Link to post
Share on other sites
I am using GXW2 in Structured programming mode. In fact the project in question was imported from a GX IEC Dev project. I've made a few mods to the code using GXW2 but I'm aware there are a few unused vars that were declared during this mod that are no longer used. I could keep searching through the local and global var lists, but that's such a time consuming method. As I say IEC Dev has a tool that does that for you. I think I might be going back to using IEC Dev. Although GXW2 looks more slick, there are features missing from it (not just find unused vars) that make using it a bind. Hopefully Mitsi will sort it out.

Share this post


Link to post
Share on other sites
In IEC developer you could search for unused variables which were [for me] usually declared local variables that I had forgotten to delete. Since "structured programmng" in GX works is essentially IEC developer it would be nice to have the feature.

Share this post


Link to post
Share on other sites
Has anyone here had problems with monitoring projects converted from IEC developer? I had used an early version of GXWorks2 for one project that had been converted and the monitor was not displaying any status. If I started a new project the monitor worked well. I'm hesitant to buy the new versions until this is sorted out since I need it to run.

Share this post


Link to post
Share on other sites
Hi KenE I've imported GX IEC Dev projects (Q Series) into GXW2 and not had a problem with the monitoring. I see you found the 'Find UnUsed Vars' a useful tool too. Just keeps up with the housekeeping!!!!!! My version of IEC Dev is 7.03 if that helps. Hope you get it sorted.

Share this post


Link to post
Share on other sites
I am sure that at some point, that feature will exist in GX Works2. But as of today, it is not 100% of GX Developer or GX IEC Developer. It's a work in progress integrating 2 completely different packages, and each new version of software adds or fixes new things. Like 1.55 (released in US now) fixed some of the items which could not be printed in GX2 but were available in GX Developer. Keep an eye on Appendix 12 in the GX Works2 Operating Manual (Common) for a complete list of changes each version. 1.55 also integrates GX Developer and GX Works2 so both can be installed, and when you create a project in GX2 for an A Series (not supported) it automatically opens GX Developer and creates the project there. There's no way I would go back to GX Developer, after working with GX Works2 for a year now.

Share this post


Link to post
Share on other sites
integration GX DEVELOPER and GX WORKS the wrong move . series AnS, QnA processors had to leave in the old software.

Share this post


Link to post
Share on other sites
I believe the integration is good, since those products will never be supported in GX Works2. But they still need to get the Q Safety, Q process, and Q Redundant into GX Works2. At least now you buy GX Works2 and it installs both products. GX Developer was included on the CD before, but you had to browse for it, copy it to the HD, rename it, and then install it. This is far cleaner.

Share this post


Link to post
Share on other sites
what's the point to maintain obsolete equipment.this is strange.the program worse UNITY PRO and STEP7. Edited by KAZAH

Share this post


Link to post
Share on other sites
Nothing is worse than Step 7. But if you don't like GX Works2 and all the major improvements, you can always stick to GX Developer.

Share this post


Link to post
Share on other sites
I propose to organize a poll members of the forum.whether they like GX WORKS2 Edited by KAZAH

Share this post


Link to post
Share on other sites
There is no real support for the older cpu's. The only thing it does is open GX developer when you select a cpu that isn't supported in GX works 2. That's all.

Share this post


Link to post
Share on other sites
Lately, i have been programming a couple of projects in Step 7 and to be honest, i don't feel like going back to Mitsubishi at all. And that comes from somebody who has programmed Mitsubishi during a lot of years, using Medoc, GX developer and GX works 2 on a daily basis. GX works 2 might have the edge when it comes to user interface and ease of use (note: not GX developer because that was a nightmare) but when it comes to structured programming, Mitsubishi has a long way to go. Simple ladder programming just isn't enough anymore these days and the structured ladder programming, most notably the editor, is poor. Also, for europeans, the integration of profibus directly into Step 7 is a god send. Step 7 has a rather poor user interface but i'm expecting this to change with the arrival of Step 7 v11 and onwards (the tia portal software). I'm not expecting things to change at Mitsubishi though. It's clear by now that Mitsubishi Japan has no interest at all in structured programming (hence why IEC was developed by another company) and that they prefer simple ladder with direct device address programming, just like what we had 15 years ago in Medoc. In fact, other than the hardware, nothing much has changed on the programming side of things at all. GX Works2 had a very promising start but i have a feeling that they are loosing focus on what's important in their latest updates of the software. Also, i don't get the "let's release a new version each two weeks" policy that they seem to have in Japan. Maybe they should work on fewer bigger upgrades with more important new features? The most important change i would like to see is Mitsubishi getting rid of the two completely different ladder editors (simple ladder versus iec ladder). Make one ladder editor that works for both methods of programming. It is going to be a lot easier, not only for us, but also for them. As it is now, they have to update and maintain two completely different editors (in look, feel and use) and both of them are lacking in some important areas (for example, simple ladder is still useless combined with labels). Others have done it so it is definately possible.

Share this post


Link to post
Share on other sites
I would think that knowing about IEC programming you would understand there is no way to combine the editors. They follow completely different rules. And that 'third party' who developed the IEC software also wrote MEDOC. And 'an update every 2 weeks'? Not on our side of the ocean. About quarterly here. In my opinion, they are trying to make it better, and I am pleased with the improvements in GX Works2. But everyone is entitled to their opinions, and I respect the fact that yours is Step 7 is better. Personally, I use Mitsubishi all the time, and have no plans to change any time soon.

Share this post


Link to post
Share on other sites
There's no denying that GX Works 2 offers a significant improvement over GX Developer, especially user interface wise. But i'm curious though: out of all the projects you do in Mitusbishi, how many are "simple projects" and how many are "structered projects" (using structures, labels, libraries, structured ladder, structured text,...)? Just trying to get an idea of what part of the software you use most. The difference i feel when using Step 7 is that i can structure my programs a lot more, document them properly, divide them in small re-usable functions and fuction blocks, cutting development time and having less errors using variabele naming instead of device addressing, choosing and mixing the best language for each solution,... And i know that all these things are also in GX Works 2 but i just don't find them that easy to use. I feel that each of those components in GX Works 2 have their limitations that, in the end, make the whole thing rather unusable. But in the end, it's definately a personal choice :) Edited by Mitsu

Share this post


Link to post
Share on other sites
mitsubishi trying to do something that has long made by other manufacturers.it turns out badly. Edited by KAZAH

Share this post


Link to post
Share on other sites
I wouldn't put it that strongly. Combining GX developer and IEC must have been a huge task to begin with since it were essentially two completely different programs. Now that both programs are combined in one software package, i hope Mitsubishi will continue to work on it and improve it further.

Share this post


Link to post
Share on other sites
I used to write all my programs in ladder. Then I started using structured text for mathematics and loops. Now I have begun writing my own function blocks and using structured ladder and structured text more than basic ladder. The line drawing in simple ladder is as it has always been in GX Developer, no difference. The line drawing in GX Works2, in the early versions, was a bit cumbersome, but it has improved greatly over the revisions. Now it basically draws the lines for you. rarely have to change into interconnect mode anymore. If nothing else, the built-in help and better use of screen real estate is worth it. People need to understand that this is VERSION 1 software! It's being improved as fast as it can, and I have seen some of the recommendations I submitted to Mitsubishi in a training class already being worked on. Of course it's not perfect. Neither was GX Developer 1.0. Neither was RS Logix 1.0. Or Step 7 1.0. Show me one vendor who out the door had a perfect programming software at version 1.0. If it was perfect, then it would still be version 1.0! Nobody is at version 1.0...

Share this post


Link to post
Share on other sites
In a way, this is true. Another point of view would be that these are actually GX Developer 9 and IEC 8 rolled into one package. But anyway, both packages should never have been made separately. So much time was waisted on maintaining both, realising it's not the right way to go and then joining them together. Also, i'm surprised to hear that IEC was developed by Beijer. Is this confirmed to be true? I always assumed that IEC was made by an external software company without any plc programming knowledge, and that they were guided by some sort of Mitsubishi workgroup. I find it hard to believe that Beijer, being plc programmers themselves, and being known for their excellent Medoc (for that time period a very good programming tool) made that awful IEC editor. Iit seems the IEC editor has been developed from the start with one goal in mind: to give the programmer complete freedom in editing code. In IEC everything is possible and you can do the most crazy things (like overlapping label names/comments over code or bending lines in all sorts of crazy ways). But imo, that is not the purpose of an editor. In fact, IEC reminds me more of a painting program or drawing tool than a plc program editor. To me (and yes, this is a personal view), a good program editor should let the programmer concentrate on the actual code and take most, if not all, layout work out of the programmers hands. Let's take just one of many examples in IEC: the IN/OUT from instructions, functions and function blocks. In the IEC editor, you can detach the variabele pins from the IN/OUT pins on the instruction/fc/fb "rectangles". In fact, if you aren't in some kind of mode (interconnect or whatever, can't remember) and you select the instruction/fc/fb and move it, the variables get detached... What on earth is the point in being able to detach pins from IN/OUT in the first place? How many times will a programmer want to move the instruction without the variables attached to that instruction? What's the point of IN/OUT without anything connected to it? It gets even crazier: you can actually draw a line from an IN var to an OUT var, and place an instruction on top of that... Seriously, you move the instruction and a line beneath it connecting the IN to OUT var becomes visible. Also, the name of the variables attached to an IN/OUT can not be wrapped (= divided over multiple lines). This means that if you have a label with a long name attached to an IN/OUT, you have the following possibilities: - either you display only a fraction of the label name (an option in the menu) which makes the program more difficult to read (lack of complete variable names) - either you make your layout so that there is room for the longest variable (yes, you have to draw/layout your ladder depending on the lenght of the label names... horror) - either you overlap your ladder with the label name (which is sloppy, but again possible). Solution: there should be label name wrapping at IN/OUT and the height of the instruction/fc/fb "rectangle" should adopt itself to the height of the label names attached to IN/OUT automatically. Another example: why isn't the comment box at the start of a network separated from the network itself (something like Step 7 in Siemens). Why does it have to be a part of the network code? If you draw a network and realise afterwards that you need to add an extra line in the comment window, you actually have to move the entire code down before you can make the comment window bigger. You have to manually move the code downwards... to make room for a higher comment box. Or, in the "everything is possible" way, you can actually overlap your comment window over your code. Can there be something simpeler, more elegant and easier to use than the comment system Siemens uses. Just give each network a comment and separate the comment box from the network code. That way you can resize the comment as you want, independant of the code "network" itself. Also, the whole "select", "interconnect", "auto connect", "guided mode" is so complex and frustrating and i do not see the point at all in it being there. As a programmer, if i place a contact over a line, i want that the editor breaks the line and inserts the contact, otherwise i would not place the contact on that line. Also, if i remove a contact, i want the editor to close the line again. Now in IEC, depending on the mode you are in and you place a contact on a line, the contact is placed on top of that line without breaking it. Seriously, is there any point at all in this kind of "feature" where your contact overlaps a line? And removing a contact, the editor does not close the line. You have to draw a line to close it. And that short line you just drew, is treated as a separate line from the two lines it connects. Which means that depending on the mode you are in, you try to move the whole line and you end up moving that one short bit that you just drew. And then people tell me i have this problem because i'm not in the right "mode"? Do you need to be in certain mode to expect the most basic, logical and normal behaviour one expects from an editor? Is there any point in lines with gaps, lines with overlapping contact, lines that can bend in all sorts of directions before reaching the next contact,... Is there any point in a line being a collection of a dozen smaller lines?... Just about anything is possible. You can insert empty networks with no code in them. At which the compiler will give a warning. Any point in empty networks? Or how about the variabele selection window. If i want to select a variabele, why can't i have a simpel dropdown window (the one in simple ladder is rather neat). Why do i need to go into that complicated varaible selection window? You can overlap comments, labels and ladder over eachother. Labels can overlap to the left side of the network. If you try, you could probably overlap labels with the pointer name at the left side of the window. If you change the wrapping height of the labels for contact and coils, iirc, your layout does not adopt itself automatically to that new height. Which means you have to re-arrange / redraw your code to adopt to the new height. Also, iirc, the monitoring values overlap everything (ladder, comment,..) while monitoring. I could go on and on. There are so many things in the IEC editor that i just don't get. I don't understand the use of them. I don't understand the point. I also believe that the state of the IEC editor is a big reason why many are reluctant to swith over to structured programming. I've tried to adopt and learn this editor multiple times. And it always ends up in frustration and unbelieve. Unbelieve in how something so simple as a ladder editor is made so complex. The ladder in Siemens, in comparison, while basic, is so simple but get's the job done so much quicker. It does the things you expect it to do. Nothing more, nothing less. No editor should need interconnect, auto connect, select or guided mode to draw a simple ladder. In fact, the whole addition of these modes is the best proof that the editor just isn't good. In short, IEC editor = everything (which no one needs) is possible but you have to do it all yourself (even if you don't want to) = big waiste of time + frustrating. Mitsubishi should rethink the whole thing and start from scratch. As it is, it's depressing to know that they will probably use that same "thing" for the Function Block Diagram. Phew, that's the last thing i'll ever say about that. Edited by Mitsu

Share this post


Link to post
Share on other sites
Bravo Mitsu!I have similar thoughts.It is interesting and software developers read this post? Edited by KAZAH

Share this post


Link to post
Share on other sites
Clearly there are issues with your familiarity with the editors. There are reasons why interconnect and selection mode are the way they are. Suppose you write a command like INC, decide later it needs to be INC. With auto-connect off, delete the old instructions, and all the connection points stay put. Now drop the new command right back in place, and you're done. There is no pleasing everyone, and I give them credit for improving upon the old products. GX Works2, even when used as a simple ladder editor, is so much cleaner and more user friendly than GX Developer and GX Simulator and GX Configurator, which all were sold an operated individually. Everything is built into GX Works2, cross reference can show addressed used in the configurators and parameters, and simulation is built in. Add all that to the better use of the screen space (docking windows, auto-hide windows, automatically changing toolbars, etc.) and of course F1 help which we've begged for for 10 years, and it blows the doors off GX Developer.

Share this post


Link to post
Share on other sites
I give them credit for improving old products too. As i said numerous times, GX Works2 is by far the best programming software they have done so far. I would never want to go back to Gx Developer. And i still look forward to each new version they release to see what they have improved. We've come a long way from version 1.05 of GX Works2 (which, iirc, was the first version i saw). That doesn't mean we should ignore the things that need improving. For me, improving the structured ladder editor is a key issue and the most important thing. After all, it's the core functionality of any programming software. It's where the programs are made. Your cross reference might be excellent, your user interface might be splendid, but in the end it all boils down to how easy and fun it is to write a plc program.

Share this post


Link to post
Share on other sites
If you don't like the editor with auto-connect off, then don't turn it off. It's that simple. Why take that feature away from others who like it? And as for replacing an instruction with another, it's not a matter of an idiot writing ADD when he means SUB. That comparison is really out there, and so clearly you don't see my point. How about if you updated a user-created function block and added new pins?

Share this post


Link to post
Share on other sites
Other plc programming software can update the pins of a changed function block without the need of disconnectable pins and auto connect off. For example, "update block call" in Step 7 is a neat solution for that problem. It can actually remap variables if you insert new pins in between the other ones, something which isn't even possible in IEC iirc... which is why they need disconnectable pins and auto connect in the first place. So that the user can manually reconnect every pin when a function block is changed, because there is no other option. Which is something i forgot in my previous list. Updating function blocks in IEC is a mess. Edited by Mitsu

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