Understanding diffrent comm. protocols

rQx

Lifetime Supporting Member
Join Date
Oct 2010
Location
Trelleborg
Posts
1,051
Hi!

I'm haven't got that good understanding on diffrent kinds of communication protocols and how to set up communications. I use Siemens and simply use network cables and switches and it works.

However I do build control cabinets to a customer and when they sell their machine the often get questions "how can we communicate with it". They forward the question to me and I deal with it since I know some basics. But now they want me to "teach" the sales persons so they can answer basic questions instead of always run it through me. So if I write down my thoughts maybe someone can help me in the right direction if I'm correct or not.


1. Modbus, Profinet, Profibus, ethernet/ip etc - is the application protocol

2. RS485, RS232, ethernet - is what type of connection I have and how I must physically wire it

3. RJ45, RJ12, 8pin - is how it is physically connected. I suppose this could be any connector really?

So I can have:

RJ45 - RS485 - Profibus
RJ45 - Ethernet - Ethernet/ip
8pin - Ethernet - Modbus TCP/IP

Many questions I get is "We want an ethernet connection". So I wan't to sort out the diffrent levels and terminology so that the sales persons can ask the correct questions and get more detailed information.


Often we don't have a possibility to communicate and would have to add it to the control cabinet. The cabinet is simple with buttons and switches. The way I see it the best way is to add decentralized I/Os like ET200s for Siemens. I think that almost every PLC supplier in the industry have decentralized I/Os so I could add the manufacture they want into my cabinet. We could also ofcourse supply voltsfree contacts of their choice.

We also have a cabinet with a ML1400. We have made a modbus TCP/IP configuration so that they can communicate with that. RJ45-ethernet-modbus TCP/IP. Sometimes they wan't to communicate to a SCADA system. And here goes my thoughts on that.

1. Some SCADA system have built in drivers for diffrent PLCs and the end customer must check if they can communicate with my PLC.

2. Most SCADA are also OPC Clients

3. If the end customers SCADA clients can't communicate directly to the ML1400 they must buy a OPC server for ML1400 that they install on their computer to communicate through.

4. RSlogix is Allen Bradleys OPC server for ML1400

5. Could also buy OPC server from other vendors that have ML1400 capability.

I have googled and tried to learn some basic, but the more basic I learn the deeper I must dig to understand it. OSI layer and what not. It seems overkill to try to learn the whole OSI layer structure since it seems it's just the top and bottom layers that are of my concern


Thanks Tim
 
Keep in mind that OSI layer is just a model. A model created so that vendors can work on app and devices that talks to each other. For doing control systems, you really need to know the language (modbus TCP, modbus, Ethernet IP) and the medium (Etherent copper/fiber, 2 wire serial) without getting to know all the details in between.

You are more or less correct on the OPC / SCADA.
 
You're correct on all accounts. Well done.

I call it Mules, Rules and Tools.

The hardware transport layer is the mule, because like a miner's mule, it just carries the load. It doesn't care what the load is, beans, pick axes, water jugs, or bags of ore, a mule just carries the load.

The protocols (Profibus, Modbus, Ethernet/IP) are the rules: who talks when, how the messages are formatted, and what happens when there's a problem/error.

The Tools are the application layer that interprets whatever the data is and does something with it.

"We want an ethernet connection"
Good Luck.

Our sales guys are incapable of understanding that the word Ethernet is essentially a meaningless term. Ethernet is just an IEEE spec for electrical specs on the data signal. It has nothing to do with the functions accomplished with or by the higher level layers in OSI model, or what one could reasonably call 'communications'.

Does Ethernet mean that they need to browse a setup page with HTTP?
Download a csv file with FTP?
Get data realtime via Ethernet/IP or Modbus/TCP?
Print a file?
Stream video?

The task defines what communications protocols, hardware and application software is needed. The TASK is key, the communications follows the task.

If you stumble onto to a magic potion for getting sales guys to ask 'what's the task you need to do?". And getting them to stay with it long enough to get relay to you an understanding of what is needed, please pass it on. I'm listening.

One hint, don't even mention the OSI model. Peoples' eyes glaze over as soon as they seen that wedding cake diagram.
 
I agree with Dan.

It's impossible for a sales person to do this.

I've connected different system in many ways many, many times both being a supplier and a customer, being both at the SCADA/DCS end and at the PLC/embedded system end.

It has to be a tech guy at both ends for the (human) communication to work.

Also the PLC program needs to be suitable for DCS communication. It's not enough to be able to communicate with a PLC, you need to determine what kind of information that is supposed to be exchanged, how and where and in what way.

For instance if you have a machine and you can change it's settings with some switched and perhaps an HMI and now you want to control it from a DCS system. The programmer must have thought about this so he can accept setting from the DCS system in some area and transfer those changes to the machine. Perhaps the machine need to have different working modes, for instance a local/remote setting. There are also safety issues to take into account. A remotely controlled machine is not the same as a machine controlled by standing next to it.


