Bafocus : aide à la MAP automatisée

[Bec à Fuel]

Tu es gentil là, mais ce n'est pas Ascom qui fabrique et vend les interfaces

Si le pilote Ascom ne convient pas c'est tout de même au fabriquant de produire le sien!

S'il n'y a pas Ascom on met tout à la poubelle?!

Je ne conteste pas le fait que le fabricant puisse être en cause dans les dysfonctionnement de son pilote Ascom, évidemment.

 

Mais...

 

Si tu te réfères à la norme pour développer ton driver, alors il faut que cette norme soit claire et cohérente, sinon c'est le bordel. Or, la norme Ascom pour les focusers est loin de l'être...

 

Par exemple, et pour être plus précis, je vais te donner l'exemple de la première propriété à renseigner dans le driver, qui est le fait de savoir si le focuser est absolu ou relatif. Je vais entrer dans le détail, alors ça risque d'être un peu long...

 

Focuser.Absolute (read-only, Boolean)

 

True if the focuser is capable of absolute position; that is, being commanded to a specific step location.

Cela exclut a-priori d'emblée les moteurs CC, d'accord ?

 

Restent les moteurs PàP. Qui dit "position spécifique", dit référentiel au départ : je ne peux pas aller à la position 100 si je ne sais pas où se trouve le 0, par exemple.

Or, sans encodeur absolu, pas moyen de savoir où se trouve ce 0 ! Tu peux effectivement décider que la position actuelle est le 0 et ensuite tu bouges à la position 100. Mais qu'arrive-t-il si tu bouges le moteur à la main ? Tu foires ton référentiel.

Conséquence, ce type de moteur ne peut pas être considéré comme absolu non plus. En apparté, comme exemple d'encodeur absolu, tu as cette monture : http://www.baader-planetarium.de/montierungen/micron/gm2000HPS-preview-en.pdf

Là, c'est du vrai absolu : la position 100 est toujours au même endroit, quels que soient les mouvements effectués, à la main ou non.

 

Donc... si on poursuit le raisonnement, aucun focuser relativement bon marché n'est absolu. Ok. Donc, on renseigne la propriété à "Faux" dans le driver.

 

Là, tu ouvres ton logiciel que tu as éventuellement payé assez cher et tu lances une procédure d'autofocus (vu que c'est pour ça que tu as acheté le logiciel, par exemple). Et là, c'est le drame ! Il ne veut pas faire d'autofocus parce que ton focuser n'est pas un focuser absolu mais relatif

Logique.

 

Bon, tu fais un mail au dev du driver pour qu'il change ça et il le fait. Il dit maintenant que son focuser est absolu. On supposera donc que l'utilisateur ne le touche plus avec ses mains pleines de doigts pour ne pas fausser les positions conservées en mémoire.

 

Tu retournes dans ton logiciel favori et là il est content, il peut faire un autofocus. Joie, bonheur et félicité !

 

Maintenant, il faut définir la position de départ. Où peut-elle se trouver : focuser complètement rentré (ou sorti) ? Pas trop loin de la bonne MAP ?

 

Réponse : A. Obligatoirement ! Pourquoi ? Parce la norme pour la commande Move() (qui déplace le moteur) spécifie ceci :

the Position parameter of the Move() method is an integer between 0 and MaxStep.

C'est à dire : pas de nombre négatif Si ta position 0 était la position de bonne MAP, tu ne pourrais pas descendre le focuser mais seulement le remonter ! C'est cul, hein ?

 

La solution, dans le driver, consiste éventuellement à attribuer un décalage (offset) qui permet de donner une position négative à l'utilisateur alors qu'en interne, tout est positif.

 

Mais interdire les positions négatives interdit aussi les vrais focusers absolus ! Pas de bol. Le serpent se mord la queue.

 

 

Tu vas me dire : "oui, mais là ça marche avec ceci-cela, alors il est où le problème ?" (si, je sens que tu vas me le dire ;-) )

Et ben le truc c'est que le fournisseur du driver fait des compromis à droite à gauche, mais qui ne sont pas forcément du goût de tous les logiciels existants, qui ne supposent pas forcément la même chose... Et donc bien souvent, c'est le logiciel fourni avec le matos qui s'en sort le mieux, même s'il est parfois incomplet.

Ou alors, c'est le programmeur du logiciel client (Prism/Maxim/Astroart, par ex) qui prend "des libertés" par rapport au driver et codent eux-même les trucs délicats. Et du coup, les logiciels réagissent différemment alors qu'ils utilisent le même driver Ascom (*).

 

 

