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:

Zitat von luisk (Beitrag 1268386)

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:

Zitat von luisk (Beitrag 1268388)

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:

Zitat von BUG (Beitrag 1268391)

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:

Zitat von himitsu (Beitrag 1268387)

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:

Zitat von luisk (Beitrag 1268394)

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.ä..

[luisk]

Zitat:

Zitat von Harry Stahl (Beitrag 1268407)

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

Danke für Tipp
werde ich mal testen:http://www.delphipraxis.net/172777-m...dia-timer.html

Da steht, dass timeSetEvent durch CreateTimerQueueTimer function ersetzt wurde:
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

timesetevent funktioniert unter Delphi 6.
Auf CreateTimerQueueTimer kann ich mit Delphi 6 nicht zugreifen. Gibt es dazu eine Unit ?

[hanspeter]

Ich habe so was mal für Prüfstände gemacht.
Da wird für einige Sensoren eine Abtastrate von 1 ms benötigt.
Gesteuert habe ich das ganze über einen hoch priorisierten Thread, der den Zeittakt erzeugt.
Das Programm ist allerdings das einzige Programm, welches auf dem Rechner läuft.
Für industrielle Aufgaben bietet sich noch eine Soft-SPS an.
Die läuft in einer Schicht unter Windows und bietet einen reproduzierbaren Zeittakt ab 100 ns an.
Auf dieser Basis habe ich auch eine größere Anlagensteuerung am Laufen.
Zwischen Prozess-Sensorik und PC eine kleine SPS, da gibt es auch einige preiswerte und fertig konfektionierte Lösungen.

Peter

[Sherlock]

Windows ist prinzipbedingt nicht echtzeitfähig. Alles was man drumherum dranflanscht macht es nur vordergründig besser, in wirklichkeit aber schlechter. Wenn Du sowas wirklich brauchst, dann benutz doch ein echtes RTOS, so wie LynxOS oder RT Linux. Freilich wirst Du mit Delphi da nicht weit kommen, aber eventuell gibts ja nen FPC dafür.

Sherlock

[hanspeter]

Zitat:

Zitat von Sherlock (Beitrag 1268429)

Windows ist prinzipbedingt nicht echtzeitfähig. Alles was man drumherum dranflanscht macht es nur vordergründig besser, in wirklichkeit aber schlechter. Wenn Du sowas wirklich brauchst, dann benutz doch ein echtes RTOS, so wie LynxOS oder RT Linux. Freilich wirst Du mit Delphi da nicht weit kommen, aber eventuell gibts ja nen FPC dafür.

Sherlock

Du hast schon mal mit einer industriellen Soft-SPS (z.B.) Beckhoff unter Windows gearbeitet?
Windows selbst ist vom Prinzip nicht oder nur eingeschränkt echtzeitfähig. Ist in dieser Richtung aber erweiterbar.
Dazu bieten einige Firmen industriuetaugliche Lösungen an (z.B. Beckhoff oder Kithara).
Ich habe mehrere Industrieanlagen auf Basis dieser Technologie realisiert.
Die laufen seit Jahren stabil(24/365). Im Sensorbereich wird teilweise eine Taktrate von 500 ns realisiert.
Die SPS ist in strukturierten Text (Pascal ähnlich) realisiert. Die Bedienoberfläche in Delphi.

[luisk]

Hier steht, dass timeSetEvent durch CreateTimerQueueTimer function ersetzt wurde:
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

timesetevent funktioniert unter Delphi 6.
Auf CreateTimerQueueTimer kann ich mit Delphi 6 nicht zugreifen.
Gibt es dazu eine Unit für Delphi 6?

[Harry Stahl]

Zitat:

Zitat von luisk (Beitrag 1268416)

timesetevent funktioniert unter Delphi 6.
Auf CreateTimerQueueTimer kann ich mit Delphi 6 nicht zugreifen. Gibt es dazu eine Unit ?

Ich verwende CreateTimerQueueTimer nicht, TimeSetEvent funktioniert auch bis unter Windows 8.1 ohne Probleme.

In den aktuellen Delphi-Versionen ist es in der Winapi.Windows-Unit importiert.

Aber Du kannst das ja selber in einer Unit importieren:

Delphi-Quellcode:

function CreateTimerQueueTimer; external kernel32 name 'CreateTimerQueueTimer';

[luisk]

