Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ModbusTCP timeout settable from Config>Port dialog #893

Closed
wants to merge 2 commits into from
Closed

Conversation

tofublock
Copy link

@tofublock tofublock commented May 31, 2022

I'm implementing a client device for Artisan as a ModbusTCP slave and sometimes my device doesn't respond quite fast enough for Artisan, as its read timeout is fixed to be min(0.2s, samplingtime/2) - so basically always 200ms. Setting the timeout to something like 0.5s fixes this problem for me and communication works well with fewer interruptions.

Allowing the timeout for ModbusTCP to be set from the "Config>Port" dialog would fully solve my problem. The timeout field that is there is currently only used for SerialModbus connections, but could be used for the same purpose without the need to change anything else.

@AppVeyorBot
Copy link

@MAKOMO
Copy link
Member

MAKOMO commented Jun 1, 2022

Hi, this sounds like a good idea, but might have consequences for all the MODBUS TCP machine setups which do not explicitly set the timeout. Any specific reason for this change?

Note: there is a major upgrade of pymodbus just being finalized which might resolve existing MODBUS communication issues.

@MAKOMO
Copy link
Member

MAKOMO commented Jun 1, 2022

Ah, just found your note in the corresponding issue. I will process this change and make sure it will not disturb anything else.

@tofublock
Copy link
Author

tofublock commented Jun 1, 2022

Thanks for taking a look.

To prevent issues with existing setups, how about something like this instead?
timeout=min((self.aw.qmc.delay/2000), self.timeout if self.timeout > 0 else 0.2)

Re pymodbus, I did notice some irregularities in the Modbus requests but assumed my device to be to blame (e.g. receiving individual read register requests when set to "optimize" or "fetch full blocks".) I haven't gotten around to investigating this further (partly because my implementation works well enough now as is), but one bulk request per 0.5s is much more feasible for a slow client than 10 small requests in the same time.
If I can help with the pymodbus 3.0 switch let me know!

@AppVeyorBot
Copy link

@MAKOMO
Copy link
Member

MAKOMO commented Jun 21, 2022

Explicit MODBUS timeout parameter added. Thanks for your input!

@MAKOMO MAKOMO closed this Jun 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants