I understand that RTU send 8-bit per byte. The problem is when i try to figure out how can i code it. Let's take for example i want to send a message to Read coils 20-56 from slave address 17 in RTU. I have to send this frame:
T1-T2-T3-T4 110100130025{CRC} T1-T2-T3-T4.

Now how can i send this mesage using Delphi such that the frame is only 8 bytes long as indicated in the reference guide? Is it possible to send 11 as 8 bits?

Thanks in advance.

 

The answer is easy - do NOT read a protocol document first and hope to implement it. Obtain one of the many free Modbus tools out there and see what they send on the wire, THEN review the protocol document to help you understand what you are seeing. I have implemented dozens of protocols and this is the ONLY time effective way to do it.

Sending Modbus from a PC application is trivial if you don't mind under-using the RS232/485 link. Your T1-T4 don't exist, they are just "do nothing" time delays.

To send, just make sure the wire has been quiet for AT LEAST 5 msec, but being quiet for 50 or 100msec is not problem. Then send with any standard computer serial driver - the 11-bit async character you are confusing with 8 data bits are not an problem unless you are using dial-up modems. Just make sure your PC port is the correct 8,N,1 or 8,E,1 setting. To receive, just wait until you have not seen any more characters from the slave in say 50-100msec.

All this is easy to do on a PC. I know people warn about the "special timing problems" of Modbus, but 99.99% of the time a PC talking directly to a device won't see these.

- LynnL, www.digi.com

 

Sure. 8-bits is a byte. Or a value from 0-255. Your thinking ASCII not RTU. You will need to send a CHR(11) at least that what I do in VB. I'm not versed in Delphi.
Sort of like a Carriage Return is an ASCII 13 or CHR(13).
Use caution with modbus RTU because there are timing issues that you need to worry about.

 

Hafta agree with Lynn on this one. The timing resolution on PLCs is such that there are minimums, but the maximum bounds are often link timeouts. There's not much point in worrying with a device that only looks for or sends data once per scan. Some aren't scan limited but they have to work with those that are. Many (most?) can't send or receive "back to back" packets even without a protocol so, if in doubt, spread it out. I don't recall getting anything to work by speeding it up. I've seen at least one combination that sends every third or fourth scan. usleep() usually gets sprinkled around quite liberally.

Regards

cww