J'ai moi-même programmé plusieurs drivers Ascom pour diverses personnes et différents matériels et ça fonctionne très bien. Mais au prix de contorsions diverses et variées dans le driver, lesquelles sont donc susceptibles à un moment ou un autre de foutre la merde parce que ce sont justement des contorsions.

 

 

Ici c'était un exemple avec le positionnement absolu/relatif, mais le même genre de souci existe avec la compensation de température, par exemple.

 

 

Voilà pourquoi je critique certaines parties de la norme : c'est une très bonne idée à la base mais elle est mal implémentée ensuite. Je signale quand même que je suis loin d'être le seul à faire ces critiques, mais la plupart des autres contradicteurs ont "laissé tomber" vu l'inertie (ou le refus de bouger) de l'équipe Ascom. Maintenant, ils utilisent des logiciels propriétaires et plus Ascom.

 

 

 

Tout ça pour dire que ce qui parait simple au premier abord ne l'est pas forcément quand on commence à fouiller un peu

Quand ça commence "mal" (ou pas très bien), alors c'est plus délicat pour que ça finisse "bien".

 

 

A plus,

________

Christophe

 

 

(*) L'exemple typique de cas est l'utilisation de la compensation de température. La norme précise :

While in temperature tracking mode, Move commands will be rejected by the focuser.

Tu lances Prism, tu paramètres le focuser pour qu'il soit en mode compensation et tu demandes à Prism de bouger le focuser : refus. Normal, c'est exactement le fonctionnement prévu dans ce cas.

Tu lances MaximDL, et lui bouge le focuser ! Quoi ? Il ne respecte pas la norme ? Ben si. Sauf que ce petit malin désactive la compensation avant de commander le mouvement et la rétablit ensuite... C'est pas interdit.

[Bec à Fuel]

Un petit up pour vous signaler une mise à jour vers la version 1.4.0.0 : http://www.lsp-fr.com/astro/bafocus/tmp/bafocus.exe

 

Corrections de plusieurs bugs :

 

• lors de la première utilisation, il n'y a plus de focuser par défaut mais la fenêtre de choix Ascom s'affiche pour sélectionner le focuser
  
• correction du bug "Erreur OLE" lors de l'utilisation du driver Ascom pour les cartes Phidgets 1062
  
• correction d'un autre bug lié à la forme spéciale de ce driver Phidget1062 qui, sous certaines conditions, pouvait donner le contrôle au deuxième moteur de la carte au lieu de rester sur le premier
  

C'est tout pour aujourd'hui

 

 

________

Christophe

Modifié 30 octobre 2010 par Bec à Fuel

[pinx]

 

 

Pinx : qu'est-ce qui n'est pas satisfaisant ? Et avec quel matériel ?

 

 

salut Bec a fuel ... après avoir suivi toute la discussion , je comprends mieux les problématique des développeurs...

 

 

en ce qui concerne mon matos: j'ai un tube 200/1000 ,un moteur Moonlite avec le moteur DC, et le boitier FCUSB shoestring. BAfocus.

 

un imageur EOS 350D défiltré, et une toucam pro 1 modifiée longue pose.

 

particularité depuis quelques mois, ma toucam de guidage est devenue parafocale avec mon EOS grâce a un prisme dans l'EOS.

 

le problème que je rencontre avec BAFOCUS est que malgré tous les essais que j'ai fait, les changement de paramètres et les différents mail que nous avons échangé, et bien je n'arrive toujours pas a faire une MAP automatiques.

 

je tombe toujours a coté.

 

j'arrive a faire une MAP parfaite, sans ton soft,(disque de bathinov) assez rapide, mais je comptait l'utiliser pour suivre le FWHM et lancer une MAP automatique toutes les 20 images par exemple pour affiner celle ci en cas de variation de température...

 

malheureusement inutilisable si je ne peux pas tomber sur la MAP correcte !

[Fred_76]

Up !

 

Quid de BAFocus ? Que devient-il ?

 

Je trouve ce logiciel très intéressant, et j'essaierai de le faire fonctionner avec le module HitecAstro DC Focus sur un PO motorisé JMI NGF quand le ciel sera plus clément. Pour la prise d'images via un APN, il serait bien de contrôler l'arrivée des photos dans un répertoire (comme le fait PHD Max) plutot que de devoir cliquer sur un bouton "continuer".

 

Si le développement est arrêté, peut être que le code pourrait être fourni à Guylain pour intégration dans BYE...

 

A+

 

Fred

Modifié 8 avril 2013 par Fred_76

[Bec à Fuel]

http://webastro.net/forum/showpost.php?p=1062915&postcount=2

 

Le code commence à se faire vieux, je pense. Mais bon, si ça peut servir, alors n'hésitez pas !

 

_______

Christophe