Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue #8 improve homing algorithm #11

Merged
merged 1 commit into from
Oct 27, 2019

Conversation

NameOfTheDragon
Copy link
Collaborator

Ensure that status is only reported at the end of the homing operation.
Ensure that AtHome is true after a successful homing operation
Streamline the home sensor code

Ensure that status is only reported at the end of the homing operation.
Ensure that AtHome is true after a successful homing operation
Streamline the home sensor code
@NameOfTheDragon
Copy link
Collaborator Author

NameOfTheDragon commented Oct 24, 2019

@knro @dave4robots updated firmware for beta testers
TA.NexDome.Rotator.zip

@rpineau
Copy link

rpineau commented Oct 26, 2019

The find home now works very well at all speed.
But .. There might be a new issue with this firmware.
As expected we can get status message between a command and its response but usually the response comes back fairly quickly after.
With the new firmware I see huge timeout between the command, status messages and the actual response :

[Sat Oct 26 16:37:08 2019] [CNexDomeV3::domeCommand] sending : @PRS

[Sat Oct 26 16:37:08 2019] [CNexDomeV3::domeCommand] response : 'XB->Online'
[Sat Oct 26 16:37:08 2019] [CNexDomeV3::domeCommand] XBee status : 'XB->Online'
[Sat Oct 26 16:37:10 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:12 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
^X[Sat Oct 26 16:37:14 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:14 2019] [CNexDomeV3::domeCommand] response : ':BV823'
[Sat Oct 26 16:37:14 2019] [CNexDomeV3::domeCommand] m_dShutterVolts : 12.07
[Sat Oct 26 16:37:16 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:18 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:18 2019] [CNexDomeV3::domeCommand] response : 'XB->Online'
[Sat Oct 26 16:37:18 2019] [CNexDomeV3::domeCommand] XBee status : 'XB->Online'
[Sat Oct 26 16:37:20 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:22 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:24 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Sat Oct 26 16:37:24 2019] [CNexDomeV3::getDomeEl] ERROR = PRR0

As you can see the @prs command is sent at 16:37:08, then we get 2 "event notifications" (XB status and shutter voltage) at 16:37:08 and 16:37:14
and then another XB status at 16:37:18
and a response arrives at 16:37:24 , that's 16 seconds after sending the command, and it's not the proper responser (hence the ERROR label).
So there is something weird going on when requesting shutter states.
This is not happening often but I saw it once on connect and another time (above)

I see more response that do not match the command send :

[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] sending : @SWR

[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] response : 'STOP'
[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] response : 'Hstop 4'
[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] sending : @SWS

[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] response : ':SER,0,1,12347,0,30'  <==== This is not a proper response to @SWS
[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] sending : @PRR

[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] response : ':SWR'  <==== This is not a proper response to @PRR
[Sat Oct 26 16:37:24 2019] [CNexDomeV3::getDomeAz] szResp = SWR
[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] sending : @PRR

[Sat Oct 26 16:37:24 2019] [CNexDomeV3::domeCommand] response : ':PRR0'

@NameOfTheDragon
Copy link
Collaborator Author

Thanks for the feedback, @rpineau . I'll need to consider this for a while.

Some of the output you’re seeing is diagnostics and will be gone by the release. I thought I’d taken it all out but clearly missed some.

The rest of it is quite puzzling because commands and responses are actioned immediately and not stored in a queue or anything, so the only place I can imagine the delay could be occurring is in the XBee itself. They do have a mode that I am using where they check for an acknowledgement of a successful transmission and they automatically re-try up to 3 times. I would imagine that this process happens fairly quickly but I must admit I don't know for sure how long re-tries take. But that's the only thing I can think of at the moment.

But then again, you are receiving XBee status updates, and that itself involves the shutter sending a handshake and getting a response back. It is difficult to imagine where such a long delay could be happening though, since commands are always fully executed (and the response returned) in a single iteration of the main loop. Responses are never deferred or awaited.

What would make more sense to me is if a response just occasionally doesn’t come back at all from the shutter. I could much more easily imagine how that could happen. I wonder if that is actually the case because the response you eventually received was not the correct one for the command you were waiting for.

As I said, puzzling. I’ll have to think about it. I may move this to a new issue as I don't think it is really related to the changes I made to homing and I need to get my sprint finished by the end of the weekend.

@rpineau
Copy link

rpineau commented Oct 27, 2019

I agree that this is potentially due to a XBee response being lost as I only see these on shutter commands. On my test rig the 2 XBee are about 15cm from each other so distance here is not the issues.
Between the 2 "XB->Online" status there are 10 seconds during which we also get a battery update. So could it also be that the Shutter XBee didn't receive the command and is therefore not responding to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants