neildobson

I've managed to spend some time (too much time actually) to write my very first class module which implements both MC & Direct FX CPU protocols. I've updated the original sample app so that you can play around with the everything and see what gets sent/received etc. and i've also included a couple of samples which demonstrate both protocols in action. Each sample reads the PLC's built in potentiometer and updates a progress bar. Have a play and let me know how you get on. I'll post some documentation when I get a minute but it's pretty easy. For those who are having problems, remember both protocols are ASCII based using only a few control codes, characters A-Z and 0-9. If the received string contains unprintable characters then there must be a comms setting or cable problem. When working with the FX CPU direct, the port should be set to 9600,E,7,1 only or it won't work!! For MC protocol this depends on how you set-up D8120. Be careful to check this and the protocol format, checksum etc. It's all detailed in the FX Comms manual. If you continue to have problems let me know your cable pin-out, D8120 setting and the sample code. Also look at both mitsi.sendstring and mitsi.receivestring which are the raw strings sent to/from PLC. If all else fails check out Kepware who sell a great range of OPC servers which include plenty of OPC sample code. Good luck. Mitsi_Comms.zip

I've been looking for some decent sample code using the Mitsubishi MC protocol for an embedded application i'm working on. I couldn't find anything suitable so I wrote a VB test app which I am due to port across to my target device (which runs a dialect of basic). Anyone looking for some VB code to communicate with a Mitsubishi PLC is welcome to use any of this code. The attached code is supplied with a sample ladder project saved in GX Developer 8 (used to set-up the comms D8120 and provide some sample data). The example is ready to run on an FX1N PLC fitted with FX1N-232-BD interface. The PC end is fitted with a USB-serial converter using COM4. The serial cable should be wired as follows: 2-3 3-2 5-5 I haven't implemented event driven comms or anything fancy, but all the configuration parameters are adjustable so you should be able to get it running with most Mitsi PLCs. Let me know if it works (or not), and feel free to modify the code yourself if it's broken. Cheers, Neil VB_MC_Protocol_Test.zip

For those getting started in PLC programming, perhaps you might be interested to hear Siemens are giving away some software. Link

We pretty much standardise on 24VDC for all but the largest of systems. The main reasons include: We use lots of PLCs, most of which have 24V inputs. Ease of which to interface with hardware such as variable-speed drives, sensors, small solenoid valves, LEDs, and other electrical/electronic devices, most of which again standardise on 24V. From a safety point of view - a requirement to keep voltage levels below 50V. Relatively low cost of DC power supplies nowadays. The only reason we would use AC for control would be when dealing with higher current devices where the cost of contactors and other control gear becomes expensive. In this case we use a mix of AC for control and DC for I/O devices.

Not sure what type of labels you're looking for but we've just invested in a printer from partex. This machine does most things from wire markers to component labeling, cable identifications etc. The machine uses various tapes, tubes, heatshrinks etc. for loads of marking tasks. The only thing it doesn't do is label plates for the panel doors. For this we use a local signmaker. Hope this helps.

We have been asked to carry out some code modifications to a network of 5/04 processors and panelview terminals all connected on a single DH+ segment. I would have been happy to connect to each device using the CPU's RS232 port using a CP3 cable, however some CPUs are doing point-to-point comms with other devices such as servo drives, and I have been unable to establish a link with them using RSLinx. I thought that there might be a way to tunnel through one CPU via its serial port and gain access to another CPU on the same network over DH+. However this does not seem to work for me and the processors that I can actually connect to show up as the only available devices in Linx. My question is what is the most economical way of connecting to any CPU and panelview terminal over DH+ network using a laptop PC? Thanks for your help.

We are quoting for a control panel upgrade which will contain a CompactLogix PLC (1769-L32E) which connects to a Red Lion G310 operator interface via ethernet. This interface offers a web server capability which we intend to use to remotely monitor machine status and for debugging. We would also like to gain access to the PLC remotely. I was wondering if anyone has experience with Red Lion operator interfaces connecting to AB equipment over ethernet? To be able to access the web server and the PLC must I set-up port forwarding and open ports to connect over the internet? Any advice would be appreciated. Regards,

