S7-1200, Profinet, Modbus TCP

Hi all,

I've been given a system to design containing a whole lot of things I haven't worked with much (or at all) before. My PLC is a Siemens S7-1200, my HMI is a Siemens KTP600 Basic Panel with Profinet interface, and I have to communicate with a Mettler-Toledo weight controller, which speaks Profibus or Modbus TCP, but not Profinet. So far my plan of attack looks like this:

Plan A is to have the S7-1200 talk Modbus TCP to the Mettler and Profinet to the HMI from the same port at the same time. Is this possible? If not...

Plan B is to talk Modbus TCP to both the Mettler and the HMI. Is this possible/straightforward/a pain in the backside?

Plan C is to get a profibus card for the S7-1200 to talk to the Mettler. Does the S7-1200 have such a card, and is it painful to set up?

In any case, I have no experience with Modbus TCP, and the only two things I know about profibus is that the cables are purple and that if you don't do the grounding properly You Are Going To Have A Bad Time. I have a little experience with Modbus Plus, from a few years back, but that's about it. So any advice or tips and tricks on getting it working are much appreciated!

ASF

My opinion is use profibus. Ive setup the Toledo weigh scales with Step7 V5.x in the past and it was very easy. I know the profibus module for the 1200 is a little expensive but by the time you screw around with Modbus codes etc...

Yes the 1200 has a profibus master module- this is what you need
Import the Toledo gsd file and boom- your done

I say go with Plan C

Thanks! Good to hear from someone who's done it before. I'm using TIA Portal, but I guess it'll be much the same. A few more basic questions then:

1. Where do I get the gsd files?

2. How do you import them?

3. How do I write the ladder logic to get the information out of the Mettler? e.g., if I was using Rockwell and Ethernet I'd probably use a MSG instruction to read the data, what do I need here?

Thanks, I know these are basic questions. This job has managed to pick out a lot of gaps in my experience, so I've got a lot to learn!

I like JRW solution. The Profibus DP Master is the CM1243-5 (6GK7243-5DX30-0XE0)
and yes, it costs more than the CPU.

You can get the GSD files free from the Mettler-Toledo Internet site.

You can have Profinet and Modbus TCP/IP at the same time. It will just take two connection resources. In my opinion if you can use Modbus TCP it is a waste of money to go with Profibus.
With profibus the advantage is that no code is required to get your data from the slave.
With Modbus TCP you need to do a bit of coding and understand modbus. Have a look into "MB_CLIENT" function block in the S7-1200 library. There are quite a few examples online too.
I believe the native capability of Modbus TCP for the 1200 and the 1500 PLCs is a blessing and we use it all the time.
If you need further assistance with modbus TCP please let me know of your questions.

Hmm. Yes, I was expecting expensive but not quite that much!

I think I'll at least consider Modbus TCP in light of the quote I got this morning. For the extra cost of it I can afford to spend a few hours working out Modbus TCP

I've had a bit of a look at the MB_CLIENT block. I think I understand how it works, if grnick50 (or anyone else) can confirm or steer me right that would be great!

All I really need to be able to do is read the live weight from the Mettler, and maybe a fault status, and then write back to it to tare it.

So if I've got this straight:
- REQ input needs to go from low to high to initiate the Modbus read/write
- DISCONNECT input should stay at zero unless I want to disable the transfer
- CONNECT_ID just needs to be a unique number, so I would just number my MB_CLIENT blocks from 1 to [however many blocks I have]
- IP_OCTET_1 through 4 is where I put in the IP address of the Mettler
- IP_PORT I should just leave as the default 502
- MB_MODE is the type of communication I'm after. So to read information from the Mettler, I will use 0, and to write it I will use 1. The Modbus Functions that I'm halfway familiar with from Modbus Plus comms will be automatically determined by the S7-1200 based on whether I set it to read or write, and which register I'm reading from/writing to
- MB_DATA_ADDR is the register I want to read from or write to in the Mettler. I can find the relevant Modbus registers in the Mettler manual
- MB_DATA_LEN is the number of sequential words to read/write, starting from MB_DATA_ADDR
- MB_DATA_PTR is a kind of "junk register" that the block uses to manage the data transfer
- DONE output means the read/write operation completed successfully
- BUSY output means the read/write operation is in progress
- ERROR output means an error occurred in the read/write operation
- STATUS gives me error codes if one exists

