RS232 or RS485?

scarince · Oct 28, 2016

I'm working on an application to have a ControlLogix 5561 communicate with a Telesis TMC420 pin stamp / dot peen controller.

The Telesis unit has a serial port only (no ethernet). I can configure it to use RS232 or RS485. It can be configured to run at up to 19200 baud.

I *think* the communication would be considered half-duplex since the 420 controller never initiates communication, it only responds to ASCII messages sent from the host.

The data sent from the Logix PLC to the Telesis will just be a part number/date code string. All strings end with an ASCII carriage return.

I have not selected a communications interface yet. I'm leaning towards the 1734-232ASC or 1734-485ASC. The PLC is far away from this station, so I don't want to try to use the on-board comm port.

I expect the serial cable run to be under 25 feet from the comms adapter to the Telesis controller.

Can anyone think of any considerations for selecting between the RS232 vs RS485? Is there any practical difference in an application like this?

Thanks!!

Epy · Oct 28, 2016

You could do RS232 at that length (<50 ft is the rule of thumb I believe?), but I prefer RS485 whether it's 1 ft or 200 ft. I'd do RS485. Safe bet.

Prayder · Oct 28, 2016

The RS-232 communication is point to point and works in full duplex mode and the RS-485 is half duplex mode but works in a multi-point environment, so you have one sender and multiple receivers.. something to consider. Also the length for RS-232 is up to 50 ft I believe... but in this situation I don't think it would really matter to be honest.. Much more knowledgeable folks on here that could give you a better answer though.

Firejo · Oct 28, 2016

Prayder said:
The RS-232 communication is point to point and works in full duplex mode and the RS-485 is half duplex mode but works in a multi-point environment, so you have one sender and multiple receivers.. something to consider.

Technically RS232 is a point to point protocol but it will work in half duplex as long has you have a means of splitting the signal (with a radio modem for example). Having said that I don’t see anything in what’s being described that would favor one over the other however I also don’t see any reason not to use the onboard DF1 port. I’ve never had any issues with it on any AB equipment.

Helliana · Oct 28, 2016

I like RS-232 devices over RS-485 because i can hook up a standard USB to serial adapter and use putty or hyperterminal when troubleshooting communications issues. RS-232 PC ports are usually easier to find than RS-485.

RussB · Oct 29, 2016

Always choose RS-485 when available it will be less susceptible to interference and disruption, those who follow you will be thankful.

scarince said:
I'm working on an application to have a ControlLogix 5561 communicate with a Telesis TMC420 pin stamp / dot peen controller.

The Telesis unit has a serial port only (no ethernet). I can configure it to use RS232 or RS485. It can be configured to run at up to 19200 baud.

I *think* the communication would be considered half-duplex since the 420 controller never initiates communication, it only responds to ASCII messages sent from the host.

The data sent from the Logix PLC to the Telesis will just be a part number/date code string. All strings end with an ASCII carriage return.

I have not selected a communications interface yet. I'm leaning towards the 1734-232ASC or 1734-485ASC. The PLC is far away from this station, so I don't want to try to use the on-board comm port.

I expect the serial cable run to be under 25 feet from the comms adapter to the Telesis controller.

Can anyone think of any considerations for selecting between the RS232 vs RS485? Is there any practical difference in an application like this?

Thanks!!

DwSoFt · Oct 29, 2016

Helliana said:
I like RS-232 devices over RS-485 because i can hook up a standard USB to serial adapter and use putty or hyperterminal when troubleshooting communications issues. RS-232 PC ports are usually easier to find than RS-485.

Rs485 ones are easy to come by as well now. I agree 485 is more adaptable.

scarince · Oct 29, 2016

Firejo said:
.......however I also don’t see any reason not to use the onboard DF1 port. I’ve never had any issues with it on any AB equipment.

So you bring up an interesting point.....I never considered just using the DF1 port. My cable run from the PLC might be 50 feet, that's why I was thinking about using the POINT I/O communication module.

Other than cost and maybe complexity, are there other pros/cons associated with just using the onboard port? Are there any issues with using the ASCII commands when using a port that is not the onboard port? I ask b/c I've never done either before.

Thanks.

Helliana · Oct 29, 2016

scarince said:
So you bring up an interesting point.....I never considered just using the DF1 port. My cable run from the PLC might be 50 feet, that's why I was thinking about using the POINT I/O communication module.

