I am designing the driver for a Modbus slave with very limited functionality. Could someone please advice the functional codes (standard) that should be essentially recognized and replied for by the slave. I mean, is it at all necessary to implement all the function codes in the slave, or it may recognise only the ones specific to my application needs?
No, is not necesary to implement all the function codes, the master will recognise your applications functions, but you will need to implement functions with processing of all errors codes that may be appear.
-ILLEGAL_FUNCTION = 0x01
-ILLEGAL_DATA_ADDRESS = 0x02
-ILLEGAL_DATA_VALUE = 0x03
-SLAVE_DEVICE_FAILURE = 0x04
-NEGATIVE_ACKNOWLEDGE = 0x07
-MEMORY_PARITY_ERROR = 0x08
If master send you a request with function FORCE_MULTIPLE_COILS and you do not have implement this function, your code will respond
with ILLEGAL_FUNCTION and that is ok for you.
There's not a standard minimum to become a modbus slave but some basic recommendations:
1) Try to make data available with several functions: a digital value can be read as a digital value and as a bit into an analog value.
This will help to integrate your product with most of modbus masters.
2) Try to make available all the data as possible: Configuration, diagnostics. A little effort at this phase will make your product much more powerfull.
3) Test it with several modbus masters, modscan is a nice application, free to try and cheap to purchase.
NOTE: Read some general documents about modbus to get familiar with inputs, coils...this will help you with the mapping process.
I am assuming that you need to Read & Write the Flags & the Registers. Folowing codes need to be implemented.
Here is a couple of hints,
1. Modbus.org has an implmentation guide for both serial and TCP modbus. It should help, admitedly I have only browsed it.
2. At a minimum use FC 3, 16, and 23. 23 seemes to be a pain to code, but it is what the NOE's use for I/O scanning and it it will give you the best performance with an NOE. Even If you are not using TCP Modbus the Modbus Rs232 to Modbus TCP bridges are getting more and more common.
I hope It helps.
Tarun, Please see my reply to the question regarding MODBUS Lite. To cover most needs, you need only 6 function codes: Read and Write multiple holding registers Read and Write multiple coils Read multiple input registers Read multiple inputs Make sure you document what your device supports. Meir
A) Minimum set is 3 and 16 for read/write multiple registers. You can pack boolean (digital) values 16 to on register - just be aware that the normal bit-order seen is not what you'd expect so make sure you document your bit order correctly. Note that some very important "embedded masters" only can issue these 2 functions! Thus a smart slave creator makes sure ALL data is available by function 3. A=(3,16)
B) Next, I'd add function #6 - write single register. It only adds a few minutes work beyond function #16, and some Masters will use #6 to write one value and #16 for more than one. Thus, if you don't do function #6, some Master may not work or may need to be configured to force use of function 16 for all writes. So NOT doing function 6 could lead to field support problems. B=(3,6,16) - This is what I'd call the real minimum set!
C) if you have lots of 1-bit digital control items, then next level to add is functions 1 & 15 for read/write multiple coils. You might as well add function 5 (write single coil) while you're at it. Just be aware that Modbus is big-endian, so the value to send for function 5 is 0x0000 and 0xFF00 for Off/On. You should not send 0xFFFF nor 0x00001. Problem is some slaves treat any non-zero value as On, while others will return an exception response if you send anything but 0x0000 or 0xFF00!!!! C=(1,3,5,6,15,16) - This is the "normal set"
D) you could add the function 2,4 for read-only bits/registers. Problem is these value MUST also be available by function 3 for maximum market application, so they have little value.
E) you could add function 8 (echo). The only value this has is some older DCS/SCADA gateways REQUIRE any modbus/RTU slave to response to an echo before it is marked on-line. This is a Dinosaur requirement, but if it means the difference between selling 50 units to some DCS or not, a few minutes to add the echo command is money well spent.
F) Finally, some "nice to have" functions: - function 23 allows 1 message to both read & write the slave. This is ideal for a small I/O unit where a Master may want to fetch the value of 16 or 32 inputs and force the value of 16 or 32 outputs. It saves having to issue 2 commands (a func 3 and func 16). - function 22 allows a masked register write. This is ideal if you (correctly) allowed all of your digital/booleans to be accessed by function 3. It works like function 16, but allows writing bits selectively scattered within the registers.
*** So in summary, if *I* were to do a product, this is my list: - Bare Min: 3,6,8(echo only),16 (limited 1-bit support!) - Preferred: 1,3,5,6,8(echo only),15,16 - Best: 1,2,3,4,5,6,8(echo only),15,16,22,23
Best Regards - LynnL, www.digi.com
( Complete Thread http://www.control.com/1026181196 )
> - function 23 allows 1 message to both read & write the slave. This is
> ideal for a small I/O unit where a Master may want to fetch the value of
> 16 or 32 inputs and force the value of 16 or 32 outputs. It saves
> having to issue 2 commands (a func 3 and func 16).
This is also frequently used in intelligent electronic devices (IEDs) to implement fetching of records and other device- and application-specific tasks.
For example, a relay might store the most recent 128 operation records. (Lets say each op record is 16 bytes long.) Rather than map each record to its own set of 8 consecutive registers, the IED might implement "fetch the Nth op record" as a write/read command: write the desired record number to register 40001, and read the specified record from registers 40002-40009.
Using the same registers for all the records saves (logical) register space. Using a write/read command gets around the problematic approach of writing the record number with a write register command, waiting awhile to give the device a chance to copy the requested record to a register set, then reading the record with a separate read registers command... and hoping that no other master has interfered in the interim by writing a different record number to the command register.
A variety of data management techniques are implemented this way. Instead of specifying the record number to fetch, the write/read command could provide a command code:
0 = fetch oldest unreported record in queue 1 = fetch next unreported record 2 = clear record list
(In this case, the response register set would contain the record number along with the record contents. To indicate no more unreported records, the device could return a record number of 0.)
>>I am designing the driver for a Modbus slave with very limited functionality.
On the other hand, it doesn't seem as if you'll need to implement anything that complicated.