×

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

Bi-monthly release with minor bug fixes and improvements

Re:Improve relationship of INDI server, driver, EKOS

  • Posts: 447
  • Thank you received: 30
Please consider the future improvement.

· Relationship between server and driver
Currently it is an operating system that starts servers and drivers all at once, but EKOS has a different procedure for local server and remote server.
As for the server, it always runs, and the server passes the driver list to the client, thereby resolving conflicts in client configuration.

· About EKOS's profile editor module
If you change to a procedure that selects a server first and then selects a list loaded from the server, the procedure for the local server is the same as for the remote server. By using this operation method, even clients such as ASCOM wrapper can operate with client.

· About the INDI control panel
At present, setting and control items are mixed.
I think that confusion with EKOS will decrease by displaying only setting items like ASCOM.

By resolving the above, I think that the setting procedure will be standardized and confusion will be gone.

Please consider in future upgrading.
5 years 4 months ago #32030

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

  • Posts: 1067
  • Thank you received: 140
I agree with first two ideas...
But the third one no, as if you take the control optipns from the INdI controller panel, you will loose many features as they are not available in Ekos, such as focuser for instance, there are limited controls in ekos focus panel, so you need to be able to use controls on driver or functions will be lost.. :)
5 years 3 months ago #32037

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

  • Posts: 407
  • Thank you received: 74
IMHO remove the Indi Control panel altogether as it just adds to the confusion. Just have Ekos and hide all references to INDI but allow the settings for devices to be setup/changed etc via Ekos. Really doing exactly what is done now, using Ekos/Indi separate windows, but a simpler single front end with "drill downs" so everything is done via Ekos.

I still think, as I have said before, you should not have call Ekos by starting Kstars :-)

Its always easier to talk about changes than do the changes :-)

People in the end don't care what its called just how simple it is to do it - at the moment its messy/confusing,especially for newbies, IMHO and less is more sometimes.

Did start with IMHO :-)
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
The following user(s) said Thank You: Alfred, AstroNerd
5 years 3 months ago #32044

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

  • Posts: 1067
  • Thank you received: 140
No, I do agree, IF all the controls can be done via Ekos....but that is a big ask for the amount of drivers and controls that would be needed to be implemented into Ekos... :) IMHO.. ;)
5 years 3 months ago #32045

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

  • Posts: 447
  • Thank you received: 30
I am not talking about my personal opinion.
It means that there are items that cause operational inconsistency in the described part.

I am already in operation, but with the introduction of StellarMate, several users have changed the environment from WINDOWS.

I wrote a blog so that new users will not get lost, but it took a long time to explain the setting.
blogs.yahoo.co.jp/t_studio_astro/folder/605849.html
(It is Japanese, it describes the setting procedure of server, driver, Ekos.)

That is because there is a part where server, driver, client relationships are complicated.
(Especially Ekos & Control panel)

Even when the function of familiar CanonDslr got wrong, it took a while to notice that it was a check on the driver's new item.

I feel it is difficult to set many functions for those who start from now.

Although the example described by me is also one plan, I think that rules such as setting are important because it is a multifunctional environment.
Last edit: 5 years 3 months ago by T-Studio.
5 years 3 months ago #32047

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

  • Posts: 1067
  • Thank you received: 140
Let’s leave it there, as don’t think you are understanding me or I you properly, I think the language barrier is in the way.. :)
The following user(s) said Thank You: Clive Stachon
5 years 3 months ago #32048

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

  • Posts: 447
  • Thank you received: 30
I do not mention that removing the INDI control panel.

In terms of control panel like Control Panel, it is said that relationships are clearly defined by dividing the device setting items of the driver and the control items and items in the client.
In the present situation there are parts that are mixed each other.

Although Ekos is a front end for control, it also has equipment setting items, and the control panel also has control items.

I feel that relationships will become clearer after organizing this.I do not mention that removing the INDI control panel.

In terms of control panel like Control Panel, it is said that relationships are clearly defined by dividing the device setting items of the driver and the control items and items in the client.
In the present situation there are parts that are mixed each other.

Although Ekos is a front end for control, it also has equipment setting items, and the control panel also has control items.

I feel that relationships will become clearer after organizing this.
5 years 3 months ago #32050

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

  • Posts: 447
  • Thank you received: 30
It is regrettable that I could not explain. . .
The following user(s) said Thank You: Clive Stachon
5 years 3 months ago #32051

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

  • Posts: 527
  • Thank you received: 139
Could you give an example of an item that you would move from one area to the other? Maybe that would help with understanding the intention.
5 years 3 months ago #32061

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

  • Posts: 269
  • Thank you received: 53
I've given the "problem" of control panel a little bit of thought. When I get a spare moment I'd like to look into how to define selected driver properties as "advanced" or something like that; either as attributes or additional elements in the driver config or as a separate xml - depending on conformity with the INDI architecture.
The idea is that those properties could be accessed through EKOS via some sort of "advanced settings" button wherever a device can be selected or configured. That could pop up a window with the defined advanced properties for the device where values can be viewed and set. Along similar lines to the way the EKOS Capture module can collect non-standard driver properties in the imaging schedule. Nomination of advanced properties could also be configurable through the INDI control panel or possibly via EKOS configuration. I think Indi is a better optiona s it makes the advanced properties available to all clients.
For instance, the ZWO driver could define Gain, Offset and Bandwidth as "advanced". So in EKOS Capture (or platesolve or guiding) module wherever the camera can be selected an advanced settings button (cogwheel icon?) would allow those values to be set. In Indi Control Panel or somewhere suitable, one could also add the 8bit/16bit property if that is desired. On the TCFS focuser driver, one could define the Auto/Manual focus mode property as advanced and maybe also temperature (read only). For a Mount maybe Guide speed would be a useful advanced property.
All properties would always be available through the Indi Control Panel.
The driver developer could pre-define typical properties as advanced so most users would have no need to configure in Indi. But anyone could redefine the advanced properties if they want. Most of the work would have to happen in the clients to enable the advanced properties.
The following user(s) said Thank You: AstroNerd
5 years 3 months ago #32075

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

  • Posts: 1067
  • Thank you received: 140
@Kengs
I agree completely with you here, to have advanced options within the ekos window tabs for driver settings would be a very good idea, I have to go back and fourth between INdI control panel and ekos a lot, (especially with focuser driver as very limited control in ekos) and it would stop all that. As I said before, to have all controls in ekos would be a massive job for the amount of drivers and all the different settings, but to have them under an advanced options would work, as the options would be different for different drivers... :)
5 years 3 months ago #32076

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

  • Posts: 1029
  • Thank you received: 301
From what I read, you are all seeking better clarity on the INDI panel. I agree sometimes I'd love to have the same tooltips in that panel as there are in Ekos, but besides that, aren't all your requests directed towards INDI driver development? I don't see the advantage of getting those controls inside Ekos if they are not part of what Ekos uses: it will require massive dependency injection.
Now, there's one point I note: when Ekos is using a particular INDI panel control, it would be interesting that this area be clearly identified as under control from Ekos. And by extension, what area is NOT under control by Ekos.
Also, an option not to show the INDI panel at all when connecting, probably.

-Eric
5 years 3 months ago #32077

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

Time to create page: 0.451 seconds