RS485 Communications

I have a PC104 SBC that has onboard RS485 ports. I previously wrote standard RS232 comm port routines to talk to devices on the rs485 network by using a 232 > 485 convertor and everything worked great. Now, however, I want to use the onboard 485 ports. I have two questions....

1, my port is a 4 wire, my network is a 2 wire. This is how I converted. +TX & +RX Tied together, -TX & - RX Tied together. The -TX & -RX hook to A on the Network, and the +TX & + RX hook to B on the network. Is this correct?

  1. In my standard Rs232 Routines, I modified to simply Raise RTS, wait 10 ms, then then the string, wait 10ms, lower RTS. I don't do anything special at all waiting on chars to arrive.

Problem is, none of this works. Any pointers? I assume I can use the standard Serial Port Routines if I turn off All flowcontrol and use the RTS line right?

I find tons of info on the difference in the specs, but not much about writing to the ports.

Richard

Reply to
Richard Skinner
Loading thread data ...

by

to

RTS

At least there has to be a jumper / control bit determining which of the incoming data buffers is connected to the UART receiver: you cannot feed it from RS-232 and RS-485 buffers at the same time. The feature is not standard on a PC serial port, it could be using the extra output bits present on

8250 -series interface chips. Go after the hardware documentation / vendor for details.

HTH

Tauno Voipio tauno voipio @ iki fi

Reply to
Tauno Voipio

by

to

Although I don't know much about RS85 and I don't know the pinout of the onboard port in RS485 mode, I've had the same problems with ADVANTECH hardware, trying to talk to industrial I/O ADAM modules from a SBC motherboard (in the "embedded" product line), by switching the direction using RTS too (and the RTS toggle mode that sets automatically RTS during a write operation). By calling their technical support they explained me that the RS485 ports on their motherboards don't fully support RS485, especially the automatic detection of receiving data, a functionality required to communicate with most RS485-compliant devices. Then I guess that RTS is unable to switch early enough the line in receive mode, causing incoming data loss. The only solution we found was either to buy an extension card with real RS485 ports, or to use a RS232RS485 adapter like you did.

RTS

I hope it did help you.

Thierry C.

Reply to
Thierry C. (NOOS)

to

Try to invert the A & B connection.

I belive that +TX & +RX are to be considered like the A channel. -TX & -RX are the B channel.

Good luck.

Reply to
Camel

by

to

No. TX/RX+ is A and TX-/RX- is B

Meindert

Reply to
Meindert Sprang

by

to

If your network is (i.e. MUST BE) 2 wire, then yes. :>

Presumably, the 232-485 converter used RTS as a "direction control" (typical). As such, it caused the 485 transceiver to "drive* the network when you were "transmitting" data, etc.

Since you don't explicitly mention *discarding* and/or *checking* the data RECEIVED while transmitting (i.e. a copy of YOUR outgoing data), I assume the 232-485 converter disabled the 485 receiver while "transmitting"...

You've not mentioned the protocol you are using to govern/arbitrate access to the network so there are big issues unstated...

The first 10ms (before Tx) is probably overkill. You just need to wait long enough for the 485 transceiver to "flip" to Tx mode. The *second*

10ms may be too small (unlikely since you haven't complained about data being "clipped"), just right, or too long.

Essentially, you want to wait for the last character to *clear* the transmitter portion of the UART before twiddling RTS. Note that this is usually one (or more!) "character times" (i.e. 10 or 11 times the "bit time") AFTER the last "transmit register empty" interrupt. It depends on the UART being used (how deep the transmit buffer is, etc.) as well as your actual bit rate.

Using a fixed "10 ms" may (does?!) work for your current conditions. But, moving to a slower bit rate, different UART or even changes in the network cabling can cause that fixed delay to become inadequate at some future date.

You want to make sure the last bit of the last character transmitted has cleared the "TxD" pin on the UART *and* had a chance to propagate through the network (cable length and potential reflections if improperly terminated) before turning off the transmitter (via RTS) and relinquishing the wire to other potential masters (transmitting nodes)

Make sure you have terminated the network properly...

RTS

Depends on what the 485 ports on your board are wired as. You haven't said if they are the same UARTs that you have been using with 232 (i.e. just some jumpers to handle the 232/485 strapping option) or if they are implemented with different physical devices entirely, etc.

The vendor/documentation should be able to tell you what controls the transmitter ("direction") in the 485 transceiver (i.e. RTS, or some other mechanism). Your protocol choices will also affect how and when you drive the wire -- as well as how you respond to activity

*on* the wire (e.g., resolve contention, etc.)

Your vendor may, also, provide sample routines describing how they

*suggest* that you use the ports (though they may be highly simplified and/or not optimized nor applicable to your particular protocol). But, a good place to *start*!

--don

N.B. Incoming mail is not accepted at this email address.

Reply to
D Yuniskis

You may have A/B backwards. I've used RS-485 for 15 years, and still can't remember if its A==+ B==- or the other way around.

Try swapping A/B.

Maybe. It depends on how your RS-485 port is wired. Is RTS used to enable the drivers?

Huh?

--
Grant Edwards                   grante             Yow!  I will SHAVE and
                                  at               buy JELL-O and bring my
 Click to see the full signature
Reply to
Grant Edwards

This is why the chief engineer had someone invent oscilloscopes!

  1. 10mSec seems like a long delay after transmission. What is the baud rate? You should normally delay only about one character time after the end of a transmission to switch to receive. This is especially true if your device is a system master. At faster baud rates, some devices my have completed their response in 10mSec.
  2. Get a scope and make sure your data is actually being transmitted. Then see if you can find any responses.

Then verify the settings with the oscilloscope! ;-)

Mark Borgerson

Reply to
Mark Borgerson

Sounds right. What about the '485 line termination and bias resistors? Do you have a separate ground to control the common mode? Check the quiescent (no signal, DC) conditions on the line.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

Got it, Actually after writing this email I broke out the storage scope and checked it. Since the RS485 is Com4, IRQ 10 the IRQ Vector was set wrong. Once I fixed that, I simply use the RTS before sending data and she worked great.

I just has so many new items I was testing so I had to narrow the problem down and the trusty Oscope let me know where the problem was. Again, Thanks for the help.

Richard

network

however, I

converted.

hook

this

wait 10

the

it

standard

vendor

Reply to
Richard Skinner

Yes, this was an Advantech board. I fixed it by doing the following:

1st - fixed the IRQ Vector problem - I was using the wrong value for the non-standard port. 2nd - Using standard RS232 Comm Routines however I turned off all the port options (required for modems) 3rd - I simply switch the RTS before sending data, then switch it back immediately after the send buffer is clear.

I'm communicating okay at 38,400 using Modbus RTU (4 wire to 2 wire setup). I never used 485 before beside with an 232 to 485 adapter so I wasn't sure what to expect.

Thanks, Richard

network

I

converted.

hook

10
a

on

Reply to
Richard Skinner

IRQ Vector Issue on the Non-Standard Port. Tracked it down using the Oscope and found NO Data was going out.

Thanks again for everyones help.

by

to

RTS

Reply to
Richard Skinner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.