kaare_t

"eMES" = "MES Interface IT" And the eMES module functions like an OPC server with drivers to Rockwell++++

If you only have (or want to log) Mitsubishi Q-systems you can get away with the more simple "MES" module instead of the "eMES"...

That's no problem, just "document" (tell us what you modified) at first (like you just did).... Then we all know what "corrections" you've done and why you did it.

I don't understand why the project had to be modified to compile...... I just opened the project in GX IEC 7.03 (and presse OK to convert the project database to IEC 7.0 database type) and compiled it without errors..... You shouldn't have to modify anything!!!

What kind of ladder? GX Developer? GX IEC Developer?

Works fine for me:

Your project contains system variables from M512. This means that they are handled by the compiler and are not statically assigned! Gambit's printout shows everything in your application. Basically all the devices you can see are "Global" variables (statically assigned addresses), while the local variables (the variables which have only a name) are handled by the compiler (and may get a different address at compile time). The printouts shows everything.

Yes, GX Works 2 opens IEC projects (except FX-Series)!!!

No. At this time GX Works cannot import GX IEC FX PLC projects. However, if you would like, I could take your existing project, convert it to a Q PLC, import it to GX Works and then change it back to FX PLC....... Regarding the A PLC, GX Works won't work on that. This would be no problem at all for me. The same with downloading/uploading the code to a PLC, it's done in a matter of minutes, the only problem is that you won't have the source files and the comments will probably not be uploaded in GX Developer..... Let me know what you want..... BTW do you speak Swedish (or any other Scandinavian) language? Inntele: Sorry, my mistake!

Hi Inntele. His problem is that he doesn't have GX IEC Developer at all (he only has GX Developer)..... Thanks for the contribution but I think you've misunderstood the topic a little.....

Swedish

If you must have it in GX Developer format I guess some of us could download the GX IEC project to a PLC, and then use GX Developer to upload the project again..... I'm pretty sure this works, and I could do it (or Gambit could do it)....... I'm not able until friday, anybody else any sooner?

Hi. When using online transfer, the compiler assigns the next availabe (free) device to any newly created device. This means that your existing program is not changed at all and you can safely do any kind of online transfer while the PLC is running. The compiler will never change your devices during run-time. However if you compile your complete program (rebuild all) and transfer it to the PLC, the local variables may have been changed and therefore it's at good practice to reset the PLC after a program transfer. But this only applies when re-compiling your complete project. Regarding PC programming you cannot compare PLC programming at all. PLC's use continous scanning while PC's normally use event driven programs. If you make an infinite loop in a PC program, the devices inside this loop will not be disposed/loose its value. OK?

This would all be a bit easier if you provided more information.... What is your programming language? Flowrate/pulses Resolution needed PLC Type (see you provided that now) Give us some info and it's easier for us to help you.

Hello. Do you use GX Developer or GX IEC Developer? In GX IEC Developer you have an instruction which is called "SPD". This instruction use one of the physical inputs (X), counts z number of pulses and automaticly scales the output so this is basically what you need.....

Exactly

Agree with you. Modbus has been around for "years" for Mitsubishi (slave only on the old A-Series), however the Master has only been there a couple of years for the Q. But then again; Modbus was developed in the 80's, and has been very popular in Europe since the 90's so I would say that they were VERY late with the module..... We've used Beijer Developed function blocks for Modbus up til a couple of years ago (when the module(s) came). So relatively speaking and comparing to others, the Modbus module(s) came VERY late!!! Why shouldn't we see Profinet? Most distributed IO supports Profinet and so does other brands (to be able to communicate with distributed IOs of other brands), so why shouldn't Mitsubishi develop a ProfiNet module? Therefore I stand by my previous statement: Mitsubishi use a lot of time testing and approving any product to ensure that there are no bugs, but then again this causes most products to come out a bit late compared to others.

Mitsubishi are quite slow on developing "the newest" modules (where's Profinet? The Modbus modules are quite "new" compared to other....), and I would say that most other manufacturers releases the "hottest" products much sooner than Mitsubishi which of course has it's drawbacks. But then again, when Mitsubishi first releases a product it is tested, verified, checked and studied to make sure that it is of the best quality. I think Mitsubishi products have that little edge of extra quality when it comes to the hardware.....

Did you enable a "MELSOFT Connection" in GX Configurator EN? You have to set up the card to allow for GX Developer. Open GX ConfiguratorEN, under "Open Settings" pick one of the connections and select TCP->MELSOFT Connection. Now you should be able to use GX Developer against the ENET module. Edit: Also, if you've done the above steps, try to disable Antivirus and Firewall to check if these are causing any problems.... Remember to enable them again after you've checked.

No problem and thanks for the feedback //Kaare

Simply make your own small timer. By making one of your own you'll have better control and higher flexibility than using timers/counters. Remember to use battery-backed up registers to ensure that the values are stored when turning off the PLC.

No problem. One thing you could do (to avoid future problems) is to just initialize D8120 at PLC boot.... Then, if you ever should "mess up" ( ) the configuration again, you can just power-OFF, then power-ON the PLC, and D8120 will be resetted again.... Or you could add an object in GOT to reset D8120 so that you can access this device from the GOT. Use one of the following: Remember to power-OFF, power-ON the PLC after changing anything in D8120 (the BD card needs to be re-initialized after changing D8120).

I think you will have to buy a programming cable (SC-09), and access the PLC directly to reset the values in D8120 unless you can modify the value from the GOT..... When you get access to the PLC (by programming cable or GOT), you just have to reset (move 0) into D8120 and it will function as a programming port again. Remember to power OFF->ON the PLC after changing D8120 values since the BD card require a reboot to initialize any new parameters.

Your BD card is channel1, and should not be affected by any devices in the 8420 range..... If you have modified anything in D8120 or in D8400 area you will have to reset those registers (set them to 0) to be able to communicate again. All in all, you will have to connect to the PLC to be able to set/reset any of the registers (or maybe you can access the correct variables from the GOT terminal and set them from there).

I haven't used GX Developer that much, but since you can ping the module in DOS, the module is clearly on-line. I rarely use GX Dev./GX IEC Dev. built in Ping functions, since ping is supposed to be on a much lower layer in the TCP/IP stack than the app. level. I suppose you are going to connect HMIs/PLCs to the E71 card. Does this work, or haven't you tried that yet? Can you program the PLC via E71-module using GX Dev.?