A few questions on this:
- To initiate the transfer the REQ needs to see a positive edge. My current thinking is that I would use the "BUSY" tag of the block to initiate this - if the block is not busy, then turn on my REQ input. This way the instruction would trigger a new read/write every time it finished the last one. Is this a good way to do it, or is there a better one?
- As I will need to both read and write, I guess I will need two MB_CLIENT blocks. Can both blocks be active at the same time, or do I need to let it finish reading, then tell it to write, and then start over again with the read?
- What do I need to put in the MB_DATA_PTR area? I had a read of the help file but couldn't quite get my head around it
- If I get an error, do I need to somehow clear it, or can I just turn the REQ bit off and on and it will clear the error and try again?


And finally, just to satisfy my obsessive-compulsive need to poke at things I don't understand, what is the MB_SERVER instruction for? I'm guessing that I would use this if the Mettler was going to actively try and read information from the S7-1200 - I would put the data the Mettler wanted into, say, register 40001 in the S7-1200 using the MB_SERVER block and then the Mettler would just go to the IP of the S7-1200 and read 40001 to get the information it needed. Am I on track here?

Thanks a lot for any help, it's massively appreciated!

Oh, and one more thing...where does the MB_CLIENT block put the data it reads? Or, where do I specify which value in the PLC I wish to write?

I used the mb_client for communication over modbus_tcp with a pac3200.
this is how i did it.

Hello,

I will try to explain how I unerstand the modbus TCP on the 1200 PLC.

Genarally in Modbus TCP we have Servers & Clients (as in Master and Slave in modbus RTU). A modbus server is a device from which a client reads data. It is a passive device in the network. It waits for the requests from the client and will give the appropriate Responses. A modbus client is a device that collects data from the servers. It establishes an active connection and sends the requests for the servers to respond.
In your case the S7-1200 is the client and the Mettler is the server. In contrast the S7-1200 could be a server in a plant's DCS who is the client.
In TIA portal it is apparent that block "MB_CLIENT" should be used if we want the S7-1200 to act as a client and "MB_SERVER" should be used if we want the S7-1200 to act as a server.
Siemens PLCs have an address mapping which is not according to the modbus standards (as in Modicon PLCs or ABB PLCs). For that reason Siemens provides the above mentioned blocks to emulate that addressing.
MB_CLIENT Reads modbus addresses (ie 40001, 30001 etc) and puts them into an S7 memory area (M or DB).
MB_SERVER does the exact oposite. It reads a S7 memory area (M or DB) and makes it available to the outside modbus TCP world as registers of the type 40001, 30001 and so on.
Another thing to bare in mind is that S7-1200 can use its ethernet port for many things at the same time. It can have profinet communication with a RIO, Modbus TCP/IP with a Metller, TCP/IP with a KTP600 and TIA PORTAL Comms with a laptop, all at the same time. The restriction is the maximum connection resources and that is CPU specific. Also, each connection needs to have its own unique ID (Connect_ID).
In the case of a modbus client, it maybe required to make many calls of the MB_CLIENT block, to read from the same server. The reasons for this are the following:
1. MB_CLIENT can read only 124 registers. If you need more, then another call is required.
2. The server has a restriction on the number of registers that can send in every request. I work with the genset controller that returns only 16 registers in every request. I need more so I make more calls.
3. You need to read different segments of the modbus registers in the client. For example in registers 100-103 you read the real weight from the Mettler and in registers 200-203 you read the errors and status. If you dont care for the registers in between you can make two calls.
If you need to make more than two MB_CLIENT calls to the same device then you have to use the same instance DB and connection ID for each call.
The way I manage the order of the calls is to use a sequencer in the REQ of the block. For example In step 1 of the sequencer is the first call, in step 2 of the sequencer is the second call and so on. The sequencer is incremented after each block call either if the DONE flag is set OR the ERROR flag is set.
I agree with Patrick to use the BUSY flag to REQ input.
You can use that sort of sequencing to perform the write after the read. The only thing you have to do is change MB_MODE to 1in the write call.
MB_DATA_PTR is where the response of the client comes in raw. It is usually an array with length equal to MB_DATA_LEN in a Data block. Make sure to have the data block set to absolute addressing and not optimized.
As soon as you have the data from the client in that array you can further process them and get them to the desired format (convert to real, dived by 10 and so on).

