[VB6] OnComm event is een beetje traag

[Paling1]

Het probleem is het volgende:

Ik ben bezig om een progje te schrijven om via de seriele poort mijn GSM te kunnen aansturen. Dat kan met behulp van 'AT+...' commando's die je bv. via hyperterminal kan sturen.

Ik heb in mijn progje gebruik gemaakt van een MSComm object dat de COM-poort voor moet stellen. Als er nu een commando wordt weggestuurd met :

code:

MSComm1.Output = "AT+CGMM" & vbCr

Dan komt er na verloop van tijd een antwoord van de telefoon. Dat antwoord kan gedetecteerd worden via het OnComm event:

code:

Select Case MSComm1.CommEvent
   Case comEvReceive   ' Received RThreshold # of characters
            While (MSComm1.InBufferCount > 0)
                strInpoet = strInpoet & MSComm1.Input
            Wend
End Select

Nou is mijn probleem dat dit event niet synchroon loopt met mijn commando's

Als ik de eerste keer een commando wegstuur treedt er pas na een tijdje een OnComm event op en als ik voor die tijd een tweede commando wegstuur dan krijg ik het antwoord van de eerste pas binnen.....

Ik heb het nu zo gemaakt dat er elke keer als er een commando wordt weggestuurd een pauze wordt ingelast voordat er wordt gekeken naar het OnComm event.

code:

MSComm1.Output = "AT+CGMM" & vbCr

    duration! = Timer + 0,1
    Do Until Timer > duration!
        dummy = DoEvents()
    Loop

Tijdens deze pauze is het OnComm event wel opgetreden en wordt de antwoordbuffer uitgelezen voor een resultaat.

Nu lijkt me dit geen juiste oplossing omdat het regelmatig blijkt dat de pauze die ik inlas (meestal ongeveer 0,1 s) te kort is. Op dat moment lopen dus de commando's en de antwoorden niet meer synchroon, met alle gevolgen van dien. Wat ook wel eens gebeurd is dat slechts een gedeelte van het antwoord opgevangen wordt.

Mijn vraag is dus:
Hoe kan ik zien dat het OnComm event optreedt zodat ik dan pas mijn antwoordbuffer ga lezen.
Ik wil bijvoorbeeld mijn telefoonboek uit gaan lezen. Dan komt er dus een commando in een loopje te staan dat elke keer een entry in het telefoonboek opvraagt. Als dit niet meer synchroon loopt dan klopt er dus helemaal nix meer van.

Ik heb me echt rot gezocht naar het antwoord op MSDN en Google, maar tot nu toe heb ik nix kunnen vinden, wat mijn probleem oplost.
Als iemand meer code wil zien laat het maar effe weten.

Alvast bedankt.

[Verwijderd]

Een eenvoudige oplossing zou de volgende kunnen zijn :

Ja maakt een globale veriabele aan die 1 of 0 kan zijn. Je zet die in het begin bv op 1 en zet DoEvents() in een while.
Een 1 betekent bv dat doevents mag uitgevoerd worden en een 0 niet.
Nadat je doevents hebt opgeroepen zet je die variabele op 0 zodat hij actief wacht tot de variabele terug 1 wordt.

code:

MSComm1.Output = "AT+CGMM" & vbCr

    duration! = Timer + 0,1
    while true
      if var=1 then
        dummy = DoEvents()
        var=0
      end if
    end while

Bij het OnComm event plaatst je dan nadat je al de invoer hebt behandelt die variabele terug op 1 zodat de Doevents terug uitgevoerd wordt en de var terug op 0 gezet wordt en zo is de cirkel rond.

code:

Select Case MSComm1.CommEvent
   Case comEvReceive   ' Received RThreshold # of characters
            While (MSComm1.InBufferCount > 0)
                strInpoet = strInpoet & MSComm1.Input
            Wend
End Select
var=1

Om te stoppen zet je var bv op 2 en met een break ga je dan uit de while.
Vraag me alleen af of dat actief wachten niet de volledige processortijd opsnoept

[ Voor 26% gewijzigd door Verwijderd op 01-06-2003 14:06 . Reden: hms foutje ]

[farlane]

JE moet gewoon de vraag pas stellen als het antwoord van de vorige ontvangen is. ( Of een timeout optreedt ).

Hiervoor kun je beter geen DoEvents gebruiken. Het is ook helemaal niet nodig.

