[VB6 / RFID] Inputbuffer raakt vol

[Koen_R]

Ik heb de mogelijkheid om eens met een (rs 232) RFID-scanner te experimenteren en probeer deze te koppelen aan Visual Basic programma.

Zodra op deze scanner een tag ligt, stuurt hij constant een stroom van x bytes (in dit geval 11) met daarachter een CR en een LF. Met een timer haal ik deze 10x per seconde op mbv het MScomm control. Ik kan hier teken voor teken uit de buffer lezen en filter de 'barcode' van de tag tussen de LF en CR uit.

Omdat de tag op de scanner blijft liggen, en de scanner continue data stuurd, loopt de buffer langzaam vol. Als ik dan de tag verwijder denkt het systeem nog (totdat de buffer leeg is) dat de tag er nog ligt.

Met de property .InBufferSize zou ik de buffer size moeten kunnen aanpassen, dat haalt echter niets uit. De MScomm control heeft ook een CommEvent waarde, die 2 zou moeten zijn op het moment dat er gegevens zijn (en 0 wanneer dat niet het geval is). Deze waarde blijft echter ook 2, dus ik kan deze niet gebruiken om zelf een soort EmptyBuffer te triggeren..

Vrij complex oplossing misschien, maar heeft iemand een idee?

[OZ-Gump]

Met een timer haal ik deze 10x per seconde op mbv het MScomm control.

Is het niet veel verstandiger om het OnComm event van het MSComm control te gebruiken, zodat je reageert op input, in plaats van er elke 100 ms om te vragen? In dat geval lijkt het me dat je de input van de scanner bij kunt houden met je applicatie.

[ Voor 12% gewijzigd door OZ-Gump op 30-11-2004 08:58 ]

[Verwijderd]

Als ik het goed begrijp dan stuurt de RFID chip continu dezelfde data?
Kun je dan de com poort niet gewoon sluiten als je weet dat je alle data 1 keer binnen hebt gehad?

[OZ-Gump]

Verwijderd schreef op dinsdag 30 november 2004 @ 09:04:
Als ik het goed begrijp dan stuurt de RFID chip continu dezelfde data?
Kun je dan de com poort niet gewoon sluiten als je weet dat je alle data 1 keer binnen hebt gehad?

Dat lijkt me wel een erg grove oplossing. Wat doe je wanneer de scanner drie minuten later andere data probeert door te sturen? Dan staat je COM poort dicht! Dit is dus m.i. geen oplossing.

[Stiegl]

Heb je de RThreshold property op 0 staan? Als je deze op 1 zet zal de OnComm event altijd afgaan op het moment dat je data ontvangt waarna je de buffer kan legen. Je kunt hem ook een andere waarde geven als je de event pas na een bepaald aantal ontvangen bytes wil laten triggeren.

[farlane]

OZ-Gump schreef op dinsdag 30 november 2004 @ 08:56:
[...]
Is het niet veel verstandiger om het OnComm event van het MSComm control te gebruiken, zodat je reageert op input, in plaats van er elke 100 ms om te vragen? In dat geval lijkt het me dat je de input van de scanner bij kunt houden met je applicatie.

Nee, de OnComm events zijn niet betrouwbaar genoeg om dat te doen.

Wat je volgens mij moet doen is elke poll de data uit je MSComm buffer halen en bij aan de vorige inputdata ( je eigen buffer ) plakken. Indien er een volledig bericht binnen is, verwijder je deze uit je eigen buffer en vergelijk je deze met het vorige volledige bericht. Indien deze hetzelfde zijn ( aan jou om vast te stellen wat 'hetzelfde' is ) negeer je het bericht.

[OZ-Gump]

Nee, de OnComm events zijn niet betrouwbaar genoeg om dat te doen.

Dat vind ik een merkwaardige opmerking. Binnen VB6 heb ik er geen ervaring mee, maar mijn Delphi 7 applicatie die hetzelfde component gebruikt werkt zeer intensief met de COM poort en dit gaat voortreffelijk. Wellicht dat het aan de soort data of het soort aangesloten apparaat ligt, maar ikzelf heb nooit problemen gehad met de OnComm event van MSComm. Dat wil natuurlijk niet zeggen dat je geen gelijk kunt hebben

[farlane]

OZ-Gump schreef op dinsdag 30 november 2004 @ 14:45:
[...]
Dat vind ik een merkwaardige opmerking.

Kan ik me voorstellen

Ik kan echter uit ervaring vertellen dat oa receive events (rxchar geloof ik?) al snel wegvallen als je in de event functie zelf zit m.a.g. dat je data mist. ( Ook al blijf je de inputbuffer uitlezen zolang er wat in staat )

Bij hogere snelheden zorgen de vele events ervoor dat je app niets anders meer doet dan in die event functie zitten.

Mijn ervaring is dat het pollen van mscomm met een timer het meest betrouwbaar werkt. ( in VB, ik heb weinig ervaring met Delphi )

[Koen_R]

bedankt voor de reacties,

OZ-Gump schreef:
[...]
Is het niet veel verstandiger om het OnComm event van het MSComm control te gebruiken, zodat je reageert op input, in plaats van er elke 100 ms om te vragen? In dat geval lijkt het me dat je de input van de scanner bij kunt houden met je applicatie.

Dat werkt niet echt prettig, omdat het OnComm event net zo lang blijft reageren als er data in de buffer zit, en deze continue lezen is niet echt fijn. Zolang de tag blijft liggen blijf je in deze event hangen.
Daarnaast kan ik dan niet zien wanneer de tag verwijderd wordt, omdat de scanner dan geen data meer doorgeeft.

Heb je de RThreshold property op 0 staan?

Rtreshold staat op 1. Hogere waardes hebben geen zin, omdat de stroom data continue is en er ook tags bestaan die meer of minder bytes data hebben.


Ik heb nu een oplossing die redelijk werkt, voordat ik karakter voor karakter ga lezen, lees ik eerst alles uit de buffer, tot er nog een stuk of 25 karakters in staan (min. 1 set data). Deze kan ik daarna uitlezen. Er is nu slechts een minuscule vertraging, maar misschien kan ik het nog iets strakker maken...

[farlane]

Waarom ga je nou met die rthreshold lopen pielen? Dat is nergens voor nodig. Gewoon pollen en alles uit de buffer lezen en in je eigen buffer stoppen.

Visual Basic:

Public Sub PollTimer_Timer()

    Static Buff as String

    Buff = Buff & Comm.Input

    While parseMessage( Buff )
       Call handleMessage
    Wend

End Sub

Waarbij parseMessage alles verwijdert uit Buff wat volledige berichten zijn