Hallo Forenmitglieder,
ich arbeite seit einiger Zeit an einer Software, die mittels einer
seriellen Schnittstelle (RS485) Daten eines Distanzsensors ausliest.
Soweit so gut. Die Übertragung funktioniert reibungslos und die
Messwerte sind plausibel.
Nun zum Problem. Der Sensor sollte laut Herstellerangaben mit einer
Frequenz von 500Hz Messwerte liefern. Das ist leider nicht der Fall.
Wenn ich den datenstrom mit einem Terminal aufzeichne, kann ich etwa
eine Frequenz von 50Hz ableiten. Ich stelle mir nun die Frage, ob das
programmierseitige Gründe haben könnte. Mein Code (Auszüge):
Programmiert wurde das ganze unter XP mit dem Visual Studio 2008 (C++)
mithilfe von MFC und der Bibliothek CSerial. Das ganze läuft in einem
separatem Thread und kann durch die while Bedingung abgebrochen werden.
Vielleich sieht jemand die Ursache auf anhieb. Zu erwähnen wäre vlt.
noch, dass der Sensor nicht direkt an die serielle Schnittstelle des
Rechners angeschlossen ist. Durch einen Adapter + zugeh. Treiber ist der
Sensor mittels USB am Rechnerangeschlossen und der Com-Port erzeugt.
Einen identischen Programmcode habe ich für einen weiteren Distanzsensor
(aber RS232) verwendet, bei welchem alles einwandfrei funktioniert.
Deshalb fehlen mir zur Zeit die Lösungsansätze...
Vielen Dank und beste Grüße,
Robin
Ich habe den Sensor jetzt testweise direkt an die serielle Schnittstelle
des Rechners angeschlossen. Das Problem der niedrigen Frequenz besteht
trotzdem noch. Also schließe ich den Treiber als Fehlerquelle aus. Also
doch die Programmierung?
Robin Ullrich schrieb:> Also doch die Programmierung?
dann teste mal ohne das ganze Overlapped zeugt. Das zieht mir unnötig
kompliziert aus. Einfach nur ein open und read in der schleife sollte
dafür doch reichen.
Das sollte auch mit Overlaped gehen. Allerdings dürften die Buffer zu
klein sein. Was hast Du denn beim g_Serial.Open(...) für Queuesizes
angegeben? Am besten mal mittels GetCommProperties(...) nachsehen, wie
die defaults sind und was da maximal möglich ist. Deinen Lesebuffer
solltest Du auch wesentlich größer machen, am besten den selben Wert wie
für die Queuesizes verwenden.
Beim auslesen der CommProperties (siehe Datei im Anhang) wird die
maximale Rx bzw Tx Queue mit Null angegeben, wodurch meiner Meinung nach
des Öffnen des Com Ports ohne die Prameter möglich ist (??).
Auch beim erhöhen des Read Buffers wird keine signifikante Steigerung
der Frequenz während des kontinuierlichen Messens erreicht.
Neu ist dagegen, dass beim Start der Messung die ersten ca 150 Messwerte
derart schnell übermittelt werden, dass es den Anschein macht, dass die
herstellerseitige Messfrequenz erreicht wird (500Hz). Danach stagniert
der Prozess leider wieder und die Messwerte werden wieder mit der
bereits angesprochenen Frequenz von ca 50Hz übermittelt...
Robin Ullrich schrieb:> Neu ist dagegen, dass beim Start der Messung die ersten ca 150 Messwerte> derart schnell übermittelt werden, dass es den Anschein macht, dass die> herstellerseitige Messfrequenz erreicht wird (500Hz). Danach stagniert> der Prozess leider wieder und die Messwerte werden wieder mit der> bereits angesprochenen Frequenz von ca 50Hz übermittelt...
kann es sein das es an der ausgaben liegt? Denn hier
do{
iResult = g_Serial.Read(szBuffer,sizeof(szBuffer)-1,&dwBytesRead);
}while(something)
würdest ja überhaupt nicht erkennen ob es daten ankommen. Kannst ja mal
so testen:
int test = 0;
do{
iResult = g_Serial.Read(szBuffer,sizeof(szBuffer)-1,&dwBytesRead);
test += dwBytesRead;
if ( (test % 100)==0 ) print(".");
}while(something)
Peter schrieb:> würdest ja überhaupt nicht erkennen ob es daten ankommen
Ich habe nebenbei immer ein Terminalprogramm laufen, was den Datenstrom
der ComPorts überwacht. Dadurch kann ich aussagen über die Frequenz
machen. Trotzdem habe ich deinen Vorschlag getestet und komme zum
gleichen Ergebnis. Dabei ist mit noch folgendes aufgefallen:
In meinem Programm habe ich quasi zwei ineinander geschachteltet
do-while-Schleifen:
1
do
2
{
3
do
4
{
5
//Read Data
6
}
7
while(BytesRead>0);
8
}
9
while(Abbruchkriterium);
Durch deinen Ansatz ist mir jetzt folgendes Aufgefallen. Ab einem
gewissen Punkt (Anzahl der Messwerte variieren) wird die innere Schleife
verlassen, also nichts gelesen. Für den ersten Durchlauf ist das dann
genau der Punkt, an dem die Datenrate stark sinkt.
Wenn ich das Programm neu starte, tritt dieser Effekt immer weiter auf:
- Erster Schleifendurchlauf: Höchste Frequenz
- Folgende: Frequenz bedeutend niedriger
Nun die Frage warum... Kann der Grund ev durch das Nichtsetzen von
Signalpegeln sein? Sowas in der Art wie SETRTS oder CLRRTS? Bin auf dem
Gebiet eher unbelesen.
Heia Jetzt-aber schrieb:> soll das ein Witz sein
Wie eingehend erwähnt, mit einem ähnlichen Sensoren kein Problem. Die
Spezifikationen verlangen übrigens den Einsatz eines PCs.