Q-Series PLC Fixed Buffer Communications

[autoexecncf 0]

I have searched the forums and most of Mitsubishi documentation. I have tried several examples (unsuccessfully) of Ethernet only communication both from here and the Internet. Admittedly I am not a highly skilled programmer and my boss isn't allowing me to make this a top priority. That being said what my goal consists of is this: I would like to communicate (using HyperTerminal on Windows as a baseline) with our Q Series PLC using ONLY Fixed Buffer TCP/IP (and or UDP) send and recieve. Caveats: -NO PROCEDURE EXIST -NO KEPWARE -NO OPC -NO MODBUS -NO MX COMPONENT (we currently use this and have issues with it - hence this post) Assumptions: -I believe all Ethernet Parameter and other module settings are correct; I am also successfully using CC-Link and a WS Safety Controller (Here is a snapshot of my current config from GX Works 2 for reference): -I am aware of the setting for Melsoft only in TCP/IP and aware of the weird port issues with Mitsubishi software from time to time (Dec or Hex etc). -You folks know more about this stuff than I do. -I use GX Works2 1.73B with the latest version of GX Developer 8. -I don't really want to use FB since I am not well versed in them yet I have tried the FB libraries from Mitsubishi and other Ethernet ladder diagram examples for several weeks now with no luck. My goal is to get one small simple piece of TCP/IP (preferably Ladder) Ethernet code that will enable me to read the following from HyperTerm: -M0 (or other M register) -X0 BIT -Y0 BIT Additionally, I'd like to send a command to the PLC and flip a bit or two on and off; I know how to use the debugging tools in GX Works2 and know my way around HyperTerm pretty well. Not asking for a handout or anything, I just need a simple WORKING Ladder example that will show me how to get started. A simple example that I KNOW actually works. I have spun my wheels for about three weeks on this, and my boss won't allow any further R&D time until I show him something that works. If any of you more experienced folks want to take a stab at this one, I would highly appreciate it. I do respectfully request that we dispense with any vague generalities or off the cuff suggestions (eg read the manuals). I have done all that as much as I know how and hit a brick wall each time. Is Fixed Buffer/No Procedure/TCP-IP only communcations even realistic as a goal? I thank each of you in advance for your knowledge and assistance. Ray

[kaare_t 155]

This is absolutely doable, but how do you plan to use the data you read/write? Hyperterminal isn't exactly the best for data processing. Would be nice with a little more information. Basically you should set the E71 to NoProtocol communication, then I would set up the PLC to send/receive data (binary or ascii) using the NoProtocol socket. Let us know some more info and we'll be able to help you.

[autoexecncf 0]

Thanks for the reply. Communication setup isn't the problem however. Ladder logic that will allow me to create a buffer, read the buffer and write to the buffer is the problem based on my above caveats. I wasn't going to use Hyperterminal to communicate. I was going to use it for testing purposes only. I figured if I can get it working that way then anything else on the Windows 7 side would be trivial. If I could read an input and output (X10 and Y30 for example) and flip M0 on and off and read it then anything else would be a shoe in. My ultimate goal: I want to set up the QE71E71-100 in NI VISA (have done this successfully on port 80 already) and talk to it with LabView 2011. We are a LabView shop and my requirements are to read our sensor suite, which consists of proxy switches, home sensors, etc. (Basically 16 place I/O modules as shown in my screen cap). Also, I am using M registers to read the status of WS safety controller low and high byte status via CC-Link. I know how to set the PLC and my sensors up, and have my ladder logic tested and approved. Now I just want to be able to read and write to and from the plc via our proprietary in-house LabView software package. and report to our main software package as to Q PLC I/O status. Ray

[kaare_t 155]

OK, do you use structured or simple ladder in GX Works2??

[autoexecncf 0]

I am using Simple Ladder until I can get the hang of the other modes.

[kaare_t 155]

Sorry, I'm a bit busy at the time and cannot find the manual for the E71 right now but it should be under the NoProtocol section of the manual. Check it out. You can then simply just set it up for receiving xxx bytes and sending xxx bytes. You can also write some logic to interact with the sending/receiveing. Just a question; why not use any of the MES modules (QJ71MES96 or MES Interface IT)? They can SELECT or INSERT to a number of database vendors and then you'll have all the data you need in the SQL. Very simple...

[autoexecncf 0]

The decisions to standardize on this particular model (QJ71E71-100) were made somewhat before my time. I could use those new modules and that is a good idea, but I'd rather stick with the approach mentioned earlier in the thread, due to speed issues with LabView (latency). The software package is mature and the sheer structure of our (LabView) proprietary package is causing some latency issues, which is most of the reason for using TCP/IP instead of an ActiveX wrapper. The delays are very noticeable during realtime data acquisition and I had hoped to eliminate at least some of this delay with some fast TCP/IP data exchange, and save money on MX Component licensing as well. MX Component works, and we are deploying it now. I will look in the manual and see if I can make progress there when I get time. Thanks ray

[kaare_t 155]

