2 wire rs485

Hi, this means that the problem could be related to the RS485 direction (TX/RX) control which can lead to bus conflicts; I have experienced similar problem with built-in RS485 ports. What is probably happening is that the slave starts responding before the master has released the bus

If your network is composed by just 2 nodes and the cable is short, then termination is not necessary

If you do not have a signal ground connection, you _must_ use the termination resistor to supply the bias current for the receiver transistors, regardless of the number of nodes or cable length.

Paul

So you have JP1 links set as:- 2 to 3, 5 to 6, 8 to 9 and 11 to 12.

...and JP2 pins 5 to 6 connected.

...and JP3 pin 3 to 4 open

...and have connected CN9 pin 15 to Meter A ...and have connected CN9 pin 11 to Meter B

(sorry if it states what you already have found out from the manual).

Not necessary to do anything with the ground except to endure one end is connected to ground to provide shielding if the cable length is appreciable or data is fast and you have a noisy environment. On the bench in the lab with a short link you should be OK on unshielded twisted pair.

Interesting that this works. I would check that the processor board is behaving as expected. Have you scoped across the pair and tried to manually decode the data stream?

I am wondering if the TX/RX pairs on the processor board have been swapped in error. After you see what happens on the data pair look beyond the drivers on the board to see if the data polarities make sense (the sort of fault that can creep in if the layout guy got things swapped).

--
********************************************************************
Paul E. Bennett...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

yes exactly.

ok, i suppose you are talking about an oscilloscope. we don't have one, sorry.

do you mean the pins 11 and 15 swapped? or that tx and rx are really another pair of pins? if you're talking about the first option, then i could just swap the A and B inputs, right? well, if i do swap them, then i do not get any response from the meter (which made me think about terminations and connection issues in the first place)

well, thank you for your answer.

vasilis.

oh and by the way,

i know that rts/cts handshake must be performed manually. could you please tell me what actions must be performed? the only thing i do now is to raise the request to send signal, send data, then lower it and wait for response.

thanks again, vasilis.

[%X]

Yes, using an oscilloscope. It is a worthwhile piece of test equipment to have in your toolkit.

I saw a layout error of this type made in another system. The TX+ and RX- were joined together on the PCB track and consequently the TX- and RX+ were joined. This is a manufacturing error of course but they do happen. It required some track cutting and re-wiring to fix that one. The maker of the board had tested it with another board of the type and with the same fault. It just didn't work with any other system.

--
********************************************************************
Paul E. Bennett...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Careful. The ground connection *is* necessary (RS-485 does not have an infinite common-mode; in fact it's +/-7V on top of the 0-5V signal swing) -

*but* it may be implicit. If both pieces of equipment are grounded to the same ground, it's implicit. If one is not connected to ground at all, it *may* work, or may not - the non-grounded end might happen to self-bias in the right range via receiver input current , but might not.

This is probably what Paul Keinanen meant in his post:

termination resistor to supply the bias current for the receiver transistors, regardless of the number of nodes or cable length.

It is self-biased by the input current.

I have been using this both with CAN as well as RS-422/485.

One RS-232/485 converter manufacturer even dropped the signal ground connector entirely from the floating RS-422/485 converter in a recent version

check block diagram on page 3 and connector list and connection diagrams on other pages.

An older converter version

in the diagram on the last page had a screw terminal labeled as "Shield", which was connected to the internal floating 0VB supply, The line connection diagram on page 13 suggest that the cable shield is connected only at one end to that "Shield" terminal to avoid ground loops.

These converters have been used for years in various industrial installations all over the world.

So the signal ground connection is not necessary nor desirable in systems with large ground potential differences.

This is really a mess (as the comment on page 12 of the latter link suggests), I have seen converters and RS-422/485 PCI cards with A/B defined in opposite ways and also various combinations of T+/T- both ways.

As long as the devices have RxData LEDs, it is quite easy to detect, if the RS-422 is connected the wrong way. If the RxData LED is constantly lit when there is no traffic, just reverse the R+ and R- pin at the receiver end.

On RS-485, use one end with active fail safe termination (typically the master) as a reference and check the RxData LED on all slaves when the bus is idle. If the RxData LED is constantly lit on a specific slave only, just reverse the D+ and D- connections on that slave.

Paul

It looks to me like both the converters you referenced are isolated converters, with no common ground between the power supply and RS-485. In that case, I can see that the RS-485 ground wire may be optional.

--
newell  N5TNL

... snip ...

Raise rts, await cts, send data, lower rts. You never send data without cts being asserted by the receiver. Those acronyms stand for request/clear to send.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

I thought this was an RS-485 interface. That only has tri-state data signals between the two devices. The RTS signal is used to enable the driver for transmission. I'm sure you know about this. I expect you just didn't get the context.

Rick

I guess I should mention to the OP that although the RTS signal is typically used to enable the driver onto the RS-485 bus, but this does nothing to make sure no one else is driving onto the bus. That has to be done in the protocol. It is also important to allow some bus turn around time in the protocol. It can be hard to control the timing of the RTS signal to perfectly bracket the character or message being transmitted. The status signals from typical UARTs are not sufficient to use to control the driver enable and extra time must be added.

A typical protocol has one unit as the master and one or more as slaves on the bus. The master queries the slaves who respond. Before they respond, they must wait for the master to release the bus. Likewise when the slave sends its reply, the master has to wait for the bus to be released before sending another message.

Rick

On an RS-485 bus side, who is going to generate the ClearToSend signal for the RS-232 port input ??

The proper way is to raise the RTS, send the data and then wait until the last (stop) bit of the last byte has _actually_ been shifted out of the Tx _shift_ register. Then drop RTS and receive the response.

On ordinary PC style 14550 series UARTS it is hard to detect when the last stop bit has been transmitted, either poll the proper UART status bit (no interrupt available) or use RS-232/485 chip that allows monitoring your own transmission and from the local echo, detect when the last byte of message has been transmitted and echoed, before dropping the RTS.

Paul

Very few protocols actually specify any extra line turn around times, the notable exception is Modbus, which specifies a 3.5+1.5 character (end of frame gap+reply preamble) separation between request and reply (but the reply preamble is often omitted). Other protocols may reply immediately as the response has been processed.

IMHO, for properly driving RS-485 lines from a multitasking OS, a proper UART with HW generated RTS should be used. The standard PC style 14550 family is mainly usable for driving RS-485 lines in single tasking MS-DOS at below 9600 bit/s with software data direction control with the RTS signal :-).

