×
INDI Library v2.0.7 is Released (01 Apr 2024)
Bi-monthly release with minor bug fixes and improvements
Driver OnStep (LX200 like) for INDI
- Alain Zwingelstein
-
- Offline
- Elite Member
-
- Posts: 452
- Thank you received: 71
- Jasem Mutlaq
-
- Away
- Administrator
-
- Alain Zwingelstein
-
- Offline
- Elite Member
-
- Posts: 452
- Thank you received: 71
- Alex Varakin
-
- Offline
- Elite Member
-
- Posts: 174
- Thank you received: 27
- Alex Varakin
-
- Offline
- Elite Member
-
- Posts: 174
- Thank you received: 27
- Alain Zwingelstein
-
- Offline
- Elite Member
-
- Posts: 452
- Thank you received: 71
Replied by Alain Zwingelstein on topic Driver OnStep (LX200 like) for INDI
@Khalid,
I agree with you, non used features should be skipped and not shown in the control panel.
This is the first difficult part since the driver itself needs declaration of expected capabilities right before anything like communication with the device can start.
this are the first actions taken at driver initialization
Next the driver stes all the properties (and we still do not know all the features of the hardware)
it is only after that that we start communicate with the hardware and really update all the properties.
It is in here where we can enable / disable features and it should be one of our effort to work on this
On the other hand there is the way the driver communicates with the hardware (which is where yo see some timeouts)
All event driven part is ok so far it is pretty encapsulated in dedicated functions and therefore easy to control.
The polling side is the "nightmare" since everything is polled regardless if implemented or not.
It is called every (polling period defined as an "option" in the control panel)
Even is this is not the cause of the timeouts it is annoying.
On way to got (and you pointed already out) is to split the polling into dedicated function which is partially the case but sot straightforward now.
And over all this "ToDos" we also have the different "flavors" (OnStep 4.xx, Older OnStep, OnStepX ) to cope with.
Additionally I believe each of us just focuses on the hardware he has at disposition (starting by myself) so things like:
- Outputs,
- Weather,
- Temperature Sensors
- Limit switches
... cannot be really tested until somebody has the needed hardware.
And last but not least, like James said , we are distracted by other things (It is "Mea culpa, mea maxima culpa" why the "skip focuser" did not end-up in the latest release.
When you speak about Indi beeing "Chatty", I understand this as too much communication.
I believe Ascom, Androïd and the Web Browser over WiFi / Ethernet are also very "chatty".
So far I never experienced timeouts due to too much communication, but more because of the way they are handled, Expected Response, One char, # ended or not ....
I know this does not bring anything to the solution, I just wanted to share my thoughts on where we should concentrate and eventually correct me is I am wrong.
And a last point, on my side, is sometimes I understand the contrary of what is meant in the text due to my poor English. (As a crazy French guy said during a meeting on one of my jobs in Buffalo, "but nobody speaks French here"
I agree with you, non used features should be skipped and not shown in the control panel.
This is the first difficult part since the driver itself needs declaration of expected capabilities right before anything like communication with the device can start.
this are the first actions taken at driver initialization
LX200_OnStep::LX200_OnStep() : LX200Generic(), WI(this), RotatorInterface(this)
{
currentCatalog = LX200_STAR_C;
currentSubCatalog = 0;
setVersion(1, 12); // don't forget to update libindi/drivers.xml
setLX200Capability(LX200_HAS_TRACKING_FREQ | LX200_HAS_SITES | LX200_HAS_ALIGNMENT_TYPE | LX200_HAS_PULSE_GUIDING |
LX200_HAS_PRECISE_TRACKING_FREQ);
SetTelescopeCapability(GetTelescopeCapability() | TELESCOPE_CAN_CONTROL_TRACK |
TELESCOPE_HAS_TRACK_RATE, 10 );
FI::SetCapability(FOCUSER_CAN_ABS_MOVE | FOCUSER_CAN_REL_MOVE | FOCUSER_CAN_ABORT);
RI::SetCapability(ROTATOR_CAN_ABORT | ROTATOR_CAN_HOME | ROTATOR_HAS_BACKLASH);
}
Next the driver stes all the properties (and we still do not know all the features of the hardware)
bool LX200_OnStep::initProperties()
{
LX200Generic::initProperties();
FI::initProperties(FOCUS_TAB);
WI::initProperties(ENVIRONMENT_TAB, ENVIRONMENT_TAB);
RI::initProperties(ROTATOR_TAB);
SetParkDataType(PARK_RA_DEC);
...
... and so on with all the properties
...
}it is only after that that we start communicate with the hardware and really update all the properties.
It is in here where we can enable / disable features and it should be one of our effort to work on this
bool LX200_OnStep::updateProperties()
{
// int i;
// char cmd[32];
LX200Generic::updateProperties();
FI::updateProperties();
WI::updateProperties();
if (isConnected())
...
...
...
}On the other hand there is the way the driver communicates with the hardware (which is where yo see some timeouts)
All event driven part is ok so far it is pretty encapsulated in dedicated functions and therefore easy to control.
The polling side is the "nightmare" since everything is polled regardless if implemented or not.
It is called every (polling period defined as an "option" in the control panel)
Even is this is not the cause of the timeouts it is annoying.
On way to got (and you pointed already out) is to split the polling into dedicated function which is partially the case but sot straightforward now.
And over all this "ToDos" we also have the different "flavors" (OnStep 4.xx, Older OnStep, OnStepX ) to cope with.
Additionally I believe each of us just focuses on the hardware he has at disposition (starting by myself) so things like:
- Outputs,
- Weather,
- Temperature Sensors
- Limit switches
... cannot be really tested until somebody has the needed hardware.
And last but not least, like James said , we are distracted by other things (It is "Mea culpa, mea maxima culpa" why the "skip focuser" did not end-up in the latest release.
When you speak about Indi beeing "Chatty", I understand this as too much communication.
I believe Ascom, Androïd and the Web Browser over WiFi / Ethernet are also very "chatty".
So far I never experienced timeouts due to too much communication, but more because of the way they are handled, Expected Response, One char, # ended or not ....
I know this does not bring anything to the solution, I just wanted to share my thoughts on where we should concentrate and eventually correct me is I am wrong.
And a last point, on my side, is sometimes I understand the contrary of what is meant in the text due to my poor English. (As a crazy French guy said during a meeting on one of my jobs in Buffalo, "but nobody speaks French here"
Please Log in or Create an account to join the conversation.
Time to create page: 1.034 seconds
© 2003-2022 by INDI Library. All rights reserved.