but when I use the LX200Basic driver I have the same bug
SCOPE 66.553373 sec : CMD <:Sr 11:49:60#>
SCOPE 66.569735 sec : CMD <:Sr 11:49:60#> failed.
So it is definitively not in the driver itself ....

continue tracking this

in indicom the function effectively can return a 66 second valueinstead of a 1 minute
==================== indicom www.indilib.org/api/indicom_8c_source.html#l00230
void getSexComponents(double value, int *d, int *m, int *s)
{
*d = (int32_t)fabs(value);
*m = (int32_t)((fabs(value) - *d) * 60.0);
*s = (int32_t)rint(((fabs(value) - *d) * 60.0 - *m) * 60.0);

if (value < 0)
*d *= -1;
}
===================================

@ Khalid,

I made some corrections in indicom.cpp
============================================ indicom.cpp line 232 ....
void getSexComponents(double value, int *d, int *m, int *s)
{
*d = (int32_t)fabs(value);
*m = (int32_t)((fabs(value) - *d) * 60.0);
*s = (int32_t)rint(((fabs(value) - *d) * 60.0 - *m) * 60.0);

if (value < 0)
*d *= -1;
// by rounding with rint() seconds could be 60, so we correct this
if (*s==60)
{
*s=0;
*m+=1;
if (*m==60)
{
*d+=1;
*m=0;
}
}
}
====================================================

Now I can slew, sync to whatever coordinates.
I retested you case
Slewing to Zozma
Host --> :Sr 11:15:05# Device --> 1
Host --> :Sd +20:25:12# Device --> 1
then slewing to Denebola
Host --> :Sr 11:50:00# Device --> 1
Host --> :Sd +14:28:02# Device --> 1

As you can see the slews work correctly

Goind further I tested the following:
slew request command output
11:59:59.4 11:59:59
11:59:59.5 12:00:00
11:59:59.6 12:00:00
so the conversion works and I did not notice side effects but I am not an expert.

Could you take a look at the correction from a programmer standpoint before I ask Jasem for change?

Thanks

The code looks OK.

You have protection for seconds and minutes. But not sure if there is a possibility of degrees overflow (e.g. degrees 24 in RA, or greater than 90 in declination?

Perhaps we should get Jasem to look at the code too?

Hi Alain! Been there done that...

Catch up time: I've been fighting an intermittent motor problem in mine. The declination motor just goes cold without obvious cause. I'm afraid it's been through one too many mount crashes as swapping driver boards didn't help. More t-shooting in the shop should sort things out..again.. I've also gotten fed up with the garbage worm and bushing issues on the little cg-4 so I finally decided to get something larger for my main mount. After looking into retooling to build a larger system and filling my shop with scrap aluminum from work, I finally gave up and went with a Skywatcher Eq6-r pro that was on sale. Still waiting to see if it arrives intact. that was a LOT of bike tubes.

I'm not abandoning the old one but this will free it up for other experiments, as well as testing use without the constant threat of ruining whole nights when it goes sideways, though there appears to be less need now since Khalid has his running, and likely more clear nights too.
I've also considered converting the cg-4 back to servo/encoders as I had better results when the system could self correct for mount errors in real time. Adapting OnStep to that purpose would be a neat little project too, probably hacking in the control section from my old Arduino-gem-driver program to handle the feedback and pseudo derivative feedback(PDF) loops. The big PWM controllers were quite a bit tougher than these tiny disposable stepper boards are turning out to be.

Hope you guys are doing well.
Clear skies!

Khalid,
Thanks for the review and advice.
Effectively it could overflow (lokking at the conversion routine) but doesn't it is blocked before du to min/max boundaries.
I will do some more tests to make sure no side effects are arround and then involve Jasem.
What is strange is nobody elese did fall on this before.

Regards

Hi, Blueshawk
nice to hear about you. Seems you go for testing another mount and for sure you will like it.
On my side some trouble .... I definitively need to vent the basement of the observatory. I opened the false floor today to install some devices and I saw some mushrooms on the floor For the time beein I used drastic arguments (Chlorine water) but will have to modify the heating air flow to go through basement to keed dry.
good I installed nothing critical for the time beeing,
Anther job beside the winter duties, but anyhow fog and clods so no matter.

Hi All,
I am very keen on integrating focuser code from azwing's branch into the master branch. Based on response from azwing, it looks like this branch will not be merged into master any time soon, so I decided to create my own fork where I would stabilize this feature and then submit a merge request.
I hope everyone is ok with this plan.
So I created a fork:
github.com/avarakin/indi
and picked the changes from azwing's branch with focuser related changes. I was able to build it but I am having trouble while testing it: every time I push buttons in the INDI control panel, I am getting errors like:

2018-11-27T04:44:04: Driver indi_lx200_OnStep: indi_lx200_OnStep dispatch error: Property ABS_FOCUS_POSITION is not defined in LX200 OnStep.

This is my 1st time doing changes in INDI, so I guess I am missing something very basic. Keep in mind that I did not do full install after I compiled the drivers, I just copied the new lx200generic to /usr/bin.

I have a fairly stable setup right now and I can do some testing, so if you are interested in including other features, which are ready for integration into main branch, I can test them too.

Alex

Alex,
merci beaucoup !

You cannot just copy one file I guess.
there are some symbolic links, xml files and probably other things you could miss due to differences between you install and the sources for building.
in /usr/bin you have some links like
/usr/bin/indi_lx200_OnStep -> indi_lx200generic

I never tryed to just copy files but for sure it is the best way to run into trouble.
Alternatively it is possible to build in /usr/local but there is still a way to mix binaries at runtime when you start from Kstars. (some xml data tells Kstars where the binaries are)

After installation you always can uninstall by issuing this command from withing build directory:
xargs rm < install_manifest.txt
The only annoying thing is for 3rdparty libraries but I suppose you did not compile/install them.

At least I can tell you my version is running correctly so the bug certainly comes from your way to test.

@avarakin "it looks like this branch will not be merged into master any time soon, " --We might be closer than you think! Especially if we get more testers. I'm guessing you have a focuser running? One solution to your short term needs might be to compile your own for the time being. I'm worried that pushing that to master may conflict with other development.

@Azwing: Mushrooms! !o.o!
Can we get a current bug list? What is left to fix?

@Blueshawk,
Not really bugs, more duplicates / incomplete implementation.
==================================== Align
My implementation still in the "Main Control" tab
James implementaion in a dedicated "Align" Tab
ToDo:
I would start with my implementation, replace the three buttons with a pull down 1 to 9 stars
and add the button "Write Alignement" (which James called Finished Align) that writes the model to EEprom
and put everything under "Align" Tab
==================================== Focuser
Works but is one has two focusers, the second focuser is not recognoised by Ekos and it's interface is not consistent with the first one
Todo:
Just clean up the code and make second focuser interface looking like for focuser 1
============================================== other things
Real testing before implementaing new functions.
My fear with releasing to Master in the state it is now is to leave debugging up to peopple that do not want to debug but just use.

==================================== Align
What if we remove(and save of course) the modeling bits for this release and continue development after, and just use your already polished 3 star alignment for now? That would also be moving in the same direction since we're planning to combine them anyway, and this would in effect clean up the code. This would also give the OnStep team more time to polish the modeling system on their end so we'd have a stable interface to call.
==============Focus
Does the ekos focus module look for more than one focus in a driver? If not that might be why it didn't find it. Removing the second one "could" be an option in the short term.
The rest of the system has been working pretty dang good!
We could then start using that branch you made for the really crazy stuff and just polish azwing main and push that when bugs come in.
OR I'm just crazy.