[eVB] Communicatie iPaq compoort hakkelt

[OZ-Gump]

Situatie
eMbedded Visual Basic 3.0 in combinatie met een iPaq 3870 van Compaq HP.
Er moet straks gecommuniceerd worden met een boordcomputer via de seriele poort van de iPaq. In tegenstelling tot eerdere berichten (yarvieh ) is het gelukt om netjes heen en weer te communiceren. Ik krijg naar de 'terminal' wat ik daarheen wil sturen, en krijg ook de gegens terug die ik zou verwachten.

(nuttige) instellingen Comm zijn als volgt:
• DTREnable = false
• Handshaking = comNone
• InputLen = 1
• InputMode = comInputModeText
• NullDiscard = false
• ParityReplace = ?
• RThreshold = 1
• RTSEnable = true
• Settings = 38400,N,8,1
• SThreshold = 1

Probleem
Zodra ik de eerste polling doe (controle om te kijken of de terminal er is) komt er een reactie terug. Elke keer daarna komt echter de data slechts de tweede keer binnen, en dan tweemaal snel achter elkaar.
Dat wil dus zeggen dat, zodra mijn eerste communicatie (na de polling) weggaat, deze ook direct beantwoord wordt door de terminal. Op de iPaq komen de gegevens dan echter niet binnen. Zodra de terminal antwoord geeft op mijn volgende verzoek (en dus voor de tweede keer een antwoord stuurt) komen beide antwoorden direct na elkaar binnen.

Geprobeerd
Ik heb al verschillende instellingen geprobeerd. Onder andere InputLen. Ik dacht namelijk eerst dat de inputbuffer niet vol genoeg zou zitten om door te komen maar dat was het (natuurlijk) niet.
Google groups lijkt me niet te willen helpen en een probleem zoals deze komt ook niet voor hier op GoT. Tenminste niet zo dat ik het redelijkerwijs kan vinden met de search hiero.

Zijn er mensen die een idee hebben waar dit vandaan komt en, misschien wel veel belangrijker, welke kant het in zou moeten om er van af te komen?

[curry684]

* curry684 heeft ooit vergelijkbare problemen gehad maar de code niet bij de hand.

Staat me echter iets van bij dat de diverse handshakemethodes moeilijk konden doen met dit soort grappen...? Kun je me ook even enlighten wat RTSEnable ook alweer inhoudt?

[OZ-Gump]

Volgens de hardwareleverancier zou de terminal geen handshake nodig hebben. Op de terminal zelf is ook te zien (datalampje) dat er een direct antwoord volgt op de verzoeken.

Van de MSDN library:

RTSEnable
This property determines whether to enable the Request To Send (RTS) line. Typically, a desktop computer sends the RTS signal to its attached modem. The RTS signal is a request for permission to transmit data.

[farlane]

Kijk je in een commevent of je data ontvangt?

Je communiceert op 38k4, terwijl je receive threshold op 1 staat. Dat kunnen veel events worden en ik kan me voorstellen dat het systeem dan events gaat missen.

Beter is het om met een timer je input periodiek te bekijken, en adh ddarvan bepalen of je voldoende binnenkrijgt.

Bovendien staat je inputlen op 1. Is dat de buffer die de mscomm intern bijhoudt? Wat gebeurt er als die volzit?

[OZ-Gump]

In de commevent wordt dus inderdaad alles afgevangen. Dat gebeurt dus alleen eens in de twee keer dat er data gestuurd wordt.

Het periodiek bekijken van de input met een timer, dat ga ik in ieder geval proberen. De terminal staat keihard op 38k4, dus daar kan ik weinig aan veranderen. En dus dan de aanpak daarvan maar

InputLen op 1 zorgt er voor (als ik het goed begrepen heb) dat er een event getriggerd wordt elke keer dat er een karakter binnenkomt op de compoort.

[OZ-Gump]

Update:
Raaaaarrrrr maar waaaaarrrrr... Zodra er een regel code staat tussen het in een variabele zetten van de input en het controleren van de variabele, dan komen de gegevens wel netjes binnen. Ik heb er nu dus maar een form.Refresh tussen gezet en dan loopt de communicatie wel synchroon. Ook als ik de variabele toeken aan een textbox gaat de communicatie goed. Het heeft dus niets te maken met de refreh, maar het lijkt echt op een willekeurige regel code aan te komen. Wat er dan in die regel staat, sja... dat lijkt niet zoveel uit te maken.

Rara rabarber

[farlane]

Volgens mij is de receive threshold de propery die voor die commevent geldt. De inputlen is volgens mij de interne receive buffer van het component.

FF checke ....

eMbedded Visual Basic 3.0

RThreshold
This property sets and returns the number of characters to receive before the Comm control sets the CommEvent property to comEvReceive and generates the OnComm event.

En ...

eMbedded Visual Basic 3.0

InputLen
This property sets and returns the number of characters the Input property reads from the receive buffer.

Jouw probleem klinkt als een timing probleem, en van de oplossing die je nu hebt bedacht heb ik het vermoeden dat ie niet onder alle omstandigheden gaat werken.

Beter is het om niet met de receive threshold te werken, en de inputlen op nul te houden.
Vervolgens met een timer pollen en alle karakters die je niet nodig hebt maar al wel zijn ontvangen onthouden voor de volgende poll.

Suc6

[OZ-Gump]

Om het topic even af te maken: zoals farlane al aangaf was de timing een belangrijk punt in de app. Hoe het nu in elkaar geknutseld is? De RThreshold staat op 0 en de InputLen staat op 1 en er staat een timer op 50 msecs om elke keer karakters uit te lezen. De inputlen op 1 is verstandiger in verband met de soort data die er binnenkomt en de controle die daarop nodig is.

Zodra een beginkarakter wordt gevonden, wordt een variabele InputBuf gelijk aan het inputkarakter. Elke keer dat daar een karakter achteraan komt wordt die ook achter InputBuf geplakt. En zodra een eindkarakter wordt ontvangen wordt de variabele InputBuf verwerkt en naar een lege string gezet. En het lijkt nog te werken ook

[farlane]

Dit lijkt me inderdaad een betere oplossing.

( Ook al is polling met een timer iets waar ik altijd een beetje kriebels van krijg. ( 'Dat moet mooier kunnen"). Maar in het geval van die mscomm control wordt je daar min of meer toe gedwongen.

[OZ-Gump]

Inderdaad. Nadeel is alleen dat ik de retourdata nog in mijn send-function wil afvangen eigenlijk, zodat ik als result van de send-functie het antwoord kan meegeven. Momenteel doe ik dat door dan de timer stil te zetten en de input te doorlopen tot er een volledige input komt. Vervolgens start ik de timer weer. Als er na 50 keer pollen geen volledige input is, ga ik een retry in. Ook al een beetje viezig, maar ik kon zo snel niks anders bedenken.

[farlane]

Mwoch, lijkt me een redelijk rechtoerechtaan oplossing.

Een andere mogelijkheid is om een send -en receivequeue te maken, waarin je makkelijk een vraag en een antwoord met elkaar kunt vergelijken.
Dat heeft echter weer wat meer voeten in de aarde en de vraag is of het nodig is voor jouw toepassing.