POCKO

Hi Wasan, As per the original post, comm's between MX Component and GX Works 3 is fine. The issue is between MX Component and Citect. Citect MXCOMP driver is the latest available but this is a few years old and it was written before the IQ-R series was released. That same Citect MXCOMP driver works fine with GX Works 2, just not GX Works 3. For sure it needs to be updated by Schneider/Aveva and I am sure this is where the fault lies but this will take forever to sort out with them. Just wanted to see if someone had an immediate work around or has tried with any success. It'll end up being a port related issue. Thanks...

Hi Wasan, Thanks for your reply. For this testing I have been using MX Components v4.17T (latest) and i have been trying to get it working using "GX Simulator 3" settings unsuccessfully.

Hi All, Have recently embarked on a project that has required me to change over to GX Works 3 in order to link an IQ-R120PCPU to a Citect 2018 SCADA package . In days gone by under IEC Developer and GX Works 2 it was quite easy to establish communications between the programming package running in simulation mode and a running Citect system using the MXCOMP driver via MX Components to perform offline testing. Can't seem to find a way to get it to work under GX Works 3 though, has anyone tried a similar setup Simulated logic in GX Works 3 is running fine and can modify the IO from inside MX Components "PLC Monitor Utility" program so there is no issues there, just cant get Citect to communicate. MX Component comm's has also been proven reading/writing variable to an excel sheet with GX Works 3 in simulation mode also. Attached are the files for getting GX Works 2 up and communicating to Citect 2018 via the same method i am trying to get working in GX Works 3 in case anyone ever needs to use that method. Any help would be appreciated.     GXWORKS 2 & CITECT 2018.zip

Good to see you're up and running. As kaare_t pointed out if we knew you had a screen a few days ago you would have been up and running a few days ago. You pretty much need to list all the hardware and software you're using. Once i knew you had the screen i had the same thoughts as kaare_t but you may have missed it at the bottom of the post. I'm still interested to see if you can get the project i posted running. I had some nasty experiences with IEC Dev v7.03 and went back v7.01 pretty quickly. It was compiling my projects differently to v7.01 and creating errors on compile that were never occuring in v7.00 and 7.01 so i dumped it. I never got a chance to find out why, but if i get time i'll reinstall it and take a look. All the best - Pocko

Ahh... I forgot that on the night i uploaded it this site would not allow the upload of .pcd files or even a .zip file, so i had to package it up using WinRAR, so the file extension is .rar. Go to the web and download a copy of WinRAR and unpack the file. Then you find .pcd project. Sorry about that, as i said at the time it was getting late when i was doing it...

Can't say i've ever seen that message. In the second box use a path such as C:\MELSEC\GX IEC Developer 7.01\Example\TEST\ and see how you go... What version of IEC Dev is it?

OK... The .pcd file i posted is a complete project backed up from inside GXIEC Developer V7.01. Open up IEC Dev and on the top menu click on "Extras" and then on "Project Restore". A window will pop up, click on the top Browse button and navigate to the saved location of the file i posted, then click on the bottom Browse button and create a blank project wherever you wish. Then your project will be compiled ready to go. I know the function blocks with REAL data outputs will go to five decimal places, I'm not sure after that... Be careful with your mapping of the D register's if you use REAL's. Using INT's your D addresses may be eg. D0,D1,D2 etc. For REAL's leave a gap as they are 32bit, so they will now be D0,D2,D4 etc. Break open the different FB's and take a look at the data conversion instructions and read up on them, particularly the INT_TO_REAL instruction. Good luck - Pocko. P.S - Just noticed you make mention of using E-Designer. Stupid question, but i have to ask - Do you actually need your logic to do stuff based on the REALS or are you only doing it to display them on the HMI screen? The Beijer screens can read the analogs, do the conversions and scaling's inside the screen and it may save you steps if you don't need the REALS inside your logic. They can also be made to read, scale, convert the 16 bit data and spit it out as 32 bit data back into the PLC converted ready for you to use in your logic if you desire. They are a nice screen to work with. Actually used one on the current job purely to get floating point Modbus RTU data into an older Mitsu PLC.

Hi All, I don't know too much about ST but does that code have divide by 0 protection? Anyway i've posted a project that may be of some interest to you inregards to scaling to your INT to REAL's. This project's library uses modified Beijer function blocks that i've modified for my own use. They still use quite a few steps, but not as many as you've stated earlier. Inside the project you will function blocks to convert most common data types. There are two types of each FB, one type has some built in alarms driven off the scaled output side, the other doesn't. I have the FB's set up to use REAL inputs as alarm set points which is what i like. You might want to rip open the FB's and then use INT's as the set points which will save you some steps. May not be the solution you want steps wise, but i know these will do the job you wish to do... Cheers - Chris. P.S - I'm half asleep as i'm piecing this demo project together, so if the project doesn't work for you let me know and i'll sort it out !! FX_ANALOG_SCALING_PROJECT.rar

Hi Again, Thanks to those who replied. I like the idea suggested of a sub-category in the download section. I'm not sure how much work this would be for the site admin's - maybe one of them could forward an opinion on this. I don't believe the section should be intended to mirror either Mitsubishi UK or Beijers sites, thus it would kind of eliminate the version control issues between all three sites. The repository should be a place to post whatever function block's you think others would find useful or interesting and for others to comment on them and possibly improve them. With regards to the file format, packed .pcd files of the complete compiled project set up ready for GXSimulator testing would be ideal, but even the smallest ones are still pretty sizable for this sort of project. Exported .asc files of the function block from a library are very small, but then a user would still need to do a fair bit of work to create a project POU to set the FB up for testing. So I'd suggest that the best way would to create a library .sul file with only the FB you want to exhibit inside. In it declare any global variables and DUT's if required for the function block to work and then post that. It would also be wise to include a project POU exported .asc file of the function set up ready to work. So then it would be a case of the user creating a blank project and importing the two very small files, compile it and you're ready to test. Bye for now - Pocko....

