Qui est doué dans les driver Kstars ??

[ch_porchet]

Petite question ,sûrement bête, mais dans le code il y a un "home" , par contre je trouve pas les entrées du switch .

Ou alors j'ai pas tous compris. 

 

A bientôt 

[olivier1986]

Salut,

 

j'ai pas tout regardé mais le programme m'intéresse un peu

Pour la position home il semblerait qu'il s'agisse d'une position 0° enregistrée et non d'un contact physique.

Je pense donc qu'il faille lancé kstars puis le drivers.

une fois connecté mettre le rotator a la position 0° voulue et effectué une synchronisation du "home" -> la valeur de l'angle sera remise à 0 dans l'EEPROM.

je ne peux pas confirmer à 100% car je ne peux pas faire la manip en ce moment mais c'est ainsi que je fais pour mon moteur de MAP.

 

Olivier

[keymlinux]

Bonjour,

 

@ch_porchet @olivier1986 La vraie roue a filtre Pyxis dispose d'un capteur de positionnement "home" et est capable de trouver sa position home. Si vous fabriquez une roue a filtre perso, vous avez le choix entre:

  - soit implementer un capteur de position home (contacteur physique ou capteur a effet Hall pour detecter la position d'un aimant sur la roue), et dans ce cas il faut implementer du code pour faire tourner la roue et tester l'état du capteur pour positionner sur home

- soit ne pas implementer de capteur, et positionner à la main la roue en position home, puis dans indi, lors de la demande d positionnement home juste répondre que c'est fait.. --> c'est comme cela que c'est implémenté dans le code

[keymlinux]

@Cedric02700 J'ai fait quelques tests sous Widows, et effectivement il y a d'une part un problème dans mon code qui gère les retour de ligne à la mode unix mais pas à la mode Windows..., et d'autre part j'ai découvert des commandes non documentées utilisées par le soft de pilotage fourni par le constructeur du Pyxis.

 

Ce soir je vais livrer un update du code avec les modifs suivantes:

- Gestion des fin de ligne "windows" pour que le soft coté windows reçoive les réponses correctement (pas besoin pour INDI mais nécessaire pour ASCOM)

- Emulation du modèle Pyxis 2 pouces (14 pas par degré) et non pas 3 pouces (128 pas par degré), en envoyant 2.03 comme version de firmware

- Implementation de 3 ordres supplémentaires "perso" pour faciliter le mode débug: DEBUG, EEPROM et HELP

DEBUG pour lister les variables internes et leur contenu sur le port série, EEPROM pour formater l'eeprom avec les valeurs par défaut, HELP pour lister les ordres aceptés par le port série.

- Pour l'ordre "home", dans la doc il est indiqué la commande "CHOMES", tel qu'implémenté dans le driver INDI, mais coté Windows le soft fourni par le constructeur envoi "CHOMEx" --> code adapté pour accepter les 2 syntaxes

- Prise en compte de 2 nouvelles commandes non documentées envoyées par le soft sous Windows

  CFGETS   --> on doit renvoyer la position en "step" sur 5 chiffres (et pas l'angle sur 3 chiffres comme CGETPA)

  Cabcde  --> on reçoit la demande de movement qui spécifie une position en step sur 5 chiffres "abcde" et pas un angle.

  Ces 2 commandes permettent un positionnement avec une précision inférieure au degré (les commandes CGETPA et CPAabc limitent cette précision au degré)

- Implementation d'appel à la fonction "yield()" pour les contrôleurs ESP8266 et ESP32 pour éviter les watchdog reset lors des longs déplacement

- quelques modification cosmétiques et de simplification du code

 

 

 

[Cedric02700]

@keymlinux Ça m'intéresse le codage des fin de ligne à la "mode Windows". 
Je ne sais pas si tu as remarqué mais le driver ASCOM quand il interroge un port série qui ne répond pas au CCLINK, envoi ensuite une commande sous une autre forme entre "<>". A priori ça serai un nouveau protocole mis en place sur les gen3. Les infos sont là:  https://www.optecinc.com/astronomy/catalog/pyxis/resources/Pyxis Command Processing_rev2.pdf 

[keymlinux]

@Cedric02700

1) Concernant le document que tu cites, avec les commandes "gen3", je ne les implémenterais pas car Optec s'oppose explicitement à ce type d'utilisation (bien relire les 2 premiers paragraphes du doc), usage visant à réaliser un contrôleur "concurrent" du leur même si par concurrent il s'agit ici d'un usage non commercial , et c'est leur droit de protéger leur propriété intellectuelle.

2) Pour ce qui est  de l'ancien protocole (celui dont les commandes commencent par "C"), il est documenté publiquement, dans un document où Optec n'exprime pas son opposition à son usage. Ceci étant, bien que je n'en fasse pas un usage commercial Optec pourrait demander à ce que son utilisation pour faire un contrôleur "alternatif" cesse, et dans ce cas je devrais me plier à leur demande.

 

Cordialement

 

[olivier1986]

Merci de ton retour.

Tant qu'il ne font pas explicitement la demande alors nous aurons le loisir d'utiliser ton code

[olivier1986]

@keymlinux

Salut,

 

un petit up savoir si tu as pu avancé sur le code  ?? merci 

[keymlinux]

Le 25/11/2021 à 10:35, olivier1986 a dit :

un petit up savoir si tu as pu avancé sur le code  ?? merci 

Avec un peut de retard, voici le nouveau code

 

Pour rappel, les modifications:

Le 09/11/2021 à 13:17, keymlinux a dit :

- Gestion des fin de ligne "windows" pour que le soft coté windows reçoive les réponses correctement (pas besoin pour INDI mais nécessaire pour ASCOM)

- Emulation du modèle Pyxis 2 pouces (14 pas par degré) et non pas 3 pouces (128 pas par degré), en envoyant 2.03 comme version de firmware

- Implementation de 3 ordres supplémentaires "perso" pour faciliter le mode débug: DEBUG, EEPROM et HELP

DEBUG pour lister les variables internes et leur contenu sur le port série, EEPROM pour formater l'eeprom avec les valeurs par défaut, HELP pour lister les ordres aceptés par le port série.

- Pour l'ordre "home", dans la doc il est indiqué la commande "CHOMES", tel qu'implémenté dans le driver INDI, mais coté Windows le soft fourni par le constructeur envoi "CHOMEx" --> code adapté pour accepter les 2 syntaxes

- Prise en compte de 2 nouvelles commandes non documentées envoyées par le soft sous Windows

  CFGETS   --> on doit renvoyer la position en "step" sur 5 chiffres (et pas l'angle sur 3 chiffres comme CGETPA)

  Cabcde  --> on reçoit la demande de movement qui spécifie une position en step sur 5 chiffres "abcde" et pas un angle.

  Ces 2 commandes permettent un positionnement avec une précision inférieure au degré (les commandes CGETPA et CPAabc limitent cette précision au degré)

- Implementation d'appel à la fonction "yield()" pour les contrôleurs ESP8266 et ESP32 pour éviter les watchdog reset lors des longs déplacement

- quelques modification cosmétiques et de simplification du code

 

SMO-PYXIS-1.1.ino

[olivier1986]

Alors là, sacré boulot

 

merci beaucoup pour ce retour vraiment très très apprécié

 

Olivier

 

PS: une petite erreur de frappe:

à la ligne 79 il manque le "E" dans le texte:  #ifdef SMO_US_ARDUINO

Cela ne crée pas d'erreur à la compilation puisque systématiquement tu sauts à la condition si faux

Modifié 30 novembre 2021 par olivier1986