Driver ASCOM avec arduino nouvelle version!!

[Raphael_OD]

Le 17/01/2024 à 10:43, astrolivier a dit :

J'ai repris à 0 le driver dans VS 2022 pour ne pas utiliser les templates 2022 mais les anciens de 2019.

Le code est toujours en C# mais le driver ne contient que le fichier ObservingConditions.cs

J'ai ensuité appliqué à la lettre la procédure du ReadMe.

J'ai donc compiler la solution, sans erreur puis j'ai ajouté dans la solution un nouveau projet pour le client.

J'ai ensuite demandé que ce projet soit definit en tant que projet de démarrage.

J'ai recompilé et sans erreur pour les deux.

Bon, je n'ai pas modifieé le client pour y afficher des valeurs pour le moment.

J'ai lancé NINA et mon driver apparait bien dedans.

Je me connecte et cela fonctionne. Bon, normal j'ai aucune données qui s'affiche.

 

Hello @astrolivier@Antiath
Perso je viens de me taper tout le site ASCOM je vois beaucoup de changement depuis 2021 ce qui m'oblige à passer en C après avoir fait un driver SQM Observing Condition et switch sous VB rapidement et fonctionnels. Bref je ne vais pas causer de la philo des dev ASCOM avec qui on fait table rase du VB demerdez vous avec Alpaca ou l'implantation d'un serveur en C : etc ... nous on s'en fout  bref je migre !!!

Ce que je cite ci dessus ne fonctionne pas sous VB2022 et les 3 templates C# ASCOM fraichement installés de mon coté.

Je crée bien un  ASCOM Plateforme 7 Driver exe based singleton (ex Safety Monitor)

 

Je défini le nom l'emplacement etc ...

 

puis ça correctement

 

 

 

Le projet est bien crée avec son arborescence.

J'attache ensuite une ASCOM Form au Driver.

 

Et bien je me retrouve en ayant défini Ma Form ASCOM comme fichier de démarrage avec une erreur NET.Framework 4.0 introuvable ! cette version est obsolète...depuis pas mal de temps

 

Ma question @astrolivier comment utilises tu les templates 2019 ? 

J'ai l'erreur de Framework bien sur je ne peux pas tester avec NINA 

 

Venant de VB et python et Tcl/Tk grande est ma déception de me taper du C abandonné depuis les études

Mes drivers VB fonctionnent bien mais pour les montées en version ça va pas le faire.

Merci de votre aide si vous passez par là pendant les vacances en attendant je prends la pelle je creuse .

 

 

 

 

 

Modifié 28 juillet par Raphael_OD

[Raphael_OD]

Bon un peu de progression : je post ici ça peut servir

 

Ayant crée mon ASCOM Plateforme 7 Driver exe based singleton (ex Observing Conditions)

 

J'ai fait les vérifications d'usage du ReadMe : cliquez droit sur le nom du driver dans l'explorateur puis propriétés

 

- Veillez a ce que les Options de la rubrique Build soient bien en AnyCPU et X86 , le serveur est selon le Readme capable de switcher dans le bon mode.

- Dans la rubrique applications vérifier le nom de l'assembly et l'espace de nom (par défaut tout est correct normalement)

- Faire une génération du projet sans erreur sous VS2022 sans l'executer.
- Se rendre dans le dossier de sauvegarde du projet sous WINDOWS puis dans ../bin/Debug localiser l'EXE du projet ASCOM.XXXX.exe 

- Ouvrir une fenêtre CMD ligne de commande en temps qu'administrateur : puis taper sous /Debug 
ASCOM.XXXX.exe /regserver ce qui permet une fois et une seule  sur un PC d’enregistrer votre serveur facile non ! 😒

 

On ouvre ensuite soit une application cliente ASCOM (NINA) soit  ASCOM Diagnostics et miracle on peut voir son driver.

 

Exemple ci dessous d'un driver "blanc" Observing Conditions

 

 

 

