×
INDI Library v2.0.7 is Released (01 Apr 2024)
Bi-monthly release with minor bug fixes and improvements
Manual slewing on EQ6-R Pro using built in USB port results in slewing forever
Replied by Yi on topic Manual slewing on EQ6-R Pro using built in USB port results in slewing forever
Man I hope it clears up for you soon. I guess clear nights is one of a very few number of benefits of living so close to a desert 
I compiled the new code and, unfortunately, the uncontrollable slewing came back. I included the entire modified StopWaitMotor function at the end just for you to check (old code is commented out instead of deleted)
Good news though, is that the "Slew to Target" and tracking accuracies went back to what they were before.
I tested a few other functions and can pretty much confirm that the only time problems occur is when I use manual slew via my ipad vnc client, which is the cause of the second spurious start and immediately stopped slew command. All programmatic slews work properly, such as "GoTo target", "Slew to Target", and perhaps what matters to me the most, "Park" command (It's the last large movement during an unattended imaging session, occurs 4:30AM while I'm asleep). Since the second slew command is not really caused by anything KStars or Ekos/INDI related stuff, it's technically not a bug anymore On the other hand, knowing a specific sequence of action can leads to potential equipment damage is a bit nerve wracking.
I'm running a capture sequence now. What I can do tomorrow during day-time is to try another "socat" recording, but this time with timestamps included so you can take a look at the intervals these commands are sent. What I don't understand is, even if the second K1 command gets ignored, the mount should just keep moving regularly, instead of moving erratically with loud noise and not responding to subsequent stop commands, all the while reporting (via f1) that the motor is stopped.
Here is the code I tested:
I compiled the new code and, unfortunately, the uncontrollable slewing came back. I included the entire modified StopWaitMotor function at the end just for you to check (old code is commented out instead of deleted)
Good news though, is that the "Slew to Target" and tracking accuracies went back to what they were before.
I tested a few other functions and can pretty much confirm that the only time problems occur is when I use manual slew via my ipad vnc client, which is the cause of the second spurious start and immediately stopped slew command. All programmatic slews work properly, such as "GoTo target", "Slew to Target", and perhaps what matters to me the most, "Park" command (It's the last large movement during an unattended imaging session, occurs 4:30AM while I'm asleep). Since the second slew command is not really caused by anything KStars or Ekos/INDI related stuff, it's technically not a bug anymore
On the other hand, knowing a specific sequence of action can leads to potential equipment damage is a bit nerve wracking.I'm running a capture sequence now. What I can do tomorrow during day-time is to try another "socat" recording, but this time with timestamps included so you can take a look at the intervals these commands are sent. What I don't understand is, even if the second K1 command gets ignored, the mount should just keep moving regularly, instead of moving erratically with loud noise and not responding to subsequent stop commands, all the while reporting (via f1) that the motor is stopped.
Here is the code I tested:
void Skywatcher::StopWaitMotor(SkywatcherAxis axis)
{
bool *motorrunning;
struct timespec wait;
ReadMotorStatus(axis);
if (axis == Axis1 && RARunning)
LastRunningStatus[Axis1] = RAStatus;
if (axis == Axis2 && DERunning)
LastRunningStatus[Axis2] = DEStatus;
//DEBUGF(telescope->DBG_MOUNT, "%s() : Axis = %c", __FUNCTION__, AxisCmd[axis]);
//dispatch_command(NotInstantAxisStop, axis, nullptr);
//read_eqmod();
if (axis == Axis1)
motorrunning = &RARunning;
else
motorrunning = &DERunning;
//wait.tv_sec = 0;
//wait.tv_nsec = 100000000; // 100ms
//ReadMotorStatus(axis);
//while (*motorrunning)
//{
// nanosleep(&wait, nullptr);
// ReadMotorStatus(axis);
//}
if (*motorrunning)
{
DEBUGF(telescope->DBG_MOUNT, "%s() : Axis = %c", __FUNCTION__, AxisCmd[axis]);
dispatch_command(NotInstantAxisStop, axis, nullptr);
wait.tv_sec = 0;
wait.tv_nsec = 100000000; // 100ms
ReadMotorStatus(axis);
while (*motorrunning)
{
nanosleep(&wait, nullptr);
ReadMotorStatus(axis);
}
}
}Please Log in or Create an account to join the conversation.
- Kevin Ross
-
- Away
- Elite Member
-
- Posts: 421
- Thank you received: 102
- Kevin Ross
-
- Away
- Elite Member
-
- Posts: 421
- Thank you received: 102
- Kevin Ross
-
- Away
- Elite Member
-
- Posts: 421
- Thank you received: 102
Replied by Kevin Ross on topic Manual slewing on EQ6-R Pro using built in USB port results in slewing forever
Well, removing all my changes, and just adding a small delay after the StartMotor command, in the SlewDE and SlewRA methods, improves stability without impacting guiding.
However, there's something wrong with the mount control dialog in Ekos I think. It seems to be missing some key presses, resulting in occasional runaway behavior. The logs show the driver is receiving a start command from ekos, but no corresponding stop command (sometimes). I also see sometimes multiple stop commands in a row, with no corresponding start command. So something is definitely wrong there.
I think this might run deeper than the amount of time I have right now to dedicate to tracking this down.
May I suggest not using manual slewing for now?
However, there's something wrong with the mount control dialog in Ekos I think. It seems to be missing some key presses, resulting in occasional runaway behavior. The logs show the driver is receiving a start command from ekos, but no corresponding stop command (sometimes). I also see sometimes multiple stop commands in a row, with no corresponding start command. So something is definitely wrong there.
I think this might run deeper than the amount of time I have right now to dedicate to tracking this down.
May I suggest not using manual slewing for now?
Please Log in or Create an account to join the conversation.
Replied by Yi on topic Manual slewing on EQ6-R Pro using built in USB port results in slewing forever
Of course!! Thank you so much for your help so far. This is really helpful. I'm also more familiar with the indi-eqmod code base now that I can keep tweaking it if I have time. I have mostly got rid of my manual slew needs. About the only time it's necessary is occasionally the mount would wrongfully believe it is pointed below the horizon, therefore refusing to turn on tracking, which in turn prevent the alignment module from syncing to plate solving solutions. But I can slew from my desktop. It looks like it's my iPad setup that is causing the spurious second slew which is really the cause of the problem.
Thank you again! I wish there is a way I can send you a beer
Thank you again! I wish there is a way I can send you a beer
Please Log in or Create an account to join the conversation.
Time to create page: 5.931 seconds
© 2003-2022 by INDI Library. All rights reserved.