Hallo zusammen,
ich habe eine Frage bezüglich Echtzeitfähigkeit. Ich möchte eine
Anwendung programmieren bei der man mit Joysticks eine Maschine steuert.
Jetzt habe ich eine Frage zur Echtzeitfähigkeit von Betriebssystemen.
Ich dachte auf die Hardware (Industrie-PC) ein Windows Embedded Standard
7 oder Windows Compact 7 zu installieren. Es soll Echtzeitfähig sein,
damit die Befehle des Joysticks innerhalb von 1 ms übertragen werden.
Ich tendiere zu Embedded Standard 7 weil es einfacher zu handhaben sein
soll.
Was könnt ihr mir zur Echtzeitfähigkeit der Beiden sagen? Habt ihr
schoonmal Erfahrungen damit gemacht?
Vielen Dank!
OsirisBob schrieb:> Es soll Echtzeitfähig sein,> damit die Befehle des Joysticks innerhalb von 1 ms übertragen werden.
1ms hat aber nichst mit Echtzeitfähig zu tun. Echtzeitfähig ist ein
system auch wenn es garantiert 5min braucht.
ist der Joysticks über USB angeschlossen? Wenn ja wird das verdammt eng
mit der 1ms.
Das ist doch wieder mal ein Genauigkeitsanspruch der völlig an der
Realität vorbei geht. Der Joystick wird von Hand bedient.
Die Reaktionsfähigkeit eines Menschen liegt (selbst trainiert) bei
mehreren 10tel Sekunden. Warum muss dann die Kommunikation < 1ms sein?
10ms wären optimal und selbst bei 20ms dürfte man noch keine Verzögerung
in der Bedienung wahrnehmen.
Möglicherweise handelt es sich hier um einen "Gamer", der bereits den
Unterschied zwischen 2 msec und 8 msec Reaktionszeit des Monitors als
"lagging" wahrnehmen zu können. Mit den muskelbepackten Oberarmen dieser
Zeitgenossen kann natürlich auch ein Joystick innerhalb weniger
Millisekunden hin- und herbewegt werden.
Vielen Dank für die zumindest teilweise zu gebrauchenden Antworten.
Gerade auf den letzten Thread kann man getrost verzichten!
Hierbei handelt es sich um eine Maschine, die ernorm teure Güter
versetzt. Sicherheit ist Erstes Gebot! Bin nicht irgend so ein Spinner
der versucht in Counter Strike ein Kill mehr auf die Reihe zu kriegen!
Ich bin Anfänger in diesem Gebiet, daher hört sich vielleicht manch eine
Frage komisch an.
Durch unsere Zusammenarbeit mit unserem Partner habe ich den Wert (1ms)
ins Ohr gesetzt bekommen. Wahrscheinlich können es auch 10ms sein. Daher
frage ich nochmal: hat jemand Erfahrung mit Win Embedded Standard und
Compact 7? In Bezeug auf Echtzeitfähigkeit. Auf unserem Bedienpanel
befindet sich noch ein Touchscreen, dessen Informationsdarstellung aber
nicht so wichtig ist wie die Reaktion des Joysticks im System. Der soll
immer Vorrang haben.
Du schreibst von einer spezifizierten maximalen Übertragungsdauer deiner
Nutzdaten. Dieser räumst du 1ms ein. Hier erkenne ich keinen
Zusammenhang zum Betriebssystem auf deinem IPC. Die Frage hier ist doch,
ist ein Bussystem vorhanden welche die Daten innerhalb der geforderten
1ms an den IPC übertragen kann. D.h. Übertragungsrate deines Bussystems
in dessen Spezifikation nachlesen. Dann Datenmenge welche pro Befehl zu
übertragen sind messen/nachlesen. Damit ist klar, ob die Datenmenge in
der geforderten Zeit mit der vorhandenen Bussystemrate übertragbar ist.
Oder meinst du eher, ob dein IPC innerhalb 1ms eine Verarbeitung der
Daten aufnehmen kann. Sprich, die Daten vom Joystick liegen vor und das
Betriebssystem bekommt den Prozess welcher für die Abarbeitung dieser
zuständig ist mit der Latenz von max. 1ms gestartet? Wenn dies gemeint
ist, so hängt das von der Hardware und Software ab. Die von dir
genannten Betriebssysteme sind aufgrund ihrer Umsetzung hart
Echtzeitfähig. Das heißt unter anderem der Scheduler kann entsprechend
priorisierte Prozesse bevorzugt ausführen. (Weitere OS spezifische
Anpassungen sind... selbst nachlesen) Probleme macht dann nur noch die
Hardware. Kann man mit ihr Interrupts priorisieren etc.? D.h. Kann
verhindert werden, dass Echtzeitprozesse von Interrupts unterbrochen
werden. Dies kann das Datenblatt der Hardware verraten. Oder wie so oft
eben auch nicht. Dann bleibt eben nur selber messen. Problem hierbei.
Hardware liegt vor und nach der Messung kann es sein, dass die Hardware
weil sie nicht passt entsorgt werden muss. Oder bessere Lösung. Es gibt
Anbieter welche Messungen für gängige Hardware vornehmen und verkaufen.
Wenn sie das System noch nicht kennen, erstellen sie die Messungen für
dich. Dauert dann halt etwas länger wie wenn die Messungen schon in der
Schublade liegen. Beide Ansätze sparen aber Zeit und Kosten. Für Linux
Kernel macht das z.B. die OSADL. Für Windows keine Ahnung. Müsste ich
mich bei unseren Doppel-Maus-Klicker erkundigen.
Oder ist gemeint, ob dein System innerhalb von einer Dauer von 1ms die
für eine vom Joystick eintreffenden Befehl eine Regelung/Steuerung
gewährleisten kann? Wenn ja, das kann nur der Quellcode beantworten. Wie
effizient ist dieser Umgesetzt. Welcher Systemtakt steht zur
Verfügung... Diese Laufzeit kann errechnet werden. Oder man wählt den
unschöneren Ansatz und misst einfach.
ES 7 erhebt m.W. keinen Anspruch darauf, echtzeitfähig zu sein, EC 7
hingegen schon. Das heißt haber noch lange nicht, dass dir bei EC 7
irgendwelche quantitativen Eigenschaften zugesichert werden, allenfalls
für Teilaspekte. Insofern ist auch EC 7, als Ganzes betrachtet, nicht
wirklich echtzeitfähig, zumindest nicht hart, auch wenn Werbeaussagen
etwas anderes behaupten mögen.
Siehe auch hier (3. Absatz):
http://de.wikipedia.org/wiki/Microsoft_Windows_CE
Aber auch ein gewöhnliches Desktop-Windows hat i.Allg. recht kurze
Reaktionszeiten, sonst wäre es unmöglich, Action-Spiele darauf zu
implementieren, die sogar wettbewerbsmäßig gespielt werden. Ich habe
auch schon Joysticksteuerungen für Roboter u.ä. auf PCs mit gewöhnlichem
Windows oder Linux gesehen, bei denen man keinen nennenswerten "Lag"
spürt.
Ob deine Joystick-Anwendung "rund" läuft, hängt aber auch nicht nur vom
verwendeten Betriebssystem, sondern von den verwendeten Treibern, deiner
eigenen Anwendungssoftware und anderen Programmen, sie simultan auf dem
System laufen, ab.
Garantierte Echtzeit (wie z.B. eine maximale Verzögerungszeit von 1ms
(oder auch 10ms) ist fast nur dann möglich, wenn du kein komplexes Be-
triebssystem mit vielen Unbekannten einsetzt, sondern deine Anwendung
direkt auf Hardwareebene laufen lässt, wie es bei Mikrocontrolleranwen-
dungen oft gemacht wird. Wenn der Rechner neben der Übertragung von
Joystick-Daten sonst nicht mehr allzu viel zu tun hat, ist ein Indus-
trie-PC mit Betriebssystem vielleicht sowieso oversized und ein Mikro-
controllersystem die einfachere, zuverlässigere und reaktionsschnellere
Lösung.
Da die Sicherheit einen hohen Stellenwert hat, musst du aber wahrschein-
lich ohnehin eine redundante Schutzeinrichtung (bspw. basierend auf
einem Hardwarewatchdog) vorsehen, die im Fehlerfall die Maschine in
einen sicheren Zustand überführt. Damit wäre auch ein kurzer Aussetzer,
der bei einem nicht 100%ig echtzeitfähigen System sporadisch auftreten
kann, nicht fatal.
Nur ein paar generelle Sachen:
- 7 ES ist ohne weiteres nicht für Echtzeit-Aufgaben ausgelegt
- 7 EC ist ein Echtzeit-OS
- Visualisierung auf einem "Standard"-Rechner und
- "Messen, Steuern, Regel" mit einem separaten Board, je nach
Komplexität mit oder ohne RTOS ist nicht möglich/gewollt?
- Wie sieht es mit Redundanz und Fehlertoleranz aus?
Schau dir mal Beckhoff an. (www.beckhoff.de)
Der CX9000 ist z.B. ein Hutschienen- PC mit WinCE CAN-Bus oder auch
andere beliebige Busklemmen (IO usw).
Darauf läuft eine SoftSPS. 1ms ist kein Problem.
Die haben eine breite Palette, je nach Anforderung
Gruß
tom
Hallo zusammen,
zuerst mal vielen Dank für die wirklich informativen Antworten!
Der CAN-Bus kann Daten innerhalb der 1ms übertragen. Auf der anderen
Seite des CAN-Bus ist ein weiterer Rechner, der ein Steuerungssystem
beinhaltet. AUf beiden Seiten ist ein durch einen Partner geschriebenes
CAN-Protokoll. Auf der Seite der Fernsteuerung ist ein Bildschirm,
Schalter und Joysticks. Diese sollen an den Industrie-PC angeschlossen
werden, direkt über analoge Eingänge und digitale Ein- und Ausgänge.
Über den CAN-Bus werden z.B. Daten wie Geschwindigkeit geschickt, die
auf dem Display visualisiert werden sollen. Und durch Joysticks wird die
Maschine gesteuert. Auf diesem Industrie-PC soll eben ein Betriebsystem
kommen. Da ich auf Windows-Basis bleiben muss fällt mir nur Win ES7 und
Compact 7 ein. Daher diese Fragen.
- Ich hatte bisher nur mit normalen Applikationen zu tun, die nicht so
nah an der Hardware programmiert wurden. Ich habe mich schon mit der
Installation von Win XP Embedded und Win Embedded Standard beschäftigt.
Das klappt auch. Welcher Unterschied besteht für mich als Entwickler
zwischen Win ES 7 und Compact 7?
Stefan B. schrieb:> Oder meinst du eher, ob dein IPC innerhalb 1ms eine Verarbeitung der> Daten aufnehmen kann. Sprich, die Daten vom Joystick liegen vor und das> Betriebssystem bekommt den Prozess welcher für die Abarbeitung dieser> zuständig ist mit der Latenz von max. 1ms gestartet?
Genau das meine ich! Da die Joysticks in der REgel an den IPC
angeschlossen werden frage ich wie der IPC das handelt wenn er arbeitet.
Er darf keine Sekunde warten bevor er die Daten vom Joystick auf den
Can-Bus schickt wenn er irgendwas bearbeitet.
Yalu X. schrieb:> Wenn der Rechner neben der Übertragung von> Joystick-Daten sonst nicht mehr allzu viel zu tun hat, ist ein Indus-> trie-PC mit Betriebssystem vielleicht sowieso oversized und ein Mikro-> controllersystem die einfachere, zuverlässigere und reaktionsschnellere> Lösung.
Den IPC muss ich wählen, weil auch die Daten auf einem Display
visualisiert werden sollen.
Yalu X. schrieb:> Da die Sicherheit einen hohen Stellenwert hat, musst du aber wahrschein-> lich ohnehin eine redundante Schutzeinrichtung (bspw. basierend auf> einem Hardwarewatchdog) vorsehen, die im Fehlerfall die Maschine in> einen sicheren Zustand überführt.
Dafür ist gesorgt!
Danke!
OsirisBob schrieb:> Der CAN-Bus kann Daten innerhalb der 1ms übertragen.
Mit welcher Baudrate arbeitet der? Wenn ich mir ansehe, wie lang ein
CAN-Bus-Frame minimal* ist, dann müsste der mit um die 5 MBit/sec
arbeiten, um das zu schaffen.
[Edit]
Als ich das schrieb, muss mich irgendwas abgelenkt haben. Das ist
Blödsinn.
Danke an Sven für's wachsein.
*) 11-Bit-Identifier, resultiert in 46 Bit, wenn keine Nutzdaten
übertragen werden.
Rufus Τ. Firefly schrieb:> Mit welcher Baudrate arbeitet der? Wenn ich mir ansehe, wie lang ein> CAN-Bus-Frame minimal* ist, dann müsste der mit um die 5 MBit/sec> arbeiten, um das zu schaffen.
Hallo,
das müsste ich nachfragen, geht aber leider erst kommende Woche.
Nehmen wir mal an ich würde auf einem IPC ein Win ES 7 laufen lassen.
Könnte ich dort die Daten, die vom Joystick kommen, zuerst auf den Bus
schicke, d.h. priorisieren? Wenn ja, wie?
Danke Euch!
Rufus Τ. Firefly schrieb:> OsirisBob schrieb:>> Der CAN-Bus kann Daten innerhalb der 1ms übertragen.>> Mit welcher Baudrate arbeitet der? Wenn ich mir ansehe, wie lang ein> CAN-Bus-Frame minimal* ist, dann müsste der mit um die 5 MBit/sec> arbeiten, um das zu schaffen.>>> *) 11-Bit-Identifier, resultiert in 46 Bit, wenn keine Nutzdaten> übertragen werden.
Kommt bei 1MBit/s in meinem Taschenrechner auf 0,046 ms.
Selbst bei 125kBit/s dauert die Übertragung eines leeren Frames mit 46
Bit 0,368ms und eines kompletten Frames mit 46 + 8*8 = 110 Bit 0,88ms.
Dafür reicht's also dicke.
(ist CAN nicht sowieso nur bis 1MBit/s spezifiert?)
Sven H. schrieb:> Kommt bei 1MBit/s in meinem Taschenrechner auf 0,046 ms.
Hmm. Da hast Du auch irgendwie recht. Was mag mich da gerade abgelenkt
haben?
Also streichen wir den Blödsinn von eben.
OsirisBob schrieb:> Könnte ich dort die Daten, die vom Joystick kommen, zuerst auf den Bus> schicke, d.h. priorisieren?
Alternativer Lösungsansatz:
Hänge den Joystick nicht an den PC, sondern mit einem CAN-fähigen µC
direkt an den CAN-Bus. Dann sind die Geschwindigkeitsanforderungen an
den PC deutlich entspannter.
Rufus Τ. Firefly schrieb:> Hänge den Joystick nicht an den PC, sondern mit einem CAN-fähigen µC> direkt an den CAN-Bus. Dann sind die Geschwindigkeitsanforderungen an> den PC deutlich entspannter.
also meinst Du ich solle neben dem IPC für die Visualisierung einen µC
verbauen über den ich die analogen Signale laufen lasse?
Mit was für nem Aufwand müsste ich da Programmiertechnisch rechnen? Ein
CAN-Protokoll besteht schon.
Wie könnte so einer aussehen? Könnte das ein PC 104 sein oder ist das
schon zu gross?
Danke!
OsirisBob schrieb:> Wie könnte so einer aussehen? Könnte das ein PC 104 sein oder ist das> schon zu gross?
"Ein PC104" - Das ist kein µC, sondern ein kompletter PC. Genau den aber
gilt es zu vermeiden.
Ein µC ist ein Microcontroller, und es gibt welche, die direkt CAN
verstehen, wie z.B. der AT90CAN (32, 64 oder 128).
www.atmel.com/Images/doc7679.pdf
Entschuldige meine Unwissenheit... aber muss ich dazu dann noch eine
Platine entwickeln oder wie geht sowas?
Und kann ich darauf einfach unser bestehendes CAN-Protocol einsetzen?
Oder wie kann ich mir das vorstellen?
Wenn ich zuviele DInge diesbezüglich noch nicht weiss, wo kann ich mich
gerade in diesem Gebiet noch informieren? Google gibt mir langsam immer
dasselbe raus!
AChja, und wenn über das Display auch wichtige Nachrichten geschickt
werden, durch Einstellungen, die man auf diesem macht, müsste ich aber
diese Botschaften dann priorisieren? ODer wie würdest ihr das machen?
OsirisBob schrieb:> aber muss ich dazu dann noch eine> Platine entwickeln oder wie geht sowas?
Richtig erkannt.
> Und kann ich darauf einfach unser bestehendes CAN-Protocol einsetzen?
Wenn es brauchbar dokumentiert ist, ja.
> AChja, und wenn über das Display auch wichtige Nachrichten geschickt> werden, durch Einstellungen, die man auf diesem macht, müsste ich aber> diese Botschaften dann priorisieren?
Dürfte unnötig sein, da die Reaktionsgeschwindigkeit des das System
bedienenden Menschen nicht allzu hoch ist.
Ob eine Benutzereingabe eine Sekunde früher oder später irgendwo
ankommt, sollte nicht zu Problemen führen.
Wenn sie das tut, liegt meiner Einschätzung nach ein grundlegendes
Problem im Bedienkonzept vor.
Ok, vielen Dank! Du hast mir schonmal weitergeholfen.
Ich muss schauen was ich mache. Das Projekt sprengt zeittechnisch
komplett den Rahmen. Aber Sicherheit geht vor!
Trotzdem muss ich mit diversen Hardware-Hersteller mal sprechen ob die
Joystick Steuerung in Echtzeit (also in einem absehbarem
Zeitabstand)über den IPC laufen kann. Watchdog besteht ja.
Rufus Τ. Firefly schrieb:> Wenn sie das tut, liegt meiner Einschätzung nach ein grundlegendes> Problem im Bedienkonzept vor.
Damit meinst Du eine Fehler in der Programmierung des CAN-Protocols oder
in der Steuerung an sich?
OsirisBob schrieb:> Damit meinst Du eine Fehler in der Programmierung des CAN-Protocols oder> in der Steuerung an sich?
Er meint wohl:
Das Sicherheits-Konzept ist Sch***, wenn es davon abhängt dass ein
Mensch innerhalb von xxx ms eine Meldung sieht, liest, versteht, und
mit einer Joystick-Bewegung reagiert.
Die Übertragung innerhalb von 10ms ist für die Sicherheit nicht so
wichtig wie eine vernünftige Fehlerbehandlung.
Was passiert z.B. wenn ein Anschlussdraht vom Joystick-Poti reißt und so
ständig Maximalausschlag gemeldet wird?
Fährt das System dann gegen den Anschlag, oder wird der Fehler erkannt
und ein "sicherer Zustand" hergestellt?
Εrnst B✶ schrieb:> Er meint wohl:> Das Sicherheits-Konzept ist Sch***, wenn es davon abhängt dass ein> Mensch innerhalb von xxx ms eine Meldung sieht, liest, versteht, und> mit einer Joystick-Bewegung reagiert.
Ich bezog mich hier nicht auf den Joystick, sondern auf
> und wenn über das Display auch wichtige Nachrichten geschickt> werden, durch Einstellungen, die man auf diesem macht,
Worunter ich irgendwelche zum (Touch?) Display gehörenden
Bedienelemente, Eingabefelder o.ä. verstehe.
Εrnst B✶ schrieb:> Was passiert z.B. wenn ein Anschlussdraht vom Joystick-Poti reißt und so> ständig Maximalausschlag gemeldet wird?> Fährt das System dann gegen den Anschlag, oder wird der Fehler erkannt> und ein "sicherer Zustand" hergestellt?
Das ist abgesichert. Ein Schutzfunktion auf Kabelbruch ist realisiert.
Rufus Τ. Firefly schrieb:> Worunter ich irgendwelche zum (Touch?) Display gehörenden> Bedienelemente, Eingabefelder o.ä. verstehe.
ok...
Hallo zusammen,
ich muss noch weitere Fragen zu diesem Thema stellen weil ich, aus
Mangel an Erfahrung, nicht weiterkomme. Wie ich ja bereits sagte,
handelt es sich um eine Fernbedienung, bei der man auf einem Display
Einstellungen vornehmen kann. Zusätzlich sind Joysticks, Schalter und
Lampen auf der Fernbedienung. Alles läuft über einen CAN-BUS zu einem
Steuergerät. Die Daten, vom Joystick und den Schaltern müssen in
Echtzeit übertragen werden. Die Einstellungen nicht. Somit habe ich ja
zum Einen, einen PC mit Bilderschirm und zum Anderen die restlichen
Komponenten. An den PC kann man ohne weiteres eine CAN-Karte
anschliessen und die Sachen über den Bus schicken. Wenn ich aber
Joysticks & Co über den PC laufen lasse, ist die Echtzeit nicht mehr
gegeben, so wie bisher meinen Quellen entnommen habe. Hier in diesem
Thread wurde vorgeschlagen einen Microcontroller fûr Joystick & Co zu
verwenden. Gibt es da noch andere Möglichkeiten, oder sehe ich da was
falsch?
Und eine weitere Frage ist: Was wird in der Regel benutzt um sowas zu
realisieren? Windows Embedded? Oder Linux? Oder was gibts noch?
Vielen Dank für Eure Antworten!!!
hast du denn mal getestet wie es auf dem PC laufen würde ohne das du dir
über Echtzeit gedanken machest? Wenn der PC nicht gerade jetzt schon
voll ausgelastet ist, dann wird es einfach so gehen. Es ist zwar nicht
ausgeschlossen das es zu kurzzeitigen "hängern" kommt, aber doch sehr
unwahrscheinlich. Immer können auch andere komponenten ausfallen z.b.
Joystick verklemmt, kabel bruch usw. Wenn du das ganze sysem nicht zu
100% sicher bekommt, dann würde ich das einfach so mal testen.
Peter II schrieb:> hast du denn mal getestet wie es auf dem PC laufen würde ohne das du dir> über Echtzeit gedanken machest? Wenn der PC nicht gerade jetzt schon> voll ausgelastet ist, dann wird es einfach so gehen.
Der PC ist momentan nicht voll ausgelastet. Auf Dauer werden Ihm aber
immer mehr Aufgaben zugeteilt. Das möchte ich vorsehen.
Peter II schrieb:> Es ist zwar nicht> ausgeschlossen das es zu kurzzeitigen "hängern" kommt, aber doch sehr> unwahrscheinlich.
Kurzeitige Hänger können beim Bremsen schon die Sicherheit gefährden.
Kann man Windows Embedded die Aufgaben, die Windows im Hintergrund macht
steuern oder eindämmen?
Peter II schrieb:> Immer können auch andere komponenten ausfallen z.b.> Joystick verklemmt, kabel bruch usw. Wenn du das ganze sysem nicht zu> 100% sicher bekommt, dann würde ich das einfach so mal testen.
Gut das kann immer vorkommen. Für Kabelbruch wurde eine Sicherheit
eingebaut. Ich würde das jetzt testen indem ich die TraceRoute verfolge
und auswerte. Wie würdet Ihr das testen?
Danke Euch!
WES ist ein 'normales' Windows 7 (bzw. XP bei der älteren Version), es
wird nur anders installiert. Damit ist es nicht mehr oder weniger
Echtzeitfähig als das was du auf dem Desktop installierst. Es gibt
Echtzeitzusätze, die lassen aber zwei OS auf einem Rechner werkeln und
dementsprechend musst du für zwei Umgebungen entwickeln und dich um die
Kommunikation der Systeme untereinander kümmern. Es gibt zB Acontis,
damit kriegst du zB WinCE und Win7/XP auf einer Kiste zum Laufen. Der CE
Teil kann dann die Echtzeit Steuerung erledigen und Visu Daten an XP
schicken.
Wenn du die Mimik zum Steuern einer Maschine/Anlage einsetzt gilt es ja
noch die Maschinenrichtlinie zu beachten, dann bist du erstmal mit
Gefahrenanalyse und Sicherheitskonzept für ein halbes Jahr beschäftigt.
Dann baust du eine Sicherheits-SPS ein und ein weiteres Jahr ist rum :-(
OsirisBob schrieb:> Kurzeitige Hänger können beim Bremsen schon die Sicherheit gefährden.> Kann man Windows Embedded die Aufgaben, die Windows im Hintergrund macht> steuern oder eindämmen?
und was ist wenn beim bremsen der CAN-Bus gestört ist?
man kann jeden Thread eine andere Prio geben, es gibt beim normales
windows auch die Prio "Echtzeit", keine ahnung ob das bei embedet auch
so ist. Damit bekommst du fast alles an CPU was da ist.
Wenn du also deiner Anwendung die höchste Prio gibst, dann hat sie
vorrang. Hänger können jetzt nur auftreten wenn z.b. gerade etwas von
der Festplatte gelesen werden soll und diese zu lange braucht.
JojoS schrieb:> Es gibtEchtzeitzusätze, die lassen aber zwei OS auf einem Rechner werkeln > und
dementsprechend musst du für zwei Umgebungen entwickeln und dich um die
> Kommunikation der Systeme untereinander kümmern. Es gibt zB Acontis,> damit kriegst du zB WinCE und Win7/XP auf einer Kiste zum Laufen. Der CE> Teil kann dann die Echtzeit Steuerung erledigen und Visu Daten an XP> schicken.
D.h. ich installier die beiden OS. Die OS Win CE kümmert sich um die
CAN-Kommunikation und die wichtigen Daten und Win XP/7 kümmert sich dann
um die Visualisierung und verschickt die Einstellungen an das CE, dass
regelt was auf den CAN-Bus geschickt wird?
> Wenn du die Mimik zum Steuern einer Maschine/Anlage einsetzt gilt es ja> noch die Maschinenrichtlinie zu beachten, dann bist du erstmal mit> Gefahrenanalyse und Sicherheitskonzept für ein halbes Jahr beschäftigt.> Dann baust du eine Sicherheits-SPS ein und ein weiteres Jahr ist rum :-(
Also die Steuerung der Maschine und das drum herum steht schon. Jetzt
muss eine Fernbedienung gebaut werden.
Peter II schrieb:> und was ist wenn beim bremsen der CAN-Bus gestört ist?
Unser Partner arbeitet schon lange mit dem CANBUS-Protokoll. Die haben
Erfahrung damit. Das werden Sie wohl beachtet haben.
> man kann jeden Thread eine andere Prio geben, es gibt beim normales> windows auch die Prio "Echtzeit", keine ahnung ob das bei embedet auch> so ist. Damit bekommst du fast alles an CPU was da ist.
Das hört sich ja nach einem einfacheren Weg an, wenn das wirklich so
ist.
> Wenn du also deiner Anwendung die höchste Prio gibst, dann hat sie> vorrang. Hänger können jetzt nur auftreten wenn z.b. gerade etwas von> der Festplatte gelesen werden soll und diese zu lange braucht.
Danke Euch!!
Ein OS auf einem PC kann nie hart echtzeitfähig sein, da
1. Software die auf Ring -1 läuft immer höhere Prio. hat als dein
Programm
2. Software die auf Ring -2 läuft höher Prio. hat als die auf Ring -1
auf Ring -2 (SMM mode) gibts Konzepte für Viren und wenn die in einen
endlos Loop gehen ist Essig mit garantierter Antwortzeit.
Lass mal ein Programm (in Assembler) unter Dos laufen.
1:
Read TSC
jmp 1
und schau dir den Jitter in den TSC Werte an - znd erschrecken.
Gruss Kalle
Kalle schrieb:> Ein OS auf einem PC kann nie hart echtzeitfähig sein, da>> 1. Software die auf Ring -1 läuft immer höhere Prio. hat als dein> Programm> 2. Software die auf Ring -2 läuft höher Prio. hat als die auf Ring -1>> auf Ring -2 (SMM mode) gibts Konzepte für Viren und wenn die in einen> endlos Loop gehen ist Essig mit garantierter Antwortzeit.>> Lass mal ein Programm (in Assembler) unter Dos laufen.>> 1:> Read TSC> jmp 1>> und schau dir den Jitter in den TSC Werte an - znd erschrecken.>> Gruss Kalle
Hallo vielen Dank für deine Antwort!
Ich kenne mich mit GUI-programmierung und Hochsprachen aus, aber in dem
Bereich hier bin ich wie schon gesagt Anfänger. Ich versuche eine Lösung
zu finden.
Ich versteh nicht alles was Du geschrieben hast, aber im Groben tu ich
es schon. Windows also dafür keine sichere Lösung.
Hier wurde von eine Prio namens "Echtzeit" gesprochen. Wie sieht es denn
damit aus? Gibts sowas? Und ist das verlässchlich?
Und was ist mit dem Vorschlag zwei Betriebssysteme zu installieren? Also
einmal CE für die Echtzeit und einmal Windows XP für Visualisierng?
Windows CE ist auch nicht hart Echtzeitfähig oder?
Hallo OsirisBob,
auf einem PC kann nichts hart Echtzeitfähig sein, weil auf einem höher
privilegierten Level als dem auf dem Du programmierst Software läuft
(laufen kann) die Du weder kennst noch auf die Du Einfluß hast.
Das macht auch keinen Interschied ob du 2 OSe oder 2 Boards nimmst
Wie gesagt nimm DOS damit kannst Du eigentlich immer Echtzeitfähig
programmieren.
1:
Programm 1
Programm 2
.
.
jmp 1
jetzt kannst Du worst case für jedes Programmteil rechnen und hast damit
deine garantierte Antwortzeit.
Teste es durch mit TSC und Du wirst sehen daß Du Zeiten hast die über
der gerechneten liegen.
Ich stell das ein wenig übertrieben dar weils ja genug Anwendungen gibt
wo es funktioniert, siehe zB. linuxcnc unter linux mit (glaub ich) RTAI
Bei dennen gibts glaub auch eine Diskussion weil SMM so oft dazwischen
funkt.
Also wenn Du wirklich Echtzeut brauchst wäre die seperate MCU
wahzscheinlich der bessere Weg.
Oder du programmierst auf BIOS Ebene eben genau im SMM. Dann sieh dir
mal
coreboot.org an.
Gruss Kalle
Kalle schrieb:> Hallo OsirisBob,>> auf einem PC kann nichts hart Echtzeitfähig sein, weil auf einem höher> privilegierten Level als dem auf dem Du programmierst Software läuft> (laufen kann) die Du weder kennst noch auf die Du Einfluß hast.
Ich weiß auf was das letztlich hinausläuft...
http://cm.bell-labs.com/who/ken/trust.html
Aber, sowohl CE, als auch andere RTOS können min. für den am höchsten
priorisierten Thread und für die Interrupt-Ausführung maximale Latenzen
garantieren, wenn vom Normalfall ausgegangen wird. Bei den meisten(?)
könnte dies zur Not auch an Hand des Quelltextes überprüft werden.
Ob das der in diesem Fall beste/einfachste/günstigste Weg ist oder das
> Also wenn Du wirklich Echtzeut brauchst wäre die seperate MCU> wahzscheinlich der bessere Weg.
kann nur der TO beantworten. Vorziehen würde ich die Lösung mit einem
separaten Controller allerdings auch.
Ok die Wahl ist dann definitiv auf zwei Komponenten gefallen. Also
Visualisierung getrennt von der CAN-Kommunikation. Aber eine Frage hätte
ich noch. Was haltet ihr davon eine Steuerung mit CodeSys zu
"programmieren"? Habt ihr schon Erfahrungen damit gemacht? Oder welche
sind die Nachteile?
Alles was ich bisher darüber gelesen habe scheint sehr positiv, aber das
ist es bei Verkäufern ja immer!
Danke Euch!!
Hallo Arc Net,
ich glaub nicht dass die irgendwelche latenzen garantieren können. Wenn
der Prozessor im SMM ist kommt noch nicht mal ein NMI durch.
Pentium Processor Family Developer’s Manual, Volume 3
Although NMI requests are blocked when the CPU enters SMM, they may be
enabled through software by invoking a dummy interrupt and vectoring to
an Interrupt Service Routine. NMI interrupt requests will be recognized
once the Interrupt Service Routine has begun executing.
sprich der wird erst ausgelöst wenn ein SMM exit kommt.
Da Du ab deb SMM Handler überhaupt nicht mehr ran kommst (wenn das BIOS
sauber programmiert ist) kabbste bich bicht mal mit einem Debugger
kontrollieren was der macht (machen könnte).
Mal extrem - der geht in einen Endlos loop , und damit ist deine
garantierte Antwortzeit ==> unendlich.
siehe auch
http://de.wikipedia.org/wiki/System_Management_Mode#Echtzeit
ps. bei deinem link krieg ich eine 404
@ OsirisBob
sorry Codesys hab ich nie programmiert, aber
www.sps-forum.de/
is da ziemlich kompetent
Gruss Kalle
Danke für deine Antwort!
Habt ihr evtuell schon Erfahrung mit Acontis oder Kithara Software
Erfahrungen gemacht? Diese bieten Echtzeit-Erweiterungen für Windows an.
Laut der Informationen, die ich gewinnen konnte soll das sehr gut
funktionieren. Aber ich verlasse mich da lieber auf Erfahrungen von
erfahrenen Bentuzern...
>Echtzeit-Erweiterungen für Windows
ich frage hier nochmal:
was hilft dir garantierte echtzeit, wenn du ein überdiemensioniertes,
aufwändiges system (PC/windows/ usw) hast, was nicht "garantiert"
ausfallsicher ist...
Ich hab mir das hier grad mal alles durchgelesen, evtl. zu spät noch
meinen Senf dazu zugeben, aber wer weiß.
- Windows Embedded 7 ist nicht echtzeitfähig
- Windows Compact 7 ist echtzeitfähig
Anwendungsfälle sind wahrscheinlich nicht die gleichen, aber ich hatte
vor ein paar Jahren mal ähnliche Voraussetzungen für eine
Prüfeinrichtung testbed. Wir hatten uns damals für Windows Embedded 7
entschieden (einfacher zu bedienen als Compact 7) und die
Echtzeiterweiterung RTX von IntervalZero.
Der Teil Echtzeit war echt nicht so kompliziert für unsere Anwendung,
deshalb kann ich nicht so viel zum Produkt sagen. Ich weiß allerdings,
dass es in ziemlich komplizierten Produkten von Siemens (zum Bsp.
Soft-SPS) verwendet wurde und außerdem wurde es uns von Microsoft
Kontakten und Partnern empfohlen.
Es war schnell und einfach erledigt und hat auch funktioniert. Wir haben
in C innerhalb Visual Studio gearbeitet, aber unsere IO' s wurden über
ein PCI board gemacht, was ja ziemlich anders ist als USB.
