Linux Serial Communication Using RS485

lindextop · 08-21-2013, 10:45 PM

Hi,
I am developing a C program to communicate with a power meter which supports RS485 Serial Communication using modbus protocol.The device has a 9-pin port available on it.I am using serial to usb convertor (pl2303 converter from Prolific Technology Inc) on my laptop to connect with the device.

I am able to communicate with the device,but the response data i get from the device is nowhere near the expected values.

So My doubts are

1)whether I need to enable anything special on the software side for enabling RS485 communication?

2)Also is there seperate USB to Serial convertors for RS232 and RS485?

3)Is there any difference in the cables to be used for RS232 and RS485?

The program I am using have been tested succesfully for RS232 Communications earlier.

Here is the code snippet i am using for communication

Code:

fserial = open(port_name,O_RDWR | O_NOCTTY);
fcntl(fserial, F_SETFL, 0);
fcntl(fserial, F_SETOWN, getpid());
tcgetattr(fserial,&save_settings);
bzero(&new_settings, sizeof(new_settings)); 
new_settings.c_cflag = BAUDRATE |  CS8 | CLOCAL | CREAD;//9600bps
new_settings.c_oflag = 0;
tcflush(fserial, TCIOFLUSH);
tcsetattr(fserial,TCSANOW,&new_settings);

I am reading data using a thread with the aid of select system call.
I am not using RTS/CTS mode, although the pins are wired in the cable.

The device is continuously sending back data in response to the data i am writing to it.If i change any of the parameters like speed,parity etc,the device wont respond.That means the parameters i am using should be correct.

I am using an Ubuntu 12.04 LT system.

My kernel version is as follows
uname -a
Linux Satellite-C850 3.5.0-39-generic #60~precise1-Ubuntu SMP Wed Aug 14 15:28:09 UTC 2013 i686 i686 i386 GNU/Linux

Below is the log data(in Hex) i am senting to port
WRITE DATA 11 03 00 00 00 02 C6 9B TO /dev/ttyUSB0

Below is the log data(in Hex) i am getting from port.
The below two lines are coming one after another.
READ DATA 00 FROM /dev/ttyUSB0
READ DATA 77 7E 1F FC 34 51 A3 47 00 FROM /dev/ttyUSB0

The actual expected data is 11 03 04 00 00 5D E6 52 E8

If anybody have any ideas about this,kindly respond.

Thank You Very Much for your time.

regards,
sree

business_kid · 08-22-2013, 04:06 AM

RS-485 (Not TIA-485) is much closer to RS-422 than RS-232. RS-232 was the basic serial line that was viewed as poor from early on and future standards learned from it. RS-232 was not specified above 9600 baud, rs-485 can go up to 35mbit, so I imagine the cable would be different. Hunt in the kernel config for stuff. The usb-serial might be supported; There are/were cards sold for industrial use that do rs-485. PLCs of a certain vintage all had it. You may find it easier to go to ethernet for support & software reasons.

Get the standard, I suggest. Read it, write for it. Become familiar with the industrial bits of the linux kernel - all the can bus and other stuff that might do some work for you.

michaelk · 08-22-2013, 07:17 AM

1) Typically no. The RS-485 converter takes care of switching between RX and TX.

2) Yes. RS-232 and RS-485 are not electrically compatible and you can not directly connect the USB serial adapter to the device without a RS-485 converter. There are USB - 485 adapters as well as RS-232 to RS-485/422 converters.

3) Yes. All that is required for RS-485 is a twisted pair. Depending on your environment shielded wiring may or may not be required.

http://www.bb-elec.com/Products/Seri...onverters.aspx

lindextop · 08-22-2013, 07:53 AM

thankyou very much michaelk,

That post was very helpful.So I guess i will need to get a convertor for that.
Then,Regarding the cable,are u saying that only the tx and rx wires are required for rs485.
Also,even if the other pins are connected, it should not matter,am i correct?

PS:I am wondering how I am even getting data without an rs485 convertor!!
The data response was received for every querry i sent to the port.It was just that it was the wrong response.

michaelk · 08-22-2013, 09:56 AM

I might have confused you a bit. At the moment I do not know why the device is responding.

As suggested you might want to read up on how RS-485 works. RS-485 in a nutshell is a differential signal, RS-232 is single ended. You would use a standard RS-232 cable to connect to the converter. RS-485 is half duplex so it transmits (TX) and receives (RX) over the same pair of wires. Make sure the wiring is a twisted pair that connects from the converter to the device.

More reading.
http://en.wikipedia.org/wiki/RS-485

business_kid · 08-22-2013, 02:18 PM

rs-232 should be differential, +/-5V. Trust the hardware guy(me) the hardware for the pair is very different. They routinely connect the Siemens series 7 plc base units(there may be several) with a single rs-485, which can address each one and direct it. You could never do that on rs232. RS232 is the worst comms standard used in dumb terminals and the like back in the sixties and seventies.

michaelk · 08-22-2013, 02:47 PM

Typo? I assume you actually meant RS-485 is differential +/- 5V...

jefro · 08-22-2013, 08:09 PM

485 has a signal across both lines in opposition usually with 100 ohm or so termination on ends or up to 75 total. There is an exact opposite signal on each side. Devices are attached parallel and have an id number usually. You set the scope on both lines to see the signal quality and voltage to determine the signal. Many companies offer software to monitor the nodes via some 232 to 485 within the plc. The sales pitch for 485 is supposed to be that noise won't affect performance. It may or may not work with a line cut.

232 is a single signal on one line with no termination usually. It is fully proven over decades of use.

You can even get pci/isa cards that can be programmed to use either standard or single use cards. Either standard is heavy used in automation. Many 485 boxes start their line with a 232 at the computer.

As with most stuff you can get black boxes for conversion. It may depend on the devices you have already. The makers of them offer help in using them in many cases and deployment kits.