[VB6/MSComm]Teruggekregen data niet volledig

[Ciqniz]

Het volgende...

Wanneer ik commandos stuur naar een apparaat aangesloten via RS232, aangestuurd via MSComm-control in VB6, krijg ik niet de volledige response retour.

Hier een voorbeeldje van wat ik terug krijg, en wat ik terug zou moeten krijgen:

Dit krijg ik:

code:

REGEL TERUGGEKRE
GEN TEKST

Dit moet ik krijgen:

code:

REGEL TERUGGEKREGEN TEKST

In principe hetzelfde, op het afbreken van de regel na.
En dat is het hem nou juist, het bovenste is wat ik continue te zien krijg in mijn log wat ik bij hou van de ontvangen data omdat het niet correct werkt. Die log werkt gewoon via de append methode, en begint elke keer op een nieuwe regel bij een OnComm-event in het programma.

Dit is niet de normale manier, aangezien het apparaat via de originele software gewoon keurig werkt. Zou het misschien een timings-probleem op een of andere manier kunnen zijn? Een mankement van Visual Basic (het is niet de perfecte omgeving om met RS232 te werken natuurlijk)?

Hier mijn instellingen van mijn MSComm-control:

code:

ConfigForm.Comm.CommPort = Homogenates.Com
ConfigForm.Comm.Settings = "38400,N,8,1"
ConfigForm.Comm.InputLen = 0
ConfigForm.Comm.RThreshold = 1
ConfigForm.Comm.RTSEnable = True
ConfigForm.Comm.SThreshold = 1

Als ik .Settings ook maar een beetje laat afwijken van "38400,N,8,1" dan werkt het hele apparaat niet meer.

Hier de routine van het oncomm-event, en hoe ik daar mee omga:

code:

Private Sub Comm_OnComm()
  Dim Base As String
  
  Select Case Comm.CommEvent
    Case comEvReceive
      Base = Comm.Input
      Open App.Path & "\logs\receive.log" For Append Shared As #137
        Print #137, Base
      Close #137
      
      Call Homogenates.CheckRaw(Base)
      
      Base = ""
  End Select
End Sub

Base vangt tijdelijk de MSComm-input op, om die vervolgens in het log-bestand te proppen, en mee te sturen aan de "CheckRaw"-routine, die zich op een ander form bevindt. CheckRaw is de routine die op basis van de teruggekregen data van de machine zijn ding doet in het programma (verkregen via variabele base). CheckRaw werkt, mits de volledige data is ontvangen, zonder dat de regel wordt afgebroken. CheckRaw zou ik voor de gein ook nog wel willen posten, maar is HUGE... Dus dat lijkt mij geen goed idee... Ik ben hier nu al een tijdje mee bezig, en ik weet even geen oplossing meer...

[Narf109]

Ik denk niet dat het de oorzaak van je CR probleem is, maar ik vind het wel vreemd dat je na iedere karakter een append aktie uitvoerd...
Beter is het om deze weg te schrijven als je alles ontvangen hebt.

[Ciqniz]

Narf schreef op dinsdag 29 maart 2005 @ 09:07:
Ik denk niet dat het de oorzaak van je CR probleem is, maar ik vind het wel vreemd dat je na iedere karakter een append aktie uitvoerd...
Beter is het om deze weg te schrijven als je alles ontvangen hebt.

Die append zit er puur voor referentie, om te kijken of de data nog steeds afgebroken wordt.
Het gaat er om dat hij complete zinnen moet doen, wat ie soms ook doet, maar niet altijd, wat ik er vergeten ben bij te vermelden. Soms wil het wel, en dan werkt het perfect, soms wil het niet. Terwijl het met de originele software altijd werkt...

Met append-aktie of niet, maakt niks uit.
Het wordt toch eerst in een variabele opgeslagen (Base)

[Stiegl]

Volgens mij heeft het gewoon met timing te maken. In principe wordt je OnComm event door elk inkomend karakter getriggered. Afhankelijk van hoe snel VB deze event opvangt zal je receive buffer blijven vollopen. Op het moment dat de OnComm wordt geevalueerd, kan je data volledig binnen zijn, maar het kan ook zijn dat een gedeelte pas binnen is. Is er een deel binnen, dan zal er 2 keer naar de file worden geschreven. Is het niet zo dat de print een CRLF aan je data toevoegd?
Als je zeker wil zijn dat je data binnen is, dan moet je je buffer eerst checken op een termination karakter, of je InputLen vergroten, als je weet hoeveel data je verwacht.

[Ciqniz]