That said, if you want to communicate over ethernet, modbus tcp is the most widely supported communication protocol. So if you build something with a PLC inside and you say you support modbus tcp then almost every system on earth will be able to communicate with you in one way or another.
 
Last edited:
I call it Mules, Rules and Tools.

Good explanation, thanks!

One hint, don't even mention the OSI model. Peoples' eyes glaze over as soon as they seen that wedding cake diagram.

I won't, it's just for myself to know little bit more about what I'm talking about

It has to be a tech guy at both ends for the (human) communication to work.

I agree, the main thing I wan't to learn them is that they can't just accept and make a deal based on "yes you can communicate ethernet with us"

Also the PLC program needs to be suitable for DCS communication.

Absolutely, the main thing the communication is beeing used for is for monitoring and alarms. Not for operating.

That said, if you want to communicate over ethernet, modbus tcp is the most widely supported communication protocol.

Yes I have came to understand that and also had incorperated into the system. Modbus TCP and Modbus RTU RS232. We use the RS485 port on the ML1400 for controlling a PowerFlex 4M unfortunally, I think that RS485 is better then RS232?

RSLogix is a designing software. RSLinx is a communication server and it has OPC server features.

You are right, I ment RSLinx (y)
 
I think that RS485 is better then RS232?
Yes, RS232 is for short distance only and not really suitable for an industrial environment. It would be OK if you where running 0.5m of it inside a control cabinet though.

RS485 and RS422 are much better. They are differential so two require two wires for each signal, often called A and B.

RS485 is the bus version of RS422. RS422 is point to point communication only.

They can be run several thousand meters/feet. Higher speed requires shorter distance.

Profibus is another example where RS485 is used.

Modbus RTU can be run over any kind of serial link, including RS232, RS422 and RS485.
 
Last edited:
I think that RS485 is better then RS232

RS-232 without all the handshaking that phone modems required, just Rx, Tx, and Gnd, is pretty simple and easy to use. But it is limited to point-to-point (only two devices), and has distance limitations.

RS-485 can have all sorts of problems,in spite of the fact that it is a differential signal.

a) The designation of the A/B driver lines is not standardized. One supplier does it one way, one the opposite. If they're backwards, it won't work, but it won't damage anything. But hooking A - A and B - B sometimes doesn't work. And they're frequently not A/B they're Data+/Data-, (+)/(-),

b) Most devices have little isolation and little ability to reject common mode. That can be a real problem over distances where common mode potentials develop.

c) Biasing can be a pain in the butt because one can't get to a V+ or V-.

d) Most of the world ignores that fact that 2 wire RS-485 is actually 3 wire: differential with respect to signal ground. Many devices are 2 wire only and use the case ground as the reference which immediately brings up issues of common mode over any distance. Learn to factor in a 485 network isolator for 485 projects.

e) No PC in the world has an RS-485 port. Of course, most of them no longer have an RS-232 port either. So now one series a USB/RS-232 converter with a 232-485 converter or uses a USB/RS-485 converter.

Compared to Ethernet with its incredibly good transformer isolation, RS-485 is the poor step child. If I can choose, I'll pick Ethernet over 232 or 485.

Dan
 
Yes, RS232 is for short distance only and not really suitable for an industrial environment. It would be OK if you where running 0.5m of it inside a control cabinet though.

RS485 and RS422 are much better. They are differential so two require two wires for each signal, often called A and B.

RS485 is the bus version of RS422. RS422 is point to point communication only.

They can be run several thousand meters/feet. Higher speed requires shorter distance.

Profibus is another example where RS485 is used.

Modbus RTU can be run over any kind of serial link, including RS232, RS422 and RS485.

Thanks, that was informative and conciese (y)



RS-232 without all the handshaking that phone modems required, just Rx, Tx, and Gnd, is pretty simple and easy to use. But it is limited to point-to-point (only two devices), and has distance limitations.

RS-485 can have all sorts of problems,in spite of the fact that it is a differential signal.

a) The designation of the A/B driver lines is not standardized. One supplier does it one way, one the opposite. If they're backwards, it won't work, but it won't damage anything. But hooking A - A and B - B sometimes doesn't work. And they're frequently not A/B they're Data+/Data-, (+)/(-),

b) Most devices have little isolation and little ability to reject common mode. That can be a real problem over distances where common mode potentials develop.

c) Biasing can be a pain in the butt because one can't get to a V+ or V-.

d) Most of the world ignores that fact that 2 wire RS-485 is actually 3 wire: differential with respect to signal ground. Many devices are 2 wire only and use the case ground as the reference which immediately brings up issues of common mode over any distance. Learn to factor in a 485 network isolator for 485 projects.

e) No PC in the world has an RS-485 port. Of course, most of them no longer have an RS-232 port either. So now one series a USB/RS-232 converter with a 232-485 converter or uses a USB/RS-485 converter.