TimeSetEvent funktioniert bei mir auch mit D6 unter Win8.1
Allerdings würde ich das Event gerne auf eine Prozedur einer Klasse setzen.
Das hat jedoch nicht funktioniert. Ist das überhaupt möglich ?
Multimedia Timer
You can't declare the TimeCallBack as a method of an object, it must be a
stand-alone function http://www.delphigroups.info/2/5a/498369.html


Danke für den Tipp mit CreateTimerQueueTimer.

[hathor]

Hier ist ein Programmpaket incl. TksTimer.pas:
https://kstools.googlecode.com/files/ksTools050.zip

Zitat:
TksTimer is a high resolution replacement for the standard VCL TTimer component.

TksTimer is a wrapper for the Win32 API functions CreateTimerQueueTimer and DeleteTimerQueueTimer.

When the Enabled property of TksTimer instance is assigned True, an underlying queue timer is created. If DueTime is nonzero and Period is zero, the timer is signaled only once after due time. If the DueTime and Period properties are both nonzero, the timer will be signaled first at the due time, then periodically. A periodic timer automatically reactivates each time the period elapses, until an underlying queue timer is canceled by setting the Enabled property to False. When the timer is signalled, the OnTimer event is triggered. The timer events are subject to scheduling delays, so the timing can vary depending on what else is happening in the application or the system.

Interval____TTimer____TksTimer
------------------------------
100_________108_________100
50__________62__________50
20__________31__________20
10__________15__________11
5__________15___________6
2__________15___________3
1__________14___________2

[stoxx]

Zitat:

Zitat von hanspeter (Beitrag 1268422)

Die läuft in einer Schicht unter Windows und bietet einen reproduzierbaren Zeittakt ab 100 ns an.
Peter

Kannst Du vielleicht bitte etwas näher darauf eingehen, wie Du das realisiert hast?
Es scheint, als sei alles auf Millisekunden unter Windows ausgerichtet ...
Danke Dir :-)

[himitsu]

Zitat:

Zitat von stoxx (Beitrag 1268508)

Kannst Du vielleicht bitte etwas näher darauf eingehen, wie Du das realisiert hast?

Wurde doch erwähnt?
QueryPerformanceCounter

[Harry Stahl]

Übrigens, wer das noch nicht kennt: Seit - ich glaube D2010? - gibt es in Delphi die Unit Diagnostics, die

{************************************************* ******}
{ Support for high-precision timing utilities }
{************************************************* ******}

enthält.

Seit XE2 ist die Unit (System.Diagnostics) crossplattform-fähig, kann man also auch unter Windows (VCL und FMX) und MAC OS X einsetzen.

Mit dem Record TStopWatch kann man ganz einfach hochpräzise Zeitmessungen vornehmen.

[Dejan Vu]

Geht es immer noch um RT-Fähigkeit von Windows, oder um Versuche, das Unmögliche möglich zu machen?

Ich habe viel mit der Beckhoff-SPS gemacht: Wirklich brauchbar, das Teil.

[Medium]

Ich habe da eine Randfrage, wo sich hier gerade die ganzen Soft-SPSler versammeln: Warum setzt ihr diese ein?

Ich frage, weil meine Brötchen auch aus Steuerungen kommen, und ich bisher nicht wirklich den Vorteil von einer "emulierten" SPS begriffen habe. Für die E/A brauche ich doch auch dort wieder spezielle Hardware, oder? Und so ein PC, industrietauglich, schnell genug für ausreichend kurze Taktzyklen bei mittleren bis größeren Steuerungen (wir machen hauptsächlich ganze Betriebe, nicht nur einzelne Maschinen), kostet ja auch nicht so arg viel weniger als eine mittelgute S7-300 CPU. Mit dieser habe ich dann aber ein schön entkoppeltes, lange getestetes, qualitativ zumindest in gewissem Rahmen gesichertes Produkt, dass ich ruhigen Gewissens auch in warmen Schalträumen unbeaufsichtigt machen lassen kann.
Und ich würde mich arg unwohl fühlen, einen PC mit mehr Dingen zu betrauen als eine Soft-SPS, weil ich eben wegen angeprochener Nicht-Echtzeitfähigkeit um meine Zyklen bangen würde. Dazu der Vorteil einfacher Integration von Dingen wie z.B. F-Baugruppen, Siwarex Karten, etc. pp - also die gesamte Infrastruktur um eine SPS herum. Und eine SPS neigt weit weniger zu Abstürzen aufgrund von wasweissich für Schluckaufs, den PCs ja ab und an mal haben.

