I'm facing a problem with applying the position command to valve actautors using modbus simulation software
Centrok Modbus interface
- Thread starter Amr Abdelsayed
- Start date
Attached is the data sheet for actutor
Attachments
The two screen shots you posted are nearly incomprehensible, which is surprising because the 48 page Centork Modbus manual for the Modbus option card is one of the most comprehensive and best written Modbus manuals I've ever seen and the info on the pages you showed are not in that manual.
http://www.centork.com//en/document/download/2143
I am not a Centork expert, so I don't know how many different lines or versions of Modbus there might be, but is there any chance you're reading the wrong Modbus document?
The map in the document I found shows Holding Registers like instantaneous torque at (4)0003 (zero based register 2) or Valve position is at (4)0004 (zero based register 3) and the bit mapping for registers 0 and 1. Pretty straight forward.
Your simulator has to be a Modbus master, because the actuator is a Modbus slave.
http://www.centork.com//en/document/download/2143
I am not a Centork expert, so I don't know how many different lines or versions of Modbus there might be, but is there any chance you're reading the wrong Modbus document?
The map in the document I found shows Holding Registers like instantaneous torque at (4)0003 (zero based register 2) or Valve position is at (4)0004 (zero based register 3) and the bit mapping for registers 0 and 1. Pretty straight forward.
Your simulator has to be a Modbus master, because the actuator is a Modbus slave.
Thanks for your reply, as you mentioned there are many versions of centrok actuator and this is the complete manual for our model from centrok website
http://www.centork.com//en/document/download/733
I'm confused because position command and position feedback is the same register number 0 as per datasheet, this right or not, or this is the starting address not the exact address for the register.
http://www.centork.com//en/document/download/733
I'm confused because position command and position feedback is the same register number 0 as per datasheet, this right or not, or this is the starting address not the exact address for the register.
I read it like you do, data word 0000 has the position value in bits 8 -15. If you want to change the position, you need to write to data word 0000 with the new position value in bits 8-15.
page 51 states:
Master Instructions:
Nominal: This variable (Nominal) is the % of opening the user wants to open the valve
and on page 53
14.1.3 Status
The following data will be exchanged when a Read Status 0x01 instruction is sent.
Their nomenclature for the slave map on page 60 is unique-ish:
0^4 means Modbus register 0, bit 4 (in a 16 bit data word)
0^7 means Modbus register 0, bit 7 (in a 16 bit data word)
1^5 means Modbus register 1, bit 5 Centronik DIP switch 5
I'm guessing, because the manual omits the list of supported Function Codes or memory areas, that "Read Status 0x01" is probably Modbus Function Code 0x01, "Read Coils". That would read the position value - the high order bits 8-15 in data word 0000.
I hope so, because if you actually have to change the status of word 0000, bit 0 (Read Status) to the value 1 in order to read the position value, you first need to know what position value to include it in bits 8-15. That doesn't make sense.
In the absence of supported Function codes, the master might use either Function Code (FC) 15 (0x0F) (Write Multiple Coils), or Function Code 06 Write single (16 bit) register, to write a setpoint/position value to a dataword that is bit packed.
It's a matter for empirical experimentation to see what works.
page 51 states:
Master Instructions:
Nominal: This variable (Nominal) is the % of opening the user wants to open the valve
and on page 53
14.1.3 Status
The following data will be exchanged when a Read Status 0x01 instruction is sent.
Their nomenclature for the slave map on page 60 is unique-ish:
0^4 means Modbus register 0, bit 4 (in a 16 bit data word)
0^7 means Modbus register 0, bit 7 (in a 16 bit data word)
1^5 means Modbus register 1, bit 5 Centronik DIP switch 5
I'm guessing, because the manual omits the list of supported Function Codes or memory areas, that "Read Status 0x01" is probably Modbus Function Code 0x01, "Read Coils". That would read the position value - the high order bits 8-15 in data word 0000.
I hope so, because if you actually have to change the status of word 0000, bit 0 (Read Status) to the value 1 in order to read the position value, you first need to know what position value to include it in bits 8-15. That doesn't make sense.
In the absence of supported Function codes, the master might use either Function Code (FC) 15 (0x0F) (Write Multiple Coils), or Function Code 06 Write single (16 bit) register, to write a setpoint/position value to a dataword that is bit packed.
It's a matter for empirical experimentation to see what works.
thanks@david-2, I will try some experimentation to see what works and share the results.
solved, 4001 is for command and 3001 to 3011 for read status.
thanks David
thanks David
Help david..., im going to control Altivar12 by schneider HMI GXU 5312 Please Im Collager Indonesia, an Honor For your help, i dont understan how to change the value of the register
Modbus is not plug-and-play. Modbus is a project. Congratulations, you're the project engineer!
This document covers an overview of implementing Modbus in the field. It assumes that the devices have commercial Modbus functionality. If you are writing your own Modbus code, you need a different information than what's here. This example uses a VFD slave/server drive and a PLC or HMI Master/Client.
Modbus is frequently an option on a device. You must determine that each of the devices you are dealing with actually has functioning Modbus (might need a license or optional hardware). RS-485, RS-232 and Ethernet are hardware buses that Modbus uses, but the presence of any hardware bus does NOT mean that firmware for the Modbus protocol is also resident. Sometimes Modbus is evident by a model number digit, sometimes by configuration or development software pages that are not greyed out.
You must obtain the Modbus manual/documentation for the drive which will be the Modbus slave/server. The Modbus manual will have the Modbus address/register map with other data like what format the data is and whether a register read only or read/write. You need to read and figure out which data you need to read from the drive (and where it is in the map/table), and which data you need to write to the drive (and where it is in the map table).
You also need the manual or documentation for the serial or communications card and the associated serial communication setup parameters: baud rate, parity, stop bit, number of data bits (8) and the wiring pin-out for the RS-485 or RS-232 connector.
For Modbus RTU over RS-485 or RS-232, the serial comm parameters must match (be identical) on all devices: baud rate, 8 bit word, parity, 1 stop bit. Usually a change of serial settings requires a power cycle (power-off/power-on) in order for the device to recognize the changed comm settings.
For communications setup for Modbus/TCP (Modbus over Ethernet), you generally only need to configure the drive's IP address, subnet mask and gateway IP address.
Each slave/server drive must be configured with its own unique integer slave node ID number (can no be 'zero'). (Modbus TCP usually uses the IP address instead of the slave ID).
The drive is a Modbus slave/server which is passive. It does not speak unless spoken to. The Modbus Master/Client (PLC in this example) is the active device that polls (sends out command messages). So you need the programming documentation for Modbus for the PLC or HMI or SCADA or whatever the Modbus Master/Client is. Many PLC/HMI's have a tutorial on Modbus basics with an example. Seek out the examples and tutorials and go through them.
The Master/Client has to send a message to the slave/server that
- addresses a particular slave/server by its slave ID number
- sends a numerical Function Code which the slave will execute
- a starting register/address for the associated data
- the number of registers or bytes (depends on the Function Code) for this transaction
- has a CRC error check value, which is usually calculated by the Master/client
The method and means of specifying all that stuff is dealt with by the development software for the master device. The method and means varies from development software package to development software package. To figure it out requires some reading and usually some guess work because Modbus tends to be poorly documented. One typically enters the needed values and master compiles that data to generate a properly formatted Modbus message.
The programming logic involves creating read or write transactions (reads done separately from writes). From an HMI, it's most likely single write action (a one-shot), for instance to change a setpoint. Continuous, successive read transactions, (once a second) might be used to retrieve process data for display on the HMI.
Some implementation hints
I find it easiest to use a generic Windows Modbus Master/Client to query a single slave (disconnect other slaves from the network) and confirm that it is setup as needed - that it has the appropriate comm parameters and that I can prove that the register addressing is correct by reading a known non-zero value from a known location. After accomplishing a read task, I'll tackle a write task. Once one slave is functional, I'll add other slaves to the network, one by one, checking Modbus functionality of each slave as it is added. If there is a slave that is a different model/brand, I'll skip that one and add it last, because sometimes players from different tribes do not play well together. Sometimes I've had to add a 2nd comm card and put the bad boy on a second RS-485 network.
RS-485 tips
2 wire RS-485 A/B or (+)/(-) driver connections are not defined by the EIA-485 specification and their labeling differs from vendor to vendor. Although A should wire to A, (+) to (+), (-) to (-), when you mix vendors, A might go B. If the wiring is backwards it won't work, but won't damage the drivers. If it doesn't work, try swapping the A/B driver lines.
Use quality shielded twisted pair (TSP) cable.
There should be a terminating resistor at the extreme far ends of an RS-485 network (usually the Master and last drive on a daisy-chained multidrop network). Typically, a terminating resistor is not needed at baud rates less than 38K with short cables for bench testing.
I use an RS-485 repeater/isolator at the Master/Client end to protect the master's serial card and another repeater/isolator half way down a multidrop network, just in case there's a really bad electrical fault on the comm line that takes out the 485 drivers, the loss is limited to only half the field devices. (I live in 3 season thunderstorm lightning land).
Ethernet
I love Ethernet because those little black box 'magnetics' isolate each and every node, whereas RS-485 uses a signal ground which changes potential and can cause ground loops and common mode offsets and swamp the 485 bus. But there are stand-alone RS-485 isolator modules to cure that situation.
One Offset
The dreaded one-offset is because some register addressing is zero based (0, 1, 2, 3, 4) and other register addressing is one-based (1, 2, 3, 4, 5). Decimal addressing is usually, but not always, one-based. Hex based addressing is usually zero-based. The problem is whether the indexed value 532 in a Holding register is (4)0532 or (4)0533. Sometimes you just have to try both and see which works.
Can't connect
If you can't connect see these threads for a list of things to check for when the Master/Client can't connect to the Slave/Server.
Documenting what you've done
It pays to document and write down the settings you used and the transactions you programmed because no one remembers that stuff a month later. And once you touch it, you own it.
And always label the device's IP address.
Other resources:
See this thread for Modbus/TCP 'can't connect' issues:
https://control.com/forums/threads/cant-reach-server-slave-check-tcp-ip-and-firewall-settings.48282/
See this thread for Modbus RTU (RS-485) 'can't connect' issues:
https://modbus.control.com/thread/1463145821
See the thread, Modbus for Dummies with links to various web resources for Modbus information
https://control.com/forums/threads/modbus-for-dummies.30496/
This document covers an overview of implementing Modbus in the field. It assumes that the devices have commercial Modbus functionality. If you are writing your own Modbus code, you need a different information than what's here. This example uses a VFD slave/server drive and a PLC or HMI Master/Client.
Modbus is frequently an option on a device. You must determine that each of the devices you are dealing with actually has functioning Modbus (might need a license or optional hardware). RS-485, RS-232 and Ethernet are hardware buses that Modbus uses, but the presence of any hardware bus does NOT mean that firmware for the Modbus protocol is also resident. Sometimes Modbus is evident by a model number digit, sometimes by configuration or development software pages that are not greyed out.
You must obtain the Modbus manual/documentation for the drive which will be the Modbus slave/server. The Modbus manual will have the Modbus address/register map with other data like what format the data is and whether a register read only or read/write. You need to read and figure out which data you need to read from the drive (and where it is in the map/table), and which data you need to write to the drive (and where it is in the map table).
You also need the manual or documentation for the serial or communications card and the associated serial communication setup parameters: baud rate, parity, stop bit, number of data bits (8) and the wiring pin-out for the RS-485 or RS-232 connector.
For Modbus RTU over RS-485 or RS-232, the serial comm parameters must match (be identical) on all devices: baud rate, 8 bit word, parity, 1 stop bit. Usually a change of serial settings requires a power cycle (power-off/power-on) in order for the device to recognize the changed comm settings.
For communications setup for Modbus/TCP (Modbus over Ethernet), you generally only need to configure the drive's IP address, subnet mask and gateway IP address.
Each slave/server drive must be configured with its own unique integer slave node ID number (can no be 'zero'). (Modbus TCP usually uses the IP address instead of the slave ID).
The drive is a Modbus slave/server which is passive. It does not speak unless spoken to. The Modbus Master/Client (PLC in this example) is the active device that polls (sends out command messages). So you need the programming documentation for Modbus for the PLC or HMI or SCADA or whatever the Modbus Master/Client is. Many PLC/HMI's have a tutorial on Modbus basics with an example. Seek out the examples and tutorials and go through them.
The Master/Client has to send a message to the slave/server that
- addresses a particular slave/server by its slave ID number
- sends a numerical Function Code which the slave will execute
- a starting register/address for the associated data
- the number of registers or bytes (depends on the Function Code) for this transaction
- has a CRC error check value, which is usually calculated by the Master/client
The method and means of specifying all that stuff is dealt with by the development software for the master device. The method and means varies from development software package to development software package. To figure it out requires some reading and usually some guess work because Modbus tends to be poorly documented. One typically enters the needed values and master compiles that data to generate a properly formatted Modbus message.
The programming logic involves creating read or write transactions (reads done separately from writes). From an HMI, it's most likely single write action (a one-shot), for instance to change a setpoint. Continuous, successive read transactions, (once a second) might be used to retrieve process data for display on the HMI.
Some implementation hints
I find it easiest to use a generic Windows Modbus Master/Client to query a single slave (disconnect other slaves from the network) and confirm that it is setup as needed - that it has the appropriate comm parameters and that I can prove that the register addressing is correct by reading a known non-zero value from a known location. After accomplishing a read task, I'll tackle a write task. Once one slave is functional, I'll add other slaves to the network, one by one, checking Modbus functionality of each slave as it is added. If there is a slave that is a different model/brand, I'll skip that one and add it last, because sometimes players from different tribes do not play well together. Sometimes I've had to add a 2nd comm card and put the bad boy on a second RS-485 network.
RS-485 tips
2 wire RS-485 A/B or (+)/(-) driver connections are not defined by the EIA-485 specification and their labeling differs from vendor to vendor. Although A should wire to A, (+) to (+), (-) to (-), when you mix vendors, A might go B. If the wiring is backwards it won't work, but won't damage the drivers. If it doesn't work, try swapping the A/B driver lines.
Use quality shielded twisted pair (TSP) cable.
There should be a terminating resistor at the extreme far ends of an RS-485 network (usually the Master and last drive on a daisy-chained multidrop network). Typically, a terminating resistor is not needed at baud rates less than 38K with short cables for bench testing.
I use an RS-485 repeater/isolator at the Master/Client end to protect the master's serial card and another repeater/isolator half way down a multidrop network, just in case there's a really bad electrical fault on the comm line that takes out the 485 drivers, the loss is limited to only half the field devices. (I live in 3 season thunderstorm lightning land).
Ethernet
I love Ethernet because those little black box 'magnetics' isolate each and every node, whereas RS-485 uses a signal ground which changes potential and can cause ground loops and common mode offsets and swamp the 485 bus. But there are stand-alone RS-485 isolator modules to cure that situation.
One Offset
The dreaded one-offset is because some register addressing is zero based (0, 1, 2, 3, 4) and other register addressing is one-based (1, 2, 3, 4, 5). Decimal addressing is usually, but not always, one-based. Hex based addressing is usually zero-based. The problem is whether the indexed value 532 in a Holding register is (4)0532 or (4)0533. Sometimes you just have to try both and see which works.
Can't connect
If you can't connect see these threads for a list of things to check for when the Master/Client can't connect to the Slave/Server.
Documenting what you've done
It pays to document and write down the settings you used and the transactions you programmed because no one remembers that stuff a month later. And once you touch it, you own it.
And always label the device's IP address.
Other resources:
See this thread for Modbus/TCP 'can't connect' issues:
https://control.com/forums/threads/cant-reach-server-slave-check-tcp-ip-and-firewall-settings.48282/
See this thread for Modbus RTU (RS-485) 'can't connect' issues:
https://modbus.control.com/thread/1463145821
See the thread, Modbus for Dummies with links to various web resources for Modbus information
https://control.com/forums/threads/modbus-for-dummies.30496/
