One SimCore over multi server instance

[samuel-dav]

Hello,

I am currently implementing a modbus server using this library at its vers 3.13. I am thus using the new SimDevice/SimData architecture.
In my application I need to serve my data over 2 layers TCP+serial. At first i have tried to pass the same SimDevice to both 'context' parameter of those servers initialization. But it then create two instances not sharing the same data.

Then I find this :

pymodbus/pymodbus/server/base.py

Lines 47 to 53 in 8a97aa0

	self.context: ModbusServerContext | SimCore
	if not isinstance(context, ModbusServerContext):
	self.context = SimCore(context)
	elif context.simdevices:
	self.context = SimCore(context.simdevices)
	else:
	self.context = context

And now I am doing this trick :

import random
import asyncio

from pymodbus import FramerType
from pymodbus.server import ModbusSerialServer, ModbusTcpServer
from pymodbus.simulator import DataType, SimData, SimDevice
from pymodbus.simulator.simcore import SimCore

class MyServers:
	def __init__(self):
		self.deviceId = 1
		self.device = SimCore(SimDevice(id=self.deviceId, simdata=[SimData(
					10, 1, 0,  DataType.REGISTERS
		)]))
		dummy = SimDevice(id=1, simdata=[SimData(1, 1, 0, DataType.REGISTERS)])
		self.modbusTcpServer = ModbusTcpServer(
				context=dummy,
				framer=FramerType.SOCKET,
				address=("0.0.0.0", 1502)
		)
		self.modbusTcpServer.context = self.device
		self.modbusSerialServer = ModbusSerialServer(
			context=dummy,
			port="/dev/ttyUSB0",
			framer=FramerType.RTU,
			stopbits=2,
			bytesize=8,
			parity='N',
			baudrate=9600,
		)
		self.modbusSerialServer.context = self.device

	async def set_registers(self, address, value):
		await self.device.async_setValues(self.deviceId, 3, address, [value])

	async def Update(self):
		newValue = random.randint(1, 50)
		print(newValue)
		await self.set_registers(10, newValue)

async def do_async():
	servers = MyServers()
	await servers.modbusSerialServer.serve_forever(background = True)
	await servers.modbusTcpServer.serve_forever(background = True)

	while True:
		await servers.Update()
		await asyncio.sleep(1)

asyncio.run(do_async())

So here is my question: Am I missing a mechanism to do it more nicely?
--> and could it be a good idea to change the highlighted condition, to accept SimCore as parameter?

Thank you,
Samuel

[janiversen]

I am not sure what your problem is ?

you point at a copule of lines where SimDevice is activated in the server, after that point SimDevice is no longer used.

Please tell what is your problem ?

SimCore is an internal class that you should not use.

[janiversen]

You cannot share a device between múltiple servers! Each server have it's own devices.

Your workaround will most likely fail when running long term, due to inconsistent register images.

if 2 servers run with the same registers and server A updates a registerm server B are likely to be "confused" because the update happened without it knowing it.

But the solution for your problem is easy, use the same SimDevice as context=, but have 2 server.set calls one to each server.

[samuel-dav]

I just read your answer, so i will share my update first...

Because i was facing the fact that my TCP server wasn't answering to all id (more or less mandatory for a modbus tcp server), i came up to change a bit the code and ended with this one :

import random
import asyncio

from pymodbus import FramerType
from pymodbus.server import ModbusSerialServer, ModbusTcpServer
from pymodbus.simulator import DataType, SimData, SimDevice
from pymodbus.simulator.simcore import SimCore
from pymodbus.simulator.simruntime import SimRuntime

class MyServers:
	def __init__(self):
		self.device = SimRuntime(SimDevice(id=1, simdata=[SimData(
					10, 1, 0,  DataType.REGISTERS
		)]))
		dummy = SimDevice(id=1, simdata=[SimData(1, 1, 0, DataType.REGISTERS)])
		self.modbusTcpServer = ModbusTcpServer(
				context=dummy,
				framer=FramerType.SOCKET,
				address=("0.0.0.0", 1502)
		)
		wrappedDevice = SimCore([])
		wrappedDevice.devices[0] = self.device
		self.modbusTcpServer.context = wrappedDevice

		self.modbusSerialServer = ModbusSerialServer(
			context=dummy,
			port="/dev/ttyUSB0",
			framer=FramerType.RTU,
			stopbits=2,
			bytesize=8,
			parity='N',
			baudrate=9600,
		)
		wrappedDevice = SimCore([])
		wrappedDevice.devices[20] = self.device
		self.modbusSerialServer.context = wrappedDevice

	async def Update(self):
		newValue = random.randint(1, 50)
		print(newValue)
		await self.set_registers(10, newValue)

	async def set_registers(self, address, value):
		await self.device.async_setValues(3, address, [value])

async def do_async():
	servers = MyServers()
	await servers.modbusSerialServer.serve_forever(background = True)
	await servers.modbusTcpServer.serve_forever(background = True)

	while True:
		await servers.Update()
		await asyncio.sleep(1)

asyncio.run(do_async())

That way my serial server only answer to id 20, and my TCP server does answer to any id. Currently my tests are a success.

