Discussion :

[megamario]

Bonjour,

Développement en C#, WPF, Framework 4.7.2.

Je ne sais pas si c'est techniquement possible, de couper l'alimentation d'un composant de façon logiciel (capteur infrarouge), connecté en USB et simulant un port COM avec dans mon cas un composant (USB/COM) de la marque Prolific.

Car parfois l'appareil ne répond plus alors que j'arrive à me connecter dessus. La LED des interrogations TX qui est dessus reste éteinte, alors que j'essaie de communiquer avec l'appareil.

Pour que cela fonctionne il faut déconnecter le port USB pour le reconnecter, ce qui n'est pas possible lorsque le logiciel est en application car le boitier est fermé.

C'est un gros point bloquant que je dois solutionner, pour la suite du développement du logiciel.

Avant nous avions un boitier infrarouge connecté en port COM RS232 qui n'avais pas ce problème de déconnexion, mais il ne fonctionne plus avec les nouveaux appareils, qui ne communique plus en 9600 bauds (ont passe par une DLL propriétaire pour la communication malheureusement, nous n'avons pas le protocole direct vers l'appareil pour nous passer de cette DLL)

J'ai tenté cela avec devcon.exe:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
        private string deviceName; 
        private string devicePort;
        private ManagementEventWatcher watcher;
        public event EventHandler DeviceChanged;
 
        public SerialPortReconnector(string deviceport)
        {
            this.devicePort = deviceport;
 
            deviceName = GetFullComPortName(devicePort);
 
            WqlEventQuery query = new WqlEventQuery("SELECT * FROM Win32_DeviceChangeEvent");
            watcher = new ManagementEventWatcher(query);
            watcher.EventArrived += (sender, e) => OnDeviceChanged(EventArgs.Empty);
        }
        public string GetFullComPortName(string portName)
        {
            string fullPortName = null;
 
            using (ManagementObjectSearcher searcher = new ManagementObjectSearcher("SELECT * FROM Win32_PnPEntity WHERE Name LIKE '%(COM%)'"))
            {
                foreach (ManagementObject queryObj in searcher.Get())
                {
                    if (queryObj["Name"] != null && queryObj["Name"].ToString().Contains(portName))
                    {
                        fullPortName = queryObj["Name"].ToString();
                        break;
                    }
                }
            }
            return fullPortName;
        }
        public void ReconnectPort()
        {
            Process process = new Process();
            process.StartInfo.FileName = "devcon.exe"; // Utilisez le chemin complet vers devcon.exe si nécessaire
            process.StartInfo.Arguments = $"enable {deviceName}";
            process.StartInfo.UseShellExecute = false;
            process.StartInfo.RedirectStandardOutput = true;
            process.StartInfo.CreateNoWindow = true;
            process.Start();
            process.WaitForExit();
        }
 
        public void StartMonitoring()
        {
            watcher.Start();
        }
 
        public void StopMonitoring()
        {
            watcher.Stop();
            watcher.Dispose();
        }
 
        protected virtual void OnDeviceChanged(EventArgs e)
        {
            DeviceChanged?.Invoke(this, e);
        }

Mais la fonction ReconnectPort n'arrange rien et l'évènement DeviceChanged n'est jamais déclenché.

On a constaté que parfois l'appareil était déclaré désactivé dans le gestionnaire de périphérique, dans ce cas un bouton apparaissait dans les propriétés pour le réactiver et cela marchait. C'est pour cela que j'ai essayé avec devcon.

Si vous avez des infos à ce sujet je suis vraiment preneur, car j'en peux plus de ces nouveaux appareils qui me font changer beaucoup de chose dans le programme, j'avais vraiment pas besoin de sa en plus.

La semaine prochaine je suis en vacance (ouffff), donc je ne vais peut être pas répondre rapidement, mais merci de votre aide comme d'habitude.



