none
Rs-232 blocage communication RRS feed

  • Question

  • Bonsoir

    Je rencontre un problème ( Un nouveau ) sur ma com Rs232 . Je cherche à lire des informations sur un appareil distant via une com Rs-232. L'appareil distant est un appareil de mesures type Oscillo, les informations à lire se font par envoi de string et l'appareil réponds par des valeurs contenues dans sa mémoire . Ci-dessous ma commande pour une valeur à lire

    Sub Display_Delay1() ' READ DISLAY DELAY Dim DD_Brut As String Try

    'Sending _Seri_Port.WriteLine("DD") '' String nécessaire pour lire une valeur 'Wait some sec for command to be send Thread.Sleep(Value_Sleep) 'Read : timeout for Rs RS232 _Seri_Port.ReadTimeout = Value_Too_Long 'reading the value DD_Brut = _Seri_Port.ReadExisting Do If Mid(DD_Brut, 3, 2) = "DD" Then ' Ctle que le retour est correct DD_Value = Val(DD_Brut.Substring(4)) * 0.1 Exit Do End If Loop Catch ex As Exception 'If there is timeout print "Wait " into textbox Display_Delay.Text = "Wait" End Try

       

    Pour cette séquence pas de problème la lecture se passe très bien, si je souhaite changer ma valeur dans l'oscillo , la réponse est immédiate et la valeur change  dans <DD_Value>. Le problème se situe lorsque je scrute l'ensemble des données de mon oscillo, environ 20 programmes du type ci-dessus inclus dans une boucle <temps_reel > , et que je modifie une valeur de mon oscillo, cela ne se passe pas bien,   il y a plantage de la communication, sans message particulier, ni exception de la boucle try . Pour info en mode debug le problème ne se produit pas. 

    En complément voici le paramétrage com. que j'utilise

     Public Shared Sub Start_com()
            _Seri_Port = New SerialPort
    
            ' Allow the user to set the appropriate properties.
            _Seri_Port.PortName = "COM3"
            _Seri_Port.BaudRate = 9600
            _Seri_Port.Parity = Parity.None
            _Seri_Port.DataBits = 8
            _Seri_Port.StopBits = StopBits.One
            _Seri_Port.Handshake = Handshake.None
            _Seri_Port.NewLine = Chr(13)
    
    
            '_Seri_Port.ReadBufferSize = 1600000
            '_Seri_Port.WriteBufferSize = 1600000
            ' _Seri_Port.DtrEnable = True
            '  _Seri_Port.RtsEnable = False
            '_Seri_Port.ReadTimeout = 500
            '_Seri_Port.WriteTimeout = 500
        End Sub

    j'ai passé en commentaire certains points de mes essais de com, mais  la base line fonctionne bien en mode debug

    Merci pour votre aide

    lundi 9 juin 2014 21:07

Réponses

  • Bonsoir et merci pour les réponses.

    Effectivement je suis tombé dans une séquence pour laquelle j'avais une grande confiance et qui me générait une boucle infini dans certaines conditions ( Avec en prime un figeage  de l'oscillo sans message d'erreur même après une remise en service , nécessité donc  d'un reset spécifique pour ce matériel) .

    Dans mon, projet j'essaie de faire des contrôles individuels pour chaque lecture/écriture de plus je vérifie bien que ma réponse contient la question d'origine 

     si la commande est <_Seri_Port.WriteLine("DD")> la réponse sera forcement <DD Valeur attendue"> 

    Avec cette méthode je m'assure d'avoir une réponse en cohérence avec mes attentes ,  si le résultat est "true"  alors j'affiche ma valeur si non j'ignore le contenu et je continue les missions suivantes en préservant l'ancienne valeur dans mon affichage en espérant qu'au prochain tour j'aurai enfin une bonne réponse, sinon cela finira par un "wait" dans l'affichage si celui-ci persiste à ne pas répondre . 

    Merci beaucoup pour votre aide 

    • Marqué comme réponse Aurel Bera vendredi 13 juin 2014 06:09
    jeudi 12 juin 2014 20:55

