Y a t'il des utilisateur de sequence generator pro? et quel est votre avis?

Parker en position vers la boîte à flats par exemple, ou pour fermer le toit.

Patte.

j'en profite pour m’immiscer dans ce thread et poser ma petite question...

Je teste SGP depuis 2 nuits complètes de setup, j'apprécie l'ergonomie, les possibilités, la fiabilité et le prix... mais j'ai tout de même un point qui me chiffonne : pour le moment, je lancer moi-même la séquence. Mais je prépare ma migration vers mon poste fixe (très distant). Ce que j'aimerais, c'est qu'à une certaine heure, mon PC s'allume (ça c'est facile), lance le cloudwatcher et attende que le ciel soit OK pour lancer une séquence (avec ouverture de toi, cool down de la caméra, auto-focus, plate solving, etc), pour terminer la séquence en flat, warm up de la caméra, park de la monture, fermeture du toit. Pour le moment, je sais faire la partie séquence avec SGP, c'est ultra simple. Par contre, je n'ai aucune idée de comment je peux asservir le lancement de SGP ou d'une séquence à ma météo. Je peux faire un logiciel qui va vérifier le cloudwatcher et dès que c'est OK, lancer SGP, ça c'est facile. Mais comment automatiser le lancement d'une séquence ? C'est un peu dommage de ne pas avoir d'option de ligne de commande ou une API qui permet de gérer le lancement de séquences (elle permet d'autres choses, mais je n'ai pas vu cela)...

Bref, j'aimerais me passer d'acheter une licence de MaximDL (que j'ai pas mal testé et qui est pas mal, soit dit en passant)... ou d'un autre soft assez cher... mais bon, s'il n'y a pas le choix, j'y serai bien contraint...

Merci d'avance de toute aide !

Petite réponse à moi-même au sujet du lancement d'une séquence : on peut ajouter à la ligne de commande de SGP le fichier de la séquence que l'on désire ouvrir et ... au démarrage de SGP, la bonne séquence est ouverte. J'ai demandé s'ils pouvaient aussi ajouter une option pour qu'elle soit exécutée automatiquement, car sans cela, ça n'a pas grande utilité et ils vont le faire (mais quand ? ils ont aussi beaucoup de demandes pour d'autres fonctionnalités !)

Bref, pour le moment : que du bonheur...

Perso je surveille le ciel et c'est moi qui décide en fonction des cartes météo.

Le cloudwatcher est capable de faire des prévisions sur la nuit?

Parce que lancer une séquence juste avant un passage nuageux...

Puis, je préfère le semi-automatique pour raisons de sécurité.

J'ai vu trop de couilles avec des fermetures quand le scope n'est pas parqué (par exemple). Le nombre de soucis augmente considérablement avec l'automatisation (surtout s'il y a de l'USB).

Bref, je suis plus à l'aise en lançant ma séquence manuellement.

Patte.

je ne pensais pas à la lancer avant un passage nuageux, mais je prenais le cas de figure d'un passage nuageux qui arrive de manière imprévisible pendant la nuit... et j'aurais voulu éviter de perdre le reste de la nuit.

Deuxième cas de figure : lancer une séquence si je suis absent et que la météo le permet... (pas les prévisions, juste le ciel en direct)... j'ai lu quelques personnes ayant ce genre de setup et je me disais que ça pourrait être sympa de ne pas perdre de nuit quand je ne suis pas disponible pour lancer une séquence qui aurait été paramétrée à l'avance...

Salut,

je suis en direct en train de tester SGP et la ma sequence ce bloque au niveau de l'autoguidage,

en gros le plate solve avec platesolve2 ce passe bien puis est ecrit en bas a gauche "resuming the auto guider" phd 2 est bien en train de guider pourtant ...

la je seche!!

a vos lumieres msieurs dames!

merci pulsar voila une bonne piste !! j'avais laissé le reglage par defaut: doonc settle inf a 0.1 pixel :b:

et 10 s et la case FOR devant le temps decoché!!!

Bonjour,

Je test SGP et je rencontre le même problème.

1) j'ai crée un equipement profile avec les mauvais paramètres dans auto guide (0.1 Settle at)

2) j'ai crée une séquence

3) quand je l'ai exécuté j'ai rencontré le blocage.

