can you help me?
I have a 485 to 232 converter for connect a MODBUS RTU to my PC. the pc don't have 232 and, I use a usb to 232 converter.
My problem is that ModBus says time out every time that i try to connect.
I don't know what is happen...
please give me the following details,
1.What kind of Instrument you want to communicate with Pc?
2.Which software you are using?
3.Do you have installed the Driver for 485 to USB converter?
thanks for your answer.
> please give me the following details,
> 1. What kind of Instrument you want to communicate with Pc?
> 2. Which software you are using?
> 3. Do you have installed the Driver for 485 to USB converter?
I need to control a swimming pool PLC, to control PH data and Cl. I need rs232 rs485 converter because my control system use only 232.
I use ModBus Poll software.
My favorite USB to RS-485 adapter is #5 here: http://ctrlterm.com/related.htm
> I need to control a swimming pool PLC, to control PH data and Cl. I need rs232 rs485 converter because my control
> system use only 232.
The main page there has free open source software and the "custom" page has ModBus.
> I need to control a swimming pool PLC, to control PH data
> and Cl. I need rs232 rs485 converter because my control
> system use only 232.
No you don't. At least according to your original post (in which you mention that you have a USB port). And from a Windows/Modbus Poll standpoint, a port is a port is a port...
So my original recommendation stands.
In any case, working with what you've got, let's do some of the basics.
When you send a command out from Modbus Poll (the PC side), do you see the Transmit LED flash on *both* converters? If not please notify us.
Should you have both Transmit LEDs working on the PC side, are you seeing the Receive LED flash on the pool side? If not, try swapping the TX and RX on the 485 (just one end, doesn't matter which end). See this page for information as to why:
If you swapped the RS485 lines, then try again. Did you see the Receive LED light up?
By the way, does your baud rate and data format match up on both ends?
That's it for the easy/free tests.
If it still doesn't work, it's time to get yourself another converter and install it in either a second USB port on the same PC, or on a separate laptop. Tap into your network's RS485 lines with the second PC/port and install and fire up Realterm. Using this setup, you can monitor both sides of the conversation from the PC to the Pool, and the Pool to the PC.
Do a capture of the traffic and post it here. Along with the manual for the Pool end of things (the Modbus memory map specifically).
While you are snooping in on what's going on the first thing that you need to determine is if packets are going out. Modbus Poll should work fine for this, or you can use Realterm and just hammer the keyboard. Either way will work since this test is just for the PC (Master?) side of things.
So try this, and if you don't see the same data coming in the snooper port as what you are sending out, try swapping the RS485 lines on *just* the snooper port. Try again. Do you see the data now? If not, please reconsider my first recommendation...
If it communicates, then we can take advantage of this setup to see if Modbus Poll is receiving (and understanding) things okay. Fire up a second copy of Modbus Poll as a slave (or use this: http://www.simplymodbus.ca/RTUslave.htm), and have it setup to respond to the message coming from the MP Master.
You will have to pick a node address for your slave that matches the address that the Master is transmitting to. Have the master fire off a request and see if the slave responds. If so, then your wiring is good and your baudrate/format is good. This would indicate that the problem is on the pool end of things.
To make it easy for us to follow along, I recommend that you use the command/response example found here:
Search for "This command is requesting the ON/OFF status of discrete coil" and proceed from there.
For this test we don't want (nor expect) any data. What I would have you do is to send out the equivalent of "0A 01 04 A1 00 01 AC 63" in RTU format and on the slave end send out the equivalent of "0A 81 02 B0 53" in RTU. The response is an exception, but that's fine, if both ends of your test setup agrees that they understood the message, then your master end of the network is golden.
Now when I say that you need to "send out the equivalent of "0A ..." what I mean is the ASCII code for the *HEX* value of each character. Go here:
And use the HX (HEX) column. For non-printable characters you should be able to create them in Realterm and send them out like any other string.
But Simply Modbus should be able to let you create a packet as well (we used to be able to set the numlock key and while holding the ALT key, type in the decimal keycode for the character, then release the ALT key. E.g. "ALT 065" would reward you with an 'A'). Do this inside of a WordPad file, save it and then use it as your "response". You can create the master command this way as well.
If nothing else, NotePad++ will do this for you.
And one last thing (for the moment), you will probably (definitely, unless the example on the Simply Modbus site already did it for you) need to swap the last two bytes around (the CRC checksum bytes) to follow the Modbus spec (it won't work otherwise). So instead of ".....AC 63", you will need ".....63 AC".
If the master end of things works, then we will have to have the pool side equipment manual *and* the dumps from your snooper setup to proceed.
Keep us posted.
Hello, can you help me? I have same problem.
1) i want to get reading of temperature using thermistor 10k that connect to input module (DataNab Ai32). The input module is connect to PC using RS482->RS232->USB.
2) i am using modbus poll.
3) i already installed the driver into PC and my Pc can detect the port but there is no reading in the software and only timeout error.
> My problem is that ModBus says time out every time that i try to connect.
Modbus RTU uses character spacing based on baud rate to determine when a message ends and the next one begins. The inter-message delay is 3.5 characters, so that would work out to be ~4 milliseconds.
Going from a 485 converter to a 232 converter, and finally to a USB converter, I'm not surprised that you are having a problem. :)
Is there a (valid) reason to go from 485-232-USB? If not, then get yourself one of these:
It's the one that I've got, and it works flawlessly.
If you are not able to change your hardware, then try to increase the amount of delay between messages, or lower your baud rate.
The first you thing you need to do is find out if your PLC is able to communicate "out" to your PC. Certain PLCs require a special adapter or setting in order to be controlled by another computer. If your swimming pool PLC is not enabled to be a slave device, you might not be able to make a connection.
There are USB to RS-485 converters that are designed to work with both commercial and industrial PLCs, like these from ICP-DAS. They also have RS-232 connectivity options, and they auto-tune the baud rate.
Do you have the model number of your PLC? That might help with the troubleshooting.
My first guess is that either the USB-485 device is expecting RTS/CTS to be used for duplex, and your software is NOT using those control pins (which the USb driver would map to the appropriate service calls to the USB adapter). or it is using a timed turn-around algorithm with is too slow, so the first byte or two of the response is lost.
Both are possible, but I'd:
1) confirm your software understands RS-485 expecting RTS/CTS is involved
2) if that doesn't help, make sure you use a native USB driver for your product, not just relying on the Windows 'stock' driver, which might not bother with anything as esoteric as RTS/CTS.
I suggest a USB to RS-485 converter by ICPDAS-USA
there are 2 versions, 1 with isolation.
There can be a number of reasons for lack of Modbus (or really any serial) comms. The normal debug checklist is
- Normally one is using a USB-serial converter whose driver creates a VCP (virtual com port) within the OS. You need to go into Control Panel/Devices/COM-LPT Ports to see what COM port number your converter appears under, and configure that in your application program. This number will vary between PCs etc according to what was previously installed.
- Check that the RS485 connections are correct. Some vendors call them + and - and some call them A and B and some call them HI and LO. Try swapping them over. There are various procedures for working out which is which (by measuring voltages) but a swap is quicker :)
- Check the baud rate etc are right. Under Windows, these parameters are configured in the application program, not in the OS. And, to keep life interesting, some slave devices have multiple configs! Most Modbus stuff runs on 8 bits/word, no parity, 1 stop bit, and the most common baud rate is 9600 baud.
- Power cycle the slave device after any config change...
- If at all possible, do interconnect the comms ground of the two (or more) devices. It is usual to run 485 with just two wires but it reduces noise immunity. With an isolated converter (like the ones below) there is no downside to having the ground connection. You can use the cable shield for it i.e. a twin twisted pair cable with an overall shield is perfect.
- Initially test with a short cable and (if there is a provision for this) disable any termination resistors in the slave devices.
We make industrial-grade USB-serial converters (stocked in the USA also) and the best ones are the USB-232 and the USB-485. Both are isolated.
Driver support is all the way from windows 2000 to windows 10. These products have a unique device ID so they come up as the same COM port number regardless of which USB port they plug into (on a particular PC) which saves an awful lot of head scratching :)