Same configuration, didn’t work except on some occasions. Tried 3 different PCs.
Tried the sky 6 last version, the sky X which was on one of the PCs (from 2012), then the last version of the sky X, and it was still doing its things.
What do you want me to tell you…
De : ap-gto@... [mailto:ap-gto@...]
Envoyé : jeudi 22 mai 2014 21:54
À : ap-gto@...
Objet : Re: [ap-gto] Re: software
Ap1600, Win7 64 bit, Sky 6 and Maxim. All integrated with the AP Ascom Driver. Works perfectly, never gets lost, never goes anywhere except where it's sent. All in a remote observatory automated with CCD Commander. I sleep thru most sessions and the 1600 always works perfectly.
On 5/22/2014 5:03 PM, 'Alain Maury' amaury@... [ap-gto] wrote:
The first mount, the AP1200 (which works) is under XP (since it has been there since 2009), and under the sky 6, under “telescope setup” it works with “Astro-Physics GTO German Equatorial Mount” which is a driver they have been using since then. With the AP1600, with a PC under windows 7 64 bits, the sky 6 and Ray Gralak’s ASCOM driver, we had a lot of very weird behavior, with the sky 6 not reading coordinates, and considering them as 0, +90°, or with the coordinates wandering around (while the coordinates on the ascom driver windows were stable and correct. This is the only thing I can tell. With the sky X we still had problems (same mount, same ascom driver,) with prism, it now works correctly. And mine (without encoders) does work like a charm with prism too. I agree the encoders are not the problem, but there is clearly some software issues between the current driver and “the sky” whatever version, here at least.
I have an AP1200 mount which works with the sky 6, but with the AP1600, we had quite a lot of problems with it.
There is zero difference between 1200 and 1600 mount. They both use the same exact electronics. There is no reason why the Sky6 should work any differently with either mount. In the recent case of the mount pointing straight down, the mount was GIVEN these co-ordinates and followed them to this position, as it must do when commanded by outside software. The mount was not lost at that point, and would easily have gone to any other commanded position, if told to do so.
Please note: The absolute encoders are NOT used to control the slewing functions. They are always in the background to adjust the accuracy of the main motor encoders and play no part whatsoever during slewing. They act only on the arc second level to adjust the sidereal tracking rates or the custom tracking rates on the two axes. They also establish the home positions and the limits for the telescope - if the operator chooses to set them and use them.
The absolute encoders immediately step out of the way when the mount gets a signal to move from a guide software, or a signal to move from centering or slewing to another part of the sky. As soon as the mount axes have finished moving, then the encoder electronics compares this new position to the exact commanded position from the external command, and adjusts it on a microscopic arc second level. NEVER does the absolute encoder circuit take over any move or slew command, it is basically in the background 99.9% of the time. It's only in the last few arc seconds that the absolute encoder commands any movement of the servos.
The reason we did this is to provide a double layer of safety to the system, so that if anything should go wrong with the electronics of the encoder, or the encoder should fail, then it is simply disregarded by the servo, and the mount is still fully functional. Never would a failure of the encoder cause any strange slewing. You can prove this to yourself by slewing the mount across the sky and while the motors are moving, simply remove power from the encoder box. You will see that nothing whatsoever will change in the slewing response of the mount.
I hope that you will take the time to understand what I have written above. I hope that this will allow you to better track down any software problems, instead of simply thinking that the AP encoders (or the new mounts) do not work with various software. I know full well when trying to troubleshoot a problem, it is tempting to always look at the biggest most central part and assign cause and effect, however, that is very much like chasing red herrings down blind alleys. It does not lead to a proper answer.
From: 'Alain Maury' amaury@... [ap-gto] <ap-gto@...>
To: ap-gto <ap-gto@...>
Sent: Thu, May 22, 2014 12:42 pm
Subject: RE: [ap-gto] Re: software
Well I guess if you want to know where you images have been taken, you will have to invest a bit in software. CCDOps clearly does not have any means of knowing where the telescope is pointed. It can “move the mount” for guiding, but does not really interface with the mount’s driver to know where it is in the sky. Same for Carte du Ciel, it can also move the mount, but does not interface with the image acquisition software. These are very basic software if you intend to use your mount with them, you are bound to get into this type of problems.
If you bought a sbig camera, you should have a demo version of the sky 5. Which I believe with some luck you could upgrade to the sky 6. I have an AP1200 mount which works with the sky 6, but with the AP1600, we had quite a lot of problems with it. Then CCDsoft (also free with a SBIG camera) and the sky 6, if it works with your mount, should get you the coordinates of the images in the header. Both software are not supported by Bisque since quite a long time. Other than that, it’s not shocking, if you paid a mount thousands of dollars to spend hundreds of dollars into some software allowing you to use the mount… (my point of view anyway, the light version of prism, allowing to take image, autoguide, focus, point the telescope, get the coordinates in the image header is 99 dollars…).
Thanks for the offer, Alain,
But, I’m OK. Just wanted to see if I could get the Elbrus plate solver integrated and working. The AP ASCOM driver talks to Cartes, and to the STL-11000. CCDSoft and CCDOPs get images, and can control the AP-900 with the relay port and I assume the SBIG’s USB port as well, using the standard Meade Command protocol. Never had any problems, except power fail recovery, with this config.
I will do a bit more testing to see which of these three is not passing coordinates to the FITS header. Seems that although CCDOPs & CCDSoft can control the AP mount by operator manual slew commands to the mount’s guiding port, and I assume the SBIG USB port as well, they may not be “ASKING” the ASCOM driver for where it is positioned (one one-way communication only ?) – Thus coordinates are missing in the CCDOps/Soft saved file header, so Elbrus can’t work “automatically” as a Plate Solver with this particular setup.
It just seemed very odd that SBIG software, jointly with Software Bisque, did not (always), automatically get coordinates. Maybe Cartes Du Ciel is the weak link – it is ONLY a planetarium program, with no CCD command linkage. Really, of the three components – CCD, Mount, and the Astro Application – the app should be the “central control authority”, and should be passing the “common set” of coordinates to everything that needs it.
I will try The Sky, and other planetarium programs to see if my suspicion is correct.
True weapons safety is between the ears.