×
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
- Kevin Ross
-
- Offline
- Elite Member
-
- Posts: 421
- Thank you received: 102
- Kevin Ross
-
- Offline
- 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
I'm glad this fixed the problem for you.
However, I'm concerned. Why does manually slewing need this delay and nothing else needs it? Why does it need it? It's not like we're sending a bunch of commands in bulk. We send one command, wait for a response, send another command, wait for a response, etc.
:shrug:
It works. I guess that's the important part.
However, I'm concerned. Why does manually slewing need this delay and nothing else needs it? Why does it need it? It's not like we're sending a bunch of commands in bulk. We send one command, wait for a response, send another command, wait for a response, etc.
:shrug:
It works. I guess that's the important part.
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
Yup as long as it works 
I had some more time playing with the setup now. I did notice a potential side effect of the delay. The symptom is that, when I use the "slew to target" function in the alignment module, I seemingly can never get the error to be under 40 arc-second no matter how many time the alignment module tries to correct. Before the code change I can easily get under 20 arc-second, usually within 2 corrections. If I understood the code correctly, this 100ms delay is introduced for ALL commands going to the mount (including the polling of axis position and motor status). I wonder if this causes enough total delay between plate solving and the actual mount movement to result in ~40" slewing error. Furthermore, I wonder if the delay could potentially causes other side effects.
I'm already running an imaging sequence for tonight but tomorrow I can try to flip back to the old code and see if I can pin this on the code change.
I had some more time playing with the setup now. I did notice a potential side effect of the delay. The symptom is that, when I use the "slew to target" function in the alignment module, I seemingly can never get the error to be under 40 arc-second no matter how many time the alignment module tries to correct. Before the code change I can easily get under 20 arc-second, usually within 2 corrections. If I understood the code correctly, this 100ms delay is introduced for ALL commands going to the mount (including the polling of axis position and motor status). I wonder if this causes enough total delay between plate solving and the actual mount movement to result in ~40" slewing error. Furthermore, I wonder if the delay could potentially causes other side effects.
I'm already running an imaging sequence for tonight but tomorrow I can try to flip back to the old code and see if I can pin this on the code change.
Please Log in or Create an account to join the conversation.
- Kevin Ross
-
- Offline
- Elite Member
-
- Posts: 421
- Thank you received: 102
- Kevin Ross
-
- Offline
- Elite Member
-
- Posts: 421
- Thank you received: 102
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
-
- Offline
- Elite Member
-
- Posts: 421
- Thank you received: 102
- Kevin Ross
-
- Offline
- Elite Member
-
- Posts: 421
- Thank you received: 102
Time to create page: 0.683 seconds
© 2003-2022 by INDI Library. All rights reserved.