RS422 Datensenden unter Windows7

[akuk]

Hallo
Beim senden der Daten über ComPort unter Windows werden zwischen den einzelnen
bytes 70 bis 100 uS durch windows eingefügt. Meine transmit funktion sendet jedoch die einzelne Bytes ohne unterbruch (pro Meldung 16 Bytes).
Benützte Komponente : uComPort, (115.2 Kbaud , N , 8, 1).
Die Transmitmethode wird durchgelaufen als Criticalsection, dürfte also nicht durch anderen Task behindert werden.
Wie kann man diese Wartezeiten im Windows verhindern ?
Umgebung : Delphi7, Windows7

[himitsu]

Es gibt ja mehrere Stellen, wo es hängen kann.

Viele ComPort-Komponenten arbeiten in einem Thread, also Senden und Empfangen nicht dort wo du es wegsendest.
Hier kommt es natürlich drauf an, wie da die Synchronisierung arbeitet.

Hier sollte es zwar nicht passieren, aber z.B. bei einigen TCP/IP-Komponenten wird auch nochmal bissl gewartet, ob nochmal was kommt, um besser ein Großes anstatt vieler kleiner Pakete versenden zu können.

Und dann gibt es vermutlich auch nochmal im Treiber/Hardware ein paar Puffer und Verzögerungen,
allerdings würde ich so eine "große" Pause doch eher/erstmal in deiner Komponente suchen.


Test:
CreateFile/TFileStream/... auf 'COM2' (oder welcher es ist), da dann ein Write ausführen und schauen ob es immernoch so lange dauert.
Hier im Windows die Defaults für BAUD und Co. beachten/anpassen, sonst müsstest du nach dem Create noch mit SetCommState das im Programm setzen.

Die alten APIs um AssignFile nicht benutzen, denn dort ist ein Schreib-Lesepuffer integriert. (vor allem für TEXT)


Bei zeitkritischen Anwendungen und wo du selber schon in einem Thread arbeitest, da wäre vermutlich eine synchrone SerialPort-Komponente besser,
aber, wie gesagt, arbeiten fast alle Komponenten asynchron, damit wenn man sie im Haupthread benutzt, nicht das Programm hängen bleibt.

Zitat:

dürfte also nicht durch anderen Task behindert werden

In deinem Programm, aber andere Programme interessiert es nicht.

Bei Einer synchronen Komponente und alles im selben Thread, da könnte man ein

Delphi-Quellcode:

Sleep(0)

vorher einfügen.
Danach wird in einem neuen Slott begonnen und für die nächsten paar dutzend Millisekunden wird der Task nicht unterbrochen.

[akuk]

Hallo Himitsu
Danke für die ausführliche Antwort, ich habe vergessen noch zu erwähnen dass die Methode Transmit
in einem Thread läuft mit: priority:= TpTimeCritical;
Im gleichem Thread ist auch die Methode Receiv wo ich aber keine Verzögerungen festgestell habe.
Interessant ist vielleicht auch noch, es werden 3 Messages zu je 16 Bytes gesendet bei ersten zwei
sind diese Verzögerungen vorhanden,beim dritten keine mehr.
Das würde vielleicht darauf hindeuten was Du geschrieben hast
"..,wird auch nochmal bissl gewartet, ob nochmal was kommt "

Ich werde Deine Vorschläge probieren und sehe was passiert.
Vielen Dank
Anton

[samso]

Zitat:

Zitat von akuk (Beitrag 1471809)

Hallo
Beim senden der Daten über ComPort unter Windows werden zwischen den einzelnen
bytes 70 bis 100 uS durch windows eingefügt. Meine transmit funktion sendet jedoch die einzelne Bytes ohne unterbruch (pro Meldung 16 Bytes).
Benützte Komponente : uComPort, (115.2 Kbaud , N , 8, 1).
Die Transmitmethode wird durchgelaufen als Criticalsection, dürfte also nicht durch anderen Task behindert werden.
Wie kann man diese Wartezeiten im Windows verhindern ?
Umgebung : Delphi7, Windows7

Ich habe zunächst mal Probleme die Fehlerbeschreibung zu verstehen. Du schreibst "zwischen den einzelnen bytes". Deine Message besteht aus 16 Bytes. D.h. du hast 15 Lücken von 70-100µs? Oder hast Du zwischen den Messages (je 16 Bytes) eine Verzögerung von 70-100µs. Wie misst Du die Verzögerungen? Mit einem Oscilloskop auf der Leitung?

[akuk]

