The past two evenings I’ve had problems with imaging after successful meridian flips. After the flip, the confirm slew to the plate solved image causes the program to freeze. The problem can be seen at 4:15 AM on Sept. 28th. Here’s the log: Login - Dropbox. Thanks for any help…Gunny
PS I should add that I am using the 10 u mount and I did notice on the hand controller the symbol for tracking limit being reached. This has never happened before, and it stops the mount from moving further. I have flip slew tolerance set to 3 degrees and flip guide tolerance set to 5 degrees. Auto meridian flip is ON, along with auto center in SGP. Day time testing shows no problems with being able to do the flip. This is also confirmed by last nights log.
If you check the log, you"ll see that the flip is occurring. It’s the slew after the flip (to confirm the plate solve image) that causes the mount to stop tracking. This then prevents the centering after the flip. I’m using 2.5.1.17 version…Thanks
Since I can’t figure out what is going on here with the mount and SGP, I was wanting to know if an uninstall/ re-install would be a good idea? Things were working fine for over two months, so maybe the driver got corrupted.
My concern about doing this is the limit of three downloads for this program. If it is done for use on the same computer does that count as strike two?
Logs have been sent to SGP and 10U. Have the developers at SGP looked at them yet?
At this point things are pointing to SGP. As I stated in this post, all was working with maxim and this problem has been referenced by another SGP user. So I’m not the only guy who has experienced this…
BTW, will I be able to reinstall without using up the 3 download limit? What email address do I reference the dropbox to for Ken or Jared?
Last night I managed to quickly test auto-centring with the latest SGP beta 2.5.2.1 and the latest 10 Micron beta firmware 2.14.4 (just noticed a new update 2.14.6 this morning). All worked as expected.
As a recap: I had found with the previous SGP beta and my new W10 pc using 2.14.4 10 Micron firmare that SGP had froze and the 10 Micron firmware had reported ‘lock clutches’ and stopped tracking/slewing during auto-centring. Only a re-boot of the PC would free the software. All had worked fine with these versions on my W7 laptop before it died. Logs for this are on dropbox here (I hope I have the correct logs Ken/Jared):
Last night I slewed to my target, auto-focused and then did an auto-centre. All worked without freezing and was succesfully concluded and I then captured a sub before pausing/quiting the sequence and closing down with cloud. I do not think that the mount slewed after the plate solving position as my goto slew was accurate enough and within the tolerance (but I’m not absolutley sure, not paying sufficient attention to the position read out, sorry). Nevertheless, all worked as expected. Log here:
I will also post the mount log to 10 Micron as well as carrying out another test of this when I’m next out (possibly tonight if weather holds) but from a mount position outside of my auto-centring tolerance (20 px) to generate a noticeable slew.
My result is contrary to my expectation from reading Gunny’s post however I hope the log posts help. I have a QSI ccd and Gunny a SBIG, W7 vs W10 pc but don’t know if these differences are of any significance.
Point one of your post, hopefully this link will work: Dropbox - File Deleted. Problem is demonstrated starting about 9:04-9:12 on the log. Here is another log from a previous session with the same problem: Dropbox - File Deleted
Point two: I’m not sure either, except last night I was able to manually center the DSO with no problems. I tried several auto meridian flips last night on various objects and all failed when it got to the point of “Auto Center” after the flip. When I UNCHECKED “auto center” under the auto meridian flip option, the meridian flips worked without fail for several tries at various objects. Funny thing about all of this is that I can manually center an object by clicking on the imaging object and clicking center now (after a meridian flip with auto center unchecked . All works with plate solve and centering the object, and it looks the same as the routine used under “auto meridian flip”.
Disregard points 3-4.
I did get some screen shots if you think that would help. The problem I’m describing is the same as described by Barry Wilson: I can confirm that the auto-meridian flip options work with the suggested settings on the 10 Micron Forum and firmware 2.14.4. In SGP I tick the ‘wait until meridian’ option and all works.
Gunny - I do have one issue though and I’m not sure if this is related to the same problem others have reported about auto-centre hanging, but I am not able to carry out an auto-centre. Whenever I try this the mount throws a ‘lock clutches’ error and stops tracking. The ccd image doesn’t download and SGP freezes and needs to be re-started. I use Per’s ascom driver and have the ‘Use J2000 (convert on fly)’ option, have a QSI683 ccd. It all worked fine on my W7 laptop but I switched to a new W10 pc 2 weeks ago and now it won’t work. I have .NET framework 3 and 4 enabled on the new pc. So puzzled why simply changing from W7 to W10 would cause a problem.
I take it you have no problem with auto-centre as I recall you have this option set after a meridian flip?
Barry
Barry seems to have fixed his problem, but neither of us have a clue as to why, since both of our mounts have the same auto flip settings…Gunny
[10/2/2016 9:11:12 PM] [DEBUG] [Main Thread] Centering: User abort…
Inferring a problem with what is not there vs what is, we expect to see this next:
Scope reports it is done with synchronous slew, verifying…
But we don’t… we get no response from the mount after asking it to slew to that location. The only recourse at this time is to try and reproduce the error with SGPro 2.5.2.2 and submit that log along with the 10U ASCOM logs that cover that same period of time. We need to see what the mount is doing…
As a note, the above text applies only to the first log linked. The other log failed for a completely different set of reasons:
Plate solve failed (maybe because location hint was not accurate enough after the flip)
One thing I am noticing in the logs is the PHD listening thread where PHD is not reporting anything coming from PHD socket. Tonight I’m having the same problems. Looking at the bottom left corner of PHD2 is showing that PHD is stopped. I’ll send a screen shot later. Manual auto centering is working after auto pier flips with auto center turned off. It is at step 3 of centering telescope that things go bad for auto centering.
I don’t think the 10u logs would help you as they are encrypted, so there is nothing that the user can gleen from the log…bad idea in my opinion, but it’s the way they do things.
The latest I’ve heard from 10U is that there maybe a timing issue with two commands going to the mount at about the same time. Filippo at 10U reported the following:
"It seems related to a situation where two commands arrive in a very short amount of time, one for synchronizing the position and another for adjusting the mount clock.
We are going to reproduce it in “laboratory conditions” with the same sequence of commands, so that we can debug it - sorry for letting you wait."
I will update as time goes on, in case others with the 10U mounts experience similar problems…Gunny
Here is one of the logs from the 10 Micron 2000hps mount. This was obtained thru Per’s ascom driver and is not the log from the 10 Micron encrypted files. I updated as you suggested 2.5.2.2 and still have the problem. I will get the log from the SGP file as soon as the mount is shut down.
I’ve included the SGP log of the failed telescope centering routine after the meridian flipl Could this possibly have anything to do with the on the fly conversion from J2000 to JNOW?. 10U is still investigating but they have noted that two sync signals are being sent to the mount at the same time…Gunny
I wish I knew more about these mounts. Hopefully Jared/Ken can throw more light on it.