Callback Server Example explained to a newbye

[Chiara]

I'm looking at this example:

https://pymodbus.readthedocs.org/en/latest/examples/callback-server.html

I need to get a modbus slave server, that when receive data, it process them and to send them to another program, this time it run as a master.  So it seems to be the right base to look at?

I'm unable to get the idea of what the part of the program will do with device map, I mean what are these devices "piece[]"?

#---------------------------------------------------------------------------# 
# initialize your device map
#---------------------------------------------------------------------------# 
def read_device_map(path):
    ''' A helper method to read the device
    path to address mapping from file::

       0x0001,/dev/device1 
       0x0002,/dev/device2 

    :param path: The path to the input file
    :returns: The input mapping file
    '''
    devices = {}
    with open(path, 'r') as stream:
        for line in stream:
            piece = line.strip().split(',')
            devices[int(piece[0], 16)] = piece[1]
    return devices

I've run the example but cannot understant :

1) It create the areas of memory where to store the values based on the device map? are those indispensable?

2) twisted got to many level of abstraction, can you please say me what are the task performed by this script?

3) why if I add to StartTcpServer the address parameter it turns out in an error?

 

[Bashwork]

So what this script is doing is running two processes: one for the modbus server and one to perform background tasks.  This works by doing the following:

1. Create one process that is listening to an IPC queue (device_writer)

2. Initialize a new modbus server whose datastore actually just writes to that queue (CallbackDataBlock)

3. Start up the modbus server (StartTCPServer)

All of the other functions are helpers to initialize or convert data:

a. rescale_value converts the value written to the queue to the value used by the controlled device (0..100) -> (-3200..3200)

b. read_device_map initializes the lookup map: every modbus write operation basically changes the controller value for a given device

c. as a convenience, we store the number of devices at register 0xbeef

This was an actually use case of a user who wanted a modbus server that could be used to control N devices.  By writing to the register mapped to that device, they could change the value that was currently set on the device controller (which was attached to the server machine).  The reason we performed the write to the device out of process was so that the modbus server wouldn't have to block while waiting for the command to finish (in case of a slow device).  Also, a queue makes sure we don't attempt to write to the same or multiple devices at once (which might cause weird errors).

To change the behavior of this example, just redefine what your registers/values map to, change the device_writer function to do your work, and remove/add initialization code to suit your purpose.  Does this help?