Regarding the write operation, if that is cyclic then you have to make sure that the Mettler can handle that. Some devices have a limited write cycles to their memory. In that case you must write only when needed and not cyclic. Otherwise you will damage the memory of the Mettler.

Sorry for the long post. I hope it helps.

Thanks, that's an enormous help! I think I've mostly got my head around it now. Just a few things to tie off:

grnick50 said:

3. You need to read different segments of the modbus registers in the client. For example in registers 100-103 you read the real weight from the Mettler and in registers 200-203 you read the errors and status. If you dont care for the registers in between you can make two calls.
If you need to make more than two MB_CLIENT calls to the same device then you have to use the same instance DB and connection ID for each call.

Click to expand...

I will need to make probably two MB_CLIENT calls to get all the data. If I understand correctly there are two ways I could do this:
1. Create a rung with an MB_CLIENT block reading the first data area, then the next rung will extract that data from the MB_DATA_PTR and put it somewhere meaningful in my program. Then the next rung will check that the previous MB_CLIENT block has completed, and when it has execute another MB_CLIENT block. This block will use the same DB and be basically identical to the previous one, except that MB_DATA_ADDR will change reflect the new value I'm after. OR
2. Set up the MB_CLIENT block as described, and then once it completes and I have extracted the data, write a different value to the MB_DATA_ADDR of the DB. The next scan, the PLC will execute the read again with the new address. Extract that data, change the MB_DATA_ADDR back, and start all over again.

Are there any benefits or drawbacks to either of these methods?

grnick50 said:

Regarding the write operation, if that is cyclic then you have to make sure that the Mettler can handle that. Some devices have a limited write cycles to their memory. In that case you must write only when needed and not cyclic. Otherwise you will damage the memory of the Mettler.

Click to expand...

OK. The only signal I'll ever be writing is a Tare signal, so I'll only execute the MB_CLIENT write block when a tare is required. Do I need to use the same DB instance and connection ID for the write as well as the two reads? Should I avoid reading and writing at the same time, or can I do them both at once?

And just one more question - if the MB_CLIENT block gets an error, do I need to somehow clear it, or can I just turn the REQ bit off and on and it will clear the error and try again?

Thanks a lot, this has been very helpful!

Oh, and one other thing...do I need to do any hardware configuration to make the S7-1200 speak Modbus TCP, or is the MB_CLIENT instruction all it needs to start talking?

Regarding the two options of multiple calls:
When I do modbus RTU I have a for loop with indirect addresing handling its loop. There is even an official example from Siemens.
When I do modbus TCP I prefer to have each call on a seperate block. I dont see advantages or disadvantages. Its how you preffer to do it.

As for the reset of MB_CLIENT, I think you can use DISCONNECT to reset it.

There is no need for any hardware configuration. It is all done in MB_CLIENT.
Another thing I did not mention is that in Modbus TCP the client can have a unit ID. There is no input for this parameter on MB_CLIENT. you can find it in the static part of the instance DB of the MB_CLIENT. Usually it is not important and it is set by default at 255.

Regards

Awesome, thanks a million for all your help on this one. I'm fairly confident that I'll be able to make it work with that!

(or as my boss would say, I should be able to f*** it up from here on my own)

Cheers!

So how many hours do you have in this ?
The price of a profibus module?

Or

http://us.mt.com/us/en/home/supportive_content/press-releases/IND780_ProfiNet_PR.html

Dear JRW,

It is very easy to setup modbus TCP if you know what your doing. I d say it shouldn't take more th 20 minutes.
Of course that is not the case when you do something for the first time. After the first time you have a library for life.
Why pay for something when you can have it for free?