Sign in to follow this  
Followers 0
Jayman

TCP/IP Port Communication on mits

15 posts in this topic

Good Day I was wondering if some one could please help me with some tutorial of advice on how to send 100 words of DATA via Ethernet TCP Port. I cant seem to find any information on that for mits. I would first like to send the data to a PC. but I need to send the DATA from a mits PLC to another manufacture plc. But i am sure if I can get the PLC to communicate to my PC the rest should be easy. The CPU I am working with is a Q06HCPU and the Comms Card is a QJ71E71-100 I would really appreciate any help. Thank you J

Share this post


Link to post
Share on other sites
What software do you use? GX Developer? GX IEC Developer? GX Works2?

Share this post


Link to post
Share on other sites
Hey kaare_t Thank you for the quick reply. it is GX developer, I apologize that I didn't add that. Thank you again

Share this post


Link to post
Share on other sites
I have been reading a lot of the Ethernet modules manuals and they say I should use jp.send and recv. as well as ZNSEND ans ZNREC. It all seems fairly straight forwad and simple. but it seems that I wont be able to send A section of the Mits PLC memory area(PLC-A) to Omron PLC memory area(PLC-B). It seems as if it is only possible for mits PLC to mits PLC DATA transfer. Am I wrong, is there away to send DATA to a third party PLC?? Thank you so much for your help.

Share this post


Link to post
Share on other sites
Those instructions are only for Mitsubishi to Mitsubishi. You'll need to use fixed buffer communication. I Think I have a program somewhere. I'll check and post it. GX Developer Fixed buffer send Q.zip Edited by Gambit

Share this post


Link to post
Share on other sites
Afaik, ZP.BUFSEND and ZP.BUFRCV (or something very close to that) are the correct commands to use. Another thing which is very badly documented in Mitsubishi software is that the ports numbers on the Ethernet setup are in HEX. Ie. port 500(hex) = port 1280 (dec)

Share this post


Link to post
Share on other sites
Hey, Thank you ever one for you help. I have managed to send data from the mits PLC to the Other PLC and it works well, I just cant receive data on the mits side. I have used all the types of Fixed Buff Configurations, Client or Server. I have even used ZP.BUFRCV and Z.BUFRCVS (With the correct interrupt instructions in ladder logic). I have Tried from the Other PLC and from my PC. Every time i send some DATA to the QJ71E71-100 it sends a few BYTES back.(Picture 1), But then I though that I might have to condition a few words in the DATA string. in other words having an value in the first BYTE the gets send to tell the QJ71E71-100 how many BYTES to expect(similar to how the zp.bufsnd works). When I Sent a DATA string with a value in it, the QJ71E71-100 sent nothing back. I think the QJ71E71-100 is accepting the data now. Im wondering how ever If I must add something else to packet to specify that is must go to the CPU(but I am sure that's what setting up a fix buffer station does). Im sure its something simple I am just over looking, because I can get the two CPU's to connect and the mits PLC sends DATA and the other PLC receives it. The only problem is the mits PLC in not receiving the DATA the other PLC is sending (and I did check the other PLC is sending DATA) Thanks again for the help

Share this post


Link to post
Share on other sites
@Jayman: Q-series ethernet can not send and receive on the same port (unlike the new onboard QnU ethernet) so if the non Mitsubishi side is sending back data to the same Mitsubishi port from which it has received data (depends on what you can configure on the other side), you have to use pairing on the Mitsubishi side. Pairing = bundling send and receive port in one port number for the "outside world". Edited by Mitsu

Share this post


Link to post
Share on other sites
Hi Mitsu Thank you for your reply. Yes I have tried the pairing, I use the pairing for sending the data to the non Mitsubishi PLC and that works fine. But yes I have tried it on the receiving but with no luck. But I just did some test by the PLC and noticed something interesting. What I did was set it up EXACTLY like the sample application( The one Gambit sent me "PLC_REC"). and I connected to it from my PC. the app I use says connected and on the PLC Ethernet card the "OPEN" LED lights up. I take it that is also confirming that there is a socket connection. In GX DEV under Diagnostics --> Ethernet Diagnostics. I can see a connection has been made between my PC IP and the PLC. So I know there is no connection problem..... Once connected I try sending random numbers/patterns. I dont get a reply from the PLC if I send it 2 digit numbers. when I go larger or send Alphas. I get a reply in HEX( C8 50 ) and the Comm. Error LED lights up.... Maybe Im looking in the wrong place but I think my set up is fine. Im sure there has to be some addressing BYTES that must be sent at the beginning of the DATA string. Do I not have to right values to the first words to describe to the QJ71E71-100 card how many BYTES are being sent and where it should go?? And in the Diagnostics --> Ethernet Diagnostics. on the station number that I have set up the socket type (K1) I get the error code (C1A6) which in the documentation means "Incorrect connection number was designated". Thanks again for all the help

Share this post


Link to post
Share on other sites
One more question: are you sure that you are receiving on the receive buffer in your BUFRCV instruction. The buffer number should be different from the BUFSND instruction. The flags (data received) are different too. There is a flag that triggers when data is arriving on the buffer of the ethernet card. Does it trigger at any point? You should only read from the card when data is in the buffer. See the basic user manual for the QJ71E71-100 card, chapter 8.6.2 Fixed buffer communication without procedure programming example. There are flags for "open request", "open completed" and "fixed buffer data receiving status". Also, in a case like this, it might be useful to monitor the buffer memory of your ethernet card (gx developer online/monitor/buffer memory batch and insert the address of your card). Look up the buffer memory address for the fixed buffer data area in the manuals. It helps a lot to see if you actually receive the data on the ethernet card itself. With ethernet communications, i often use hyperterminal to test communications. As a test, maybe you can define one port for receiving (without pairing) on your ethernet card, connect with hyperterminal and input text in hyperterminal. Experiment and see how the flags and buffer memory behave. You should be able to see data coming in on your card with buffer memory batch prior to reading it out with the BUFRCV instruction. Edited by Mitsu

Share this post


Link to post
Share on other sites
Hi Mitsu Thank you for the reply. What I have done is stripped all the sending and other code out of the app and just working with the zp.bufrcv instruction. Here are two pictures of the code and set up. maybe you will be able to see something. Also how would I know what memory area is this particular fixed buffer. Thanks again

Share this post


Link to post
Share on other sites
As a simple test, define a port on your ethernet card: - tcp / unpassive / receive / no procedure / no pairing / confirm Load up Hyperterminal (Windows Accessories / Communications) and make a Winsock tcp/ip connection to that port. Once connection is established, type some stuff in the hyperterminal window. In Gx developer, watcht the flags on buffer memory address 20480, 20482 and most important 20485. That receive data signal in 20485 should trigger when you input data in hyperterminal. Monitor the fixed buffer data area for this port (in my case it was port 4 so buffer memory address 4736 -> decimal) and you should see the data appear. Once data is on the buffer, you have to empty it (with BUFRCV) to continue receiving data. If that works, then the last steps should be easy. Edited by Mitsu

Share this post


Link to post
Share on other sites
The data area for fixed buffer 1 is starting at 1664 decimal. See basic manual chapter 3 List of Applications and Assignments of the buffer memory area.

Share this post


Link to post
Share on other sites
Great :) Thank you!! It works. I knew it was something simple and something I was over looking. I believe it has something to do with "no procedure" and "confirm" of these settings you gave me (tcp/ip / unpassive / receive / no procedure / no pairing / confirm) as those are the only settings I changed. Thank you again for helping me... if you have a moment could you explain to me what those two setting do?... "no procedure" and "confirm". Thank you again..

Share this post


Link to post
Share on other sites
Procedure exist should only be used if the data you are sending to the Mitsubishi plc is compliant with the MC Protocol, which is not the case for you. A port defined with procedure exist will examine the data that arrives on it and expects this data to be according to that protocol. If not, i assume that the data is rejected and an error is generated (not sure about this though). Mc protocol is a Mitsubishi specific protocol for exchanging data more easily and is very useful for exchanging data between Mitsubishi plc's or pc and Mitsubishi plc's. Let's say you want the content of data register D10 -> D20. You can build a message (a question) according to a certain frame in which you ask the content of D10 -> D20. Send this message to the Mitsubishi plc that is defined with procedure exist and the ethernet card will automatically generate an answer with the content you asked for (in that case the value of D10 -> D20). Major advantage is that you can set up bi directional communication more easily since you only have to write the communication on one side. Destination existence check should be set to "confirm". Let's say a tcp connection is made to a Mitsubishi port and the cable on the ethernet card is disconnected when the connection was still open. The normal tcp closing procedure done by the active side can not be done in this case because the connection is cut. In that case, the ethernet card assumes the connection is still open and the active side will never be able to connect to that open port again (in short, you will have to reset the plc). The destination existence check will help in that case. It checks if there is data received on a port that is open (= connected). If no data is received within a certain time, the ethernet card will check if the connected partner is still "there" using a ping or ack signal (can be chosen in the ethernet card settings). If no response is received, the ethernet card will close the connection so that it can be reopened by an active partner in the future. In short, if no data is received from the partner on an open connection, the ethernet card will check if the partner still exists. If not, it will close the connection so that a new connection can be setup. Explanations are a bit short but that is the general idea.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0