kaare_t

Hi. First of all: It looks like the "EN" input is "low"..... Is the PLC in RUN? Second: Have you assigned D2 to anything, or do you use D2 anywhere else? (use [ALT]+F3 to search for "D2", and select the entire project when searching).

There's also a difference in how you connect to the PLC.... ProgPort/Ethernet/BD(if FX)....

I think there's also an issue regarding performance..... I haven't used the module myself, but as far as I know the performance of the MES interface is WAY ABOVE any OPC server when it comes to pushing out huge amounts of data in a short time - and you've also got an internal memory which can buffer data in case the database server or network link should go down for a while.

Some nasty (and strange) errors in the project..... Not really sure how to fix that project in an easy way (and in addition make sure that it work as it should....) I'm still not sure if it will help by using GX Dev., but it shouldn't crash! Since GX IEC generates errors, then it would have been nice to try an upload with GX Dev. Did you install GX IEC 7.03 after you installed GX Dev 8.78? Also: Have you tried to power-off the PLC, set it to "STOP", power-up the PLC (still error?) and then upload the project to GX IEC and see if it's the same?? I'll have to leave soon, going away for the weekend, but the best of luck!

I'm not really sure why GX Dev. chrashes, but since you could upload the project into GX IEC you now have the project on your computer - right? Does the project compile in GX IEC? Because if you can compile the project in GX IEC, then you could erase the PLC memory, download the "new" compiled program with GX IEC - and then I'm pretty sure that it would work (won't guarantee it ). However, I would guess that you would like to use GX Dev. to edit/download the project since you can use ladder instead of IL? Have you tried to upload a project from any other PLC using GX Dev. at this time? Just to ensure that this is not a GX Dev. problem? In any case; if you upload/send me the uploaded GX IEC project (probably IL), I can download it to a PLC at work and then upload the project with GX Dev. and send you the project. In addition, then we would know if the project actually works when downloaded to a PLC.... If you would like this, please do it ASAP since I'm leaving for a weekend in about 1.5 hours!

I've seen this before! The error 6401 was caused by a bug in GX IEC 7.00. The problem was a parameter setting under PLC Parameter. If you have a project which is below 32000steps, and the parameter setting for memory was set to 64000steps, the PLC would go into an error state with the error code 6401. This bug was fixed in 7.01+ (7.03 is OK). There is a possibility that the project was once downloaded with these parameters..... I would upload the project with GX IEC 7.03 and save it to your hard-drive. Then I would clear the PLC (Online->PLC Clear->All), recompile the project in GX IEC 7.03 and then transfer the program to the PLC again....

Do you also have a printout of the "System Errors", and also a printout of the instruction(s) which fails? When using "System Errors" you'll also get the step-number where the instruction(s) fail by using the "Show" button....

Try to use debug to read out the error codes in the PLC (Debug->System errors and PLC Diagnostics). If you have problems with your "faulty" project try to create a new, empty project and use debug. I still think that your error messages indicates that there's something wrong with the installation, maybe the latest MELSOFT installation corrupted some files or maybe an Antivirus or Antispyware have corrupted some files. The dll with error (eccodegeneratorfx2.dll) is connected to the MELSOFT Easysocket, which in turn is shared by all versions of GX IEC and also GX Dev. A "serious" problem with easysocket components could actually "knock out" all versions of GX IEC and GX Dev. You could upload/send me your project, and I will try to download it to a FX3U.... At least then we'll know if the problem is the project itself or your software/windows installation(s).

If Gambit's suggestion didn't help, have you un-installed/installed any MELSOFT software lately? I can also see that you've used both GX IEC 7.0, 7.03 and GX Dev. 8.78.... In which order did you install the programs? I've experienced some software problems, especially when installing version "backwards" (e.g. First install 7.03 then install 7.0).... Edit: Have you tried to disconnect both extension units and then power up the PLC? Maybe you have a problem with one of them, or a faulty bus-cable....

It's not the size (steps) of the program, it's the commands/intructions you use, and you'll have to check them in the back of the manual. Basically, some instructions take up a lot more time than other. One example is TO/FROM instructions (which you probably use); they take up pretty much time in the FX-series..... And also note that the instruction takes up some time, and in addition you'll have to add an amount of time for each device (word) you transfer. Do you use GX Developer, or GX IEC Developer? -If you use GX IEC Developer you could control the different code sections by using Task-Interrupt.

FYI: Beijer's are Mitsubishi distributors and they also have the manuals in their website. They've also got some "Knowledge" information, PPTs, Start-up/How-To documents and some other stuff for many of Mitsubishi's products..... For those outside of Scandinavia and just know Beijer as HMI produces, there's also a big difference between "Beijer Electronics Automation" which are Mitsubishi distributors in Scandinavia, Finland and the Baltic states, and "Beijer Electronics Products" which produces the E/Exter++ terminals (and have offices in Germany, U.S., China ++++)! For any English speeking people I would recommend the English website, instead of the Swedish one, and this is the link to Beijer Electronics Automation (English site): http://www.beijer.net/web/web_aut_en.nsf/A...12571EE004ABB9D I would actually recommend searching that site for knowledge cases and for startups/How-To's for Mitsubishi equipment, since they don't require any registration or membership, everything is free of charge, and as stated earlier in this post, the search functions and browsing functions are easier to use (at least easier than most other sites I've tried to use for manuals/information and other). If you wan't info on the MES just search for it ("MES"). For the people reading this post I would just recommend the PPT on the MES module which would answer many of the questions related to this post. To find it: -Search for MES. -Go to "Knowlegde(1)" -Double-click "Information and How To, QJ71MES96 -Open/Save the ppt

You could also try Beijer's function blocks for Modbus, with respective program examples and help files: http://www.beijer.net/web/web_aut_en.nsf/A...12571EE004ABB9D Put in search string in "the middle of the screen": DSSS-7LXKE5

Hi! Sorry for the late response, I'm preparing for a 1 month holiday (going to China), so I'm trying to get everything in place at work before I leave..... Well, I'm a fan of the Q-series since I can pretty much do anything I want (except for CANopen... ), but the price is of course a drawback......I would consider the following: Is this a "one-time" application, or is this like a machine with potential of xxx systems? If this is indeed a "small-number" system, I would go for the Q-series because this ensures that you can always get an extra card if any extra needs suddenly pops up. Most often, the extra cost of the Q-series pays off when you start to program since you have the flexibility, and you don't have to spend a lot of time trying to figure out how to solve things or make workarounds in the FX-series.....

It sounds like CANopen would be a good alternative, and you could run everything in one dynamic network instead of dividing into several sub networks. The biggest problem with the FX2N-32CAN (and also CANopen in general) is the configuration of both the FX2N-32CAN and/or every other node on the network. You'll need to either configure every node by themselves, or you can use a network manager (NMT Master) which supports some kind of network configuration. Another alternative is to use a software tool (several exists by different vendors) to generate a configuration which you download to each node, or the NMT Master node. Some general notes: I would consider the following before deciding: 1. How many potensial systems? Is this mass-production of a machine? -If not, then I would consider something else. 2. Do you need real-time data updates (and we're talking REAL real-time, not like Profibus or CC-Link which are not the same as real-time)? -If not, then I would consider something else. And by the way; I don't think that an FX1N would do the job if you really need real-time data updates since the scan-time and the FROM-TO bus-time is too slow. 3. If this is a single system (not mass-production), how much money can you spend on learning CAN? -CANopen isn't the easiest system, and you'll have to spend 'pretty much' time just to get the basics of the bus, then you'll have to start configuring and/or programming your units (most dynamic systems require configuration/programming to work - like PLCs, Controllers, ECUs +++). 4. If you're still considering CANopen: Are you sure you can't solve youre problems in any other way (even if this method isn't 'the ideal')? CANopen is a very, VERY flexible system and you can implement almost anything by configuration, but this is also what complicates everything. I'm sorry to be so negative about your idea. I have implemented several CANopen applications, where I have used the FX2N-32CAN as a network manager. I've also used the module to configure other devices on the bus, and/or the complete network system. This is all done by PLC code (depending on the size and connected nodes, the configuration code spans from 1000-15000 steps of code). If you are able to use GX IEC Developer I could send you some of the code I've made and you could take advantage of this. But then again, you would have to get some basic knowlegde of CANopen to be able to use any of the code I could provide, since the code itself is based on functionality and/or terminology of CANopen. If you already know a little about CANopen I've got general code and general function blocks for: -SDO Configuration of specific and/or every node on the network -Network startup and on-the-fly configuration -NMT Commands -NodeGuarding -Custom NodeGuarding -SYNC I've also got some examples of actual (and specific) configuration of (by use of SDO): -FX2N-32CAN -Encoders (Pepperl and Fuchs) -Hydraulic Controller (Danfoss) -ECU (Deif Marine) A good starting point if you would like to learn anything about CANopen is the CiA (nice name.....): www.can-cia.org/ If you have questions feel free to ask me, or continue this thread. Good luck with the decision

You can't really compare CANopen with CC-Link (or Profibus or most other bus'es), but to answer the questions (2. first): The bus always runs in CANopen, and even if a device fails (or even if it short-circuits the bus), the bus is always available and accessible. You can detect if devices are missing by using the NodeGuarding or HeartBeat protocols, but the FX2N-32CAN only supports NodeGuarding.Do you have any other information about the network and/or other devices connected, and what would you expect to send/receive?

