[AudiA4B6US]

Hallo zusammen,

Ich mache gerade meine ersten Gehversuche in C# (Visual Studio Express 2005) und stosse immer wieder auf das gleiche Problem. Zum Vergleich habe ich aehnlichen Code auch mal in VB geschrieben aber das Resultat ist das gleiche.

Der unten angehaengte Code ist ein einfaches Programm welches den Serial Port oeffnet, den CANUSB Adapter initializiert und dann die empfangenen Strings in einer Textbox ausgibt. Ich habe den Open Knopf mit der CANUSB Initialissierung verbunden, sodass das Loggen sofort mitlaeuft. Genauso mit dem Close Button der dem CANUSB Adapter sagt er solle aufhoeren mitzuloggen.

Das Problem ist nun, dass mein Programm einfriert wenn ich den Close
Button druecke. Nicht jedes mal aber ungefaehr jedes zweite mal. Wenn ich beim Schliessen die Zeile serialPort1.Write("C "); weglasse dauert es laenger bis das Programm einfriert, es tritt aber denoch nach 5-10x oeffnen/schliessen auf. Der Wechsel auf einen Timer anstelle des DataReceived Events umgeht das Problem auch, aber ich bin mir nicht sicher, dass dies die Loesung fuer mein Problem ist oder es nur weniger offensichtlich macht.

Da ich noch ganz am Anfang bzgl. Programierkenntnisse stehe bin ich natuerlich etwas verwirrt und wuerde gerne ein paar Meinungen dazu hoeren. Auch Beispiele in VB6, VB 2005 oder C# 2005 waeren nuetzlich. Interessant ist, dass dies nur bei meinem eigenen Code passiert. Den CAN Tool kann ich sooft wie ich will Connecten oder Diconnecten, da fiert nichts ein.

Waere fuer jeden Tipp dankbar.

Gruss,
Dirk


using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.IO.Ports;

namespace CANTest10
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private void btnOpen_Click(object sender, EventArgs e)
{
if (serialPort1.IsOpen)
{
btnOpen.Text = "Open";
//reset CAN adapter and close COM port
serialPort1.Write("C ");
serialPort1.Close();
}
else
{
btnOpen.Text = "Close";
// set COM port parameters and open COM port
serialPort1.PortName = "COM4";
serialPort1.BaudRate = 115200;
serialPort1.DataBits = 8;
serialPort1.StopBits = StopBits.One;
serialPort1.Parity = Parity.None;
serialPort1.Open();
//init CAN adapter to read all CAN traffic off CAN bus
serialPort1.Write("C S3 Z0 O ");
}
}

private void serialPort1_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
//if new data arrives in serial port buffer use invoke to display on Windows form
this.Invoke(new EventHandler(ProcessNewData));
}

private void ProcessNewData(object sender, EventArgs e)
{
//read all data received off buffer and display in text box
this.textBox1.Text = serialPort1.ReadExisting();

}
}
}

[candev]

Hi,

die Kiste haengt m.E. genau im serialPort1.Close()-Aufruf. Das koenntest Du mit dem Debugger mal testen. BreakPoint auf den serialPort1.Close()-Aufruf, dann Einzelstep. Haengt die Kiste hier so lange fest oder erst wenn Du das SerialPort-Objekt "loeschst"?

Schade ist, dass Dein Code die relevanten Stellen nicht enthaelt. Wichtig ist, wie und wo Du z.B. das serialPort-Objekt instantiierst und abraeumst.

Das Problem haegt oft mit Resource-Management zusammen. Du kannst unter interpretierten Sprachen und runtime-basierten Sprachen wie C#/Java nicht so programmieren wie in C++. Du solltest insbesondere das Dispose-Pattern ausgiebig nutzen (siehe Microsoft-Seiten). Solange Du wie in VB, C++ oder anderen compilierten Sprachen vorgehst wirst Du noch einen Haufen solcher Probleme bekommen.

Stell erstmal fest wo genau der "Haenger" ist. Die Kiste haengt sich m.E. nicht wirklich auf sondern es dauert einfach saulange, bis das Programm weiter ausgefuerht wird. Zu dem Umgang mit den Ports im besonderen wirst Du aber im Netz ganz gut fuendig.

Ach ja, der Haenger beim Schliessen des ser. Ports mit Close() tritt genauso auch unter C++ auf. Das Verhalten des seriellen Treibers ist, sagen wir mal, nicht gerade amusing. Sollte also der Close-Aufruf der fragliche Knackpunkt sein wirst Du Dich selbst um einen Workaround kuemmern muessen. Bei falschem Resource-Management kannst Du in Deinem eigenen Code Abhilfe schaffen.

Ich bin bei meinem Diagnosetester - auch wegen des Haengers im Close, aber auch wegen der nicht zufriedenstellend arbeitenden Baudraten-Umschaltung und der fehlenden Bitraten-Erkennungsmoeglichkeiten direkt auf der Hardware unterwegs. Das macht weniger Probleme als ueber die von Windows bereitgestellten Moeglichkeiten (API, OCX) zu gehen, allerdings erfordert das einen Geraetetreiber um an die Hardware zu kommen.

Gruß,
Jens

[candev]

Kleiner Auszug aus der Hilfe-Seite zur SerialPort-Port Class, Member Close:

The best practice for any application is to wait for some amount of time after calling the Close method before attempting to call the Open method, as the port may not be closed instantly.

Wenn bei Dir also wirklich der Close-Aufruf die Ursache sein sollte, dann wirst Du
a) damit leben muessen oder
b) wie ich eigenhaendig Abhilfe schaffen muessen.

Viel Erfolg,
Jens

[AudiA4B6US]

Lieber Leser, Du hast keine ausreichenden Rechte um weiter zu lesen, weiter hier.