OK, just asking. You can take a look in the manual under NoProtocol and Fixed Buffer section (see screenshots). It's pretty easy to set up the PLC and you don't need much programming. In your case, it will be the computer application/interface that will require some attention I'm working on a remote site with limited internet availability and spare time but look at the manual for the E71 card (dowload the latest version from Mitsu) and I'm sure you'll figure it out easily. If not, you know where to write.... Since you can set up connections for both send and receive, my approach would be to use TCP, 1 socket for sending and 1 for receiving. That way you can send/receive data at the same time without any handshaking. This makes it pretty easy on the PLC side: -Socket 1 sends data all the time as fast and as often as it gets "a chance" on the network -Socket 2 receives data at any given time I know you said that you have read the manual, but I hope you'll take a quick look since the instruction(s) ZP.BUFSND and ZP.BUFRCV. Let us know how it goes... EDIT: Forgot the pictures, here they are Edited 20 Mar 2012 by kaare_t

[autoexecncf 0]

I have downloaded most if not all manuals from www.meau.com for each module in my Q series PLC, at least the ones I know about. I have seen these pages you are posting here in the QJ71E71-100 User's Manual (Basic) and I sincerely appreciate your taking the time to point out these examples. It is a big help and your description is very encouraging. I won't have any further programming time until next week but I will get back to you and let you know how it goes. I found fixed buffer no procedure examples in the manual, clear examples of how to send and recieve so I will give those a try. Edited 21 Mar 2012 by autoexecncf

[kaare_t 155]

It is pretty easy with the instructions provided above. The "problem" is the configuration of the sockets which you will do in the prog software. You said you use GX Works2 and you want to use Simple Ladder, correct? I'll see if I have a sample config for the sockets. If you run into problems you know where to post.... When you have a time window, would it be possible to give a little info on what you plan to do on the computer side? I'm just curious to know what you will use on the computer side. I would guess that you will program a custom application for this purpose, and what programming language do you use?

[autoexecncf 0]

The application is really going to be simple. Using NI LabView 2011 I plan to send and gather the following from the QPLC every 100 to 250ms in some sort of a loop on the PLC: X0 - X1F INPUT STATUS Y20 - Y3F OUTPUT STATUS W2.0 - W2.B I/O STATUS CC-Link up status (WS and QPLC QJ61BT11N) PLC SM400 (Always On - check for this) PLC Error PLC CC-Link Comm Error PLC Comm Error (QJ71E71-100) Just things like that. Data will be one way "push" as IP or UDP from the PLC to the main Windows XP LabView application for now at 100msec to 250msec intervals. Data arrival is not that critical at this point; I am basically writing a customer status and monitoring screen. Each one of these items as listed will turn on a Boolean indicator in LabView. The application will communicate with NI VISA and we will finally be able to do away with MX Component. We are doing some of this with MX Component already but it is clumsy to use, and has had memory leaks with our large software package in the past. Further info: A Q PLC and WS Safety PLC gets deployed with every large field (factory deployable) system we sell. All of our I/O including safety is now done with the WS PLC (safety) and Q PLC (non safety and monitoring). Using this PLC for our large factory machines is a little like using a grenade launcher to shoot rabbits but my test machine setup is working nicely so far. Our customer can also customize it to suit their needs on the fly and since we are in the US and our customers aren't, modularity is important. Some sensors we use: Proximity sensor, door open sensor, xy rail home and off home sensors, including safety light curtains and E-Stop switches. We now use and deploy MX Component as a baseline but I want to get rid of that clumsy Active X wrapper and use pure IP/UDP fixed buffer communications. Maybe that clears things up a little. Edited 22 Mar 2012 by autoexecncf

[autoexecncf 0]

Question: How would I set this program to look for X0 - X1F then Y20 thru Y3F? See the screenshot. I am not sure I understand just WHERE in this ladder diagram they are setting this. This is a cap from the manual. At the top it states this program is for a specific IO range and I want to know how they determine that since I see nowhere obvious to do so.

[kaare_t 155]

Hi, The module start X/Y and head address in the example = 00, which can be identified by the following parameters: 1. X19 = The hex address 19 starting at X0. If the module start address is 20, change X19 to X39, if the start address is 60, change X19 to X79 and so on. 2. ZP.BUFSND - "00" (n) = The module head address - if the module head address is 20, change 00 to 20, if the start address is 60 change 00 to 60 and so on. 3. ZP.BUFSND - "K1" (s1) = The connection no (1..16) 4. ZP.BUFSND - "D3000" (s2) = The starting point of the completion status signals 5. ZP.BUFSND - "D300" (s3) = Starting point of send data 6. ZP.BUFSND - "M300" (d) = Starting point of completion signals Does this clarify?

[autoexecncf 0]

Very much so thanks. Was unable to determine this readily from the documentation. Can you reference me to a manual where this is located (e.g. page number, SHNAxxxx, Name)?

[kaare_t 155]

I'm not much of a "manual guy", and the manuals for Mitsubishi have been somewhat "strange" in the past (I think they are getting better now, but rarely use them besides when doing comm. and accessing buffer memories directly). So I normally rely on the help provided with each instruction. See the attached screenshots of the "Instruction Help" and the "Detailed Help". So when combining the manual printout you provided with the instruction help we are able to "decode" what the instruction in/out are....

[autoexecncf 0]

That was a big help. Thanks. Will keep you posted.