Does anyone know how to change the baud rate of the FX programming port? I have the new FX3U CPU and would like to connect a peripheral device (E-series terminal) directly to the programming port and take advantage of the higher baud rate offered. I've noticed in GX Developer the software connects to the CPU at 112K without any adjustment. However when I connect the E-terminal it only works at 9.6K. I guess GXDEV changes the baud rate temporarily whilst downloading/monitoring etc? I've read some of the new FX3U communications manual and it doesn't mention anything about connecting directly to the programming port and I don't believe setting D8120 has any effect on the prog port but i'm not really sure. Help as usual would be appreciated. Thanks.

I've tried changing the baud rate of the e-terminal but I don't think this works as the FX prog port defaults to 9.6k. In any case as Sergei suggested, perhaps the baud rate should be left as default in case anyone connects to the PLC in future. I just wanted to increase speed so that the terminal would update a bit quicker if I intended to display lots of live variables and perhaps scroll some messages etc.

Can anyone help me with comm settings to enable me to connect an E200 to the Q-series RS232 module? I had the terminal working for a while but after fiddling with the baud rate I can no longer get any comms. I need to reduce the baud rate to 19200 because of the 20m long cable length. I see there is a switch settings dialog in GXDEV I/O configuration but when I adjust parameters here it seems to affect my programming port connection. Do I select the CPU protocol or C24 protocol in the E-terminal software? Any have example switch settings? Any help would be most appreciated.

Thankyou, after studying the manuals and a bit of experimentation i've got it working. Here are the settings for future reference: E200 terminal configured with default C24 protocol settings: - RS232, 19200, N, 8, 1 C24 module settings: -Baud rate:19,200 = 07H (bits 8-15) -bit 0:OFF - independent -bit 1:ON - 8 data bit -bit 2:OFF - no parity -bit 3:OFF - odd parity (ignored) -bit 4:OFF - 1 stop bit -bit 5:ON - sum check on -bit 6:ON - write during run enabled -bit 7:OFF - setting modification prohibited Setting = 62H Protocol Setting: -Format 5 = 05H Configuration in GX Developer: From PLC Parameters, I/O assignment, Switch setting, enter the following for the communications module: Switch 1:0762 Switch 2:0005 Job done.

My customer has one of these connected to an old FX PLC and wishes for us to carry out some mods to it. However I am unsure as to which software and programming cable is needed. Can anyone help? Many thanks.

I've been using GX Developer for a couple of years now and there are a few things that annoy me a little like the non-use of modern windows dialogs (instead of the circa 1990s dialogs for open, save etc.) but the biggest annoyance is with transfer settings. We use lots of FX PLCs and unfortunately we don't have time to sit and test applications on paper so we have to constantly modify the program, download, test, modify, download, test etc. etc. When downloading you first have to select the MAIN program by clicking the checkbox and then press execute button. This of course will download the program to the PLC writing the whole of it's memory. If you are constantly downloading new revisions you can save a bit of time by just downloading only the memory used by your program. For instance if your program is 156 steps (goto the last rung and note the step number) you can select the Program tab and pick Step Range and enter the step number. The problem is GX Developer doesn't remember any of this meaning you have to go through the same steps each time you download. I can't seem to find a way of persuading the software to remember my settings. Any ideas? What would be cool is if GXDev defaulted to select MAIN program and there was an option in the program tab to download 'just the program'. This would save a whole load of time in our developement. I don't know any way of getting feedback to Mitsubishi on matters such as this...I'm from the UK!!

