[C#] Communicatie Serial Port

[Verwijderd]

Ik ben bezig om een applicatie te schrijven die kan communiceren via de seriele port. Dit is geen probleem. Ik kan gewoon een string versturen en deze komt vervolgens netjes aan op de andere computer. Vervolgens wil ik een deel van deze string terugsturen naar de andere computer. Dit blijkt echter niet goed te werken. Want ik krijg meestal maar een deel terug of mijn programma crashed.
Ik heb met google heel veel sites bekeken en van alles geprobeerd, maar niets heeft tot nu toe geholpen.

Ik open mijn poort op de volgende manier:

C#:

comPort.PortName = cmbCom.Text;
comPort.DtrEnable = true;
comPort.Handshake = Handshake.RequestToSend;
comPort.RtsEnable = true;
comPort.BaudRate = int.Parse(cmbBaud.Text);
comPort.DataBits = int.Parse(cmbDataBits.Text);
comPort.StopBits = (StopBits)Enum.Parse(typeof(StopBits), cmbStopBit.Text);
comPort.Parity = (Parity)Enum.Parse(typeof(Parity), cmbParity.Text);

Dit is vervolgens mijn Datareceive functie (Deze heb ik gelijk bij de initialisatie van de comport toegevoegd):

C#:

string incomingData = "";
incomingData = comPort.ReadExisting();
           
writeTextToConsole(MessageType.In, incomingData);

comPort.Write(incomingData.Substring(2));

Heeft iemand een oplossing zodat de juiste string terug wordt gestuurd?

[Arethusa]

Als je maar een deel terugkrijgt kan het zijn dat je programma niet de tijd neemt om alle data op te halen. Misschien is het gebruik van threads iets? Zo heb ik ook het een vergelijkbaar probleem opgelost. http://gathering.tweakers.net/forum/list_messages/1181850/

[ Voor 68% gewijzigd door Arethusa op 26-03-2007 16:52 ]

[Verwijderd]

Arethusa schreef op maandag 26 maart 2007 @ 16:52:
Als je maar een deel terugkrijgt kan het zijn dat je programma niet de tijd neemt om alle data op te halen. Misschien is het gebruik van threads iets? Zo heb ik ook het een vergelijkbaar probleem opgelost. http://gathering.tweakers.net/forum/list_messages/1181850/

Ja daar zat ik ook aan te denken. Maar weet niet echt precies hoe ik dit moet doen, wel hoe ik een thread moet aanmaken. Ik heb zitten kijken naar die andere post, maar mijn visual basic is niet zo goed .

[Arethusa]

Ik denk dat je het best een thread kunt aanmaken na het openen van de port en voor het uitvoeren van

C#:

comPort.ReadExisting();

Maar misschien zijn er mensen op GOT die je hiermee verder kunt helpen. Ook is er veel informatie van op het net te vinden.

[cspare]

Verwijderd schreef op maandag 26 maart 2007 @ 16:49:
[...]
of mijn programma crashed.
[...]

Met welke melding crashed hij? Komt dit omdat je Substring(2) aanroept zonder te controleren of je string valid is? Of gooit je comm component een exception (welke?)

[Verwijderd]

cspare schreef op dinsdag 27 maart 2007 @ 08:36:
[...]


Met welke melding crashed hij? Komt dit omdat je Substring(2) aanroept zonder te controleren of je string valid is? Of gooit je comm component een exception (welke?)

Nou omdat inderdaad die substring niet werkt. Maar dat is vrij logisch. Het com component geeft geen exception.

[Teunis]

Verwijderd schreef op maandag 26 maart 2007 @ 16:49:
Vervolgens wil ik een deel van deze string terugsturen naar de andere computer. Dit blijkt echter niet goed te werken. Want ik krijg meestal maar een deel terug of mijn programma crashed.

wat je hier omschrijft heeft idd met substring te maken, als deze length 1,2 zal deze een execption geven

C#:

string incomingData = "";
incomingData = comPort.ReadExisting();
           
writeTextToConsole(MessageType.In, incomingData);

if(incomingData.length>2)
comPort.Write(incomingData.Substring(2));

of dit nogsteed doet wat je wilt weet ik niet

[Verwijderd]

Teunis schreef op dinsdag 27 maart 2007 @ 13:38:
[...]


wat je hier omschrijft heeft idd met substring te maken, als deze length 1,2 zal deze een execption geven

C#:

string incomingData = "";
incomingData = comPort.ReadExisting();
           
writeTextToConsole(MessageType.In, incomingData);

if(incomingData.length>2)
comPort.Write(incomingData.Substring(2));

of dit nogsteed doet wat je wilt weet ik niet

Nee daar ligt het niet aan, want als ik hem verwijder, dan stuurt hij nog steeds niet de volledige string, maar een deel.

[Teunis]

dus probleem is dat ie het in delen stuurt ?
zo ja dit is lastig op te lossen,
je kan
ReceivedBytesThreshold gebruiken maar als je constante veranderde lengte hebt is dit geen oplossing.
anders is de meest makeleijk manier om kleine protocol om heen maakt. en in de eerste byte de lengthe meegeeft die binnen moet komen, zodat je zeker weet dat je alles binnen hebt gekregen

[Verwijderd]

Teunis schreef op dinsdag 27 maart 2007 @ 14:29:
dus probleem is dat ie het in delen stuurt ?
zo ja dit is lastig op te lossen,
je kan
ReceivedBytesThreshold gebruiken maar als je constante veranderde lengte hebt is dit geen oplossing.
anders is de meest makeleijk manier om kleine protocol om heen maakt. en in de eerste byte de lengthe meegeeft die binnen moet komen, zodat je zeker weet dat je alles binnen hebt gekregen

Dat is inderdaad het probleem. Als er een deel binnen is gaat hij alweer verder met het volgende statement, het terugsturen van de gegevens. Dat is niet de bedoeling, hij eerst de buffer van de Com Port moeten uitlezen en vervolgens terug sturen wat hij heeft uigelezen. Maar er is volgens mij niet echt iets van een buffersize bij dit object.

[farlane]

Je zult echt een protocol moeten implementeren, anders is er geen enkele manier om te bepalen of je het hele bericht binnen is.

[Teunis]

tenzij er grote tijd (langer dan 1 ms) tussen de packeten zit dan kun je via timeout werken.

anders is een eigen protocol de enige oplossing

[farlane]

Teunis schreef op woensdag 28 maart 2007 @ 13:33:
tenzij er grote tijd (langer dan 1 ms) tussen de packeten zit dan kun je via timeout werken.

Wat heeft die tijd er mee te maken?

[Verwijderd]

Ik heb het opgelost. Heb de comPort.ReadExisting() vervangen door devolgende code:

C#:

while(!incomingData.EndsWith("(CR)"))
{
       incomingData += Convert.ToChar(comPort.ReadByte());
}  

Dit werkt perfect en zo wacht de applicatie tot de volledige string binnen is.

[farlane]

Verwijderd schreef op donderdag 29 maart 2007 @ 15:08:
Ik heb het opgelost. Heb de comPort.ReadExisting() vervangen door devolgende code:

C#:

while(!incomingData.EndsWith("(CR)"))
{
       incomingData += Convert.ToChar(comPort.ReadByte());
}  

Dit werkt perfect en zo wacht de applicatie tot de volledige string binnen is.

Mjaja en als die CR nooit komt?

[cspare]

farlane schreef op vrijdag 30 maart 2007 @ 14:58:
[...]


Mjaja en als die CR nooit komt?

Zoals Arethusa al aangaf, de code in een thread stoppen. Als je dan de volledige data hebt ontvangen kan je misschien een event raisen zodat je normale applicatie code het kan verwerken.

[farlane]

cspare schreef op vrijdag 30 maart 2007 @ 15:20:
Zoals Arethusa al aangaf, de code in een thread stoppen. Als je dan de volledige data hebt ontvangen kan je misschien een event raisen zodat je normale applicatie code het kan verwerken.

Volgens mij lees je niet goed. Als er geen CR komt krijg je geen 'volledige data binnen'

[cspare]

Ik zei Als je dan de volledige data hebt ontvangen. In het geval dat dit niet gebeurd, is het in iedergeval voor de client applicatie niet blokkerend als je gebruik maakt van een aparte thread. je GUI zal bijvoorbeeld gewoon kunnen blijven functioneren. Ik doelde dus meer op de gebruikers ervaring van de software.

Als je uberhaupt nooit een CR binnen krijgt zal je zoeizo je probleem op een andere manier moeten oplossen, bijvoorbeeld door een protocol te implementeren met timeouts/NACK/ACK'jes. Maar dat gaat een beetje offtopic denk ik.

[farlane]

cspare schreef op zaterdag 31 maart 2007 @ 00:53:
Ik zei Als je dan de volledige data hebt ontvangen. In het geval dat dit niet gebeurd, is het in iedergeval voor de client applicatie niet blokkerend als je gebruik maakt van een aparte thread. je GUI zal bijvoorbeeld gewoon kunnen blijven functioneren. Ik doelde dus meer op de gebruikers ervaring van de software.

Als je uberhaupt nooit een CR binnen krijgt zal je zoeizo je probleem op een andere manier moeten oplossen, bijvoorbeeld door een protocol te implementeren met timeouts/NACK/ACK'jes. Maar dat gaat een beetje offtopic denk ik.

Nee de GUI blokkeert niet maar de communicatie wel. Je probeert een probleem dat zo oud is als de communicatie zelf op een verkeerde manier op te lossen. ( Je probleem is niet het blokkeren van je GUI maar het feit dat de communicatie niet goed is geimplementeerd, daarvoor is multithreading an sich geen oplossing )
En het implementeren van een protocol gaat helemaal niet offtopic want dat is de enige goede manier om het te doen.

Je kunt daarbij alsnog multithreading gebruiken als je dat wilt maar normaal gesproken is het helemaal niet nodig.

[cspare]

farlane schreef op zaterdag 31 maart 2007 @ 11:13:
[...]
En het implementeren van een protocol gaat helemaal niet offtopic want dat is de enige goede manier om het te doen.

Ik geloof dat we een beetje langs elkaar heen praten; ik denk niet dat we het inhoudelijk oneens zijn.

Maar ik zal toch nog even uitleggen waarom ik vind dat het offtopic is. Over het feit dat je een protocol moet gebruiken zijn we het eens. Maar ik vind het zinloos om hier verschillende protocollen te gaan bevechten. Het protocol wat de TS nu geimplementeerd heeft is ongetwijfeld niet de beste. Maar je kan totaal niet oordelen of dat voor zijn situatie niet voldoende is. We weten immers niet wat voor applicatie de TS'er aan het maken is.

Voorbeeldje, ik heb een half jaar onderzoek gedaan naar een revolutionair communicatie systeem voor auto's (FlexRay). Daarin zitten een hele rits aan technieken die vrijwel alle communicatie problemen weten te voorkomen of op te lossen. Een aantal van deze technieken kan je met een kleine aanpassing ook wel toepassen op seriele communicatie.
Ik denk dat het een beetje te ver zou gaan om deze hier te opperen om zo alle eventueel mogelijke problemen van de TS af te dekken, zonder dat hij er zelf om vraagt.

[farlane]

cspare schreef op zaterdag 31 maart 2007 @ 13:35:
Ik geloof dat we een beetje langs elkaar heen praten; ik denk niet dat we het inhoudelijk oneens zijn.

Denk het ook niet

Maar ik zal toch nog even uitleggen waarom ik vind dat het offtopic is
..... zonder dat hij er zelf om vraagt. ...

Waarschijnlijk vraagt hij er niet om omdat hij niet weet wat er allemaal bij komt kijken. Jij kennelijk wel dus zou je imho niet moeten praten over multithreading en hoe dat voorkomt dat zijn ui blocked als er iets mis maar meer over hoe hij zijn communicatie stabiel kan krijgen. Als dat het geval is blocked zijn ui ook niet meer, ook niet als je geen multithreading gebruikt.