If you use a BD card, and you use the CPU driver in the HMI then you have to set D8120=0! If you set D8120 to anything other than "0", then you will disable the CPU-Protocol and enable one of the other possibilities like MC/Computer Link/No Protocol depending on the number you insert in D8120. E.g.: H0090 -No Protocol(b14 = 0) -19200bps -7N1 -No Header/Terminator

I would recommend to use HMI 1 = ADP HMI 2 = PLC prog port By doing this, you can connect the HMIs/PLCs as normal, and you can choose the protocols/communication setup's as you would normally do it.

You can only use a total of 2 comm cards on the left hand (you can have 1 BD + 1 ADP, or 2 ADPs). Are you planning on putting 2 HMI panels on 1 ADP card (on each PLC), or are you planning on 1 HMI on PLC Prog Port and 1 HMI on ADP card?If possible in the HMI, I would recommend Ethernet (FX3U-ENET) between HMI and PLC. Then you can connect almost as many HMI's as you want to one or more PLC's, and you can also cross-connect HMI's to PLCs.....

Well, let's hope the customer is satisfied with the present situation then, or wants to spend some more money..... Just a note: E-Terminals (E1000) are able to use 115.2k, and they are not produced by Mitsubishi (they are branded). Mitsubishi's own GOT terminals are also able to use 115.2k.