Hallo samso
Zwischen der einzelnen Bytes hat es Lücken, siehe LA Aufzeichnung auf der Emfängerseite
Signale Rx-/RX+ in der Beilage.
Hier Ausschnitt aus der Methode Transmit, genau die aufgezeichnete Meldung
.......
else // alle 16 + 1 Byte Meldungen S1 bis S9
begin
OutMsg.Meldung[0]:= OutType; // MeldungsTyp (Byte 0) setzen
for i:=0 to 16 do //Byte 0 bis 16
Comport.SendByte(OutMsg.Meldung[i]);
MldgOK := true; // Meldung gesendet
end;
end;//case

Gruss Anton

[akuk]

Hallo
Die LA Aufzeichnung ist nicht mitgekomme, hier die Korrektur

[TurboMagic]

Sehe immer noch keine Aufzeichnung...
Wie soll die Aussehen? Screenshot?

[akuk]

Anhang 52905

[akuk]

sorry das war genau die dritte Message, anbei das mit Lücken, 1. Message
Anhang 52907

[samso]

Zitat:

Zitat von akuk (Beitrag 1471831)

Hallo samso
Zwischen der einzelnen Bytes hat es Lücken, siehe LA Aufzeichnung auf der Emfängerseite
Signale Rx-/RX+ in der Beilage.
Hier Ausschnitt aus der Methode Transmit, genau die aufgezeichnete Meldung
.......
else // alle 16 + 1 Byte Meldungen S1 bis S9
begin
OutMsg.Meldung[0]:= OutType; // MeldungsTyp (Byte 0) setzen
for i:=0 to 16 do //Byte 0 bis 16
Comport.SendByte(OutMsg.Meldung[i]);
MldgOK := true; // Meldung gesendet
end;
end;//case

Gruss Anton

Ok, danke für den Quelltext.

Für mich sieht das so aus, als wenn dieses Comport.SendByte tatsächlich auf die Übertragung des Bytes wartet. Denn 87µs ist ja gerade die Zeit für die Übertragung eines Bytes. Bietet Comport denn nicht die Möglichkeit einen kompletten Puffer zu schicken? Also alle 16 Bytes in einem Rutsch?

[KodeZwerg]

Zitat:

Zitat von samso (Beitrag 1471837)

Bietet Comport denn nicht die Möglichkeit einen kompletten Puffer zu schicken? Also alle 16 Bytes in einem Rutsch?

Gibt es, man muss es nur anders nutzen als vom Entwickler gedacht.

Delphi-Quellcode:

procedure SENDSTRING(Buffer: Pchar);        // Text über die serielle Schnittstelle senden

Falls das hier genutzt wird.

[samso]

Zitat:

Zitat von KodeZwerg (Beitrag 1471839)

Zitat:

Zitat von samso (Beitrag 1471837)

Bietet Comport denn nicht die Möglichkeit einen kompletten Puffer zu schicken? Also alle 16 Bytes in einem Rutsch?

Gibt es, man muss es nur anders nutzen als vom Entwickler gedacht.

Delphi-Quellcode:

procedure SENDSTRING(Buffer: Pchar);        // Text über die serielle Schnittstelle senden

Falls das hier genutzt wird.

Da diese Klasse nicht mit Delphi 10.3 kompatible ist, kommt sie eher nicht in Frage :shock:.

[KodeZwerg]

Zitat:

Umgebung : Delphi7, Windows7

Ich las nirgends von wo uComPort her kommt, tut mir leid das war nur ins blaue geraten und ich bin auch schon wieder still.

[samso]

Ich würde mal messen wie lange die Transfer-Schleife braucht (->QueryPerformanceCounter).

Normalerweise sollte sie eigentlich überhaupt keine Zeit benötigen, weil die Daten ja lediglich in den Puffer der seriellen Schnittstelle übertragen werden müssen.

[samso]

Zitat:

Zitat von KodeZwerg (Beitrag 1471843)

Zitat:

Umgebung : Delphi7, Windows7

Ich las nirgends von wo uComPort her kommt, tut mir leid das war nur ins blaue geraten und ich bin auch schon wieder still.

Stimmt Du hast recht, ich hatte mich an der Version im Profil orientiert. Die Klasse ist trotzdem schauderhaft. SENDSTRING erwartet leider einen abschließendes 0-Byte. Also eher nicht brauchbar. Die Klassen könnte aber erweitert werden:

Delphi-Quellcode:

procedure TComport.SendBuffer(const Buffer; Len: Integer); // Einen Puffer senden.
var BytesWritten: DWord;
begin
  WriteFile(PortHandle, Buffer, Len, BytesWritten, NIL);
END;

[himitsu]