Kommunikation ist auch kein großes Problem: S7-Online Verbindung via LibNoDave, und ich komme ratzefatze an alles ran. Alles. Dazu braucht es nichtmals einen CP oder projektierten Datenaustausch, die SPS legt einfach, und liest alles in/aus ihre/n DBs und hat aktiv nichts mehr mit der Kommunikation an sich zu tun.

Dazu noch, dass sich eine SPS viel einfacher und kostensparender (weil weniger verbrauchend) mit einer USV versorgen lässt, uuuuund das ganze ist auch noch hübsch klein und handlich auf einer Alu-Schiene angeordnet. Warum wöllte ich da eine Soft-SPS einsetzen? Welchen Vorteil böte das? Wo ist da das Einsatzgebiet?

[Dejan Vu]

Ich habe für eine Firma gearbeitet, die Beckhoff eingesetzt hat. Kein Programmierer hat sich gefreut, S7 zu machen, im Gegenteil: Alle haben gekotzt. Mit diesem CoDeSys-Zeugs (Pascal-ähnlich) kann man ganz brauchbar programmieren, OOP geht zwar nicht, aber Clean Code Ansätze schon.

Eigentlich ist die Beckhoff-SPS (also das TwinCat) ein Treiber, der auch dann noch läuft, wenn Windows ordentlich abgeschmiert ist. Windows ist hier nur der Aufsatz für eine HMI (lustig, die ist auch in Delphi geschrieben. Scheint Mode zu sein). Die SPS schnappt sich feste 80% (einstellbar) der CPU. Mit dem Rest kannst Du machen, was Du willst. Das reicht für ziemlich brauchbare Tools, Datenbankanbindung, HMI etc.

Es ist garantiert, das die Zyklen eingehalten werden (wenn die Steuerung mitspielt, ist ja logisch)

Die Industrie-PC sind -wenn sie den Montagstest überstanden haben- sehr zuverlässig. Die kosten ein wenig mehr, als ein PC von Saturn, aber dafür haben die keinen Lüfter, sind schnell genug usw. Der ganze Schmonz ist in einem Schaltschrank.

Die Firma hatte sich sehr früh für Beckhoff entschieden, weil die Maschinensteuerungen sehr komplex waren und man sich mit S7 vermutlich einen abgebrochen hätte. Weiterhin haben die Programmierer ein Framework entwickelt, das sich auf so ziemlich alle (Sonder-) Maschinen von denen anwenden ließ. Man hat die ganzen Bibliotheken importiert, die man so brauchte, alle Listen angelegt und konnte dann die Maschine ziemlich flott programmieren. Anpassen und Entwanzen dann in der Halle und beim Kunden.

Die Pharmaindustrie wollte wohl unbedingt S7 und dann mussten einige Programmierer umschulen. Glücklich waren die dabei aber nicht.

[Medium]

Ich vermute fast, dass CoDeSys sich nicht allzu stark von SCL unterschiedet, da es hier imho auch Standards zu gibt. (Auch kein OOP, aber strukturiert.) Die meisten SPS Programmierer kennen aber fast nur KOP/FUP und mit etwas Glück genug AWL für den einen oder anderen Kunstgriff. Aber mit SCL lassen sich die wildesten Dinge bauen, bei denen sich unsere Kunden ab und an auch wunderten, dass das mit der SPS alleine möglich ist, ohne einen PC als "Kopf".
Die wenigsten SPSler sind Informatiker, die Regel sind hier eher Elektriker, die sich mehr oder weniger fortgebildet haben. Für die ist KOP/FUP sicherlich prima, ich bekomme da auch leichte Anfälle :D. SCL/AWL sind bei uns die Mittel der Wahl, womit wir z.B. eine komplette sehr variable Rezeptsteuerung in der SPS selbst realisiert haben. Bei BATCH steht ja alles wenn der Leit-PC weg schmiert. Passiert das bei uns, rennt die gesamte Anlage dennoch weiter - ein großer Vorteil wenn chemische Prozesse ablaufen, denen es egal ist wenn was ausfällt. Das Zeug reagiert einfach weiter! Einzig manuelle Eingriffe und Visu sind dann weg, aber deshalb hat man ja noch Taster und Leuchten für ganz kritische Dinge.

Ich lese daher aus deinem Beitrag, dass es im Wesentlichen auf den jeweilig etablierten Firmenstandard (inkl. der bestehenden selbst entwickelten Tool-Chain) und persönliche Zuneigung zurück geht.

