To help you if you encounter difficulties understanding ModBus and JBus, we have compiled the most frequently asked questions.
ModBus is a protocol that was developed in the 1980s to be an industry wide standard by a company called Gould. The protocol works in principal by storing data in a table of registers. Registers can be read from, and written to, depending on their type. Although a register is a 16-bit store (2 bytes, 1 word), different methods of encoding data can be used, eg. bits, bytes, ascii characters, signed and unsigned values. It is possible to access the registers as blocks, known as multiple registers.
The ModBus protocol was developed as an industry standard by Gould, but due to a copyright problem the protocol entered in to the public domain. It has been used by a multitude of manufacturers under the name of 'JBus'. Therefore, ModBus and JBus are identical protocols, only the name is different. If the product is JBus or ModBus compatible then it can be communicated with using the North JBus driver. What has to be determined is how a particular manufacturer has applied the protocol to their system - which registers have values in, and how are they stored.
There are two fundamental types of devices - Master and Slave. The Master makes requests to the Slaves and instigates all communications. A Slave has no choice but to reply to a Master and will not instigate communications. There can only be one Master on a ModBus network. Depending on which role your North interface product is to play, determines which North driver you require.
If we are to act as a slave device on a ModBus network, as above - for example to provide information for a ModBus compatible GUI to access, then our ModBus slave product - JBusDev would be required. This simply requires our interface to make data received from other units available for the Master to read and or write. We do this by acting as a slave device, a store of registers, on the ModBus network.
Search the North e-Library for more information and technical documentation on the JBus slave interface.
It is more common for a user to require a Master unit on a ModBus network. The majority of systems are
designed as Slaves, so our standard JBus driver is would be used. In order to request data from the Slaves
the user needs to know how the other systems have implemented the ModBus protocol.
This is achieved by examining their ModBus implementation document that would have been produced and published with the development of the product concerned. This tells us the register structure or 'map' that they have used and the type of registers they support. Basically, this tells us the range and type of values they support and how a ModBus Master would access them. From this information it is possible to create a contents file for ObSys to access and display the values contained within the device concerned.
If the system uses the ModBus or JBus protocol, then we can communicate with it. If North have been asked to perform a conformance test on a specific ModBus product, then contents files and help documentation is also developed for ObSys. We currently have numerous contents files that have been generated and tested with a wide range of different manufacturer's products, and new developments are constantly underway. As this list is ever increasing the easiest method to see which ModBus products have ObSys support is to view the Interface List, or to contact us directly.
Search the North e-Library for more information and technical documentation on the JBus master interface.
Consult the Interface List to view the current released JBus interfaces available. If the system you require to interface to is not listed, or if you have further questions, contact our support team. We hope this has been of use.
For the complete reference guide to all North products. Visit the North e-Library
North offer a range of training courses for each of our product ranges.
learn more..