Proposal to allow Modbus Server to take SimCore instances as context

[km-64]

In older versions of pymodbus, particularly prior to 3.13 where ModbusServerContext and ModbusDeviceContext internally started using SimData/SimDevice, it was possible to store server 'state' in the ModbusServerContext instance.

After that change, the state of the server is stored internally with the server instance in an instance of SimCore. This means that if you pass the same ModbusServerContext to a new server as with a previously running server instance, the new server will not retain the values written to the previous server.

It could be said that in new versions of pymodbus, SimCore with SimRuntime behave similarly to how ModbusServerContext did with ModbusDeviceContext. However, ModbusServerContext and ModbusDeviceContext were intended to be accessible to end users, while SimCore and SimRuntime are pymodbus internals.

To replicate this in newer versions of pymodbus, it could be possible to allow Modbus servers to directly accept an instance of SimCore as an argument for the context parameter.

At the moment I have found a workaround in a project I'm working on and it involves manually setting the context attribute on a new server after instantiating it, but before starting it.

context = SimCore(SimDevice(...))
server = ModbusTcpServer(
    context=[]  # pass 'dummy' context.
)
server.context = context  # use custom context
# run server...

Effectively this means that the lifetime of the SimCore instance is not restricted to that of the server object. It can be observed that inside ModbusBaseServer that the SimCore instance is created from SimDevices or similar. My workaround just does this outside of the __init__ of ModbusBaseServer.

pymodbus/pymodbus/server/base.py

Lines 48 to 54 in f051adf

	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

[km-64]

See #2967 for a proposed implementation of this feature

[km-64]

@janiversen do you see any potential problems with adding something like this? I guess this would make it possible to use one instance of SimCore with multiple servers running at the same time. That could cause some concurrency problems, but it isn't something that users would likely do.

[janiversen]

yes many.

as explained in the draft, we want freedom to change SimCore as needed, without thinking about the API.

SimCore is designed to work with one server instance...allowing it to be created outside the server object, means it can be:

• used in parallel in múltiple server objects
• reused in new server object, without having the inicial condicions checked.

Both will likely led to strange problems, which we do not want to deal with.

All requests passes through a single action function which the app can supply...in that function you can branch out to whatever you want and return the result to the internal SimCore.