Ein Problem ist erstmal, dass WriteFile auf eine Serielle Schnittstelle nicht asynchron arbeiten kann. (kein Overlapped möglich) und besser auch nur innerhalb eines Thread behandelt werden sollte.
Da aber viele SerialPort-Komponenten asynchron arbeiten wollen, müssen sie es dann irgendwie (teilweise echt pervers) in einen eigenen Thread übergeben.


Wer wirklich zeitkritische Dinge machen will, sollte sich daher eine synchrone Komponente basteln.
Ich hab mir vor 'ner Weile etwas für einen FingerPrintReader gebaut, aber hatte noch keine Zeit das in eigenständige eine Komponente auszulagern.
(allerdings kann ich versprechen, dass es keine endlose Abwärtskompatibilität geben wird ... maximal bis XE3 ... eher neuer, so ab XE8 oder 10)



Willst dir 'nen CNC basteln?
Meine GUI hatte ich mal angefangen, aber viel gibt es noch nicht.
Allerdings nutze ich einen Arduino mit einem angepassten Grbl, um vom Computer halbwegs entkopelt zu sein und mit zeitkritischen Dingen keine Probleme zu haben.
Windows ist kein Echtzeitsystem und auch wenn es Ansätze gibt das zu beheben, will ich mich damit nicht befassen wollen.

Ich selbst habe aber keine Problme, egal ob zwischen den Zeichen oder Zeilen Pausen sind, da es im Grbl/Arduino einen Cache gibt, wo die nächsten Befehle bereits vorgeladen sind und somit Pausen ignoriert werden.

[KodeZwerg]

Mist, nun schreib ich doch nochmal :-]

Zitat:

Zitat von samso (Beitrag 1471849)

SENDSTRING erwartet leider einen abschließendes 0-Byte. Also eher nicht brauchbar.

Ich hatte es mir so gedacht, ohne seperate methode zu entwerfen:

einen PAnsiChar mit 16 bytes füllen, abschließend sich irgendein byte ausdenken zum terminieren, da ja vielleicht auch mal weniger als 16 oder mehr....
dann SendString(Buffer) ausführen.
dann sollte ja

Delphi-Quellcode:

function  READSTRING() : Pchar;             // Text über die serielle Schnittstelle empfangen

was empfangen haben.
das dann wiederum bis zum selbst erfundenen terminierer byte auswerten.

//edit
Oder halt generell immer nur bis "length(buffer) -1" auswerten ginge auch denk ich mal.

[akuk]

Hallo
besten Dank an Alle, der Hinweis :

"die Möglichkeit einen kompletten Puffer zu schicken?
Also alle 16 Bytes in einem Rutsch?"

war Goldwert.

Ich habe versuchsweise eine Methode gemacht in Abänderung von SENDSTRING :
//--------------------------------------------------------
T_OutMld = packed array [0..16] of byte;
//------------------------------------------------
procedure TComport.SendArray (Data : T_OutMld);
var BytesWritten: DWord;
begin
WriteFile(PortHandle,Data,17,BytesWritten,NIL);
END;
//--------------------------
und es lauft ohne Unterbrechungen, ich muss es noch für gössere Anzahl Bytes testen als 17.
Bsten Dank für Euere Hilfe
Anton

an himitsu:www.zuritronic.com

[Andreas13]

Hallo Anton,
Du kannst Deinen QuellCode hier mit Hilfe des Delphi-Symbols (= Helm mit rotem Kamm) richtig formatieren, damit er besser lesbar ist.
Gruß, Andreas

[samso]

Zitat:

Zitat von akuk (Beitrag 1471864)

Hallo
besten Dank an Alle, der Hinweis :

"die Möglichkeit einen kompletten Puffer zu schicken?
Also alle 16 Bytes in einem Rutsch?"

war Goldwert.

Ich habe versuchsweise eine Methode gemacht in Abänderung von SENDSTRING :

Delphi-Quellcode:

//--------------------------------------------------------
T_OutMld    = packed array [0..16] of byte;
//------------------------------------------------
procedure TComport.SendArray (Data : T_OutMld);
var BytesWritten: DWord;
begin
  WriteFile(PortHandle,Data,17,BytesWritten,NIL);
END;

//--------------------------
und es lauft ohne Unterbrechungen, ich muss es noch für gössere Anzahl Bytes testen als 17.
Bsten Dank für Euere Hilfe
Anton

an himitsu:www.zuritronic.com

Falls Du die etwas universellere Methode TComport.SendBuffer (s. #15) benutzen möchtest, geht das z.B. so:

Delphi-Quellcode:

var
  Msg: T_OutMld;
begin
  Comport.SendBuffer(Msg, Length(Msg));
end;