I should have mentioned Mitsubishi Automation UK's site in the original post as you are correct they do have a partial collection of the Beijer function blocks (but a lot of them out of date!). To get to them you will have to sign up to their site, login in, then go to Downloads and then to Program Examples. The main place to go to though is over at Bejiers support section . The site's not in English so it's a bit awkward to navigate around, but you get the hang of it pretty quickly (they do have an English section, it's just not as comprehensive). As far as I'm concerned this site is by far the best Mitsubishi knowledge base on the web. If you are new to IEC programming this should be the first place you visit. Whilst I'm on the subject of Beijer if you have a problem their tech support there are great to deal with. As a side note if you deal with Mitsubishi PLC's linked to Citect they have some good stuff there in the SCADA section. All the best, Regards - Pocko.

Hi All, I mainly work with IEC Developer and I'm now toying around with GXWorks. Programming with function blocks in IEC Developer and GXWorks makes your code look a lot neater and you can get a lot more of your I/O on screen at once. It also make your code easier to re-use across projects. Beijer are masters at function block development for the Mitsubishi programming platforms and I use many of their "intelligent function module" blocks which simplify the set up of Analog cards, CC-Link IO and VSD's, PID control to name a few in both their original incarnations and I have also modify theirs to suit myself. I'd be interested to hear people's thoughts about the posting of function blocks here for discussion, learning, review and further testing and development. This would lead to having access to a powerful library on top of the libraries that are built in both IEC Dev & GXWorks (the Standard Lib and the Manufacturer Lib). The aim should be to end up with an arsenal of function blocks that we know are stable and safe to use in a production environment. Suggest a topic (say a star-delta motor starter) and see who can come up with the most functional and cleanest function block solution using the least amount of steps. Do some research on Codesys an OSCAT which is an open source library for Codesys to see what i'm on about. AB have many function blocks available for download at theAB sample code home , and Schneiders Function block home . I come from a petro/chem background and the process control function set of IEC Dev and GXWorks leaves a lot to be desired compared to say AB's RSLogix 5000 and Schneider's Unity. Yes, PX Developer can handle things in this field better but few plants have Mitsubishi's process control processor's so let's not go down this path with this topic! So in short why not come up with our own set? I have many function blocks to handle analog scaling, data type conversion, PID control, flow totalizers, motor control, CC-Link I/O device control, actuated valve control etc that i would be willing to share. Most are just simple day to day ladder logic made in to function blocks. If would be best to stear clear of ST and SFC language and stick to ladder and native FB for this project like this. I understand a lot of people are very protective of their code as you do spend a lot of time and dollars developing reusable function blocks to give you an "edge" on your competitors and whilst we may be in one sense competing against each other for work to a degree, at the same time it's a big word and the chances that you and i are quoting the same job are very unrealistic. Once a function block has been made it's very easy to export that function block as an ASCII.asc file which could be posted as either an .asc file or as text. What do you think? Cheers - Pocko.

I started programming Mitsu PLC's after changing over from AB's around 5 years ago. I tried using both GX Developer and IEC Developer to figure out which platform I'd settle with and quickly realised for me personally GX Developer was (and still is) archaic and sucked compared to IEC and so for around 4 years now i've been with IEC. Congrat's to Mitsubishi for their GXWorks efforts thus far as i believe you get the best of both worlds (GX Dev & IEC Dev) and I like the path it's heading. From my experiences most of the world (outside of America) are using IEC languages and for me IEC programming software make it a lot easier to swap between brands of PLC when the base instruction set does not change. One of the primary reasons I went for IEC was the way it handled tags. Which brings me to a problem i have encountered. I'm doing some testing using GXWorks 2. It's an older version (1.05F) and i've struck an issue when converting over my IEC projects. On compiling it seems to complain about the length of my tags, though the documentation states pretty clearly the limit is 32. Can anyone confirm if this fixed in a newer version? I get the following pop up - I also have an issue with GXWorks 2 not remembering the last state I left the Project window in when i shut down the project. In IEC if I have a project expanded and shut down the project, the next time I open it the project tree structure is exactly how i left it. In GXWorks if I expand the project tree and then shut down the project then open it again I have to go and expand all the parts of the tree again. In IEC you could right click on any part of the project and expand or collapse that part of the project. A small thing but it annoys me! I'd be interested if to know if one of you guys have come across it.. Also i'm not sure but i think Beijer wrote the IEC Developer software for Mitsubishi (although I stand to be corrected on this), who's doing it this time around? Cheers - Pocko

Hi TMU, Can you please tell me if you are using it as Modbus Master? As this the mode I have had trouble with - in slave mode things are working fine. Also if you could be kind enough to forward the project you used it on, or even just a text dump of the MT91 intelligent function module set up it would be great. It be interested to look at your set up. Have a great day, Regards - Chris.

Thanks for the info, it seems to be what i'm after. I've been working on other parts of the project this week and hopefully i'll get a chance to do the set up the same as in the powerpoint presentation. The E-designer sample will be of use to me too as we have a few E1000 screens around the place and one will using modbus. I appreciate the help, Kind Regards - Chris.

Hi and thanks for the reply. I'd love to get hold of the examples you have as this thing is really doing my head in! Feel free to attach the file to this thread, email them to me or i can give you access to my ftp site, i'm open to any method that suits you best. All the best, Regards - Chris.