×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Override Focuser Polling Period control

  • Posts: 77
  • Thank you received: 14
I have been trying to set the minimum value of the Serial Polling period to 1000ms, or just remove the control and hard code POLLMS to 1000ms.

It looks like I cant overwrite the control values as they are private.

I removed the addAuxControls call, and assumed this would remove the serial Poll Period control, but no!

I'm sure I am missing something simple? At the end of the day it does not need a variable Poll Period, so fixxing to 1000ms would be ideal.
4 years 6 months ago #43239

Please Log in or Create an account to join the conversation.

  • Posts: 472
  • Thank you received: 165
In focuser case the addPollPeriodControl() seems to be called by the base Focuser::initProperties() call, you can set the driver specific default polling rate to 1000ms with setDefaultPollingPeriod(1000); and it's also saved with options so I don't see the need to take away the control in case someone wants to use it, to make the period longer for example.
4 years 6 months ago #43257

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 14
It is not making the period longer that is the issue, it is being able to set it to less than 1000ms. The focuser in question does not like to be polled any quicker than 1000ms, so as I originally stated I either want to override the minimum value of the control, or hide it completely.

I have used the setDefaultPollingPeriod as you suggested, but the Polling period control is still there and overrides it.

So I have hard coded it to be POLLMS = 1000 in the TimerHit (override). My issue with this is that the GUI is now lying to the user, i.e. regardless of what they set it gets changed to 1000ms, which to me is jut wrong
4 years 6 months ago #43259

Please Log in or Create an account to join the conversation.

  • Posts: 472
  • Thank you received: 165
Ah, it would then be useful to add something setMinimumPollingPeriod() and perhaps setMaximumPollingPeriod() to DefaultDevice that would set the range for that control, currently the limits are somewhat generous (10-600000ms) and most serial devices wouldn't like 10ms either.
4 years 6 months ago #43262

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 14
I totally agree, min and max overrides would be the way to go.

How do we go about trying to get this implemented? Should it go in the general wish list, though I believe that is for end user features not developer options? Or will a core developer happen along at some point and spot this issue?
4 years 6 months ago #43339

Please Log in or Create an account to join the conversation.

  • Posts: 472
  • Thank you received: 165
I made a pull request to add these methods as github.com/indilib/indi/pull/1013 and hopefully Jasem has time to review them at some point.
The following user(s) said Thank You: Alan Townshend
4 years 6 months ago #43397

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 14
That's great, thanks.
4 years 6 months ago #43404

Please Log in or Create an account to join the conversation.

  • Posts: 472
  • Thank you received: 165
It has now been merged to master, hopefully it works as I didn't actually test it :)
4 years 6 months ago #43428

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
I have a very hard attitude to untested code. - it doesn't work, it is broken.

It remains so until it has been tested and demonstrated to work.

Publishing untested, aka broken, code isn't a good idea. It delegates ensuring that it works to others and in a way that makes it much more labour intensive to fix.

I'm also uneasy about a 'fix' to help with one device applied to the default driver because this is now applied to every driver.

Couldn't the existing limits, inherited from the default driver, be modified in the hardware specific driver and if an additional control really needed being made available to the user could that have been done in the driver.

I would have done what the OP originally did, set the polling interval in the driver and ignore the property in the default driver. Maybe see if there was a way to remove it from the default UI.
4 years 6 months ago #43429

Please Log in or Create an account to join the conversation.

  • Posts: 472
  • Thank you received: 165
Normally I agree, though in this case the risk is very low as the code doesn't get called unless the device actually opts in to use it and it's literally three trivial lines of code to set new minimum and maximum values over the defaults. I would have tested it in my own drivers but had other things to do during the weekend so I thought it would be better to get it out early for others to use. As for device specific hacks I much prefer the base classes to be flexible enough not to need to be worked around as that just leads to code rot and incoherent user experience, especially if the fix is trivial like this one.
4 years 6 months ago #43430

Please Log in or Create an account to join the conversation.

  • Posts: 472
  • Thank you received: 165
Just tested and it does work, set the range for my ScopeDome driver to 1000-3000ms and it showed up correctly. The device doesn't like too long intervals as it has a watchdog mechanism that resets the serial connection if there hasn't been traffic for a while.
4 years 6 months ago #43432

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 14
Just seen you PR has gone, does that mean it has been included, and I can use it?
4 years 6 months ago #43433

Please Log in or Create an account to join the conversation.

Time to create page: 1.167 seconds