from a automatic power factor controller i have to collect some data to my computer. there is a software of that controller which i have installed . we can get data out of the device by rs485 protocol . since my computer has got only rs232 serial port, i used a 485 to 232 converter . but still iam not able to get data
I connected A, B in the port provided in the device to A, B of converter, also i provided working voltage for the converter. the error indicated is"communication error" in rs232 , i used direct connection ie 2 to 2 and 3 to 3
what would be the possible reasons

I generally agree with Mark Strube’s answer. However, different commercial models of the so-called “null modem” adapters for RS-232 are frequently wired quite differently. Typically the difference is in the internal wiring or jumpering of pins. These pins may or may not be jumpered to bypass various styles of hardware handshaking.

You can make your own generic “null modem” adapter, but some assumptions have to be made. First, we will assume the computer and the RS-232 / RS-485 equipment is newer and that both are using DB-9 connectors configured as standard DTE devices. This essentially means pin 2 is receive, RX, and pin 3 is transmit, TX. You will need two DB-9 connectors for attaching to a cable, soldered or push style, etc. You will also need a short piece of 3 conductor cable, preferably communication quality. An old piece of CAT5 network cable is as good as anything.

On each end jumper the following pins. Jumper 7, RTS, to 8, CTS. Then jumper 1, DCD, to 4, DTR, and 6, DSR. Note that 7 and 8 are jumpered. Also 1,4, and 6 are jumpered. But, these two groups are not joined or jumpered to each other, they are two separate sets of jumpered pins. Do, this on both sides.

Then connect the cable. Attach pin 2, RX, on one end to pin 3, TX on the other. Now connect pin 3, TX, of the first connector to pin 2, RX of the other. This creates the “null modem” cross over of transmits and receives of each side being inter-connecterd. You must also inter-connect the signal ground, SG. So, connect pin 5 of the first connector to pin 5 of the other connector.

Now you are ready to try it. This cable can be tested if you have two computers with DB-9 RS-232 ports, and the cable was made with the appropriate gender connectors, by simply hooking the computers together and testing with a communications software. From Windows you might use Hyperterminal. Remember, no handshaking configured in the communication software, because the jumpering is defeating hardware handshaking.

Finally, getting RS-485 to talk is often much more challenging than getting the RS-232 side talking. Although RS-232, RS-422, and RS-485, as they are popularly called, are standards today, there are many variants on all sorts of hardware essentially verging on proprietary. As a result, if you are connecting something like an RS-485 based control device to a typical PC style computer, follow the directions of the manufacturer of the control device. If they do not specify the RS-232 / RS-485 converter they recommend or have tried with success, then call them or email. It could save you an incredible amount of time if you simply follow their guidance exactly.

What protocol are you using to communicate with the power factor controller? Modbus/RTU? If so, you could have a Modbus addressing problem.

And what is the baud rate? You need to make sure that all devices (PC, converter, controller) are operating at the same baud rate.

In RS-485 any connection is meaningless without a protocol. The most common like Jim Mimlitz says is the MODBUS protocol. Again,in addition to whatever Jim says, you need to set the slave-ID on the PF controller, assuming that other comm parameters lie baud, parity and stop bits are properly set. Lastly your PC must have a software which sends requests for reading the variables inside the slave device.

Once you get to this stage, please look up the address mapping table to seek particular variables. Usually slave devices have a number of variables inside them which contain the values of different parameters.

One free utility available for debugging Modbus connections is called MODSCAN. This will help you see inside your PF controller.


REGARDING CABLES
Please note, in my experience, I've seen people mistakenly using a crossed cable between the 485/232 converter and the 9 pin serial port of the PC. You need a Straight cable. ie. no crossing RX/TX. Usually 3 wires(pins 2,3, &5) are adequate. as most devices use software flow control.

Step 1: Is your PC's serial port ready to work?. Use a loopback 9-pin female connector (jumpers: 2-3, 4-6, 7-8). Start Hyperterminal for that port, ensuring that the terminal emulation does not "echo" sent caracters. Type anything, you should see the typed characters. When you remove the loopback connector, the characters should NOT be echoing.
Step 2: Is your RS232-RS485 adapter working properly? Follow the hints above for the cable and settings. Does the adapter have its own DC power adapter? Just to be sure, use it, even if the RS232/485 is documented as working without it as well.
Ideally, if you have a second adapter, and another PC with a serial port, you may connect them RS485 - to - RS485, and Hyperterminal from one PC to the other. This exercice will also provide you with useful insights on RS485.
If not, jumper the adapter's RS485 A to B and repeat the hyperteminal test at Step 1. If it does not work, you know what's wrong. If it does work, it means it has about 2/3 chances to connect to the device.
Step 3: Now you are reasonably sure the RS232/485 adapter works. Be aware that many devices connection is documented A to A, B to B, + to + , - to -, or vice-versa. It's crazy. Therefore you need to be ready to swap the connections.
Step 4: Find as much as you can about the serial parameters: baud rate, parity, start/stop bits, Xon/Xoff (software), DTR/DSR, CTS/RTS. If this sounds unfamiliar, please familiarize yourself with these notions. For an RS485, it's Xon/Xoff. The other parameters, however, must be specified identically on the device and the PC.
Any decent device would have a light to flash when it receives data. Some of them have a light that flashes when it sends data, too. If the serial parameters are correct, and the A and B polarity is correct, then this light should flash when a correct message is received. Not all devics will flash the LED when the message is "bad". But if you see the light flashing, you are surely going somewhere. If there is a light to indicate the device is sending, and you can see a dialogue (like PC sends a message, and then the device sends a message back), you are in luck !!!! Check the reply as decoded by the PC application you're using to talk to the device. Maybe the problem is there....
Step 5. Get as much inforamtion as possible regarding the "protocol" (i.e. the language) the device and PC should talk to each other. In other word, whether it's Modbus, HostLink, DS-1, DH-485, or whatever. Make sure you get the PC and device right. Follow the directions provided above. At this point you may call the Customer Technical Support to help you out.
Keep on trying, and reply to let us know how far you are.
Good luck

There are my additional ideas. RS485 is Half duplex protocol. This mean that computer must switch RS485-RS232 converter to Send mode and back, dependently on operation (Send or Receive). Sure, modern RS485-RS232 converters has automatic switching, especialy converters RS485-USB are automatic. But I know some older popular converters RS485-RS232, that must be driven to right direction by signal "RTS". Unfortuneately, these popular converters RTS signal polarity must be oposite than IBM PC by default sets/resets when data is send from computer. This mean that RTS signal must be driven from computer program by using of special rules and special delay time that may allow to switch converter Send/Receive (usualy 50ms). As I know, not all popular programing tools allows easy operate with RTS signal. My programs where written on Microsoft C++ and I have used Win32 API to solve this challenge in my old projects.
My proposal - find converter RS485-USB to avoid such kind of problem. I know one manufacturer of such converters if you need.
Best regards.

I had years ago the same problem: I used a hardware converter RS232-RS485. On some computers everything is working on others not. After a lot of analyzing with all kinds of equipement, I discovered the RS232 interface is not handled equally with all manufacturers of computers. The switching between receive and send is critically and some computers do not give priority to the serial interface. Therefore it is good to use an intelligent converter which means a converter which has a buffer and does the switching and timing . There is a company which is selling these converters very cheap (www.rs485.com)
Hope this helps you....
Best regards