Delphi findet sich in der Industrie übrigens noch verhältnismäßig oft. Ich vermute stark, dass das daran liegt, dass die Wurzeln dieses Zweigs gerade da lagen, wo Turbo Pascal so richtig Fahrtwind aufgenommen hat, und dank seiner Syntax in technischen Berufen gerne gelehrt wurde. Sieht man auch schon daran, dass Sprachen wie SCL und CoDeSys so Pascal ähnlich sind. Ich treffe öfter mal offensichtliche Delphi-Progrämmchen an.

[Dejan Vu]

Zitat:

Zitat von Medium (Beitrag 1268546)

Zeug reagiert einfach weiter! Einzig manuelle Eingriffe und Visu sind dann weg, aber deshalb hat man ja noch Taster und Leuchten für ganz kritische Dinge.

Genau das geht natürlich auch mit einer Soft-SPS.

Anhand der Gesichter der Programmierer (die sich an Pascal gewöhnt haben) würde ich annehmen, das S7 einfach schmerzhaft ist. Irgendwie war da was mit Variablen, Strukturen (CodeSys hat Records und Methoden für Records (Funktionsbausteine FB)).

[hanspeter]

Die Soft-SPS ist reiner Installationsaufwand.
Rechner kaputt , irgendein neuer - Installation und fertig.
Der Bus kann z.B. auch über Eternet angeschlossen und damit auch relativ problemlos simuliert werden.
Die Beckhoff SPS kann übrigens 4 SPS unabhängig und parallel realisieren.
Da ich das TWincat als Demo-Version auf dem Rechner daheim installieren kann, habe ich ein eigenes Entwicklungssystem im Büro stehen.
Mit der Demo Version verfährt Beckhoff ziemlich großzügig. Diese ist in der Laufzeit auf 4 Wochen begrenzt.
Nach Ablauf deinstallieren und wieder neu installieren und die Laufzeit beginnt von vorn.
Die SPS Hardware (Buskoppler und E/A) sind im Vergleich preiswert.

Peter
Auf SPS Ebene kann übrigens auch mit C programmiert werden.

[Dejan Vu]

Zitat:

Zitat von hanspeter (Beitrag 1268553)

Auf SPS Ebene kann übrigens auch mit C programmiert werden.

Im Visual Studio, soweit ich mich erinnere.

[hanspeter]

Zitat:

Zitat von Dejan Vu (Beitrag 1268555)

Im Visual Studio, soweit ich mich erinnere.

Im Entwicklungssystem (IDE+Compiler+Bausteinverwaltung+Debugsystem) war direkt ein GNU-C integriert.

[Dejan Vu]

Das ist mir wiederum neu (ich kenne bei Beckhoff nur dieses Pascal-Derivat). Als ich aufgehört habe, für den Maschinenbauer zu arbeiten, war Twincat 3 im Kommen, und das war mit C++ (oder nur C?) in VS zu programmieren. Ob C#, weiß ich nicht (glaub ich auch nicht), aber C(++?) sollte funktionieren.

[Insider2004]

Zur Frage: Nein. MS Windows ist kein Echtzeit-OS. Da musst Du schon VxWorks nehmen. Damit kannste einen Terminator steuern.

[luisk]

Zitat:

Zitat von Dejan Vu (Beitrag 1268540)

Kein Programmierer hat sich gefreut, S7 zu machen, im Gegenteil: Alle haben gekotzt.

[Polemik on]
1. immerhin sind sie mit S7 Marktführer: "...S7 steuert die Welt..."
2. Die Sprache ist endg...: L S5T# in S7 was soll soll S5 und was soll # ?
http://plc.mavjuz.com/en/siemens/sim...p7/timers.html
das und vieles mehr werd ich nie kapieren
und hier: Programmiertechnik aus den 80er:shock: Jahren im revolutionären Tia-Portal mit
"goldenen Regeln":shock:
http://www.youtube.com/watch?v=xtMypCDuhkU :?
immerhin haben die damit so viel Geld verdient, dass sie Unigraphix, Tecnomatix, Comos uvm. kaufen konnten.
"Sowas können wir nicht selbst entwickeln, aber wir können jeden kaufen..."
[Polemik off]

[himitsu]

STEP 7 fand ich jetzt nicht so schlimm.

Gut, ist jetzt auch schon 15 Jahre her und man erinnert sich kaum noch, aber gegen STEP 5 und zusammen mit der möglichkeit das Programm virtuell testen zu können ...

[Medium]

