autoexecncf

Is there a simple way (programatically) to reset the QJ71E71-100 from ladder? Something like this: ---| |-------------------------------------------------------------------------------------------------------(????????) M0 I have looked in the protocol manual and do not know how to use the listed 1617 (0000) command to do this. I thought maybe someone had a quick routine as I have spent about two days trying to do this and can't budget any further time on it. I'd like to read the status, see if there is an error then reset it as part of an initialization routine. I am using MX Component with a Q-PLC and the above Ethernet card. Thanks rg

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

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)?

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.

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.

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.

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

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

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

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

Will do. Appreciate the fast response all. ray

HI Searched the forums and did not find an answer to this question. I have a Mitsubishi Q-PLC with the Q62P Power Supply module. It has two grounding nodes called LG and FG. I attached a snip from the Mitsubishi Quick Start guide for reference; what I'd like to know is this: Do the abbreviations stand for Line Ground and Field Ground? What are the purposes of each? I would assume that Line Ground is for AC Mains and the Field Ground is for switch / sensor / module returns, but can't find a verification in the documentation. Appreciate any clarification in advance. We have a customer wanting to know the answer for their safety certification process and I'd like to be able to answer them correctly. Ray

I concur. Haven't seen it here in the states.

I have it on the way. Many thanks for the advice.

Is there much difference between GX Works2 version 1.73B and the last major release GX Works2 1.64S (that is to say any added functionality)?