Compared to Ethernet with its incredibly good transformer isolation, RS-485 is the poor step child. If I can choose, I'll pick Ethernet over 232 or 485.

Dan

Thanks for good information! I would also pick ethernet if I had the choice, unfortunally it's not always up to me :)
 
a) The designation of the A/B driver lines is not standardized. One supplier does it one way, one the opposite. If they're backwards, it won't work, but it won't damage anything. But hooking A - A and B - B sometimes doesn't work. And they're frequently not A/B they're Data+/Data-, (+)/(-),

The use of A & B is actually standardized in RS422 and RS485 and there is no question what is what. You can check it out here: http://www.itu.int/rec/T-REC-V.11/en

However, I have also encountered devices where A and B has been mislabeled. Probably by people that don't know enough to get it right.

But if you go to the source and look at the datasheets from the manufacturers of the RS485/RS422 components they are never wrong. So guys that are actually making the integrated circuits that goes into the products sure know what they are doing.

They also have the best information (besides the standard) how to wire, protect from ESD etc etc. Manufacturers are for instance Texas Instruments, Linear Technology and Maxim.


e) No PC in the world has an RS-485 port. Of course, most of them no longer have an RS-232 port either. So now one series a USB/RS-232 converter with a 232-485 converter or uses a USB/RS-485 converter.

It's pretty standard to have one or several RS422/485 ports as well as RS232 on industrial PCs. But they are indeed rare on laptops nowadays.


Before RS422 became popular we used 20mA current loop for serial communication over distance. Not to be confused with the 4-20mA analog current loop.
 
Last edited:
Pete,

Be my guest and love 485 for all it's worth.

But it's a royal pain when non-integrator user-level customers try to use it and have a hard time figuring it out.

Even if the chip manufacturers agree on labeling, the device vendors do not and its their documentation that's used in the field.

Here's a sample of a dozen or so 485 labels I've run into lately.

RS_485_terminal_connections_and_labeling.jpg


I'll take Ethernet any day.
 
Thanks for the laugh Dan. That was a pretty funny collection. :ROFLMAO:

You should add a few RS422 to that as well. Especially those that run the RTS, CTS signals over RS422 in addition to the transmit/receive signals.

I don't have much trouble but then I'll whip out the scope if I have to.


I like ethernet too but unfortunately it's not without it's problems either.

For instance you often have to change your IP address on your laptop to access anything on a LAN without DHCP servers. And you have the firewall settings in Windows to wrestle. And you have smart/managed switches with individual port settings (better put it in the right port). And ports with POE and ports without. And while copper works pretty much with auto-negotiate, fiber is a different ballgame. You have multimode and singlemode and 1GB fiber can't negotiate with 100MB fiber and you have SFP incompatibilities in switches of different brands. And let's not talk about all the different fiber connectors. I could go on and on. The thing is that these problems make it difficult for people. And then just as with serial communication we still have protocols, addresses and whatnot to configure. Except that tcp/ip while extremely flexible also adds another a few curve balls.

But I'm not complaining. Complexity and problems is how I put food on the table.
 
Last edited:
RJ45 - RS485 - Profibus
Profibus is two wire, typically connected to a 9-pin D-SUB. RJ45 is usually for Profinet.

Without knowing exactly at what technical level you get the questions on interface; I would say you only need to specify the protocoll, ie Profibus, ethernet/ip, modbus etc.
If you install this using the de facto standards for each protocoll i think it will be easier for the sales people to only give the costumers the protocoll name.

Edit: Line break was broken.
 
Hi,

I have a follow up question on this subject so I thought I would ask it here:

I have a ML1400 that is programmed with a small program, nothing special to it. If I make sure the customer have a SCADA system that can communicate with me over ethernet/ip. Do I need to do any programming to my program? They are just going to read out some variables and alarm bits. Can they access all my datafiles? N,B,L,I,O?

That was a general question, actually I got a customer saying: "We wan't to communicate with your PLC through ethernet/ip to our SCADA system". Just wondered if I needed to do something. And according to what I know and have read I would say that I don't need to do anything in my program for them to access everything.

/Tim
 

Similar Topics

I am using Allen Bradley PLC for Ethernet/IP communication. I send any explicit msg request (Get attribute or Set attribute), I observed packet...
Replies
0
Views
69
Took a new job and the controls schemes are fairly old and I'm used to Allen Bradley and Siemens. I'm looking to replace a pair of Superior...
Replies
1
Views
105
Hello Team, I am desperate for some help with an assessment I have as part of a Level 3 general engineering course. I am in a role that is much...
Replies
9
Views
345
Good day is there somewhere i can see the situation and compatibility regarding different firmware revisions. I have a 2711-K5A5, series H and...
Replies
4
Views
212
Good Evening , I should know more about Solid State Relays . I have a system with 8) 120 vac Vibrators . These Solid State Relays have...
Replies
24
Views
2,041
Back
Top Bottom