Discussion :

[Original Prankster]

Re bonsoir,

Après avoir résolu mon problème d'émission/réception avec ma carte électronique, voilà que surgit un nouveau problème... Je vous le conte, car il me semble assez désagréable à contourner, et j'aurais besoin de témoignages à ce sujet.

L'appli a été débugguée et testée avec succès sur un PC puissant (1024Mo de RAM et CPU de l'ordre de 3GHz). Restait quelques modifications à apporter. J'ai alors transféré l'ensemble sur mon laptop qui lui fonctionne à raison de 256Mo de RAM et 1GHz de CPU. Mais voilà, sur cette config l'appli ne parvient plus du tout à communiquer avec la carte, à cause d'un problème de timing !

Ce problème est gênant puisque l'appli perd de sa portabilité.

Voici selon moi la partie critique :

Code :

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

1
2
3
4
5
6
7
8
9
10
On Error GoTo errcom
LabelCOM.Caption = "COM" & CStr(portCom)
MSComm1.PortOpen = True ' Ouverture du port
LabelCOM.ForeColor = &HC00000
Call Send_COM("-") ' Passage en mode invisible si ce n'est pas le cas
Sleep (2000)
MSComm1.OutBufferCount = 0 ' On vide le buffer d'émission pour éviter phénomène d'écho
MSComm1.InBufferCount = 0 ' On vide le buffer de réception pour éliminer toute info inutile
Call Send_COM("Z")
Call Receive_COM

Avec :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Public Sub Send_COM(Message As String)
    sent = Message ' Sauvegarde message
    Label1.Caption = sent
    On Error GoTo errsend
    MSComm1.Output = sent & vbCr
    DoEvents
    On Error GoTo 0
Exit Sub
 
