Server Simulator Can't Distinguish Holding / Input Registers

[erezblm]

Hey all,

I'm using the ModbusSimulatorContext class (which is a super nice module) and I noticed that it does not make distinction between different types of registers, while generally it can be the case where the same address is used differently in different .

It's pretty clear I believe according to the ModbusSimulatorContext.getValues implementation that it takes all values from the same registers array, regardless of the received 'func_code' (see below).

Shouldn't we add an indicator in the setup dictionary that states the register type?

Also, I would generally note that the documentation for the simulator is pretty slim and takes some guessing and experimentation to understand how it works.

    def getValues(self, func_code, address, count=1):  # pylint: disable=invalid-name
        """Return the requested values of the datastore.

        :meta private:
        """
        result = []
        if func_code not in self._bits_func_code:
            real_address = self.offset[func_code] + address
            for i in range(real_address, real_address + count):
                reg = self.registers[i]
                if reg.action:
                    reg.action(self.registers, i, reg)
                result.append(reg.value)
        else:
            # bit access
            real_address = self.offset[func_code] + int(address / 16)
            bit_index = address % 16
            reg_count = int((count + bit_index + 15) / 16)
            for i in range(real_address, real_address + reg_count):
                reg = self.registers[i]
                if reg.action:
                    reg.action(i, reg)
                while count and bit_index < 16:
                    result.append(bool(reg.value & (2**bit_index)))
                    count -= 1
                    bit_index += 1
                bit_index = 0
        return result

[erezblm]

Ok, after getting deeper into the code, I do see that it's possible to split the registers to sections according to their declared 'size' and the 'shared_block' parameter.
It's still unclear which type comes after which (only when looking at the code), and still impossible to use the same address for 2 different types, which as far as I understand is legal in Modbus.

[janiversen]

there are NO restriction on the order of the addresses, it is a simple as the figure:

Read_holding(addr=1, count=1) reads the first register in the block holding, but in case of shared blocks, all 4 blocks start at the same physical address.

[erezblm]

But modbus spec doesn't refer at all to physical addresses, these are all virtual addresses dependent on the implementation to decide whatever mappings they wish. They only offer some examples to how this could be implemented.
For instance, I have an implementation for modbus server that doesn't access memory at all.

What I'm saying, is that I can't find any reference in the doc that states that it's not allowed (for example) for register 0x01 with function code 'holding register' to access memory A and register 0x01 with function code 'input registers' to access memory B.

[janiversen]

That is because you are mixing issues. You are reading the "modbus protocol specification", that is in other words how a device can be accessed from the outside world, it does not specify how the device implements the protocol.

Looking at figure 7 ("shared blocks" = True) you can see that all function codes access the same physical memory, In this case register 0x01 access the same memory using "read holding register" as using "read input registers"

Looking at figure 6 ("shared blocks" = False), you can see that all function codes do not access the same physical memory, . In this case register 0x01 access different memory using "read holding register" as using "read input registers"

IMPORTANT figure 6 and 7 are only examples, NOT recommendations nor requirements !! Many devices do not have a memory model as such but read/write directly from/to the physical sensors.

[erezblm]

ohhh ok... now i understand.
So when we define addresses in the config we refer to our simulator memory address, and the size also refers to our simulator memory model.
so if i set shared blocks to False, and I define for 'hr size' be size 4000 and 'ir size' be size 4000:

• When modbus HR reads 0x01 it will access our memory address 1
• when modbus IR read 0x01 it will access our memory address 4001
  right?

thanks so much for the patience, I will try to spend time to document it.

[janiversen]

your example is correct, looking forward to see your documentation. Maybe something like figure 6 and 7 can be helpful.

[janiversen]

The simulator does allow you to use the 4 blocks defined in the modbus specification:

demo_config = {
    "setup": {
        "co size": 100,
        "di size": 150,
        "hr size": 200,
        "ir size": 250,
        "shared blocks": True,

And self.offset[func_code] is used to get the real address. If you use "shared blocks" all functions can read the same register. With different blocks only functions of the same type read the same register.

see datastore/simulator.py line 261++:

       else:
            offset[1] = 0
            offset[5] = 0
            offset[15] = 0
            total_size = size_co
            offset[2] = total_size
            total_size += size_di
            offset[4] = total_size
            total_size = size_ir
            offset[3] = total_size
            offset[6] = total_size
            offset[16] = total_size
            offset[22] = total_size
            offset[23] = total_size
            total_size += size_hr

Thanks for the calling it super nice. I am working on enhancements, and if you have more specific ideas on how/what to configure with function codes, please submit a PR, or explain it a bit more detailed.

To be honest, I am a hard core developer (I cried for days, when the world moved away from assembler) and documentation is a task I tend to do as rapid as possible....so if you would write some explanation etc in Markdown, I am happy to help you include them in the documentation.

[erezblm]

Sure, it is super nice! I find it very useful for mocking Modbus servers that we're integrating with :)
"I cried for days, when the world moved away from assembler" -> HAHA.... good one (not me ;) )
I'll try to find some time to help with the docs.

[janiversen]

very much appreciated, and as I said if you write it in markdown, I can help with the integration into our doc setup. We can easily dedicate a chapter to the simulator alongside the documentation extracted from the source files.

Be aware that the simulator is first step in a bigger enhancement, the server will very soon have a web frontend and an open REST API to make mocking more interesting.