Windows echtzeitfähig mit Delphi

[luisk]

gibt es eine Möglichkeit, Windows echtzeitfähig zu machen ?
Es gibt RT-Kernal, die sind aber sehr teuer .

[himitsu]

Nein,

abgesehn von

Zitat von luisk:

Es gibt RT-Kernal, die sind aber sehr teuer .

und das eventuell auch nicht unbedingt immer 100%ig.


Was heißt denn "Echtzeit", bzw. was willst du erreichen?



Echtzeit wäre praktisch nur möglich, wenn das Programm der einzige Prozess auf dem Kern wäre und wenn es sonst von nirgendwo unterbrochen oder gebremst werden könnte.
=> also keine störenden Interrups und alleiniger Zugriff auf die sonstige Hardware (Speicher, Festplatte usw.)
Und das ist praktisch nahezu unmöglich.

[luisk]

Die machen sowas
http://www.kithara.de/de
http://www.kithara.de/de/loesungen/echtzeit-ethernet

http://www.sybera.de/german/g_sybera.htm

Warum bieten Microsoft oder Embaccadero so einen Modus nicht an,
sondern nur Spielerei ?

[BUG]

Zitat von luisk:

Warum bietet Microsoft oder Embaccadero so einen Modus nicht an, sondern nur Spielerei ?

Weil Echtzeitanwendungen für Windows eben eine Nische sind: Für Echtzeitanwendungen hat man halt andere Anforderungen als an ein allgemeines Betriebssystem.
Das es Firmen gibt, die es schaffen solche Lösungen anbieten, ist bewundernswert ... und vermutlich jeden Euro wert.

[himitsu]

Wobei die nicht wirklich 100% Echtzeit anbieten, vorallem seit Windows 8 nicht mehr, da dort vom Windows die CPU geschützt wird.

Im Prinzip geht es darauf hinaus, da die spezielle Sorftare einsetzen, welche gezieht auf diese Aufgabe ausgelegt wurde und dazu noch spezielle Hardware und von der CPU resservieren die sich komplette Kerne in der CPU nur für sich (was aktuell für Win8 im kombinierten RealTime- und NonRealTime-Betrieb nicht mehr möglich ist), welche praktisch komplett getrennt von Windows nur noch für die RealTime-Anwendungen laufen.
Dazu dann noch spezielle Treiber und alles von Windows und Programmen wird mit viel Aufwand von dem System abgekoppelt, bzw. nur mit speziellen Schnittstellen nach außen freigegeben.


Dazu läuft alleine ein billiges Delphi-Program, im Normalbetrieb, gleich mal mit 5 bis 20 Threads (inkl. Styles, Datenbankverbundung usw.), welche sich alle die CPU und Resourcen teilen müssen und vorallem die ihre Resourcen sharen/synchronisieren.
Und schon wird klar, warum das mit Delphi nicht geht.

Die bieten zwar eine Schittstelle zu C# an (was man vestimmt auch zu Delphi hinbekommt), aber der Code vom C#/Delphi wird dann nicht in Echtzeit ausgeführt.


Es gibt extrem abgespeckte Linux-Kernel, wo man fast alles rausgeworfen hat, damit möglichst wenig reinfunken kann, womit man dann praktisch auch sowas wie Echtzeit in speziell angepassten Programmen/Programmteilen hinbekommt.

Zitat von BUG:

Das es Firmen gibt, die es schaffen solche Lösungen anbieten, ist bewundernswert ... und vermutlich jeden Euro wert.

Das ist so, als wöllte man zur Rush Hour geziehlt eineige Autos mit einer bestimmten Geschwindigkeit und zu ganz bestimmten Zeiten (Sekundengenau) quer durch Berlin schicken ... selbst wenn man versucht eine Minute vorher per Polizei alle Straßen freizumachen, wird das nicht grade einfach werden.

[luisk]

Zitat von himitsu:

Was heißt denn "Echtzeit", bzw. was willst du erreichen?

Ich hab in Delphi eine objektorientierte Software-SPS entwickelt mit einer vollintegrierten 3D-Visualisierung in OpenGL.