Toutes les réponses

  • Bonjour

    Qu'est que vous comprenez par "plantage de communication"?

    Essayez d’écrire dans un fichier texte un des messages pour voir exactement où il plante.

     

    Bien cordialement,


    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    mardi 10 juin 2014 13:14
  • bonjour,

    Je considère le plantage suite aux évènements ci-joint

    • Pas d'échange entre  l'appareil questionné et le PC ( Surveillance par leds sur le câble Rx, Tx rts, cts )
    • je n'ai plus la possibilité de déplacer la "Form" avec les informations attendues.
    • j'ai intégré l'heure dans la "Form " et celle-ci n'évolue plus.
    • la fermeture de la "Form" n'est plus possible par la fermeture classique des fenêtres Windows ( petite croix rouge). Je ferme donc  par l'arrêt débogage Visual basic.
    • aucun message d'erreur .

    A retenir que lorsque je réalise la scrutation du programme au pas à pas détaillé il n'y a pas de problème de fonctionnement. Si je scrute chaque séquence de questionnement  individuellement il n'y a pas de problème non plus ...

    Cordialement

    mardi 10 juin 2014 18:40
  • Bonjour,

    Cela pourrait ressembler à un pb de boucle infini qui gaspille toute la CPU, ou bien en encore un pb de threading.

    Est-ce qu'on observe une montée de la CPU dans le Task Manager ? Si oui, le pb est qq part dans la boucle mais je n'y crois pas trop, vous auriez pu le simuler en debug.

    Autre possibilité si l'interface visuelle ne répond pas, c'est que son thread de "dessin" est utilisé pour autre chose ; en l'état la communication avec le matériel. 

    S'il n'y a rien sur les LEDs, le programme est bloqué qq part et n'arrive pas à s'en sortir, soit sur l'attente d'une méthode, soit sur l'attente d'une ressource, peut-être même une sorte de deadlock si vous écrivez dans l'oscillo pendant que l'on lit de l'autre côté. On ne voit pas de problème en mode debug car le pas à pas est incroyablement plus lent que le mode runtime.

    Je vous propose la stratégie suivante. Lancer votre programme en mode normal.

    Quand il est bloqué, essayez de voir si vous pouvez avec Visual Studio vous y attacher. Pour se faire dans le menu de Visual Studio, allez dans Debug, Attach To Process, puis attachez-vous à votre programme. (Normalement Visual Studio comprendra tout seul qu'il s'agit de .Net ou du langage machine, etc).

    Si l'opération fonctionne (ce n'est pas certain, mais espérons que oui), vous verrez Visual Studio changer d'apparence et se retrouver en mode "Debug". Dans ce cas, vous pourrez alors mettre en pause votre programme en appuyant simultanément sur CTRL + ALT + Pause (ou Break si votre clavier est anglais), ou en cliquant sur le bouton de pause dans la barre d'outils de débugage.

    Visual Studio s'arrêtera alors sur l'opération ou l'attente en cours, ce qui commencera à vous donner des pistes. N'oubliez pas de regarder s'il n'y a pas des threads concurrents que vous avez démarré ou bien lié aux API que vous utilisez (cliquez dans le menu sur Debug, puis  Windows, puis Threads). Vous pourrez voir l'état des threads mais surtout les instructions qu'ils sont également en train d'opérer.

    Si par hasard,  vous essayer d'écrire et lire en même temps sur un port Série il peut y avoir de gros problème. Le read et le write ne sont pas threadsafe. En C++, on fait appel à des Overlapped I/O dans ce genre de cas.

    En .NET, il faut s'assurer de bloquer l'écriture pendant la lecture et vice-versa. A cette fin, vous pouvez fonctionner avec des events du genre une fois que les données sont reçues on lève un évènement du genre "DataReceived", et on bloque lecture, et réveille l'écriture, etc.

    Bon courage,

    Fabrice JEAN-FRANCOIS

    mercredi 11 juin 2014 10:31
  • Bonsoir et merci pour les réponses.

    Effectivement je suis tombé dans une séquence pour laquelle j'avais une grande confiance et qui me générait une boucle infini dans certaines conditions ( Avec en prime un figeage  de l'oscillo sans message d'erreur même après une remise en service , nécessité donc  d'un reset spécifique pour ce matériel) .

    Dans mon, projet j'essaie de faire des contrôles individuels pour chaque lecture/écriture de plus je vérifie bien que ma réponse contient la question d'origine 

     si la commande est <_Seri_Port.WriteLine("DD")> la réponse sera forcement <DD Valeur attendue"> 

    Avec cette méthode je m'assure d'avoir une réponse en cohérence avec mes attentes ,  si le résultat est "true"  alors j'affiche ma valeur si non j'ignore le contenu et je continue les missions suivantes en préservant l'ancienne valeur dans mon affichage en espérant qu'au prochain tour j'aurai enfin une bonne réponse, sinon cela finira par un "wait" dans l'affichage si celui-ci persiste à ne pas répondre . 

    Merci beaucoup pour votre aide 

    • Marqué comme réponse Aurel Bera vendredi 13 juin 2014 06:09
    jeudi 12 juin 2014 20:55