4) j'ai modifié les paramètres dans l'equipement profile (pour testé j'ai mis 2.5 px et 1s)

5) toujours le problème, je ne suis pas sur que les nouveaux paramètres soient pris en compte.

Faut-il modifier les paramètres dans la séquence ? mais ou ?

Faut-il que je recrée un séquence ?

En haut dans le titre de la sequence, je vois bien le lenom.sgf (le nom de l'equipement profile).

Des idées ?

Merci

Si tu as modifié le profil équipement sans modifier la séquence c'est normal.

Soit tu recrées ta séquence en utilisant ton profil modifié, soit tu modifies ta séquence en direct live avec le Control Panel (onglet AutoGuider)

Si tu as modifié le profil équipement sans modifier la séquence c'est normal.

Soit tu recrées ta séquence en utilisant ton profil modifié, soit tu modifies ta séquence en direct live avec le Control Panel (onglet AutoGuider)

J'en profite , y-a-t-il une option pour qu'il ne génère pas une séquence au lancement du programme ?

Pas à ma connaissance

Après tout il est fait pour gérer... des séquences

En quoi le fait qu'il ouvre une séquence vierge te dérange-t'il ?

On peut ouvrir une séquence dépucelée, voire page 98:

http://mainsequencesoftware.com/content/Sequence%20Generator%20Pro.pdf

Patte.

Bonjour,

j'ai testé SGP avant-hier pour la première fois, et après avoir seulement lu ce topic j'ai à peu près réussi à tout faire marcher, il est vraiment cool ce programme

Pour PHD2 j'ai mis qu'il reprenne les photos quand le guidage descend en dessous de 2,5 pixels pendant 10 secondes. Mais que ce passe-t-il si les conditions se sont dégradées et qu'on ne retombe jamais en dessous de la tolérance? Est-ce que la séquence va se terminer un jour ou il va continuer jusqu'à taper dans le mur?

Pour l'autofocus, j'ai un moteur à courant continu, donc j'ai un backlash assez important... Ma courbe en V ne ressemble pas vraiment à un V. Est-ce qu'il y a des choses à paramétrer quelque part?

Et finalement, j'aimerais bien qu'il gère le toit de mon abri.

Il est commandé par une carte arduino, en envoyant la lettre "a" sur le port série ça ouvre le toit, et en envoyant la lettre "b" ça le ferme. J'ai écrit un petit programme dans Visual C++ pour faire ça mais je n'y connais pas grand chose de plus. J'ai un peu regardé pour faire un driver ASCOM correspondant mais ça a l'air d'être une vraie usine à gaz...

Vous ne connaitriez pas un endroit où je peux trouver un exemple de driver ascom pour dialoguer avec une carte arduino, le plus simple possible dans lequel je pourrais simplement ajouter mes deux boutons d'ouverture et fermeture?

Ah oui, un autre truc aussi,

Est-ce que SGP peut arrêter l'ordinateur une fois qu'il a terminé toutes les séquences? Ça serait bien pratique

Salut Romain

Pour éteindre ton ordi en fin de séquence, tu peux utiliser un petit script VBS avec le contenu suivant :

Dim oShell

Set oShell = CreateObject("WScript.Shell")

oShell.run ("shutdown -s -f -t 00")

Tu copies ces 3 lignes dans un éditeur de texte (Bloc-notes ou autre). Tu enregistres le fichier (ex : "Arrêt PC") et tu changes l'extension . txt par .vbs

Tu sélectionnes ce script dans le champ "Run script" situé en Post-Event Options de ton dernier événement. Tu coches la case "Run script".

J'ai lancé le script en direct sur un windows XP (double-clic souris), ça fonctionne. Par contre, je ne l'ai pas testé avec SGP, mais il n'y a pas de raison que ça ne marche pas car j'ai déjà utilisé d'autres scripts vbs sans problème avec SGP.

A priori, la commande shutdown fonctionne sous XP, Vista, Seven et 8.

Quelques explications sur la commande shutdown :

• "-s" : correspond à l'arrêt du PC. -r à la place, redémarre le PC.
  
• "-f" : permet de forcer la fermeture des applications en service.
  
• "t 00" : temporisation de l'action (mise à l'arrêt ou redémarrage). Cette valeur est exprimée en secondes.