Schwachpunkte:
1. OpenGL bietet keine gescheiten Schriften, da muss man GDI-Bitmaps alias Texturen reinpfuschen.
2. dieses Betriebssystem von MS hat keine Echtzeitfähigkeit.

Meine in Delphi realisierten SPS-Binärbefehle inclusive SFC( s.Siemens) benötigen
ca. 50ns (aufm Laptop 2,5 Ghz.)

Wenn ich über einen Timer oder einen Tread triggere komme ich von System her nur auf Zykluszeit von 15 ms. also 300000 mal so langsam.

[himitsu]

Du wirst immer Pausen bekommen, selbst wenn man die Thread- und Process-Priority extrem hochschraubt und "versucht" überall die Prozesse an bestimmte Kerne zu binden. (sowas machen diese Echzeitspezialisten raktisch und der Aufwand dafür ist nicht grade sehr gering, wenn das durchgängig und vorallem zuverlässig funktionieren soll)

Es gibt ja immer mehr Prozesse als CPU-Kerne, womit Windows deinen Prozess vermutlich immer mal wieder aus der CPU rauswirft, um andere Threads bearbeiten zu können. Damit wird dein Thread also immer mal wieder kurz schlafengelegt. (Windows schaltet das durchschnittlich so etwa alle 15-50 Millisekunden um)

Und Timer kannst'e eh vergessen denn der liebt numal aktuell bei einer Auflösung von etwa 15-16 Millisekunden -> siehe die vielen Threads zu GetTickCount und sessen Auflösung.
Abgesehn von gewissen Multimediatimern, welche oft auch über Threads getriggert werden.

[Harry Stahl]

Zitat von luisk:

Wenn ich über einen Timer oder einen Tread triggere komme ich von System her nur auf Zykluszeit von 15 ms. also 300000 mal so langsam.

Hast Du dazu einen Multimedia-Timer verwendet? Damit kann man zumindest in einem Intervall von 1 MS triggern.

Zur Messung kann man einen Highperformancecounter (QueryPerformanceCounter) verwenden, der auch im Nanobereich messen kann (einige hundert Nanosekunden).

[BUG]

Im Nanosekunden-Bereich werden selbst solche Sachen wie Cache-Misses interessant. Da wird es schon extrem eng.
Neben dem Scheduling können dir auch Interrupts den Spaß verderben, TLB-Misses, Paging ... im Prinzip alles was nicht dein Code ist.

Andererseits ... wenn du Aussetzer/Jitter verträgst und nicht gerade ein Atomkraftwerk an deiner Steuerung hängt: Ich würde es ausprobieren ... vielleicht genügt es dir ja.
"Echtzeit"-Priorität, alles andere auf einen anderen physischen Kern. In diesem "Echtzeit"-Thread läuft dann nur das absolut nötige und wenn du warten musst, dann wartest du halt aktiv.

[Namenloser]

Generell ist das mit „Echtzeit“ so eine Sache. Es hängt ja nicht nur am Scheduling, sondern auch so Dinge wie Speicherverwaltung, evtl. Swapping, und propabilistische Algorithmen (z.B. Quicksort) muss man berücksichtigen. Die ganze Laufzeitbibliothek muss echtzeitfähig sein. Die Delphi-RTL ist auf sowas aber nicht ausgelegt, und auch OpenGL dürfte damit kaum vereinbar sein.

Ich habe keine Erfahrung mit Echtzeitsystemen, aber ich denke, die einzige sichere Lösung wäre, den Echtzeit-Teil von der Oberfläche komplett physisch zu trennen. Also einen dedizierten Rechner/Platine (?), der sich nur um die Ansteuerung der Maschine kümmert und mit einem abgespeckten Echtzeit-Kernel (oder gleich ohne Betriebssystem) läuft, und einen getrennten Rechner mit Windows, auf dem die Benutzeroberfläche läuft. Die beiden Rechner kommunizieren dann über eine serielle Schnittstelle o.ä..