Paul

An other method is to operate the RS-485 bus as a CAN bus i.e. with dominant and recessive states, which does not require active data direction control.

The RS-232 TD pin on the RS-232/485 converter is permanently connected to the "0" state and the TxEnable pin is connected to the UART TX pin so that when "0" bit needs to be transmitted, the transceiver chip is enabled and the bus is driven actively to the "0" dominant state. When the "1" bit needs to be transmitted, the transmitter is disabled and the "fail-safe" bus termination will pull the bus to the "1" idle (recessive) state. This may have some implications for the noise margin.

Paul

On Feb 11, 1:21=A0pm, "Steve at fivetrees" wrote: then I'm puzzled ;).

485

and

m

hat

for

e -

ok, i'll try to be as precise as possible, but bear in mind i am a sw engineer, i don't have much of an electronics knowledge.

when i use the converter (which by the way is a JaRa 2102E(chinese)) i do this:

- plug the converter to the serial port RS232

- screw one end of each of two wires into, respectively, a hole marked d+/A and a hole d-/B on the converter side

- screw the other end of the wires to the holes of the meter i mentioned before.(A and B)

the total length of the cable is approx 60cm.

the software i wrote does this:

- set the port parameters as needed to communicate with the meter(1200 baud, even parity, 8 data bits, 1 stop bit)

- send 16 bytes(a packet of the meter communication protocol with a request enclosed)

- receive 20 bytes (the response packet)

no rts cts lowering or raising. no ground wire, even though there is a hole on the converter end marked as GND.(as i mentioned before, the meter doesn't have one)

i googled for the converter model but i found no electrical scheme, just a few pages in chinese.

also, about waiting for the clear to send signal, well, it is never sent by the meter.

thank you all, vasilis.

The line-driver hardware. Sometimes it contains a delay timer, sometimes it's just RTS looped back.

One presumes that was what was meant by "send data, then lower RTS".

I've seen chipsets where that bit wasn't implimented correctly and went active before the last stop bit was sent.

On faulty hardware (which you have to assume is the case on a PC) the local echo method is the only reliable way to do it.

--
Grant Edwards                   grante             Yow! Hello.  Just walk
                                  at               along and try NOT to think
                               visi.com            about your INTESTINES being
                                                   almost FORTY YARDS LONG!!

The "transmit buffer empty" flag just says the data has been loaded into the Tx shift register, and hence the transmit buffer is ready to receive more data. It doesn't tell you anything about the Tx shift register, which typically (unsurprisingly) takes one more frame time to send that last stop bit.

So: use the flag to start a timer for e.g. 1.5 chr times, *then* disabled the transmitter. Or, as Paul says, monitor your own transmissions (closely: doing so periodically is nowhere near good enough).

Steve

--

Ah - but if they're isolated (which is actually very common and desirable), then the ground wire *is* useful - on each side of the isolation barrier, but not across it ;).

Steve

--