Step 7 communications

Greetings,

Whereas in the past I mostly tried giving answers to others or asking obscure Allen Bradley questions. Today I ask a question as a student. I recently began a S7 class and my lab partner and I were asked to figure out how to communicate between 2 S7-1200 PLCs and write a how to document. My lab partner and I learned how to use TSEND_C and TRCV_C to transfer data between two PLCs. We figured it out and wrote up an instruction sheet. Today I followed my own directions and failed. While setting up a return send and receive pair I accidently accepted the default setting for "Connection Data." The default was incorrect but I immediately realized this. So I reset it to the proper settings but still could not get the send and receive to function until I canned my program and I recreated the entire program. Once everything was done correctly the first time two way communication worked normally.

I was hoping I could add the voice of experience to this document. Are there any rules of thumb that should be observed? Are there common problems that you see when networking two plcs? Any help will be appreciated.

Hi Glen,

Is there a reason why you have picked these functions? Why not Profinet Controller - Device or Put and Get?

The main thing I have ran into using connections is establishing the actual connection. I have not set up connections in TIA yet, but I imagine it would be pretty similar to this:

Click

boneless said:

Hi Glen,

Is there a reason why you have picked these functions? Why not Profinet Controller - Device or Put and Get?

Click to expand...

Personally, I prefer TCP comms, especally with the new _C blocks, to Put/Get, but I agree that I-Device (controller/device) is much easier.

GlenGineer said:

I was hoping I could add the voice of experience to this document. Are there any rules of thumb that should be observed? Are there common problems that you see when networking two plcs? Any help will be appreciated.

Click to expand...

Not sure if this is what you ran into the first time or not, but there are two ways to declare the communications parameters. The first way is to have the IP addresses and everything listed in a data block in a specific structure, which is what I typically do. The second way is to draw connections in the HW/Network editor, and then reference it in the block call. I've seen a couple times where I accidentally used one when I meant to use the other, and it wouldn't work.

Get and Put were the first form of communication that I was going to try. However I came across a video (in Spanish) that described the TSEND_C and TRCV_C communication. I spent many hours trying to get two S7-1200s to talk back and forth and finally managed it. However repeating the operation seems to be a challenge. To me it seems slightly buggy. The slightest mistake at one of several points seems to cause an unfixable error. Its like you fix your error but somewhere in the back of the TIA program it remembers how you originally set it up (even though it displays correctly in the TIA software).

Another classmate is establishing comms with Gets and Puts and will then write his own instructions.

To close the loop I suppose I should say that I am doing Ethernet communication using version 13 of the TIA portal.

Thanks for any suggestions you all have,
Glen

I would definitely look into controller-device communication using profinet. I cannot find any examples, but last time I played with it it was very simple.

GlenGineer said:

The slightest mistake at one of several points seems to cause an unfixable error. Its like you fix your error but somewhere in the back of the TIA program it remembers how you originally set it up (even though it displays correctly in the TIA software).

Click to expand...

I'm not sure exactly what you were doing, but I can think of two things that could be related to the cause.

1. If you feed the blocks new communication parameters, you probably need to reset the connections so that it knows to pull in the new parameters. You might need to expand the block interface to see this input, I can't remember.
2. Depending on how you updated the parameters, it may require extra steps to become effective. There are at least three different values for any given tag: A) The offline value, what it shows in your S7 project, B) the online start/initial value, which is what the tag reverts to when it is reset (startup, if the interface is changed & reinitialized, etc), and C) the actual value, which is what the PLC actually uses in work memory.

There could be something else going on, but I've seen those two different interactions cause all sorts of "entertaining" commissioning issues.

I CHANGED THE VALUE, SEE?! WHY IS IS STILL DOING THE OLD THING?

did you put the controller through a stop/run transition? often portal is a pig for retaining the old settings until restarted

Chris Hasler said:

did you put the controller through a stop/run transition? often portal is a pig for retaining the old settings until restarted

Click to expand...

I second this, have had issues with this myself.