Sorry if my english isn't the best in this post! Let me know if anything is "not understandable"....!! SPEED: I do agree with you too, it's 2009 and of course 9.6bps is 'bad', but if your HMI supplier supports FX3U CPU protocol, then they should also support 115.2kbps! The reason I'm asking about the speed itself is that a HMI panel (with a human reading the numbers) would have time to update about 570 16-bit words in one second (exactly 600, but when you remove the overhead protocol bytes you'll end up with about 1140 data bytes), or appr. 57 16-bit words every 100ms! My point is that for the human eye, a "real-time" update doesn't have to be super fast, and very often the problem might be the processor speed of the panel itself, and not the protocol/bit-rate. PROTOCOLS & SPEED: Modbus at 9.6k is pretty much the same as FX-CPU at 9.6k which in turn is pretty much the same as MC at 9.6k! So if the maximum speed on any port is 9.6k, it doesn't really matter if you use Modbus-, CPU-, or MC-Protocol, or most other serial binary protocols (if you were to run Profibus or CC-Link at 9.6k they would also be slow)!My point is: The Maple guy don't know what he's talking about. If you are sure that you need the speed, I would indeed push Maple further since they should support FX protocol even for the new FX3U! Btw. You can't choose any other protocol than the FX-CPU protocol on the FX-series programming port! SUGGESTION: In any case (slow processor on the HMI, or slow baud-rates) it's always best to group all the variables in each "screen". The HMI usually only updates the variables in the selected "screen" (the screen that the user is looking at), and if they are wide-spread the HMI will have to use many but small requests to the PLC instead of one large batch read! Many and small requests are not good, since they require more processor speed in the panel, and many requests means a lot more overhead! PROFIBUS & FX2N: The FX2N don't have a ProfibusDP master, but you can indeed get a ProfibusDP slave - FX0N-32NT-DP!

300ms is pretty much! Is this time the same in all the nodes, or just some of them? In any case, you have to wait for a reply before you send a new request. I've used FR-F700 and Modbus and they had about 40-80ms response time for each inverter, which is in my opinion pretty slow compared to other devices, but far from 300ms!!

I'm also a bit curious, why do you need that high baud-rate just for an operator panel? Edit: By the way, the "technical support" don't seem to know what they are talking about! 1. Doesn't matter which protocol you use as long as the baud rate is the same (doesn't matter if you use Modbus/FX/MC protocol or others as long as the bit-rate stays the same)! 2. All the FX-series use the same CPU protocol. The only difference is that some areas has been expanded over the years (e.g. FX2N/FX3U you have M1600+ as opposed to the old FX, in the FX3U you have R devices (R0-R32766) and so on.....). However, the protocol itself is exactly the same!

Hi. It's against the rules of this forum to discuss hacking/cracking passwords (check out the "Terms of Use" you've agreed to: http://www.mrplc.com/tos.shtml You should probably check with the original programmer/company to get information about the program. If you can't get information from them, then you could try Mitsubishi.

The problem is that Mitsubishi use special handshake commands at startup, where they use the control pins (RTS/CTS++) to negotiate the transfer speed for the specific session. The possibility of 115.2k exists only for the CPU(Programming) protocol, and not the MC protocol. Therefore, if your HMI supports CPU protocol then the supplier should provide you with an updated driver. If your HMI only supports MC protocol then you're stuck with max 19.2k. BTW the programming port has a DMA channel and can therefore also respond even faster than any BD/ADP/etc. card....

Can't you just compare the value with less than/greater than instructions? I'm not really into GX Dev. but something like "If D0 is greater than 10, and smaller than 20, THEN M0=True"....!? Sorry for not being able to provide you with a GX Dev. example..... Anyone else with a code line?