Si tu utilises une caméra avec un système de refroidissement, il faut ajouter une temporisation qui permet à SGP de gérer la remontée en température en fin de séquence.

Il suffit de modifier la valeur t 00 en mettant une durée suffisante pour que la remontée en température s'effectue. Exemple : t 600 pour une temporisation de 10 minutes.

Ce qui donne au final, donne le script suivant :

Dim oShell

Set oShell = CreateObject("WScript.Shell")

oShell.run ("shutdown -s -f -t 600")

Essaies d'abord avec une durée de 5 secondes (t 5) pour voir si tout se passe comme prévu.

Bon amusement

Jean-Pierre

Salut

C'est parfait, merci!

Je connaissais la commande mais je ne savais pas que c'était ça ces fameux scripts vbs

Un problème de moins!

Maintenant faut que je réussisse à faire ce driver ascom pour le toit et et je serai à peu près prêt pour des nuits pratiquement automatisées

Au fait, pourquoi te faut-il un driver ascom pour le toit ?

Parce qu'on peut le connecter dans Sequence Generator Pro, alors autant tout automatiser au même endroit

À moins qu'il y ait d'autres solutions pour le connecter sans passer par ascom?

Actuellement, qu'est-ce que tu utilises comme système de pilotage pour les manoeuvres de ton toit ? Sur ton site perso, j'ai vu que tu utilises un téléphone pour déclencher les mouvements. Mais quelle électronique as tu mis en oeuvre (carte relais USB, carte relais ethernet, arduino, ...) ?

Je l'ai écrit dans le premier post sur cette page, mais comme j'en ai écrit deux d'un coup t'as du voir que le deuxième

C'est une carte arduino avec un gros shield moteur et un moteur d'essuie glace

La carte est branchée en usb sur l'ordi et avec un petit programme que j'ai écrit dans Vusual basic, j'envoie la lettre "a" sur le port série pour ouvrir et "b" pour fermer (et "c" pour l’arrêt d'urgence)

Effectivement, je n'avais pas lu le contenu du premier message sur cette page

Pour la manoeuvre du toit, je vois 2 solutions pour t'éviter d'écrire un driver Ascom :

1 - Si ton programme de pilotage est un .exe, il est normalement possible de le lancer via un script VBS.

2 - Si le programme est écrit en VB, il doit être possible de le traduire en VBS.

Si tu es d'accord, je t'envoie mon mail perso en MP pour que tu me transmettes ton programme en VB de manière à ce que je regarde si j'arriverais à le traduire en VBS.

En lisant ton 1er message de la page, tu dis avoir une courbe en V qui n'a pas trop la forme d'un V.

Vu que le processus de mesure se fait dans le même sens, j'imagine qu'il y a juste le début de la courbe qui doit être chaotique, le temps que le jeu dans la motorisation du focuseur soit repris.

En plus, si les pas (Step Size) entre 2 mesures sont trop faibles, la mesure de la HFR peut ne pas être probante.

Essaies avec une valeur de pas plus importante et un nombre de pas (Auto Focus Data Points) permettant à SGP de s'affranchir des premiers pas "foireux".

Aux extrémités de la courbe, il faut voir les étoiles bien défocalisées, mais pas trop. Au début, je me disais qu'en mettant des pas de faible valeur, j'obtiendrais une précision importante. Ce n'est pas le cas car la mesure de la HFR entre 2 pas n'est pas significative. J'ai augmenté la valeur des pas, et mes courbes ont bien une forme de V.

Il faut également démarrer le processus en ayant une mise au point proche de ce qui est nécessaire, cela évite à SGP de s'y reprendre à plusieurs fois pour trouver la bonne plage de mesure, chose qui peut arriver également si la valeur des pas est trop faible.

Hello,

perso je pense aussi qu'il est plus simple de piloter ton toit via script vbs... si tu regardes la définition standard des pilotes ascom pour toit, tu verras qu'ils sont prévus essentiellement pour des domes et qu'un toit ouvrant est considéré comme un shutter de dôme. Dans l'absolu, ce n'est pas grave, mais par contre, cela signifie que tu ne sais pas avoir d'ouverture intermédiaire... par exemple, moi j'ouvre le toit à 40% pour balancer la température environs 1h avant le début de ma session... j'ai un driver ascom pour le toit ouvvrant mais je ne l'utilise pas à ce moment-là car il ne sait pas faire cela... tandis que le programme qui gère le toit ouvrant, lui, sait très bien le faire... donc, pour moi, le driver ascom pour toit ouvrant n'apporte vraiment rien si tu as déjà un programme qui gère bien cela...