• NOTE : my will to share one SimDevice to both servers is mainly to avoid any inconsistent registers between them. In my real application i really don't want that a TCP client read something different than a serial client... But Maybe my solution is worth... Moreover, during my initialization i am settings quite a lot of registers, and i am a bit concerned of the time it will take to do these init for both SimDevice (in your case scenario where i instantiate 2 SimDevices)

-> That being said, you warn me about "(...)due to inconsistent register images.(...)" what does it means? Do you have something in mind?

Thank you for your share.

[janiversen]

A modbus server as pr protocol definition only responds to defined device ids.

Most servers also respond to id 0 which is broadcast.

If you add SimDevice id=0 the server will respond to any id, please read the documentation.

Your workaround uses SimCore/SimRuntime, be aware those are NOT part of the public API and will be changed without notificaciones.

I am actually a bit puzzled why your code works, because you bypass quite a lot of setup code.

the problem with your code is that server.async_get/setValues are not synchronized between the 2 servers, so at some point 2 calls will be active in parallel causing all kind of potencial problems.

But of course if you with to take the risk, that is your choice, but please do not open any issues, as this is really very unsupported.

[janiversen]

You are welcome to submit a PR, which f.x. adds a shared flag as server parameter with the relevante code.

But is most be done without exposing SimCore/SimRuntime, those are internal for a lot of reasons, the biggest one being maintenance (SimData / SimDevice cannot be changes easily because they are part of the API).

[samuel-dav]

You may already know this, but for other readers…

A modbus server as pr protocol definition only responds to defined device ids.

Most servers also respond to id 0 which is broadcast.

If you add SimDevice id=0 the server will respond to any id, please read the documentation.

I read them both, the modbus specification, and pymodbus one... Modbus TCP specification quote :
From MODBUS MESSAGING ON TCP/IP IMPLEMENTATION GUIDE V1.0b -- 3.1.3 MBAP Header description

Unit Identifier – This field is used for intra-system routing purpose. It is typically
used to communicate to a MODBUS+ or a MODBUS serial line slave through a
gateway between an Ethernet TCP-IP network and a MODBUS serial line. This field is
set by the MODBUS Client in the request and must be returned with the same value in
the response by the server.

So, this doesn't mean that a modbus server have to answer to any id, but in real life, most modbus TCP server answer to any Unit Identifier (this is because the IP of the device is already a unique identifier) --> big exception are modbus gateway between modbus RTU and modbus TCP : they do need this Unit Identifier in order to distinct modbus RTU devices.
--> That being said, my device isn't a gateway, so my will is to have a server which answer to any Unit Identifier which can be done using the id=0 of a SimDevice (as described in the pymodbus documentation)

Moreover :

Most servers also respond to id 0 which is broadcast.

Here is mix up between RTU and TCP...
--> in TCP : most server answer to id=0 (because most server answer to any address, 0 being an allowed one)
--> in RTU : most server take into account request on address 0 (which is broadcast) but doesn't answer to the request (RS485 couldn't handle it)

Samuel

[samuel-dav]

You are welcome to submit a PR, which f.x. adds a shared flag as server parameter with the relevante code.

But is most be done without exposing SimCore/SimRuntime, those are internal for a lot of reasons, the biggest one being maintenance (SimData / SimDevice cannot be changes easily because they are part of the API).

Well Reading your previous message, I will switch my code to the solution with 2 distinct simdevices, mainly because of your warn :

(...) be aware those are NOT part of the public API and will be changed without notificaciones.

So because of this change, I don't think I will go for a PR to add this SimDevice share over multi server feature....

Thank you for your feedback!
Samuel

[janiversen]

In my experience, which is a lifetime (30+ years of work in the industrial automation sector) with modbus:

All the professional tcp servers I know do NOT respond to undefined ids ! This is independent if the RTU or SOCKET frame is used. A lot of servers have a configuration option to enable/disable broadcast, and in this case responds with all known device ids.

The TCP/IP address only defines the server, NOT the devices within the server, you need both to uniquely address a device.

Gateways (which is one of the most popular uses of a TCP server, are nothing special be merely a normal server with clients as backend.

--> Here is mix up between RTU and TCP...
--> --> in TCP : most server answer to id=0 (because most server answer to any address, 0 being an allowed one)
--> --> in RTU : most server take into account request on address 0 (which is broadcast) but doesn't answer to the request (RS485 couldn't handle it)

Not correct id=0 is broadcast independent of the framer type used. If a client sends a request with id=0 all devices must respond against independent of how the request is transmitted. Please remember that a TCP server can use SOCKET or RTU frames, internally the modbus request with its id are typically handled identically.

And actually on serial lines , all devices must respond to id=0....this feature is often used to detect connected device. RS485 is half duplex, but most RS485 chips checks if there are traffic on the line, and wait for a silent period (3.5chars) before transmitting.

pymodbus server allows you to define id=0, so you define the response, and currently do not send a response from all devices, this is actually a know bug, which we are working to fix.

Regarding you timing concern, that is easy solved.

1. make your list of simdevices with the values you want
2. do list2 = list.deepcopy()

Jan