[Paling1]

@Farlane, misschien heb ik de vraag niet duidelijk gesteld, maar het probleem is juist dat ik niet weet hoe ik kan detecteren dat het (volledige!!!) antwoord terug is.

Volgens MS moet het OnCommevent dat doen, maar bij mij lukt dat blijkbaar niet echt goed. Tot nu toe werkt het bij mij alleen als ik een pauze inlas van een paar tienden van een seconde.

@Yakko, je oplossing had ik ook al eens geprobeerd, maar het probleem is dan dat niet het volledige antwoord binnenkomt ofzo. Als ik dan nog een commando geef, dan krijg ik het laatste deel van het antwoord op de eerste vraag.

Ik ben er inmiddels ook achter dat als er een lang antwoord (veel tekens) komt dat het dan langer duurt, en dat de 'normale' pauze dan niet lang genoeg meer is.....
Het probleem is dus waarschijnlijk dat ik te weten moet komen wanneer het hele antwoord binnen is. Weet iemand of daar een mogelijkheid voor is?

[farlane]

Ok, dan had ik je vraag idd niet helemaal begrepen

Als je wilt weten wanneer het hele antwoord binnen is zal het protocol daar voorzieningen voor moeten hebben. ( Bijvoorbeeld vast eindteken of de lengte van het bericht dat ergens in het bericht zelf zit. Het kan ook nog zijn dat elk antwoord een vaste lengte heeft )

Aangezien het om een ascii protocol gaat kan het zijn dat bijvoorbeeld elk bericht met een CR wordt afgesloten.

Naast dat, zul je altijd zelf een timeout constructie moeten inbouwen om faulty communicatie te detecteren.

[ Voor 7% gewijzigd door farlane op 02-06-2003 09:03 ]

[Paling1]

Het regende, dus ik ben maar weer eens verder gegaan met mijn progje en.......


Farlane DANK JE WEL......

Jou oplossing werkt!!!!!!!

Ik heb nu dit stukje code ingebouwd:

code:

Do
      dummy = DoEvents()
Loop Until Not InStr(1, strInpoet, "OK" & Chr(13) & Chr(10), vbTextCompare) = 0

Hiermee wordt er dus gewacht totdat het OnComm event heeft plaats gevonden en het antwoord (met een OK aan het eind) helemaal binnen is.

Nu kan ik weer lekker verder met proggen....

[farlane]

Paling1 schreef op 04 June 2003 @ 18:09:
Het regende, dus ik ben maar weer eens verder gegaan met mijn progje en.......


Farlane DANK JE WEL......

Jou oplossing werkt!!!!!!!

Ik heb nu dit stukje code ingebouwd:

code:

Do
      dummy = DoEvents()
Loop Until Not InStr(1, strInpoet, "OK" & Chr(13) & Chr(10), vbTextCompare) = 0

Hiermee wordt er dus gewacht totdat het OnComm event heeft plaats gevonden en het antwoord (met een OK aan het eind) helemaal binnen is.

Nu kan ik weer lekker verder met proggen....

Waar zit je timeout constructie ?

Btw, ik zou 'em zelf op een of andere manier zonder DoEvents proberen te bouwen. Als je doevents gebruikt heb je namelijk plotseling reentrant gedrag van al je event functies. Als je vanuit hier een funtie aanroept die opnieuw een commando verstuurd en in een doevents gaat staan wachten heb je een probleem.

[Paling1]

Maar hoe moet ik het dan zonder die doEvents doen?

Het duurt gewoon altijd effe voordat er een antwoord binnenkomt. Ik weet geen andere manier om ervoor te zorgen dat het programma wacht totdat er wat binnen komt op de COM-poort.

En inderdaad die TimeOut moet ik er nog effe inbakken denk ik.

[farlane]

Paling1 schreef op 04 June 2003 @ 21:55:
Maar hoe moet ik het dan zonder die doEvents doen?

Over het algemeen kun je in VB beter een timer gebruiken die je start op het moment dat je een commando verstuurt, en die je ontvangen string gaat bekijken of ie al aan je voorwaarden voldoet.
( Deze timer kun je dan eventueel ook als timeout timer gebruiken )

Misschien is het wel mogelijk om die MSComm op een CR een event te laten afvuren.

En inderdaad die TimeOut moet ik er nog effe inbakken denk ik.

Denk het ook