none
Temporisation et évenement support serie RRS feed

  • Discussion générale

  • Bonjour tous le monde,

     

    J'ai un souci de "fiabilté" avec la fonction datarecevied, Je m'explique :

     

    J'envoie une requete toute les 50ms, l'un apres l'autre, a 120 appareils communiquants par port serie, ceux ci me repondent par une trame sur 4 octets.

     

    j'utilise donc la fonction datareceived pour lire ces octets, avec les reglages suivants :  readbuffersize=4; receviedbytesthreshold=4.

     

    Mon souci est que bout d'un certain temps la fonction semble se mettre en "veille", il suffit d'ouvrir l'explorateur ou autre pour la relancer la lecture.

     

    Je voudrais avoir une lecture sur de mes 4 octets et ceux-ci pendant au moins 10h !

     

    Avez vous une solution, une maniere plus pro d'ecrire ceux-ci ?

     

    Merci a vous.

     

     'Evénement se déclenchant lors de l'arrivée de données sur le port PortSerie
     Public Sub SerialPort1_DataReceived(ByVal sender As Object, ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) Handles SerialPort1.DataReceived
      Dim nb_octet As Integer = SerialPort1.BytesToRead ' on récupére le nombre d'octet prèsent dans le tampon
      Dim trame(nb_octet - 1) As Byte ' Tableau acceuillant les données au format byte
    
    
    
      SerialPort1.Read(trame, 0, nb_octet)
      Try
       If m >= 1 And m <= 20 Then
    
        Select Case trame(0)
    
         Case 1 To 20
          ProgrammePrincipale.Rack1Present = True
    
         Case 21 To 40
          ProgrammePrincipale.Rack2Present = True
    
         Case 41 To 60
          ProgrammePrincipale.Rack3Present = True
    
         Case 61 To 80
          ProgrammePrincipale.Rack4Present = True
    
         Case 81 To 100
          ProgrammePrincipale.Rack5Present = True
    
         Case 101 To 120
          ProgrammePrincipale.Rack6Present = True
    
        End Select
       End If
    
       Valeur = trame(1) * 256 + trame(2)
       Me.Invoke(New EventHandler(AddressOf DoUpdate))
      Catch
    
      End Try
     End Sub
    

     


    samedi 16 juillet 2011 11:28

Toutes les réponses

  • Bonjour,

     

    Avez-vous essayé de désactiver l'économiseur d'écran ?

    sinon vous pouvez ajouter un timer et lancer un process comme l'explorateur toutes les x minutes en calculant x au bout de combien de temps votre port série ne lit plus.

     


    fred
    dimanche 17 juillet 2011 12:24
  • Bonjour Fred,

     

    Merci pour ta reponse, j'ai pensé a desactiver l'ecran de veille, pas de changement.

     

    Lancer une appli toute les x temps serait peut etre une solution, mais tres pro !

     

    Si vous avez d'autres pistes je suis preneur !

    dimanche 17 juillet 2011 15:45
  • Bonjour,

    Commencez par supprimer cette clause catch vide qui masque probablement une exception qui survient dans votre code. Je vois cela de temps à autre sans doute dans l'espoir de rendre l'application plus "robuste" mais à mon avis c'est largement contre productif.


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    dimanche 17 juillet 2011 17:20
    Modérateur
  • Bonjour,

     

    La clause catch est la source de mes soucis je pense ! en effet elle est là car j'ai des erreurs sur l'index de ma trame de reception, du faite que que mon BytesToRead n'est pas toujours egal a 4 !

     

    Gilles tourreau, MVP, propose sur un autre post de mettre un thread.sleep de 10s pour remedier a ce type de probleme. Je vais faire l'essai ce soir, mais avec 10ms ( contrainte de mon appli)

     

    Toute proposition est la bienvenue !!!

     

    dimanche 17 juillet 2011 18:14
  • Humm... Balayer l'erreur sous le tapis n'est certainement pas une bonne idée. Il faudrait plutôt trouver la source de l'erreur. C'est égal à combien quand ce n'est pas 4 ?

    Je ne suis pas spécialement expérimenté sur le sujet mais je crois avoir vu qu'une erreur fréquente est d'essayer justement de forcer le traitement en blocs de taille fixe alors que le principe serait plutôt de s'adapter à ce que l'on reçoit sur le port série. Notamment je vois dans la doc qu'une valeur inférieure à 4096 pour le buffer n'est pas prise en compte et un "threshold" est un seuil (donc à mon avis cela ne veut pas dire que l'on a 4 octets mais "au moins" 4 octets) donc si on a plus de 4 octets cela ne me parait pas spécialement anormal.

    Pour moi le principe serait plutôt :
    - de recupérer dans DataReceived ce que le port série nous envoyer sans chercher à traiter des blocs de 4 octets
    - et de traiter les blocs complets de 4 octets que l'on a reçu jusqu'à présent

    A mon avis on pourrait tout à fait avoir qq chose comme :

    - un DataReceived avc 7 octets donc je récupère tout et je traite les 4 premiers
    - un autre avec l'octet manquant qui complète les 3 non traites, je traite le bloc de 4 octets

    etc...

     En gros il faut à mon avis désolidariser la réception et le traitement, la réception se fait au bon vouloir de ce que le port série nous transmet, le traitement se fait en fonction du "protocole" utilisé par l'application.

     

     


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

    dimanche 17 juillet 2011 19:43
    Modérateur
  • Bonjour,

     

    Merci pour cette analyse , normalement mes appareil me repondent par 4 bytes !

     

     

    lundi 18 juillet 2011 12:46
  • Mais concrètement cela ne semble pas être toujours le cas ce qui parait tout de même suspect. Attends on une réponse avant d'envoyer vers l'appareil suivant ? Se pourrait il que ce soient des réponses venant de plusieurs appareils et reçues en un seul bloc ou des caractères de contrôle comme XON/XOFF si un appareil est débordé ou un accusé de réception etc ?

    Si on laisse de côté ce point pour l'instant, ignorer peut-être explicitement cette situation par exemple en ignorant l'évènement si on ne récupère pas exactement 4 octets. Actuellement ce catch vide est sans doute trop général et masque probablement encore une autre erreur.

     

    Ou par exemple sortir les erreurs dans un fichier pour pouvoir avoir une trace de ce qui arrive...


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    lundi 18 juillet 2011 21:18
    Modérateur