Frequently Asked Questions
When customers ask for a port that we do not have, we offer a fixed price that includes hardware and the software engineering effort. We share the cost of hardware and the engineering effort. In this way the customer gets a developed and tested port for a very attractive price.
Yes. At present our code is compile time configurable to support Modbus RTU (RS232/RS485) or Modbus TCP.

We have two licensing models, Multiple Product and Single Product.

The Multiple Product license is designed for manufacturers of end-use equipment, sensors, meters, and other data acquisition hardware. They can use the Modbus library for unlimited number of end-use units for all their products. The price for one Multiple Product License library is USD 1,000.00.

The Single Product License supports design engineers, product developers, consultants and integrators who require Modbus for a single product that they are working on. The library can be deployed on multiple end-use units of the design. The price for one Single Product License library is USD 500.00.

Documentation for the source code library is available on our website.
Generally Modbus IP devices are Human Machine Interface(HMI's) that needs to communicate with many serial remote terminals (barcode readers, temperature controllers, pressure sensors etc.) to acquire data from them or send control signals. Now since HMI is one for a control system with many RTU's, it invariably becomes the Modbus Master with all terminals acting like slaves.
The spec that you reproduced from Pololu website only talks of the physical layer (baud rate, parity, signal levels etc.) and not of the Modbus register map. Usually in PLC's where you create tags (variables), there is a provision to assign Modbus register addresses to them. Sometimes, the PLC software may auto-assign the addresses as you create tags/variables. Please check out the Users Manual of the PLC software and you will find some answers. Non-programmable devices (e.g. a pressure meter capable of Modbus communication) have fixed register maps and the OEM usually provides a table of this map in the device's Users Manual.
Since you are using our both libraries on the same CPU, the contention is because of macros with the same name present in master library and slave library. To resolve this, please rename all of such macros with a different name.

Can we use Modbus for this application?
If the temperature controller that you are using is Modbus compliant then you can certainly use Modbus for this application. This would entail writing an application on the Host PC that acts as a Modbus Master and then communicating with the temperature controllers. If the controllers are not Modbus compliant, then you cannot use Modbus here unless ofcourse you are the designer of the temperature controller and so have the option of adding this support to it.

How to do it? Can it be a cost effective solution? What are the steps involved? Do we require any additional Hardware/Software?
If the controllers are already Modbus compliant, then all you need is a Modbus Master library for the host. You can then write your application in VC++ or VB or C# using this library and do all the application logic you want to. Alternatively, there are SCADA applications that already support Modbus and you could use them if you do not want to write software at the C/C++/C# level. If you are the designer of the controllers and would like to add Modbus functionality to it, then you need a slave library for the micro controller used in your product. The only additional hardware that I think you will need is an RS485 card for your host PC. You can also use a USB to RS485 converter for this purpose.

No, It is not possible to have a server to sever communication, instead it is a client to server communication where client send a request and server respond back. You can have one master which communicates with both PLC and robot.