I have a strange problem where the remote I/O is freezing (the inputs change state but the image table is not updated in CPU). My application is quite complex. I have four main racks populated with a variety of digital and analog I/O. This is expanded by using the D4-450CPU as remote I/O master (the 25-pin port) which connects to an additional two remote slave racks also containing various digital I/O modules. Finally for good measure the main rack contains an H4-ECOM ethernet module which connects to a PC which does logging/data capture functions. This application has been running quite successfully for the past 7 years. However from day one we have had some mysterious I/O problems where certain ladder rungs do not operate correctly. I have spent some time on this recently and the problem is the remote I/O. One of these racks has its inputs and outputs configured as X1000 and Y1000 respectively. So the following example should work fine: ----[X1000]----------------(Y1000) You would naturally expect when bit 0 of remote inputs turns on (X1000), the first remote output bit 0 (Y1000) would also turn on. This does work. However after a while, the I/O is no longer updated and if Y1000 is already ON, then if we lose X1000, Y1000 still stays ON. Conversely, if Y1000 is OFF (because X1000 is off), then no matter if X1000 switches ON, Y1000 stays OFF. The problem appears to be that the CPU forgets to refresh the I/O image table from the remote I/O racks and the whole lot is just frozen. Even more strange is that to fix the problem we fire up DirectSoft and as soon as the link appears (green icon) in the launch window, everything fires up normally and I/O refreshes fine for a while. I guess there is no easy answer for this, but I have a number of things to look at: 1) The remote I/O cable. This appears to be wired correctly and is only 5metres end-end, fitted with terminating resistors. I will check screening, resistor values etc. 2) Remote I/O configuration. This has been checked over and over and as far as I can tell this is correct. The I/O is configured as per the example in the D4 user manual. The unused slots are zeroed and C740 is set. Everything is set-up using first-scan bit SP0. Is the remote I/O information in the D4 manual correct? I see it differs slightly from the remote I/O manual. 3) Remote I/O status. I have seen no errors on any of the slave racks. Perhaps the status bits should be logged? 4) D4-450 as remote I/O master. How reliable is this. Any problems reported? Would it be better to use a D4-RM instead? 5) H4-ECOM. There is some heavy duty logging going on. Could this cause issues in the CPU? If anyone has had any remote I/O problems, particularly if using the D4-450 as remote master, or had any other problems when using the H4-ECOM I would be interested to hear from them. Regards,

We're designing a machine with a Q-series PLC with a CPU172N motion controller. It has been suggested by Mitsubishi that we consider using IEC developer instead of GX Developer (which we have). I've not looked at this software yet but I hear it has been developed in Europe and is quite different to standard GX Developer. Does anyone have any good (or bad) things to say about this software? Those with IEC Developer, do you use it exclusively for all Mitsi projects (even small FX applications) ? What about the (so-called) overhead, does this affect scan-time much? Does IEC Developer have ability to convert projects to/from GX Dev? What is the latest version and is there a demo available? Thanks in advance for info.