errsend:
    Call MsgBox("Erreur (" & Err.Number & ") : " & Err.Description & vbCrLf & "Message : """ & Message & """", vbCritical, "Envoi COM" & portCom)
    Call Reinit_COM
End Sub

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
Public Sub Receive_COM()
    ' Tentative réception réponse
    On Error GoTo errrcv
    tampon = MSComm1.Input
    On Error GoTo 0
    posCr = InStr(1, tampon, vbCr)
 
    ' Récupération du message reçu ligne par ligne
    While tampon <> "" And posCr > 0
        If posCr > 1 Then
            Call Traitement(Mid(tampon, 1, posCr - 2)) ' Routine de traitement
            If posCr < Len(tampon) Then
                tampon = Mid(tampon, posCr, Len(tampon) - posCr)
                posCr = InStr(1, tampon, vbCr)
            Else
                tampon = ""
                posCr = 0
            End If
        ElseIf posCr = 1 Then
            tampon = Mid(tampon, 2, Len(tampon) - 1)
            posCr = InStr(1, tampon, vbCr)
        End If
    Wend
Exit Sub
 
errrcv:
    Call MsgBox("Erreur (" & Err.Number & ") : " & Err.Description & vbCrLf & "Message : """ & Message & """", vbCritical, "Réception COM" & portCom)
    Call Reinit_COM
End Sub

Comment ne pas subir les contraintes liées à la configuration de la machine ?

Merci d'avance

[Original Prankster]

Après réflexion, je crois comprendre que la carte ne reçoit pas tous les messages que j'envoie, ce qui explique qu'elle ne me réponde pas.

Est-ce déjà arrivé à quelqu'un ?

J'aurais 2 hypothèses :
- Soit elle effectue un traitement (un envoi par exemple) et délaisse donc le message que je lui adresse
- Soit elle tourne très vite, et n'a pas le temps de s'apercevoir qu'un message lui est parvenu...

[méphistopheles]

Bonjour.

Code :

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

On Error GoTo errcom

je suppose que dans le cas d'une machine lente tu fait forcément erreur et tu va sur errcom non ?

Code :

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

Sleep (2000)

euh... je crois que l'erreur vient de là. Une des premières choses à faire serait de mettre

Code :

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

Sleep(Ma_Variable_De_Temps)

et de modifier la variable au besoin, par exemple dans le errcom.
D'autre part, il serait peut-être oportun d'utiliser une différence de temps avec le moment ou tu démare l'appel, car le code va s'executer plus lentement sur une petite machine.

Code :

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

1
2
3
4
errsend:
    Call MsgBox("Erreur (" & Err.Number & ") : " & Err.Description & vbCrLf & "Message : """ & Message & """", vbCritical, "Envoi COM" & portCom)
    Call Reinit_COM
End Sub

Qu'est-ce qu'il fait là celui là ? en dehors d'une procédure ?

Code :

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

1
2
3
4
errrcv:
    Call MsgBox("Erreur (" & Err.Number & ") : " & Err.Description & vbCrLf & "Message : """ & Message & """", vbCritical, "Réception COM" & portCom)
    Call Reinit_COM
End Sub

idem (si c'est possible de mettre des erreurs en dehors des procédures, je me suis longtemps cassé la tête pourien (je ne me ferais pas moine ce coup ci, c'est déja le cas))

bon, ben ... je vois rien d'autre...

Bonne chance !

[Original Prankster]

Hello

Merci pour la réponse à laquelle je vais tâcher d'y apporter toutes les lumières possibles.

Non, je ne vais pas dans le traitant d'erreur, tout est bien effectué, après maints tests avec points d'arrêts à l'appui.

La carte envoie dans son mode "verbose" un compteur en continu. La commande "-" fait passer la carte en mode "muet", mode dans lequel elle n'émet plus ce compteur qui me gêne dans ma conversation avec elle. Le sleep n'est là que pour effectuer des tests. 2 secondes sont beaucoup trop longues mais c'est volontaire, je voulais juste être assuré que la carte ait fini de m'envoyer le compteur avant de procéder à l'effacement de mon tampon de réception. --> Histoire de pas effacer alors qu'elle m'envoie encore des données, au risque de me retrouver avec un buffer pas totalement vide.

Enfin, mes traitants d'erreur ne sont pas EN DEHORS des procédures ! Ils font suite à un Exit Sub, et non pas à un End Sub...


Comme je le disais précédemment je pense que le pb était mal diagnnostiqué, il semblerait que la vitesse de ma machine influe sur la bonne réception des commandes envoyées... Et là je ne sais pas expliquer pourquoi.

Merci

[méphistopheles]

oups, désolé pour les ext sub, ça fait longtemps qeu j'ai pas fait un peut de vb.


Tout ce que je peut te conseiller et de faire un journal de déboguage que tu met à jour à chaque instruction (crée un petit txt à coté). Tu peux utiliser le débug, mais il me semble qu'il sature vite donc bon...

sinon, pas d'idées...

[Original Prankster]

J'ai une explication à la non réception de mes commandes envoyées. Il ne s'agit pas en fait de la rapidité de mon processeur, mais d'un problème... de câble !

Je m'explique.

Ce qu'il faut savoir, c'est que le câble RS232 est "légèrement trafiqué" par le fabricant de la carte électronique, afin de ne plus être en situation standard, et placer ainsi une barrière aux amateurs de reverse engineering...

Ainsi je dispose d'un câble complètement atypique, dont une des particularités est de relier la masse (n°7 côté PC) au fil DTR (n°4 côté carte). Ce qui fait que l'état vacille sans arrêt.

Ainsi, les commandes que j'envoie sont bel et bien reçues SEULEMENT si la masse se trouve dans un état correct ! (haut ou bas je ne sais pas).

J'ai réalisé un test avec un Terminal codé en VB, le soucis est le même qu'avec mon appli : les commandes sont parfois reçues, parfois non, certainement en corrélation avec ce qui se passe sur mon fil n°7.

Ce qui est étrange en revanche, c'est que l'HyperTerminal de WinXP ne souffre pas de cette particularité !!! Si quelqu'un a une réponse à cette curiosité, je suis preneur, d'autant plus qu'elle me permettrait de corriger mon problème, dans l'hypothèse ou je peux l'implémenter aussi.

Pour le moment j'en suis réduit à envoyer mes commandes en rafale, en espérant qu'au moins l'une d'entre elles passe...

Voilou.

Merci encore de m'aider.

[méphistopheles]

Pour le moment j'en suis réduit à envoyer mes commandes en rafale, en espérant qu'au moins l'une d'entre elles passe...

Aie... Bobo le processeur. pour le reste, je ne saurais pas dire, mais à mon avis, ton problème concerne maintanant plus la section 'hardware' ou
'Windows' que celle-ci ...

[Original Prankster]

Le problème est hard, c'est sûr ! Mais c'est vraiment à cause du câblage exotique, et cela ne me concerne pas... J'ai seulement forcé RTSEnable et DTREnable à True (je ne suis en charge que de la partie IHM).

En ce qui concerne les rafales, il ne s'agit rien de compliqué : j'envoie 5 fois la commandes au lieu d'une seule fois. Et ça tourne !

Merci en tout cas, mon contrat est enfin rempli !
(Remerciements spéciaux à ProgElecT)

[ProgElecT]

Peut être un dernier espoir, avez vous experimenté cette propriété ?

Handshaking, propriété
Définit et renvoie le protocole de communication matériel.
Un protocole de communication permet de ne pas perdre de données en cas de dépassement de la capacité du tampon,
c'est-à-dire lorsque le périphérique de communication ne parvient pas à transférer les données vers le tampon de réception car elles arrivent trop rapidement au port.

[Original Prankster]

Oui. Mais le Handshaking gère le soft, pas le hard !

Code :

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

MSComm1.Handshaking = comNone

La carte n'émettant selon aucun protocole, directement en assembleur, à une grande vitesse, cela ne sert à rien pour moi de positionner la propriété Handshaking à autre chose.

Par ailleurs, mon problème n'était plus situé à la réception de ce que m'envoie la carte. J'ai résolu ce problème en vidant le buffer (InBufferCount = 0) aux moments critiques où je devais consulter ce qu'elle m'envoie (MSComm.Input).

Le problème ici était plutôt que LA CARTE ne reçoit pas tout ce que J'envoie. Mais il s'agit clairement d'un problème hard, pas soft.

[ProgElecT]

Ok

En attendant bravo pour la constance et la pugnassité

Sujet clos donc, tres interessant en ce qui me conserne.

Salut