Add execution of actions for WriteMultipleRegistersRequest and WriteMultipleCoilsRequest

[krogozinski]

Discussed in #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]

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]

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]

Still working on this. Should have a PR soon.

[janiversen]

Any progress ?

[krogozinski]

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 <#2158 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4CANINI3NXPPPW5GDN5MTZG76OXAVCNFSM6AAAAABGBWJFZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRSGM3TAMRUGA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[krogozinski]

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]

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).

[janiversen]

Seems this is no longer an issue and no PR have been presented. Closing for now.

[krogozinski]

@janiversen apologies for the lack of activity; travel and subsequent sickness have slowed my progress.

It seems that I was a day too late. If possible, could you please see my draft PR #2255? The tests are passing and I have a proposed solution which does nor further complicate configuration.

There are opportunities to refactor if you find my general approach is acceptable.

[janiversen]

No problem, I will take a look later.

[github-actions]

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]

Documentation and example update are almost done. Would you prefer that I issue the PR to "dev" or "wait3.8.0", considering my proposal has API changes?

[janiversen]

I will do that once you have marked the PR as ready.

[github-actions]

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.