pymodbus-dev / pymodbus

A full modbus protocol written in python
Other
2.16k stars 889 forks source link

Add execution of actions for WriteMultipleRegistersRequest and WriteMultipleCoilsRequest #2158

Open krogozinski opened 2 months ago

krogozinski commented 2 months ago

Discussed in https://github.com/pymodbus-dev/pymodbus/discussions/2157

Originally posted by **krogozinski** April 10, 2024 I have a requirement to define custom actions for `WriteMultipleRegistersRequest` and `WriteMultipleCoilsRequest`. This is for testing the Modbus client on a new hardware project. To the best of my understanding, actions (custom or built-in) for writes to the server seem to only be performed for `WriteSingleCoilRequest` and `WriteSingleRegisterRequest`, and not `WriteMultipleRegistersRequest` and `WriteMultipleCoilsRequest`. The proposal is to add the capability of executing actions for `WriteMultipleRegistersRequest` and `WriteMultipleCoilsRequest`.
janiversen commented 2 months ago

I am all in favor of the idea, the problem as I see it is to implement actions for setValues !

I suggest to amend the actions to include the function code and a boolean for set/set, but the is just a thought not a demand.

github-actions[bot] commented 1 month ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

krogozinski commented 1 month ago

Still working on this. Should have a PR soon.

janiversen commented 2 weeks ago

Any progress ?

krogozinski commented 1 week ago

Progress has been slow, but picking up now. Will have a PR ready soon.

On Wed, Jun 12, 2024, at 6:06 PM, jan iversen wrote:

Any progress ?

— Reply to this email directly, view it on GitHub https://github.com/pymodbus-dev/pymodbus/issues/2158#issuecomment-2162370240, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4CANINI3NXPPPW5GDN5MTZG76OXAVCNFSM6AAAAABGBWJFZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRSGM3TAMRUGA. You are receiving this because you authored the thread.Message ID: @.***>

krogozinski commented 6 days ago

Would it be beneficial to implement a solution where:

  • existing user-defined custom actions can remain unchanged?
  • existing default behaviour remains unchanged i.e. custom actions are only executed by the simulator for requests that call getValues()?

If so, I would suggest some additional optional configuration for custom actions. Please see an example snippet below of a possible configuration that adds "triggers". These allow specification of the applicable function codes and the access types where the custom action should be executed.

# ...
{"addr": 2305,
    "action": "my_custom_action",
    "kwargs": {
        "triggers": [
            {"func_code": 6, "access_types": ["set"]},
            {"func_code": 16, "access_types": "default"},  # get only
            {"func_code": 22, "access_types": ["get", "set"]},
        ]
    }
},
# ...

If the "triggers" are not specified, existing behaviour is maintained. The custom action is only executed for requests that calls getValues().

The function code and access type (get/set) for the current request can be passed to the action method in the keyword arguments. This will allow existing user-defined custom actions to remain unchanged.

janiversen commented 6 days ago

The simulator configuration is overdue to be replaced by something simpler, not sure triggers goes in that direction, but pull requests are always welcome (most likely if you want something implemented it's up to you to do it).