Confirmation en connectant les deux applications : NINA et ASCOM Diagnostics deux connections concurrentes sont possibles en même temps.

 

Modifié 28 juillet par Raphael_OD

[Antiath]

Haha, je suis aussi en train de développer un nouveau driver ASCOM en ce moment. Heureusement je suis habitué au C# ( et pas au C 😅, la distinction est importante)  donc c'est moins douloureux  mais ouai je n'ai pas particulièrement apprécié non plus les derniers changements effectués sur la chaine d'outils  d'ASCOM depuis la version 7. Je n'ai pas de soucis en soi avec ALPACA, c'est très bien comme initiative parce qu'ils continuent de supporter le développement de drivers pour Windows. Par contre l'abandon des drivers DLL classiques pour ne supporter plus que les drivers à serveur local... Je trouve cela vraiment très mal avisé...ça rajoute de la friction supplémentaire au développement de petits drivers simples qui n'ont pas besoin des fonctionnalités d'un serveur local. Bref.

Je vois que tu as finalement résolu tes soucis mais je me permet quand même quelques conseils:

1)  si ce n'est pas déjà fait, passe en .NET framework 4.8 minimum.

2) pour débugger le driver, normalement avec un driver DLL tu devais dire au débuggeur quel executable lancer, typiquement tu ajoutais un client ASCOM à la solution pour ça et comme ça tu pouvais mettre des breakpoint dans ton driver. Pour le serveur local c'est un peu différent, tu n'as pas besoin de rajouter de client dans la solution. Le serveur/driver lui même est l'exécutable que le débuggeur pointera. Donc après avoir build la solution, et fait cette petite étape dand cmd.exe pour enregistrer le driver ( ...m'énerve aussi ce truc),  tu lances l'execution dans Visual studio en pointant le projet du driver, il executera le serveur local et après celà tu ouvres à part, en dehors de Visual studio, n'importe quel client que ce soit NINA  ou autre. et tu lui demandes d'ouvrir ton driver. Tes breakpoint fonctionneront sans problème. C'est finalement assez simple mais j'ai quand même buté là dessus pendant quelques heures.

3) Ils le précisent bien dans le readme mais je vais le répéter quand même : le seul fichier qu'il est réellement nécessaire de modifier c'est SwitchHardware.cs. Ton driver il est là dedans et sa structure est essentiellement la même que les drivers DLL classique. Le reste, à moins que tu ais besoin d'autre chose qu'un port série (qui est déjà implémenté dans Sharedressources),  pas la peine d'y toucher.

 

Donc au final une fois qu'on sait où on doit mettre notre code et comment débugger, c'est pas beaucoup plus difficile qu'avant.
 

[Raphael_OD]

Le 02/08/2025 à 15:09, Antiath a dit :

.NET framework 4.8 minimum.

bah c'est fait ouai 

Le 02/08/2025 à 15:09, Antiath a dit :

...m'énerve aussi ce truc

une pure aberration

Le 02/08/2025 à 15:09, Antiath a dit :

C'est finalement assez simple mais j'ai quand même buté là dessus pendant quelques heures.

Moi j'ai failli buter l'équipe des dev ASCOM au bout de 2 heures 

Le 02/08/2025 à 15:09, Antiath a dit :

Donc au final une fois qu'on sait où on doit mettre notre code et comment débugger, c'est pas beaucoup plus difficile qu'avant.

jusqu’à la prochaine tête pensante qui va arriver dans leur équipe qui va tout remettre à plat 😂


Merci de ton retour

[Antiath]

Je partge tes frustrations ouai...

Je crois que ce qui m'énerve le plus c'est cet encart sur leur stie : 

En particulier le point où on te dit de ne surtout pas réutiliser du code existant. Comme si tout le monde savait exactement quoi écrire rien qu'en lisant leur doc, certes extensive, mais obscure et totalement dépourvue d'exemple concret et de snippet de code.  Ouai ben...je vais me gêner hein.