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.
Wie ist denn die Maschine an das System angebunden, auf dem das Windows Embedded laufen soll?
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.
(über die echtzeit würde ich mir keine gedanken machen, vorher eher über die stabilität... ein "echtes" betriebssystem ist viel zu komplex und stürtzt auch mal ab..) ich würd es jemanden machen lassen, der ahnung von sowas hat.. (ich mein, ist ja jezt nix "besonderes") vielleicht kann man sich ja auch an standards halten: http://www.google.at/search?q=isobus+terminal&hl=de&prmd=imvns&tbm=isch&tbo=u&source=univ&sa=X&ei=-nVQT_TENYzpOeuRgaMK&ved=0CF8QsAQ&biw=1920&bih=897
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.