My shutter has been closing randomly. Has ruined a couple of imaging sessions over night. I have the low voltage to 10.5 and it reports 12.5 V. I also do not have The rain sensor because I’m using the AAG. Do I need to change anything in the set up to ignore rain sensor? Also would software watchdog maybe cause it to close during a long exposure If it thinks the dome lost connection?
Or maybe does xbee wireless send send a data signal that could be replicated by random noise?
just the shutter (I updated both to report version 2.12 but there is no changes in the rotator firmware).
Thanks Rodolphe!! Does this require updating both the rotator and the shutter?
Wow! Quick service :) my chick-fi-a isn’t even as fast. Mmm nuggets....
I just pushed a new 2.12 version with the watchdog code disabled.
So there is no clear pattern .. TSX alone on Windows has the problem (Dave), TSX alone on Windows doesn't have the problem (Steve).
ASCOM : You have the problem.
So no clear pattern. Could be some XBee issues, interference, environment related... gremlins ...
So just disabling the watchdog in the code seems the only real option here.
I can do that now and commit the change so that you can all use your dome without having to worry about the watchdog.
I’m using 2.11 firmware.
It happened once with CCD commander taking a set of image exposures 120 seconds. I reopened and reset the ccdcommaner and it took the set no repeat incident.
Tried just using TheSkyX and take series and it happened again after about 10 exposures of 360 seconds. Reopened and it stayed open rest of the night.
then it happened again when I did a t-point model run of 100 points. It just randomly closed while the mount Was slewing between points. So the dome was slewing, tracking, had not been idle for longer than it takes to make a 5 second plate solve Exposure.
I have not not had a chance to make the change to the firmware because it’s been cloudy but I will try it.
I am using 2.11E with ASCOM client. With watchdog enabled I see random closures about every other night. When this happens the session is killed because the client (ACP) did not request closure so it stops everything and sends a operator intervention email. with watchdog commented out like I've said all is really solid with no issues at all. I'm hoping also to be testing Tim's stuff again with next beta hopefully sometime this weekend. We did so last weekend (Tim comes in remotely to the observatory) and found a few things to address. I'm hopeful that next beta will be something that I can just leave running. Motions are sure smooth and quick. Last beta did display shutter battery in the server window and I've not looked at code but would assume low volts would call a closure. Of course a threshold needs to get set and also ignored DURING shutter motion as it can lag under load. For me this just leaves rain sensor which is not much code.. I do know the recipe to return to 2.11 as the XBeeReset hex must be run in a particular way to do that. Back and forth between Tim's stuff and 2.11 has been flawless but only if the recipe is followed:
1.) load the XBeereset hex with uploader to rotator.
2.)Connect a serial port (arduino tools fine) to rotator and watch the reset. If you do not do this the reset does not happen.
3.) power off rotator.
4.) Repeat steps 1-3 with shutter.
5.) load 2.11 back in shutter.
6.) load 2.11 back in to rotator.
7.) connect a serial port to rotator and send #x to configure xbees.
Easier to do than to type :-).
Best,
Ron
I'm using 2.11E no changes to stock code. usb port saver? (quite sure I don't have it enabled). I'm not worried. I can often hit open and get it back - (sometimes it doesn't seem to respond to open) ? but our new firmware/drivers are near!
Rodolphe,
I am using v2.11 firmware with X2 plugin v2.130 in TSX 10.5.0 (Daily Build 12165). Watchdog timer set to 60s. Never had any problems.
Steve
So we have 2 cases :
1- People who've been using firmware 2.11 and never got any problem
2- People who need to disable the watchdog or they get closure.
So it would be useful do identify what people in each category are using.
And if we can't figure it out we also have 2 option :
- disable it all together (2 line changes and I can commit this)
- Wait for Tim's firmware (No X2 plugin for now and probably for a while until there is the same feature coverage as the 2.11 firmware).
Rodolphe
Hi Rodolphe, I recall we spent most of a weekend once trying to get to the bottom of this. I had thought at one time the phenom had to do sky position and how often a little ~1 degree slaving move would happen. It never was reproducible in testing. Even so closure does occur with those lines 109-117 active in shutter.ino with never a mention of the event in the ascom log files. Like I said since I removed watchdog from shutter.ino I have had zero issues over 40+ full nights now with 2.11. It works really well so I simply forgot about the issue. Completely illogical problem. For me the watch dog was now trapping for a problem I never see - communications are rock solid. With lines 109=117 active it does work though.. say rotator is off and I manually open the shutter a crack to sweep water out of the u channel after a big rain.. It will close itself after a spell.
The rotator Arduino sends ping to the shutter Arduino every 30 seconds when you're connected even if you don't send any commands to the rotator Arduino.
For a closure to happen this would require you to disconnect, in which case the Arduino probably exit the main loop (to be check/tested) and stop sending the ping.
Are your usb port power saving disabled ?
I have been using v2.11/2.11E continuously since March/April and have never seen this happen. My shutter watchdog timer has been set to 60s (default?) the entire time.
So there is a ping? always seemed to me like something had timed out... usually happening when I'm not tracking.
I'm not sure why we see these random closure unless the rotator Arduino stops sending PING. I wonder why this would happen, XBee going to sleep ?
Just comment out the watchdog and all will be well in meantime. For me 2.11 (lines 109-177 in shutter.ino commented out) has been flawless. If I leave them active random closures. I use both AAG and also NexDome rain sensor as insurance.
Best,
Ron
ODDLY I've had several of these events. Sometimes FRUSTRATING as to why other times I figured I'd call it a night. I have no idea why... I have been playing with new software (Kstars/Ekos) and I have a AGG as well and figured it was just something triggering it. But I have no idea what. I wondered if it was a time out of lack of use as I messed with new software. But seeing this perked my interest. I'm using 2.11E - I need to rem out some code? OR - I can just wait for the new Tim Long updates!
Ron and Rudolphe thanks as usual for the informative and knowledgeable replies. I will try that mod to the shutter ino and give it a try!
I had the exact same issue and reported long ago. Just comment out the watchdog section in shutter.ino. comment out lines 109 to 117. I've had > 40+ flawless full-automation nights with this mod.
Best,
Ron
2 things can close the shutter :
- Low voltage : the voltage display in the X2 plugin settings dialog is updated every 4 seconds so you should see the change.
- Watchdog timer get triggered. This will close the shutter if the shutter Arduino doesn't receive any data for the length of the watchdog timer value. The default is 90 seconds. As TheSkyX queries the dome very often, even during long exposure, the shutter shouldn't close. In addition to this the Rotator Arduino sends a "ping" to the shutter Arduino every 30 seconds. So even if TSX was not querying the system, there will still be some communication between the 2 Arduino.
The Arduino don't have any local storage so they can't keep a log.
In term of distance the XBee can communicate to up to 100m "outside" aka with direct line of sight, which is the case in the dome (and 30m inside with walls and whatnot).
Rodolphe