Ah, beaucoup de choses intéressantes

Avec 7 points de mesure c'était un gros W la courbe

Tu dis que ça fait les mesures toujours dans le même sens? Il ne faut pas être parfaitement au point quand on commence alors, sinon il n'explorera pas les deux côtés du focus, non?

Et une fois qu'il a tracé la courbe et dépassé la mise au point, il revient en arrière au HFR minimum c'est ça?

Dans ce cas comment il gère le jeu dans le changement de sens de rotation?

Mon programme n'est pas exceptionnel, c'est juste "ouvrir" et "fermer" ça joue sur la temporisation, il ne peut pas savoir dans quelle position il est.

(mais j'essaierai d'ajouter des capteurs de fin de course quand même)

Du coup c'est vrai que je peux faire un script VBS pour faire ça aussi! C'est un .exe mon programme, et je peux en faire un autre encore plus simple juste pour fermer

Je vais te l'envoyer Discret68 si tu veux me dire ce que t'en penses

Par contre j'aimerais bien tenter le driver ascom aussi, comme ça je peux le connecter dans SQP et ça me fait moins de choses à ouvrir

TeBilePas, peut être que ton driver peut me suffire, t'as fait ça comment? Il controle une carte arduino? Tu peux me le montrer?

Je ne vais pas pouvoir t'aider sur ce coup-là, c'est un driver tout fait reçu avec le contrôleur de toit : un Talon6. Je ne sais même pas te l'envoyer, il a été directement installé sur le PC de l'observatoire (le système de contrôle de l'ouverture de toit faisait partie de l'observatoire, ce n'est donc pas moi qui ai fait le choix / géré son installation).

Ceci dit, il comporte des capteurs de fin de course des 2 côtés et comme c'est un moteur pas à pas, une fois calibré il est assez précis sur l'emplacement du toit.

Sinon, concevoir le driver ASCOM n'est pas très compliqué, l'interface est assez limitée et tu n'implémentera que 2 méthodes, en définitive : ouvrir et fermer (il n'y a rien d'autre exploitable pour un toit ouvrant), qui seront en gros des wrappers appelant ton exe, j'imagine. La seule chose à laquelle il faut être attentif, c'est la manière de faire le binding du driver (late binding si mes souvenirs sont bons), et donner l'info nécessaire pour que ton driver apparaisse bien dans l'énumérateur... mais je ne suis pas expert en la matière, j'avais juste regardé quand j'ai voulu écrire un driver pour ma vieille CCD Orion SSDSI2...

Perso, pour le moment, je poursuis la paramétrisation de SGP et pour le moment ça marche plutôt bien... J'ai paramétré l'autofocus hier soir et ce matin, il me semble que tout a fonctionné (mais bon, faudra que je vérifie les logs et les brutes plus en détails). Changement de cibles pendant la nuit, recentrage avec plate solving, recalibration automatique de PHD2 au changement de cible, changement de filtres, utilisation d'heures limites pour les cibles afin de m'assurer que les cibles sont dans les limites de l'espace dans lequel je veux imager, bref, c'est pas encore finalisé, mais c'est pas mal...

Bonne chance et bon amusement,

Mike

@ XILI

7 points de mesure me paraissent insuffisants, surtout si tu as du backlash au niveau de ton focuser.

En ce qui me concerne, j'ai 13 points de mesure (soit 12 intervalles). Lorsque que SGP fait un auto-focus, il place le focuser dans une position extrême correspondant au nombre de points/2 x valeur du pas. Chez moi, SGP sort le focuser, puis fait tous ses points de mesure en rentrant le focuser.

La répartition des points de mesure étant symétrique par rapport à la position de départ, il est préférable de lancer l'auto-focus à partir du moment où la MAP est proche de la "vérité".

Ce qui me donne, avec 13 points de mesure et un pas de 20, si mon focuser est à la position 3000 (MAP pratiquement bonne), le focuseur se place à la position 3120 et revient progressivement jusqu'à la position 2880.

Une fois que la course totale est faite, SGP calcule le points idéal de MAP et positionne le focuser à la cote déterminée. Par contre, vu que j'ai un backlash proche de zéro, je n'ai pas fait attention si SGP sort le focuser au delà du point de MAP et le ramène au point de MAP pour compenser le backlash.

Je pense que SGP réalise cette action lorsque tu précises une valeur de backlash dans la fenêtre prévue à cet effet (accessible par le bouton "Other" dans l'onglet "Focus").

Dans la bulle d'aide en passant la souris sur le terme "Focuseur backlash compensation", il est précisé que la valeur du backlash n'a pas besoin d'être précise mais supérieure à la valeur réelle du backlash. Je présume que SGP va déplacer le focuser d'une valeur supérieure à la valeur indiquée, pour revenir ensuite à la cote réelle. Le sens de compensation est à déterminer en fonction du sens de déplacement du focuser durant le tracé de la courbe.

Quelques tests en réel devraient te permettre d'améliorer la réalisation de la MAP. Comme dit précédemment, il peut être aussi nécessaire d'augmenter la valeur du pas, de manière à obtenir une différence avérée de HFR entre 2 photos.

Perso, j'ai suivi la formule indiquée dans l'aide de SGP pour déterminer la valeur d'un pas (j'ai pris la valeur maximum de la fourchette) et c'est nickel avec 9 pas...

Au lieu de créer un Nième pst , je préfère continuer sur celui ci:

Problème pendant le retournement au méridien avec SGP et PHD2 .

Le retournement ce fait correctement , le "recentrage aussi " , PHD2 redémarre , mais progressivement la courbe en DEC dérive j'usqu'a ne plus guider.

J' ai surveillé la manip , pas de cable coincé ou autre pb mécanique ( peut être un optique voir plus bas ). En cliquant juste sur inversion de calib dans SGP ( module auto guide) : elle part dans l'autre sens ...J'ai donc refait une nouvelle calibration de PHD2 et le guidage a pu se dérouler normalement jusqu'au bout .

Quelles options cochez vous dans PHD et SGP pour automatiser le processus ?

J'ai coché dans les options de retournement: " auto center after meridian flip " et "re calibrate after target change " dans le panneau auto guide.

Dans le cerveau du soft PHD2 j'ai coché " inversé en DEC apres retournement"

Il y a t il une option que je n'ai pas trouvé pour déclencher un re calibrage auto de PHD2 , ou une simple inversion de calibration suffit ?

Je me suis rendu compte que pendant cette soirée que mes étoiles se déformaient progressivement malgré une bonne collimation initiale. En fait mon miroir bougeait de 2-3 mm en latérale , a force de ne pas vouloir le contraindre je l'ai trop libéré. Est-ce une explication possible a mes problèmes au retournement?

Bon ciel,

Salut,

C'est dingue: Quelle que soit la recherche que je fais sur google à propos d'astro, je finis par revenir sur WA... (d'ailleurs c'est étrange mais les recherches internes sur le forum par mot clef sont assez inefficaces, par contre google connaît parfaitement nos archives!).

Je pointe donc ce sujet pour y revenir facilement car je suis proche du moment du choix d'un log pour piloter ma future cam N&B.

Une question qui me tracasse (je rois avoir  la réponse pais je veux être certain): avec Plate solve 2, en chargeant les catalogues on n'a plus besoin d'internet ?, C'est bien ça?

C'est important en nomade mais aussi dans mon jardin ou j'ai pas de réseau...

J'ai téléchargé le mode d'emploi mis en lien par SyncoPate.

Merci, je l'attaque demain! 

JM

Non plus besoin.

Attention, en général on utilise Astrometry.net en secours si Platesolve plante, donc il faut aussi charger les catalogues pour Astrometry.net et l'installer en local (je sais plus si c'est les mêmes catalogues...).

Après ça, on n'a plus jamais besoin d'Internet.

@Pulsar59

Merci Pulsar, j'ai la réponse à ma question!

Donc on charge en local les deux Platesolve et astrometry.net avec leurs catalogues.

Je sens que je vais m’intéresser aux SSD externes pour mon pauvre petit NUCi3 qui pilote le set up !  🙂

Va y avoir du volume de data à faire circuler.