Je précise que j'ai constaté cela en mode débogage, mais pour le moment jamais sur une PC simulant les bornes définitive avec un exe en release. Je me fait peut-être du mouron pour rien, mais si cela ce produit ont serait bien embêté, car ont va déjà changer les milliers de modèles RS23 par les USB (enfin ont va faire des tests avant quand même ), mais si il faut encore les rechanger pour un autre modèle plus robuste, cela va être compliqué.
Les bornes sont fermées avec un écran tactile donc impossible de dire au client de débranché les USB et les remettre et encore moins aux utilisateurs finaux.

[umfred]

Si tu sais détecté quand ton USB ne répond plus, il faudrait avant de faire le enable aevc devcon, peut-être faire le disable?
L'idéal serait quand même de trouver pourquoi ça arrête de communiquer (attente de quelque chose sans timeout (je dis une bétise mais lpar exemple, on attend une chaine se terminant par un "\n" mais le protocole n'envoie plus celui-ci, donc le système reste en attente), ou timeout beaucoup trop long).

[megamario]

Si tu sais détecté quand ton USB ne répond plus, il faudrait avant de faire le enable aevc devcon, peut-être faire le disable?
L'idéal serait quand même de trouver pourquoi ça arrête de communiquer (attente de quelque chose sans timeout (je dis une bétise mais lpar exemple, on attend une chaine se terminant par un "\n" mais le protocole n'envoie plus celui-ci, donc le système reste en attente), ou timeout beaucoup trop long).

Bonjour umfred,

De retour de vacance, j'ai déconnecté mon cerveau une semaine et cela fait du bien.

Donc pour te répondre, malheureusement je ne sais pas quand il est bloqué, si ce n'est que j'ai pas de réponse si j'appel une fonction de la DLL, mais cela pourrait être simplement une déconnexion de l'utilisateur qui enlève son appareil avant la fin de la procédure, malheureusement on a pas de sécurité mécanique pour enlever l'appareil uniquement quand c'est le moment.

Concernant le problème de fond, malheureusement comme j'ai dit, ont passe par une DLL fourni par le fabriquant des appareils et donc ont a aucune maitrise de son fonctionnement, ni même sur les vitesses de communication.
J'ai 3 évènements en retour de cette DLL: Détection d'un appareil, connexion et déconnexion.

La procédure de connexion étant la suivante:

1. On s'abonne à l'évènement de détection d'un appareil.
2. On attend un appareil via l'event.
3. On s'abonne aux event connexion et déconnexion.
4. On se connecte.
5. On attend de retour de l'event connexion, pour dialoguer avec.
6. Une fois fini ont demande à l'utilisateur de retirer l'appareil.
7. On attend l'event de la déconnexion.
8. On réinitialise les variables et désabonnement aux events.
9. Fin du cycle, retour en 1.

Malheureusement quand le récepteur infrarouge est bloqué, j'ai aucun évent de déclenché.

Juste une question, est-ce que l'utilisation de devcon (que j'ai jamais utilisé auparavant) est équivalent à une déconnexion manuel (physique), autrement dit est-ce que cela coupe l'alimentation de l'USB par exemple. Sinon est-ce qu'il y a un autre moyen de le faire ?

J'ai ajouté des timeout à chaque appel de la DLL, en cas de timeout, je pourrais couper l'alimentation et la rallumer avant de faire une détection de présence puis reconnexion, c'est l'idée, mais je ne sais pas si c'est possible logiciellement depuis C# ?

Merci

[EDIT]

Bonjour umfred, j'édite mon message, car votre intervention m'a donnée une idée. Concernant l'attente d'un caractère de fin.
Ont utilisait déjà un serialCOM pour vérifier que la COM n'était pas déjà utilisé. j'en ai profité pour lui envoyer un \0 puis un vidage du buffer s'il y en a quelque chose à lire, et cela semble fonctionné, hier après cette ajout, j'ai constaté que par défaut j'avais rien à lire, mais parfois j'avais une 20ene de bytes, une fois vidé, le lecteur semble fonctionner normalement.
Je continue les tests et je passerais cette conversation en résolue si cela ce passe bien aujourd'hui, cela m'enlèverais une bonne épine du pied.

Merci