Ich würde nie behaupten wollen, dass mit Siemens alles paletti ist. Im Gegenteil: Lizenzwald und Installationshöllen z.B. schießen mir sofort in den Kopf. Aber rein Sprachlich gesehen ist SCL halt wirklich so nah an Pascal, dass man eine SPS damit zu nahezu allem überreden kann. Wer nur KOP/FUP nutzt, schöpft nur den aller kleinsten Teil des Potenzials aus, und die einfachsten und kürzesten dinge, die wir Delphianer für absolute Nichtigkeiten halten, entarten da auch schon mal zu regelrechten Spaghettimonstern. Mit SCL schreib ich dir aber gerne Pacman auf S7.

Um aber zum Thema zurück zu kommen:
Ich war bislang auch der Auffassung, dass Windows von Grunde auf keinerlei Unterstützung für RT mit bringt, eher genau das Gegenteil. Wie macht die Beckhoff SPS das? Ist die quasi ein eigenes OS, das aber nebenher auch noch ein Windows laufen lassen kann? Weil egal wie: Um einigermaßen RT fähig zu werden, sind imho extrem tiefe und umfangreiche Kniffe an den am schlechtestesten publik dokumentierten Systemkonzepten nötig. Das riecht nach einer beachtlichen Menge nötigem Know-Hows und viel Zeit und Nerven.

[Dejan Vu]

Zitat:

Zitat von Medium (Beitrag 1268633)

Wie macht die Beckhoff SPS das? Ist die quasi ein eigenes OS...

Ich glaube, so ähnlich. Aber frag die doch einfach.

Wie gesagt: Mindestens 10000x weltweit im Einsatz (auch unter Vollast, sodaß die HMI zwischendurch einfriert), bezüglich RT keine Probleme.

[hanspeter]

Läuft völlig unabhängig von Windows direkt auf der Hardware.
Die SPS selbst ist eine Art eigenes Betriebssystem.
SPS funktioniert auch noch, wenn Windows abgestürzt ist.
Für die Datenübergabe (Messtellen) wird eine Art Speichermapping bereitgestellt.
Windows Systemaufrufe sind auf SPS Ebene natürlich nicht möglich.
Mann kann sich das ungefähr so vorstellen, das direkt ein Timer der Hardware programmiert wird.
Dieser Interupt erfolgt direkt aus der Hardware und ist deshalb hochgenau.
Dieser teilt der SPS Rechenzeit zu.
Kithara macht das ähnlich aber ohne SPS Funktionbalität.
(Kithara stellt einen Hardware gesteuerten hoch präziesen Timer zur Verfügung.)
Bei neueren Versionen kann man die Arbeit wohl auch auf mehrere Kernel verteilen.
Eine SPS arbeitet immer mit zyklisch angesteuerten Programmen/Bausteinen.
Meine Programmbausteine ordne ich dann den gewünschten Zykluszeiten zu.
z.B. Systemüberwachung 100ns , Visualisierung 1 sec , Temperaturüberwachung 5 sec

Delphi-Quellcode:

Modul1   Takt  500ms;

if Hauptschalter.Ein then
  Anzeige1 := true;
  Anzeige2 := true;
  FlagLauf := true;
elsif
  Anzeige1 := false;
  Anzeige2 := false;
  FlagLauf := false;
endif
end;

[luisk]

um den PC voll in den Griff zu bekommen, muss man wohl hier ansetzen:
http://www.lowlevel.eu/wiki/Eigener_Bootloader
http://www.lowlevel.eu/wiki/GRUB

[Medium]

Faszinierend. Danke für die Infos! (Auch wenn diese jetzt nur am Rande die eigentliche Problemlösung des TEs berühren. Ich würde mir das Vorhaben als Einzelperson oder kleines Team jedoch abschmiken, viel zu aufwendig wenn man es nicht im ganz großen Stil vermarkten kann. Das riecht nach Mannjahrzehnten.)

[luisk]

hier ist eine kleinere Firma, die sowas hat:
http://www.sybera.de/german/g_sybera.htm
http://www.brunner-ag.com/4736.html

[himitsu]

Kleine Firma vielleicht, aber die haben auch schon ganz schön Arbeit und viel Zeit da reingesteckt. (in das ganze System und nicht nur in ein Programm, welches damit arbeitet)

Und sie haben bissl was zum Lesen, wenn man es unbedingt selber machen will.
http://www.sybera.de/german/g_literature.htm


http://www.heise.de/download/sybera-...io-362293.html