It doesn't connect, but it connects well with lx200 onstep

Sad, it could have been a quick solution to your problem.
Sorry

Hi,

I had a deeper look into the problem of multiple focusers and stumbled upon some things I wanted to clarify before I continue.

One problem I see, when using FocuserInterface is, that it is impossible to inherit it multiple times. Because of that, it is necessary to have multiple BaseDevices which implement the FocuserInterface. I assume it would be better to use the INDI::Focuser class as a base for the Onstep Focuser. I also saw that approach in the focuslynx driver .
Unfortunately, this only works flawlessly for statically created drivers. Unfortunately, the diver tabs do not get updated when I create a new Focuser dynamically. It requires a reconnect to the indiserver within Ekos. But maybe I am still missing something.
You can see this in my basic implementation .
Furthermore the dependency on Lx200Generic restricts the implementation of a shared lx200 parser class. That's why the onstep_focuser needs access to the file descriptor PortFD and implements its own lx200 parser.
I attached a drawing to illustrate the new class hierarchy. (File: "Blank diagram Focuser Update.png")

This is quite a hacky approach and will result in some duplicated code. As I can see that there is a discussion about restructuring the driver I also made a drawing of a in my opinion better approach. (File: "Blank diagram New Structure.png") But this would mean dropping the dependency on lx200generic and writing some onstep protocol parser, that can be shared between drivers.
As a bonus, it would be also possible to make just a bare rotator driver.

Questions:

1. how to trigger a driver reload for dynamically created based devices in the indiserver and Ekos?
2. is it possible to drop the dependency on Lx200generic?
3. are there problems with concurrency when reading and writing to PortFD unprotected?
4. what do you think about the hacky approach and a complete restructuring of the driver?

regards Alex

1. how to trigger a driver reload for dynamically created based devices in the indiserver and Ekos?
I did not find any way to do that in an unattended way nut via button ... not nice
2. is it possible to drop the dependency on Lx200generic?
Needs a complete rewrite from scratch and this is exactly what TeenAstro did
3. are there problems with concurrency when reading and writing to PortFD unprotected?
What do you mean by unprotected?
4. what do you think about the hacky approach and a complete restructuring of the driver?
same as for 2, rewrite all from scratch

Looks like I found a way to use lx200 onstep driver as a focuser by creating a custom driver and reassigning the type. But have to solve other things.
1. The rotator can be found but cannot be assigned to my optical train.
2. The Wheather tab doesn't show any info (I use bme280).
3. Focuser works weirdly. It moves the motor only when pressing the up arrow button for the first time (the next press of the button does nothing). Pushing the down arrow button occurs an error every time (doesn't depend on focuser position).
All these things work in windows via ascom driver, so the device is working properly.

1. how to trigger a driver reload for dynamically created based devices in the indiserver and Ekos?
Alain: I did not find any way to do that in an unattended way nut via button ... not nice
Alex: ok, I will have a look if I find a way. The other solution would be to create all drivers static and disable them, if they are not needed.
2. is it possible to drop the dependency on Lx200generic?
Alain: Needs a complete rewrite from scratch and this is exactly what TeenAstro did.
Alex: First look does not seem to be that big of a deal. LX200Telescope is just 1600 lines of code compared to the onstep driver with around 5000 lines. And as the onstep driver is overwriting some functionality of the LX200Telescope driver this might be even less. But yes the change is still quite substantial. Thats why I am asking if this would be accepted or if a smaller change is preferred.
3. are there problems with concurrency when reading and writing to PortFD unprotected?
Alain: What do you mean by unprotected?
Alex: Never mind, I found the lx200CommsLock mutex.
4. what do you think about the hacky approach and a complete restructuring of the driver?
Alain: same as for 2, rewrite all from scratch
Alex: Ok, I assume the smaller change is preffered.

I will continue working on the "smaller change" solution. Thank you for your help!

regards
Alex

Hi,

I have an issue with focuser OnStep driver - it doesn't show telescope temperature.
Some image reference below...


I would appreciate some help in here.

Thanks and regards,
W

Maybe TCF Enable would help

It has already been enabled, but it doesn't help much...

W

By the way - the CPU temperature is also wrong, but it's minor thing...

Hello
I am currently trying to use an off-the-shelf Onstep controller with Kstars. It is manufactured by Terrans Industries and contacting them has not resulted in an answer.
I am using the LX200 OnStep driver. I can connect however once initialisation occurs I receive a repeated warning on the Indi driver control panel (in orange):

Date/time: [WARNING] Communication: Ft# error, check connection.
Date/time: [WARNING] Invalid response, check connection.

This error message repeats every second in the Indi driver control panel, however the mount appears to respond to commands using the mount control feature in the mount section of Ekos.
I haven’t yet used it in the field.

Alain has suggested I contact this forum. He has also suggested that the problem may be related to Focuser although I have left that function blank in the in profile setup. Whatever the problem is, it is beyond my limited technical understanding.
I have not included Indi logs or Onstep firmware version.


I’m not sure how to progress. The ‘connection’ tab reveals nothing that I can see. A screenshot is attached.

Hi,I will try to reproduce this but don't wory for the time beeing.Which system are you using?
Linux, Windows, Mac OS ???

Depending on the system you are, there are differnet tools to communicate and debug OnStep connections
On Linux I use "minicom"
On Windows I use "putty"
nMac OS I don't know, I have no Mac

Once you are connected with the terminal to OnStep you can send commands to OnStep and see responses.
In your case you shoud send the command that brings you the issue and see if OnStep answers.The command should be typed in like this: ":Ft#"

to test OnStep you could use the ":GVP#" command where OnStep shoud answer with firmware version