The Cheese schreef op dinsdag 29 maart 2005 @ 09:27:
Volgens mij heeft het gewoon met timing te maken. In principe wordt je OnComm event door elk inkomend karakter getriggered. Afhankelijk van hoe snel VB deze event opvangt zal je receive buffer blijven vollopen. Op het moment dat de OnComm wordt geevalueerd, kan je data volledig binnen zijn, maar het kan ook zijn dat een gedeelte pas binnen is. Is er een deel binnen, dan zal er 2 keer naar de file worden geschreven. Is het niet zo dat de print een CRLF aan je data toevoegd?
Als je zeker wil zijn dat je data binnen is, dan moet je je buffer eerst checken op een termination karakter, of je InputLen vergroten, als je weet hoeveel data je verwacht.

Hier heb ik wat aan! 1000x-dank! Ik heb het op de volgende manier opgelost:

code:

  Dim BaseEnd As Boolean
  
  BaseEnd = False
  
  Select Case Comm.CommEvent
    Case comEvReceive
      While Right(Base, 1) <> Chr(3)
        Base = Base & Comm.Input
      Wend
      
      If Right(Base, 1) = Chr(3) Then
        BaseEnd = True
      End If
      
      If BaseEnd = True Then
        Open App.Path & "\logs\receive.log" For Append Shared As #137
          Print #137, Base
        Close #137
      
        Call Homogenates.CheckRaw(Base)
      
        Base = ""
      End If
  End Select

Misschien niet de mooiste manier, maar het werkt wel!!

[OZ-Gump]

offtopic:
Gebruik de functie FreeFile om een vrij bestandsnummer te krijgen. Wanneer bestandsnummer 137 in gebruik is, gaat het mis in je applicatie. Terwijl er niets is om op mis te gaan!
Verder is de variabele BaseEnd een beetje overkill, omdat je die maar 1 keer uitleest, net als de select case met een enkele case erin. En het is niet zo dat deze er nou voor zorgen dat je code veel leesbaarder wordt... Maar dat gaat eigenlijk wel ver qua optimalisatie.

[ Voor 6% gewijzigd door OZ-Gump op 29-03-2005 10:04 ]

[Ciqniz]

OZ-Gump schreef op dinsdag 29 maart 2005 @ 10:03:

offtopic:
Gebruik de functie FreeFile om een vrij bestandsnummer te krijgen. Wanneer bestandsnummer 137 in gebruik is, gaat het mis in je applicatie. Terwijl er niets is om op mis te gaan!
Verder is de variabele BaseEnd een beetje overkill, omdat je die maar 1 keer uitleest, net als de select case met een enkele case erin. En het is niet zo dat deze er nou voor zorgen dat je code veel leesbaarder wordt... Maar dat gaat eigenlijk wel ver qua optimalisatie.

Hier ben ik van op de hoogte, omdat ik bijna elke seconde met bestanden werk in mijn applicatie, wil hij met freefile ook nog wel eens de fout in gaan, dus ik hou gewoon exact bij welke nummers er gebruikt worden, en dat gaat verder goed. En had al aangegeven dat de het niet de meest ideale manier is om het te laten werken, de optimalisatie komt later, als ik alles werkend heb. Maar bedankt voor de tips

[jan-marten]

Kijk eens naar de volgende properties van het MSComm-object: RThreshold en Inputlen.

Het is normaal dat je na een x aantal karakters (bij jouw 16 zo te zien) een comm-event krijgt. In dat comm-event moet je zoeken op een vbcrlf (of een andere 'einde van de regel' reeks) en als je die niet vind moet je de ontvangen karakters in een interene buffer opslaan (globale var ofzo). Als je hem wel ontvangt heb je een complete regel en stuur je die naar je bestand.

[Ciqniz]

jan-marten schreef op dinsdag 29 maart 2005 @ 13:15:
Kijk eens naar de volgende properties van het MSComm-object: RThreshold en Inputlen.

Het is normaal dat je na een x aantal karakters (bij jouw 16 zo te zien) een comm-event krijgt. In dat comm-event moet je zoeken op een vbcrlf (of een andere 'einde van de regel' reeks) en als je die niet vind moet je de ontvangen karakters in een interene buffer opslaan (globale var ofzo). Als je hem wel ontvangt heb je een complete regel en stuur je die naar je bestand.

Dat heb ik gedaan...
En dat werkt... Het commando is afgelopen bij Chr(3). En dan pas word de var verwerkt in de routine. Zoals te zien in een stukje code bovenaan in een van mijn reacties...