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

No response to @PRS commands #18

Closed
rpineau opened this issue Nov 15, 2019 · 6 comments
Closed

No response to @PRS commands #18

rpineau opened this issue Nov 15, 2019 · 6 comments
Labels
bug Something isn't working

Comments

@rpineau
Copy link

rpineau commented Nov 15, 2019

Hi Tim.
Based on a few lofs for 2 users I see timeout every time I request the shutter position 👍

[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] sending : @PRR


[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] response : ':PRR20196'
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::getDomeAz] szResp = PRR20196
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::getDomeAz] m_nNbStepPerRev = 55080
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::getDomeAz] m_nCurrentRotatorPos = 20196
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::getDomeAz] dDomeAz = 132.00

[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] sending : @PRS
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] response : ':PRR20196'

[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] sending : @PRS
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] response : 'XB->Online'
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] XBee status : 'XB->Online'
[Thu Nov 14 20:26:09 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:10 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:12 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:13 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:14 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:16 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:17 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:18 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:18 2019] [CNexDomeV3::domeCommand] response : 'XB->Online'
[Thu Nov 14 20:26:18 2019] [CNexDomeV3::domeCommand] XBee status : 'XB->Online'
[Thu Nov 14 20:26:19 2019] CNexDomeV3::readResponse Timeout while waiting for response from controller
[Thu Nov 14 20:26:20 2019] [CNexDomeV3::getDomeEl] ERROR = PRR20196

as you can see I do get some of the inline messages, like the XBee online status and no actual :PRSxxxxx response to the @prs command, but I do get the same response as the previous command (which was a @prr in this case).
So there is either a timeout in the XBee communication with the shutter or in the firmware somewhere.
Is there a minimum amount of time required between commands ?

@NameOfTheDragon
Copy link
Collaborator

@rpineau Which firmware version was this please?

@rpineau
Copy link
Author

rpineau commented Nov 25, 2019

I believe these log come from people using the 3.0.0 firmware.
I can retest with the 3.1 beta in pull request #17

@NameOfTheDragon
Copy link
Collaborator

NameOfTheDragon commented Nov 25, 2019 via email

@rpineau
Copy link
Author

rpineau commented Nov 25, 2019

ok, I can wait and retest once 3.1 is out (or a pre-version so that if this is still and issue it can be fixed before 3.1 is released).

@NameOfTheDragon
Copy link
Collaborator

So now that 3.1.0-Beta.6 is out, I'm having another look at this. My eye is drawn to this part of the log:

[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] sending : @prs
[Thu Nov 14 20:26:08 2019] [CNexDomeV3::domeCommand] response : ':PRR20196'

You seem to be getting two responses to the @PRR command. Do we know where that second response is coming from?

When you send the second one, that's clearly not answered and that is (or was) a bug. I think this one should be fixed by PR #17 . There was a race condition where a command could get lost if it happened right as the XBee state machine was polling for an active connection. This race condition should now be eliminated.

@rpineau
Copy link
Author

rpineau commented Nov 29, 2019

I'll re-run some test with log enabled and check if this is still the case.

@NameOfTheDragon NameOfTheDragon added this to the 2019-11-A milestone Nov 30, 2019
@NameOfTheDragon NameOfTheDragon added the bug Something isn't working label Nov 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants