Colin Carpenter

IEC Developer Ethernet Peer to Peer Comms

14 posts in this topic

Hi,

I know this is an old topic, but I'm still not sure how to do this.

I have two PLCs that I need to get to communicate with each other .... a new one, yet to be defined, probably a Q03UDE or similar, and an existing Q2AS-S1 with an E71 ethernet card.

I have a test bench that allows me to play with a similar set up, and am looking for a fairly simple exchange of data registers going each way.

I have downloaded a pdf that explains how to do it in GX Developer, but as always, there are some differences with IEC Developer regarding the settings, and wondered if anyone has actually done this and can, perhaps, point me to some ready made function blocks (perhaps by Mitsubishi or Beijers) that will aid in what should be a fairly simple thing, but probably won't be....

We need to ideally programme in IEC Developer V7.04 for consistency.

Thanks in advance,

Colin

Share this post


Link to post
Share on other sites

Hi Colin.

The advantage you have with using IEC Developer is that you can take advantage of structured programming for example using Function Blocks (and multi instances where needed). 

MELSEC do provide some FB's to do these tasks which you will need to import into your project (from memory, these do not come in the standard libraries), also some functions are CPU Relevant so I cannot vouch 100% that these are compatible with A-Series, you may need to look at the compatibility first. Easiest way to determine this is to import whatever block into your A-Series Project and see if you can get a sucessful compile.

See if you have access to these blocks in your library, if not I will try and find you the ASCII Source and send across.

Here is a useful guide to get you started....

ftp://81.105.173.212/PLC/Current%20Product/Q%20Series/New%20Q/Networks/Ethernet/Qn%20Ethernet%20P2P%20Datasheet.pdf

Regards

Daniel

Edited by collinsd70

Share this post


Link to post
Share on other sites

Thanks for that Daniel, that looks like it addresses all my requirements, specifically IEC Developer.

Will give it a go and report back,

Thanks again.

Share this post


Link to post
Share on other sites

You are most welcome.

Let us know how you get on..

Share this post


Link to post
Share on other sites

Look into the already made function blocks from Mitsubishi for Fixed Buffer for the Q-series (made in GID7.04). Screenshot from their website. I think you'll have to dig a little regarding the QnAS though... As @collinsd70 writes; let us know how you get on

q_fb_gid.PNG

Share this post


Link to post
Share on other sites

Hi Colin.

Please see PM regarding fixed buffer FB.

 

Regards

Daniel.

Share this post


Link to post
Share on other sites

Good news, I got this working yesterday and it is remarkably simple to do by following the PDF in the link that Daniel provided.

I had a Q2AS-S1 CPU and a Q01 CPU, both fitted with relevant E71 ethernet cards at the first slot and just used 2 PLCs rather than the three that were detailed on the PDF.

The Q2AS ethernet setup dialogue was missing some of the boxes that the pdf talked about, but the Q01 had them as shown, but it seems that that's not a problem for the Q2AS.

I decide to write all the code in the Q2AS ( so that it would READ FROM and WRITE TO the Q01), and the code is shown in the attached graphics. The Q01 just had a single line of meaningless code so so that it had something to work on when switched into RUN mode.

It took a while to work out that the READ and WRITE commands happen on the leading edge of the enable signal, so just used a 100 ms pulse bit and everything sprang to life and is still running this morning.

Looks good, thanks Daniel.

 

 

 

 

ethernet read.png

ethernet write.png

Edited by Colin Carpenter
1 person likes this

Share this post


Link to post
Share on other sites

It looks good @Colin Carpenter, however I just wish to add a comment:
You are using a timer for triggering the instructions. Note that this isn't always the best choice. A 100ms timer is good, but if you go down on the timer interval you risk that the scantime exceeds the timer value, hence you will not alternate (and trigger) the send/receive instructions and it won't work. I'm just writing in case someone sees this post and tries this with lower timer values.

What I normally do is to wait for the receive ACK signal (command executed "OK"), then wait one scan and then execute again. That is basically as fast as possible after receiving the ACK, without any special measures, and what I would normally recommend. That way, the routine for sending/receiving Ethernet data will always work even with high scantimes.

Share this post


Link to post
Share on other sites

Thanks for that.

Any idea which bit would be the best to use for that ACK bit?

I assume it would be one of the bits in the two Boolean Arrays Read_Done and Write_Done, which are set up to be 3 bit arrays (0 - 2)

Edited by Colin Carpenter

Share this post


Link to post
Share on other sites
1 minute ago, Colin Carpenter said:

I assume it would be one of the bits in the two Boolean Arrays Read_Done and Write_Done, which are set up to be 3 bit arrays (0 - 2)

I haven't downloaded the code you are referring to, but in your screenshots you are moving the possible error code by using Read_Done[0] and Write_Done[0]. I would say that are two good candidates for ACK... So something like:

  1. Trigger send signal
  2. Wait for e.g. Read_Done[0] -> set a temporary bit high
  3. Wait one scan
  4. Use the temporary bit to trigger send signal, and then reset temporary bit

It will be a small sequence, but this is how I would have done it. Just to ensure that nothing will ever "stop" the Ethernet transmissions, no matter the scantime...

Share this post


Link to post
Share on other sites

Glad to see you got this working Colin.

Think I might also have a go at this over the weekend, unfortunatley my A-Series only has MELSECNet so will have to test this Q<--->Q.

Ideally id like to nest my core logic in a FB and create some form of communications check. Then port the code as when the necessary projects require it.

 

Regards

 

Daniel.

Share this post


Link to post
Share on other sites

I'll give it a try next week and see which one of those "done" bits will do the business and report back when I find out which one it is.

Thanks for your help,

Colin

Share this post


Link to post
Share on other sites

I just tested the Unpassive Send and Recieve blocks across 2 Q PLCs and works like a charm, literally took minutes to set up.

Have now encapsulated all logic in FBs with external read in of IP Address and Port numbers and diagnsotics and alarms on Output Parameters (Like 'Link' down and open connection timeout).

All these blocks can be found in the .SUL (library file).

 

Regards

 

Daniel.

 

Share this post


Link to post
Share on other sites

Just as an update, I used the Write_done[0] and Read_done[0] bits to pulse a local variable bit and used the relevant pulsed bit to initiate the read or write instead of the 100ms timer bit and it all works perfectly. 

Cheers

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