I am running a Pointing model t-point and it is supposed to skew to several targets an

I’ll get ahold of him and see. Thanks.Dave Compton <span class=

TheSkyX v3 x2 slew getting stuck about firmware HOT 14 CLOSED

nexdome commented on July 29, 2024

TheSkyX v3 x2 slew getting stuck

from firmware.

Comments (14)

NameOfTheDragon commented on July 29, 2024

Fair enough, but what evidence is there that makes you think this is a firmware issue and not an X2 driver issue or an issue with TheSky itself? Can you reproduce this using the ASCOM driver, for example? (TheSky should be able to use an ASCOM dome driver). The ASCOM driver produces copious log output that may help to zero in on the problem. Otherwise I have no "smoking gun", I can't reproduce it myself because I don't have TheSky and so I will not really be able to troubleshoot the issue.

from firmware.

dave4robots commented on July 29, 2024

I’m the same Dave Compton, just FYI. I only put the issue here because you directed me to github versus continued email. The issue may indeed be a SxkY X2 issue. Just wanted to report an unexpected behavior.

I think it may be because the T-point software rapidly moves between alignment points and the dome update may fall in a crack. Also, seeing the azimuth get written as a Zero when it was not may indicate a communication problem between the X2 driver and the firmware.

Again, maybe not your issue, but reporting on GitHub for continuity.

from firmware.

NameOfTheDragon commented on July 29, 2024

Hi Dave. That’s fair. However if it does turn out to be an X2 issue, then I don’t think Rodolphe will see it on Github because I don’t think he uses it. I hope I haven’t put you in a position where you’re unsure where to go for help. I’m directly responsible for the firmware and the ASCOM driver and I track those here on Github. In this particular case, it may be better to start troubleshooting at the top of the stack, i.e. talk to Rodolphe about the X2 driver. My gut tells me this isn’t a firmware issue because we don’t see it happening with ASCOM users. Rodolphe may feel that it isn’t an X2 problem either, in which case then you are welcome to bring it back here. But he’s a smart guy and he might have an insight into what may be happening. The difficulty for me here is that I can’t test an X2 driver so my hands are kind of tied in terms of gathering data. I need a “smoking gun”. Best regards, Tim Long From: dave4robots <[email protected]> Sent: 24 October 2019 04:14 To: nexdome/Firmware <[email protected]> Cc: Tim Long <[email protected]>; Comment <[email protected]> Subject: Re: [nexdome/Firmware] TheSkyX v3 x2 slew getting stuck (#9) I’m the same Dave Compton, just FYI. I only put the issue here because you directed me to github versus continued email. The issue may indeed be a SxkY X2 issue. Just wanted to report an unexpected behavior. I think it may be because the T-point software rapidly moves between alignment points and the dome update may fall in a crack. Also, seeing the azimuth get written as a Zero when it was not may indicate a communication problem between the X2 driver and the firmware. Again, maybe not your issue, but reporting on GitHub for continuity. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#9?email_source=notifications&email_token=AAJVWCQKUTCSJSTX5HKWI5DQQEHF3A5CNFSM4JD2HHXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECDRHRI#issuecomment-545723333>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAJVWCW5BIBSNI5ZOSOHMN3QQEHF3ANCNFSM4JD2HHXA>.

from firmware.

dave4robots commented on July 29, 2024

I’ll get ahold of him and see. Thanks. Dave Compton

…

On Oct 24, 2019, at 12:23 PM, Tim Long ***@***.***> wrote: Hi Dave. That’s fair. However if it does turn out to be an X2 issue, then I don’t think Rodolphe will see it on Github because I don’t think he uses it. I hope I haven’t put you in a position where you’re unsure where to go for help. I’m directly responsible for the firmware and the ASCOM driver and I track those here on Github. In this particular case, it may be better to start troubleshooting at the top of the stack, i.e. talk to Rodolphe about the X2 driver. My gut tells me this isn’t a firmware issue because we don’t see it happening with ASCOM users. Rodolphe may feel that it isn’t an X2 problem either, in which case then you are welcome to bring it back here. But he’s a smart guy and he might have an insight into what may be happening. The difficulty for me here is that I can’t test an X2 driver so my hands are kind of tied in terms of gathering data. I need a “smoking gun”. Best regards, Tim Long From: dave4robots ***@***.***> Sent: 24 October 2019 04:14 To: nexdome/Firmware ***@***.***> Cc: Tim Long ***@***.***>; Comment ***@***.***> Subject: Re: [nexdome/Firmware] TheSkyX v3 x2 slew getting stuck (#9) I’m the same Dave Compton, just FYI. I only put the issue here because you directed me to github versus continued email. The issue may indeed be a SxkY X2 issue. Just wanted to report an unexpected behavior. I think it may be because the T-point software rapidly moves between alignment points and the dome update may fall in a crack. Also, seeing the azimuth get written as a Zero when it was not may indicate a communication problem between the X2 driver and the firmware. Again, maybe not your issue, but reporting on GitHub for continuity. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#9?email_source=notifications&email_token=AAJVWCQKUTCSJSTX5HKWI5DQQEHF3A5CNFSM4JD2HHXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECDRHRI#issuecomment-545723333>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAJVWCW5BIBSNI5ZOSOHMN3QQEHF3ANCNFSM4JD2HHXA>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

from firmware.

rpineau commented on July 29, 2024

Hi guys.
I identified the issue (the 2 issues). One is a bug in my code and is fixed in my develop version and should be in next 1.05 version to be released tomorrow.
The other issue (I'll open a separate issue for this) is that when sending a PRS commands I never get the response from the controller and when I get a response is the same response as the previous command before this. For now I'll by-pass that code and return 90 degrees or 0 degrees based on whether the dome is open or closed.

from firmware.

dave4robots commented on July 29, 2024

I downloaded 1.06 from rti-zone. I can not get shutter to be recognized unless I physically unplug/ reset shutter. This is not beneficial for remote operation. Requires a trip to the dome.

Would appreciate any help.
maybe Xbee getting out of sync and losing wireless link?

from firmware.

rpineau commented on July 29, 2024

Did you check the "Shutter controller present" checkbox in the settings dialog ?
If yes, any errors reported on connect ?
I can send you a debug version so we can see why it's doing this.

from firmware.

dave4robots commented on July 29, 2024

Okay, so this is after a successful run/ night with ccd commander and I park the dome and scope. If I check inside the driver under settings I hit more settings. The ‘shutter controller present’ is checked. But it reports 0 Volts for shutter voltage. Dave Compton

…

On Nov 24, 2019, at 2:38 AM, Rodolphe Pineau ***@***.***> wrote: Did you check the "Shutter controller present" checkbox in the settings dialog ? If yes, any errors reported on connect ? I can send you a debug version so we can see why it's doing this. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

from firmware.

rpineau commented on July 29, 2024

Hi.
Based on your email, Tim need to look into what happens when the rotation arduino and XBee are off for a long period while the shutter arduino and Xbee are left on.
@tim, Dave parks the dome after a session and power off the rotation Arduino, but the shutter one is never powered off and is left on all day(s) until the next session. During all that time, it can't talk to the rotation arduino. What happens in this case ? We ask as this seems to be the issue there as when the rotation arduino is powered back up, it can't communicate with the shutter arduino, so I wonder if the shutter arduino get into a state were it stops all communication or goes into some sleep mode after a period without any communication.

from firmware.

dave4robots commented on July 29, 2024

So will it be better to leave dome motor also on all the time? It probably won’t hurt. I just power everything down after a session. But no way to power off/ on the shutter remotely. Dave Compton

…

On Nov 24, 2019, at 12:56 PM, Rodolphe Pineau ***@***.***> wrote: Hi. Based on your email, Tim need to look into what happens when the rotation arduino and XBee are off for a long period while the shutter arduino and Xbee are left on. @tim, Dave parks the dome after a session and power off the rotation Arduino, but the shutter one is never powered off and is left on all day(s) until the next session. During all that time, it can't talk to the rotation arduino. What happens in this case ? We ask as this seems to be the issue there as when the rotation arduino is powered back up, it can't communicate with the shutter arduino, so I wonder if the shutter arduino get into a state were it stops all communication or goes into some sleep mode after a period without any communication. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

from firmware.

rpineau commented on July 29, 2024

On Sun 24 Nov , at 11:53, dave4robots ***@***.***> wrote: So will it be better to leave dome motor also on all the time? It probably won’t hurt. I just power everything down after a session. But no way to power off/ on the shutter remotely.

"Better" .. not sure about better, but as a test to confirm that this is the issue (one controller off while the other one stay on all the time) you could do a test and leave both on next time and see if you can connect without issues on the next session. If you get some errors (hopefully not) it would mean there is some issue in the firmware that creeps in after running for a while. If after leaving them both on you see an error 206 on connect in TheSkyX Pro let me know. you should be able to retry to connect and it should work. If it still fail .. we'll know the controller end up in weird state after being on for a long time. I'm going to publish version 1.07 today that fixes a small issue that happen very rarely. Regards, Rodolphe -- | Rodolphe Pineau RTI-Zone | | http://www.rti-zone.org/ |

from firmware.

NameOfTheDragon commented on July 29, 2024

By design, the XBee comms stack constantly polls for an active connection and takes remedial action if it is down. If the connection drops, then after about 10 seconds that will be detected and the XBee is rebooted and reconfigured and that whole process should repeat over and over at both ends of the link. In theory, when the power comes back on then the XBees should re-associate and everything should just recover. Most of the time things work as designed, but a number of people have mentioned that the shutter doesn’t like reconnecting after the rotator has been powered off, so there does seem to be some sort of issue there. I’m not currently sure whether it is an XBee systemic issue or something the firmware is doing, but I’m issuing a “factory reset” to both XBees every time I reconfigure them, which is about once a minute if the link is down. I’ve seen similar issues myself after I upload a new firmware build. Sometimes those XBees just will not play until they’ve been power-cycled. I recommend leaving everything powered on all the time if at all possible. The motors are de-energized when not actually moving so there shouldn’t be an heat generated and the current draw should be fairly small. Best regards, Tim Long

from firmware.

dave4robots commented on July 29, 2024

It’s winter now so I don’t mind, but In the summer it gets really hot in Oklahoma so I try to save electronics by keeping off till cooler evening hours. In the closed dome during a summer day On the roof it can get to 120F in there. Granted most of those days I won’t be imaging. I guess when that issue comes up I can visit the dome to unplug everything and maybe even bring the OTA indoors. Dave Compton

…

On Nov 24, 2019, at 9:17 PM, Tim Long ***@***.***> wrote: By design, the XBee comms stack constantly polls for an active connection and takes remedial action if it is down. If the connection drops, then after about 10 seconds that will be detected and the XBee is rebooted and reconfigured and that whole process should repeat over and over at both ends of the link. In theory, when the power comes back on then the XBees should re-associate and everything should just recover. Most of the time things work as designed, but a number of people have mentioned that the shutter doesn’t like reconnecting after the rotator has been powered off, so there does seem to be some sort of issue there. I’m not currently sure whether it is an XBee systemic issue or something the firmware is doing, but I’m issuing a “factory reset” to both XBees every time I reconfigure them, which is about once a minute if the link is down. I’ve seen similar issues myself after I upload a new firmware build. Sometimes those XBees just will not play until they’ve been power-cycled. I recommend leaving everything powered on all the time if at all possible. The motors are de-energized when not actually moving so there shouldn’t be an heat generated and the current draw should be fairly small. Best regards, Tim Long — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

from firmware.

NameOfTheDragon commented on July 29, 2024

Duplicate of #18

from firmware.

TheSkyX v3 x2 slew getting stuck about firmware HOT 14 CLOSED

Comments (14)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent