Hello everyone, long time since I posted. I apologise in advance that I don’t have logs or screenshots for this episode, but I think it’s important to report an incident that resulted in serious damage.
Here’s how it went:-
EQMOD (v2.00q) and SGP (v3.1.0.479) all up to date. EQ6-R mount direct-connected using USB cable.
Two targets selected for the night; foolishly I went to bed after the first sequence was started.
SGP successfully slewed to the second target and plate solved.
There was a very slight (approx 1.3 degree) rotation error on that target, which displayed the screen requesting me to rotate my camera to match up with the working image.
I was asleep so the rotation correction never came.
The mount tracked the target for the remainder of the night and into the morning, resulting in a pier crash (see photo) which burned out the motherboard of my EQ6-R and shredded the RA drive belt.
On discovering the state of my rig I pulled the power to all of my gear. In my distress, I didn’t think to save a log of SGP or take any screenshots, but the “Rotation Required” screen was still present, and clearly the basis for the issue.
The “Rotation Required” warning screen in SGP asking for the rotation to be corrected seemingly over-rode the instructions I had given to SGP to stop the sequence at a set time, and also clearly over-rode the EQMOD protection to not track below a certain elevation.
My rig has been out of service since, the parts required to repair are out of stock, and I haven’t had the time to strip out my mount to see if there’s further damage to the worms and ring-gears. I’ll be out of commission until well into 2021 for these reasons. Not happy.
Once again, I apologise for not supplying logs or screenshots, but I think there is enough evidence to make this a cautionary tale for others.
My suggestions:
Have a timeout for any screens which require user input. If it doesn’t come within say 30 mins then it’s not likely to come because the user is asleep, and freeze all operations or command a Park.
If the user sets a finish time in the sequence, then that must override everything else. I have a very good reason for setting that time, and it was ignored.
SGP cannot override the safety features of EQMOD, which were set correctly.
UPDATE: I haven’t used SGP since this episode a few weeks ago; if it’s possible to extract logs from it then I’d be very happy to do so, but AFAIK they need to be actioned before shutting down the app.
I’m sorry this happened. I have a similar setup with an Atlas mount and Eqmod. I also had an overnight crash once but don’t know the cause. In any event, I escaped serious damage by leaving the clutch just tight enough to move the scope, so once it made contact with the pier it just kept slipping.
Yes, I think I’ll rething my clutch settings. Normally quite tight to get the most accurate guiding, but of course they are there for a reason, which is this…
Sorry for your loss CaptBuscemi. In my humble opinion this loss is not on SGP though. If you’re using EQMod, one of the first things you must do when you initially set up your imaging rig is set the horizon and meridian limits in EQMod. I also learnt the hard way by ignoring the advice of those that have gone before me, but it only needed to happen once. Now when I set up a new mount and imaging rig, I set those two limits without fail, and I confirm that they both work. My pier bump did not result in any damage because I also make sure I do not overtighten the clutches (there is no necessity for overtightening).
1. SGP cannot override the safety features of EQMOD, which were set correctly.
This is an interesting comment. Are you saying that you had meridian and horizon limits set in EQMod, and had the limits checkbox set, and despite this SGP somehow overrode them? I don’t believe that is possible, and in my experience to date SGP has never been able to override the limits set in EQMod on my systems. Perhaps EQMod lost the connection to your mount? That might be one explanation for the collision, assuming you did have the limits set correctly, but once again, that has nothing to do with SGP.
In any case, I hope you don’t find any further damage.
Not trying to blame anybody, I can’t say for certain what all the settings were at the time because I had to pull the power.
What I do know is that my laptop (which was on battery power) showed the “rotate camera” screen. The fact that something like this is able to hang for hours and hours is definitely an SGP problem, as is the fact that it ignored my End Sequence at the appointed time. When I reopened EQMOD, the altitude limits were still set as they always had been.
Yeah, I’d agree. Any action in SGP that blocks requiring user input should really just time out after X minutes and result in an “end of sequence” to return the mount to a safe location, if SGP cannot safely proceed.
If not, then you would really want meridian flips, end of sequence altitude or time horizons etc to be honored even if SGP was still blocked waiting for the user, and that could be tricky to implement / manage.
I’d rather loose an night’s imaging because the system timed out waiting for me and returned the mount to a safe parked position, rather than find it crashed into the pier the next morning.
edit: Of course the above assumes that you have configured a safe end of sequence set of actions (e.g. parking the mount).
Yes, that’s pretty much what I’m getting at. I understand EQMOD exists outside of SGP and the devs can’t be responsible for it. But in my case if SGP had stopped the sequence after half an hour of no user response, this incident would most likely not have happened. The Mount Limits in EQMOD should really be the last line of defense.
I do not believe SGP can “override” the mount limits set in EQMOD. Also, I did not see any reference in the EQ6-r manual to built-in mount limits. The limits in EQMOD are software limits that exist in EQMOD only. You said you were running the laptop on battery power? I’d say the most likely cause of your issue was a communication or power drop from the laptop to the mount. If EQMOD lost communication while the scope was unparked, your limits are no longer valid.
A note about tight clutches : I own a NEQ6 and I too like to tight the clutch like there is no tomorrow. But one telescope mechanic (yup, I’m lucky enough to personnaly know one) says that if it’s very tight it can deform the main gear and worsen any PEC you might have.
Firstable, sorry for the all situation. Hopefully you can get your equipment back in working order soon. This is a bit off topic, but I thought it was worth mentioning. I uses the app GNS (good night system) on my cell. SGP supports GNS and allows different level of monitoring and warnings. I normally leave my setup running all night while I sleep and if anything goes wrong with the secuenses the app sounds an alarm. GNS woke me even when clouds rolled in, GNS will sound the alarm due to tracking star lost. The app is not cheap for what apps cost, but I see it as extra insurance. Also GNS has a trial version.
Were you imaging something in the north that requires a meridian flip at it’s lowest transit?
I’ve found a problem where SGP doesn’t seem to have the programming to flip at this point, it’s a very special case thou of colurse, but can be pretty dangerous.
More than likely this is the cause for the problem and not caused by SGP waiting for user input, it’s hard to say thou because you haven’t provided a log file.
Log files stay for 1 month now and you can find the files by clicking on help and open log folder.
I use EQMOD as well and have set my horizon limits in EQMOD. I have also instructed EQMOD to park the scope should it slew or track to those limits. I have never had an issue - knock on wood - but I have always used the EQMOD limits feature. My goodness…I hate that this happened to your “kit”!!! Good luck on getting what you need so you can return to imaging.
