|
|
Modbus with sc23
May 6, 2008 6:09 pm, by kprabu_24
Subject : Software in Automation
 from the R&D dept.
Text :
Dear Sir,
1) I saw a sample code for Modbus on a web site.
In that code they initialized the I2C. Can you explain why they initialized I2C?
2) We are only framing the ADU and PDU units. On the server side we are only checking these units. There is no protocol (hardware) check made for Modbus protocol. So can we send data in any format? Can you clarify this?
3) Modbus works for me on all ports [i.e. also on port no 1000].
But it is given in document that the Modbus port no is 502. Can you help me in this regard?
4) What is meaning for coils, holding register, starting address?
5) I have to read a table from server. Can you send a sample code with frame containing function code=0x0f, data length=1, Port no (user defined bytes).
Thanking you.
K.Prabu.
Reply
Re: Modbus with sc23
May 8, 2008 12:39 am, by Michael Griffin
To answer your questions in order:
1) I2C is a communications system used for simple communications over very short distance (often between chips on the same circuit board). I don't know what the application you were looking at used it for.
2) I am assuming from the context of the rest of your message that you are talking about the Modbus/TCP version of the protocol. The ADU is the entire Modbus "frame". The PDU is inside this and contains the function code and data. All of this sits inside the Ethernet packet. On serial (e.g. RS-232, RS-485) with Modbus RTU and Modbus ASCII, the ADU includes a checksum. On Ethernet with Modbus/TCP, there is no special Modbus checksum as Ethernet takes care of this error check automatically. I assume this is what you were asking about in your question on "protocol (hardware) check".
As for the format of the data itself, the Modbus function code determines whether it is bits (coils or discrete inputs) or registers (16 bit words). Other than that, Modbus doesn't worry about what the data *means*. That is up to your software to interpret according to the application. Basically, the protocol just gets the data to where it is going (including the address of the data table).
3) The "standard" Modbus port is 502. However, Modbus will work on any port provided that both ends of the connection are aware of which port is being used. A port number is an Ethernet TCP and UDP thing, not a Modbus thing. It allows different programs to share the same physical Ethernet plug. A server application asks the operating system to be assigned a particular "port number". Then when an Ethernet data packet arrives, the operating system just passes the packet to the appropriate program according to the port number in the packet. This system was originally part of Unix, but virtually every other operating system that can use Ethernet has copied the Unix way of doing things.
This is why you can have an e-mail server (port 25), a web server (port 80), an FTP server (port 21), etc., all on the same computer. They all speak different protocols, but they don't interfere with each other because they are using different port numbers. The only problem you might have in running a Modbus server on a port other than 502 is if the software (both client and server) doesn't have a setting to let you specify a different port number.
4) Modbus defines 4 address areas in a data table. Coils and discrete inputs are bit addresses. Holding registers and input registers are 16 bit word addresses. You can have a maximum of 65536 of each type.
Essentially, coils correspond to digital outputs, discrete inputs correspond to digital inputs, holding registers correspond to analogue outputs, and input registers correspond to analogue inputs. These addresses of course do not have to be hooked up to actual physical I/O. They can just be internal addresses that a program writes to. The difference between inputs and outputs though is that discrete inputs and input registers are read-only addresses, while coils and holding registers are read-write addresses (there are no Modbus functions for writing to discrete inputs or input registers). This lets you have protected memory addresses (the server software of course can write to any address it pleases, since it doesn't go through the protocol to write to its own memory).
Different Modbus function codes apply to different address areas. This means that the memory area you are reading or writing is determined by which function code you use.
How many addresses are actually implemented depends upon the system designer. In other words, not all 65536 addresses of each type will necessarily exist. The designer can also overlay address ranges on top of each other, so that for example, coils could actually just be bits in holding registers and a request to read a coil just gives you a bit from a holding register. The person designing the system implements whatever makes sense for that application. Basically though, you have read-only and read-write memory, and you have bits or words. You have to read the server documentation to find out what the designer did with them.
5) You can download the Modbus specs from www.modbus-ida.org. These specs are well written and detailed with good examples. You want the following
documents: Modbus_Messaging_Implementation_Guide_V1_0b.pdf, and
Modbus_Application_Protocol_V1_1b.pdf. I won't repeat what they say here. If you have specific questions about the documents, then ask another question, but make sure you refer to which page and paragraph in the spec you don't understand so we can answer the question more appropriately. Pay particular attention to pages 2 to 8 in the first document, and pages 2 to 17 plus page 48 in the second document (this covers just about everything you need to know).
The way you have phrased your question (#5) though doesn't make much sense. You said you need to read a table from a server. But function 0x0f is for *writing* data. For reading, you need one of the following functions: 1, 2, 3, or 4 (corresponding to coils, discrete inputs, holding registers, or input registers respectively). You also asked about "Port no (user defined bytes)". I don't understand what you are talking about there.
Something to keep in mind is that the words have to be in "big-endian" byte order (look that up in Google if you don't understand it - it has to do with which byte in a word is the "high" byte). Intel microprocessors use "little-endian" word format, which is backwards from normal format, and backwards from what most network protocols use.
Reply
|