Anyone used this cable before? I need one to connect to an encoder to the Q173PX module. This module has a 40-pin connector (similar to other high-density modules). Normally an A6CON1 is used, but of course you'd have to solder a cable. The Q40CBL-3M is (apparently) a ready-made 3M cable but I can't seem to find details of the cable colours (or is it colors . I've done a search on all my PDF's and on google etc. Is this a Mitsubishi part? I will receive my cable in the next week or so, but I just wanted to get a schematic drawing done in advance.

I found this document which explains a bit more about FX CPU (Programming) Protocol. This is quite interesting as it implies that you can do single bit read/writes as well as words. However I am still unsure what are the addresses of all the PLC devices. This protocol does not use D,X,Y etc. Anyone shed any light on this? mitsufxs.doc

I've included an example which provides a simple joystick controller. There are four buttons, each of which when pressed sets an M bit and when released resets the same M bit. The PLC ladder (see enclosed screenshot) then sets Y outputs depending on which M bit is set. In your application you would set/reset various data using whatever protocol you wish. You load the data into the mitsi.PLCdata() array and then execute the command with ExecuteMCCommand (if using the MC protocol). You then wait for reply from the PLC. I have implemented mitsi.CommsBusy. This is set to true when you execute the command and goes false when the PLC has replied or a timeout has occured. You then look at the mitsi.TimedOut and mitsi.ErrorCode properties to see if there is an error. Remember if you are waiting in a loop to use DoEvents. Joystick_Controller.zip

I have included two samples which demonstrate each of the protocols in action. Both require the Comm settings to be adjusted to your PC configuration in order for them to work. Both samples continuously read the data register D8030 which is the first potentiometer on the FX PLC. The value is displayed in the text box and also graphically represented in the progress bar. Adjusting the potentiometer with a screwdriver should quickly update the controls. This was done to show how simple it is to read some data from the PLC. Finally i'm looking for some information on the memory map of FX PLCs. The Direct FX CPU protocol doesn't use X,Y,D,T etc. but instead uses absolute memory addresses. I found some 5+ year old C code which converts the device address (D100, T50 etc) into the absolute address but I don't know if i've included everything for all PLCs. In particular there appears no way to address M data as words which I am sure you must be able to do. Is there any Mitsi or 3rd party documentation which describes the PLC memory map? I spent about 3 hours with google yesterday with no luck.

OK I have details of the FX CPU programming port protocol. You need to open your COM port with the following: 9600 baud,even parity,7 data bits,1 stop bit. The protocol format is as follows:- <STX><CMD><Address 4 hex bytes><Qty 2 hex bytes><ETX><Checksum> Where: CMD is 0 for read, 1 for write Address is absolute memory address (need to work on this) Checksum is lower 2 hex bytes from total of all chars including ETX, but excluding STX. I'm working on updating the test app which is currently working with device reads. Once completed this will allow direct connection from VB to FX CPU port using SC-09 or the basic cable mentioned elsewhere on the forum.

If anyone knows the basic FX CPU protocol please let me know? I am going to write a simple class or perhaps an ActiveX which embeds the mscomm control and allows simple batch read/writes. This combined with the simple programming cable will make a low-cost option to enable VB comms direct to the CPU port. A quick look on the internet shows that a number of HMI companies such as Beijer, Proface etc. already have the FX CPU protocol drivers as well as the 1:N computer link drivers but the FX CPU protocol appears undocumented so perhaps this was reverse engineered?

Well what seemed to work fine yesterday now appears to be broken. It is of course important that D8120 is set-up correctly in order for this to work. Yesterday I had the port set-up as 9600,N,8,1. The PLC no longer replies when I run the test for whatever reason and I get the no response message. I have no idea why this is the case so I have modified D8120 which should be set to H4880 for the example to work as set-up in the enclosed screenshot. The PLC contains the following ladder M8002 -[ ]---------[MOV H4880 D8120] I have also been unable to connect directly to the programming port. I wonder if MC protocol is available on this port? Interestingly when you plug in Mitsi or 3rd party HMI panels into the programming port these work fine without having to adjust D8120 so I guess these use some other protocol?

Well I'm no expert on Mitsubishi comms by any means but I wondered myself whether the programming port was configured to receive protocol requests but alas it didn't work for me. I was however intrigued so I used a serial port monitor to look at the comms traffic with GX Developer loaded (with data monitor window open). The messages sent to/from GX look different to the MC protocol (as far as I could tell), so I guess there is an additional undocumented protocol that Mitsubishi uses for programming access. Having said that, perhaps you can configure the programming port to switch to protocol mode using D8120. Haven't tried that yet. I'm unsure why the program doesn't work with A1S (and I don't know your switch settings) but might they differ from those set in the test prog? I've noticed if you have anything set differently such as checksum, protocol format etc. the PLC doesn't reply at all!! I posted a GX config so that those with identical set-up to me (FX1N-40MR-ES + FX1N-232BD) could run the software without guessing the protocol configuration (D8120). For those who don't have GX, i'll post the ladder tomorrow.

Does anyone know if these are available from Mitsubishi or anywhere else? I am putting together documentation for a customer and would like to include an overview of the Q-series PLC rack graphically illustrating each of the I/O modules. Thankyou.

Thanks all for your help. The UK Mitsi site had most of the CAD files i'm looking for except some of the Q motion stuff such as the Q172CPUN, Q172LX, Q172PX. However I should be able to manipulate some of the other drawings to suit. Now all i've got to do is learn how to do motion control with Q-series... Don't you just love the huge Mitsi manuals full of tables and jap-anglo loosely translated function descriptions?? My head hurts....