Other than cost and maybe complexity, are there other pros/cons associated with just using the onboard port? Are there any issues with using the ASCII commands when using a port that is not the onboard port? I ask b/c I've never done either before.

Thanks.

One con IMO is that the newest CompactLogix and Controllogix processors do not have serial ports. If you make your program use the onboard port, you will have to re-engineer it later if you ever want to update to newer firmware. This could also make it harder to replace processors in the future because you are locked into a older model. It's not a huge deal now, but its something i would consider.

Plastic · Oct 30, 2016

The easiest way to send ASCII data from AB to serial devices over distance.

You only have to load the ASCII string(s) into a single string tag in the PLC.
The RTA 435 will handle the serial part.

Flawlessly Robust.

http://www.rtaautomation.com/product/435nbx-2/

We used dozens for ASCII inputs from scanners, and ASCII outputs to printers and dot marking equipment

scarince · Oct 31, 2016

Helliana said:
One con IMO is that the newest CompactLogix and Controllogix processors do not have serial ports. If you make your program use the onboard port, you will have to re-engineer it later if you ever want to update to newer firmware. This could also make it harder to replace processors in the future because you are locked into a older model. It's not a huge deal now, but its something i would consider.

That's a really good point that I hadn't thought of. Thanks!

Plastic said:
The easiest way to send ASCII data from AB to serial devices over distance.

You only have to load the ASCII string(s) into a single string tag in the PLC.
The RTA 435 will handle the serial part.

Flawlessly Robust.

http://www.rtaautomation.com/product/435nbx-2/

We used dozens for ASCII inputs from scanners, and ASCII outputs to printers and dot marking equipment

I'm going to give that device a good look. Thanks Plastic!

a062549 · Oct 31, 2016

I've used the Moxa for the application your using! CLX to a Telesis marker. We used these for a lot of application in our plant and made sense to use it here. http://www.moxa.com/product/MGate_MB3170_3270.htm

Firejo · Oct 31, 2016

I guess the way I look at it is that you’ve got a serial port on the processor that is there to do, among other things, what you are trying to do. Why add other components to do something that is already doable? Yes the serial ports are going away however I don’t believe that they (Rockwell) will ever create a firmware version for an existing processor with a serial port that will disable the serial port. If there is a concern that the processor might have to be replaced in the future then I would be looking at creating a system that doesn’t use serial at all.

OkiePC · Oct 31, 2016

Firejo said:
I guess the way I look at it is that you’ve got a serial port on the processor that is there to do, among other things, what you are trying to do. Why add other components to do something that is already doable? Yes the serial ports are going away however I don’t believe that they (Rockwell) will ever create a firmware version for an existing processor with a serial port that will disable the serial port. If there is a concern that the processor might have to be replaced in the future then I would be looking at creating a system that doesn’t use serial at all.

I agree with you for DF1 or even Modbus with a SLC or Micrologix that supports Modbus well. When it comes to ASCII or other protocols, the time spent to get it all working right is often more expensive than adding a third party protocol converter.

I have been down the road of writing ASCII code in ladder for a PLC-5. After three days of debugging and handling all the what-ifs, I still ended up with a system that would stop talking about once a week. It was for a Keyence vision system and the only way I could recover comms was to power cycle the vision system. This was for a test application that was not critical but made me a believer in buying a protocol converter with all the bugs (hopefully) worked out by the vendor.

Epy · Oct 31, 2016

Since this thread is still going on, I'd just like to add that I've had trouble with RS232, with shielded cable, under a distance of 50 ft. I had a Sierra mass flow controller and added a DB9 extender cable in the line (total distance of maybe 12-15ft?), and was losing messages.

RS485 all the way.

RS232 or RS485?

scarince

Lifetime Supporting Member

Epy

Lifetime Supporting Member

Prayder

Lifetime Supporting Member

Firejo

Member

Helliana

Member

RussB

Lifetime Supporting Member

DwSoFt

Lifetime Supporting Member

scarince

Lifetime Supporting Member

Helliana

Member

Plastic

Member

scarince

Lifetime Supporting Member

a062549

Lifetime Supporting Member

Firejo

Member

OkiePC

Lifetime Supporting Member

Epy

Lifetime Supporting Member

Similar Topics