I need RS232 to RS485 converter or USB to RS485 converter, are there vendors out there you recommend for these converters? More specifically, RS485 I am using is 2-wire (ground, don't need 4-wire version) at 19200 baudrate.
RS-232 to RS-485 needs two simple chips back-to-back: RS-232 to logic (e.g. MAX232) and logic to RS-485 (e.g. MAX485). The real problem comes from the control of the RS-485 transmitter enable, if your interpretation of two-wire RS-485 involves traffic in both directions (which is 4-wire with transmit and receive bus lines connected in parallel).
There are simple boxes which contain the chips and usually a simple power supply (e.g. a plug transformer, 'wall wart'). Usually, they are four-wire, but the common bus two-wire is achieved by connecting the RS-485 bus sides in parallel. The boxes often control the transmit enable with the RS-232 RTS (request to send) signal.
I have found that the converters using RTS to enable are not very useful to me. It is not possible to use them with Hyperterminal in windows because when hardware handshaking is turned on, RTS is permenantly asserted, so bi-directional transfer is impossible.
It is also not possible to use them with windows application, because it is impossible to know when to reset the RTS line, because the application has no way to know exacltly when all data has been transmitted out the serial port.
I think the only way to make a useful RS-232 to RS-485 adapter for windows is to use a hardware one-shot triggered by the start bit to control Transmit enable on RS-485 driver. Please let me know if I am wrong.
Yes, thats the way I see it also. However, the basic difference between RS485 and RS422 is that RS485 was designed to have more than one transmitter - although with only one transmitter active at a time. RS485 allowed higher common mode voltages to achieve that, together with parallel termination at each end.
It is possible to have 4 wire RS422, 2 wire RS485, or
4 wire RS485. The 4 wire RS485 would typically have a master (such as a PC) transmitting on one pair all the time, and receiving on the other pair all the time, with a number of connected slaves (such as field devices) each receiving on one pair all the time, and transmitting on the other pair only when they were supposed to.
One disadvantage of the 4 wire RS485 (besides the extra two wires) is that no slave can see the other slaves transmssions. So by definition it is only good for Master-Slave type protocols, not peer to peer protocols. One advantage is that the Master or "PC" does not need to control its transmit line - it can transmit all the time.
Personally, I have found Hyperterminal a real PITA, and highly inconsistent. There are a hundred and one free terminal programs for windows that are far better (and as many again commercial ones). At the risk of starting yet another "my terminal program is better than your terminal program" thread, I'd recommend "Tera Term Pro" for most serial work (because it is small, fast, neat, and does what enough for most jobs without doing too much) and "RealTerm" for more complex work (because it is big, powerful, with more options than I could imagine needing). In particular, "RealTerm" supports RTS control of RS-485 lines as you want here.
It is perfectly possible to do exactly that - when setting the DCB flags in a SetCommState api call, you can choose to have the RTS line permanently high, or low, or hardware handshaking, or to have it active whenever there is something being sent out and deactivated when there is nothing being transmitted. It is simply a matter of choosing that flag, and your RS-485 communication should work perfectly. I haven't done any measurements as to the exact timings on the line, but I have found it far more reliable than using so-called "intelligent" RS-485 adaptors.
Now, if anyone can tell me how to get the same effect in linux, I'd be most interested!
RS-422 is point to point with the transmitters always on.
"4 wire RS-485" usually refers to a single RS-422 master (with Tx always on) and multiple slaves with one pair constantly listening to the master transmission on the master Tx pair, but the slave transmitters can be tri-stated and all slave Tx chips are connected in parallel to the master Rx pair.
The master can communicate with a single selected slave at the time in full duplex. Alternatively, the master can send broadcasts to all slaves and simultaneously receiving data from a single slave.
I have not read the actual standard to check if 4 wire RS-485 actually is standardised, but this name is often used in practice for 4 wire multidrop systems.
Unfortunately the 16550 family UARTs (as usually used in PC:s) are more or less useless for controlling the RTS/DTR etc. pin for data direction control, since these chips _do_not_ generate an interrupt, when the transmitter shift register is actually _empty_ (it only generates an interrupt when the last character is loaded from the FIFO to the Tx shift register).
If a UART with hardware direction control is not available, one way is to connect the Tx data pin also to the Tx enable pin on the RS-485 chip and actively drive the line only when the "0" serial bits are to be transmitted (and use passive pull-ups for the "1" bits an idle) or use some micro controller to detect the stop bit and turn of the transmitter immediately after that (usually requires selecting the baud rate with DIP switches) and turning on the transmitter again, when the next start bit is detected.
To control RTS, I wrote my own program that uses DCB flag in one of those Windows API calls. Definitely don't want to use HYPERTERMINAL to toggle RTS. Have not measured exact timing yet, but it worked as I intended.
My original post was to find commercially avialable RS232-485 converter. We have built in-house version of such a converter, but it takes longer to build it internally than buy it somewhere else...
I don't agree this would mean "it" (RS485) is 4-wire, then.
It's really two independent RS485 links, using 2 wires each. The fact you're not using full-fledged transceiver chips on your nodes is not a feature of the RS485 line protocol as such --- it's a detail of the particular application.
You wouldn't call a bundle of ten classical coaxial Ethernet cables used to connect ten machines to ten other ones a "10-coax Ethernet" connection either, would you?
Hans-Bernhard Broeker (firstname.lastname@example.org)
Even if all the snow were burnt, ashes would remain.