Hallo,
ich verarbeite das Ankommen bzw. Abgehen meines Iow56 über Win32-Api-Funktionen (RegisterForDeviceNotification). Um den IoWarrior zeitlich möglichst präzise steuern zu können, nutze ich in meinem Programm einen selbt entwickelten Timer der wiederum auf Funktionen aus der Multimedia-Bibliothek winmm.dll basiert. Das zeitliche Verhalten ist stabil und der IoWarrior arbeitet absolut verlässlich.
Schwierig wird es, wenn der IoWarrior bei laufender Routine vom USB ausgesteckt wird. Das Programm erfasst zwar innerhalb eine try-catch-Blocks die entstandene Ausnahme, kann diese aber nicht behandeln, weil ich lediglich eine Wrapper-Klasse für die iowkit.dll einsetze. Der Zugriff auf die ablaufenden Vorgänge in der iowkit.dll ist somit schwierig bis unmöglich.
Da der winmm.dll-basierte Zähler mit größerer Geschwindigkeit als die Windows-Message-Loop läuft, ist auch das Einschreiten innerhalb der betroffenen Code-Blöcke von C# aus mehr Glückssache als gesteuertes Eingreifen.
Wichtig: Der Zähler triggert jede Millisekunde. Pro Millisekunde wird eine Schreib- bzw. Leseaktion durchgeführt. Die Update-Geschwindigkeit in der Windows-Nachrichtenschleife scheint ordentlich darunter zu liegen. Die Nachricht, die signalisiert, dass der Io-Warrior ausgesteckt worden ist geht auf jeden Fall mit Verzögerung (bezogen auf die Geschwindigkeit des Zählers) ein.
Nun zu meiner Frage: Kann ich eine "hängende" iowkit.dll-Instanz zurücksetzen oder gar neu laden ? Hat das schon mal jemand versucht ?
Mir fehlt da z.Zt. der richtige Ansatz. Vielleicht geht ja auch ein ganz anderer Weg ?
Danke für Eure Antworten :-)
Iowkit.dll : Reset nach Ausstecken des IO-Warriors ? C#
Moderator: Guido Körber
Hallo,
wenn ich mich recht entsinne, bemerkt man einen Unplug des IOWarrior innerhalb der IowKit-lib nur an einem Fehler beim Schreiben. Das funktioniert aber wohl recht zuverlässig (zumindest gabs da im Forum keine Hinweise auf Probleme).
Mit dem Parameter SetLastError=true in den DllImport-statements und der Funktion Marshal.GetLastWin32Error() sollte man auch Problemen innerhalb der iowkit-lib auf die Schliche kommen.
Es gibt auch noch die Funktion CancelIO in der iowkit-lib, aber wenn da ein Fehler war ist da eh nichts mehr zu cancelen.
Ansonsten ist aber auch für den Anwender eh nix zu machen, wenn der Iow nicht mehr funktioniert. Er ihn höchstwahrscheinlich abgezogen, oder der Blitz ist eingeschlagen, oder er hat ein Tasse Kaffe zu viel über seinen Schreibtisch gegossen, was war bei mir das Problem war.
Eberhard
wenn ich mich recht entsinne, bemerkt man einen Unplug des IOWarrior innerhalb der IowKit-lib nur an einem Fehler beim Schreiben. Das funktioniert aber wohl recht zuverlässig (zumindest gabs da im Forum keine Hinweise auf Probleme).
Mit dem Parameter SetLastError=true in den DllImport-statements und der Funktion Marshal.GetLastWin32Error() sollte man auch Problemen innerhalb der iowkit-lib auf die Schliche kommen.
Es gibt auch noch die Funktion CancelIO in der iowkit-lib, aber wenn da ein Fehler war ist da eh nichts mehr zu cancelen.
Ansonsten ist aber auch für den Anwender eh nix zu machen, wenn der Iow nicht mehr funktioniert. Er ihn höchstwahrscheinlich abgezogen, oder der Blitz ist eingeschlagen, oder er hat ein Tasse Kaffe zu viel über seinen Schreibtisch gegossen, was war bei mir das Problem war.
Eberhard
Moin Eberhard,
erst mal vielen Dank für Deine Antwort. Du hast recht, wenn Du sagst, dass für den Anwender eh nichts mehr zu machen ist, wenn der IOW nicht mehr funktioniert.
Nur in meinem Fall sind die Anforderungen etwas andere. Der IOW und die zugehörige Klassensammlung wird von mir genutzt um Drehwinkel eines zweiachsigen Systems (Gewicht ca. 5 t) in den steuernden Rechner zu übertragen. Die Ansteuerung der Servoverstärker, die das Teil drehen, kommen aus dem PC. Die Regelstrecke ist als PID-Regler realisiert. Damit der Soll-Ist-Vergleich zuverlässig funktioniert, muss stets gewährleistet sein, dass der IOW
1. Seine Daten mit einem garantierten zeitlichen Abstand liefert (ist erfüllt)
2. Immer verfügbar ist.
Bedeutet im Umkehrschluss, dass ich ein Entfernen des IOW zu jeder Zeit (bzw. seinen Ausfall) bemerken muss. Damit die Daten schnell genug in den PC kommen, greife ich gesteuert durch einen eigenen Timer (timeSetEvent() Funktion aus der Win32-Api) auf den IOW zu.
Ich vermute nun, dass ein Ausstecken des IOW während eines aus der CLR heraus laufenden Zugriffs auf die iowkit.dll, die selbige zum Absturz bringt. Ich werde versuchen, dass über GetLastError() herauszufinden. Manchmal funktioniert der Mechanismus und manchmal wieder nicht. Das ist Glückssache. Das bestärkt mich in meinem Verdacht.
Ein vom Steuerprogramm unbemerkter Ausfall des IOW's hätte böse Folgen für die gesteuerte Anlage und die Menschen, die daran Arbeiten. Ich muss mir da also was einfallen lassen.
Marc
erst mal vielen Dank für Deine Antwort. Du hast recht, wenn Du sagst, dass für den Anwender eh nichts mehr zu machen ist, wenn der IOW nicht mehr funktioniert.
Nur in meinem Fall sind die Anforderungen etwas andere. Der IOW und die zugehörige Klassensammlung wird von mir genutzt um Drehwinkel eines zweiachsigen Systems (Gewicht ca. 5 t) in den steuernden Rechner zu übertragen. Die Ansteuerung der Servoverstärker, die das Teil drehen, kommen aus dem PC. Die Regelstrecke ist als PID-Regler realisiert. Damit der Soll-Ist-Vergleich zuverlässig funktioniert, muss stets gewährleistet sein, dass der IOW
1. Seine Daten mit einem garantierten zeitlichen Abstand liefert (ist erfüllt)
2. Immer verfügbar ist.
Bedeutet im Umkehrschluss, dass ich ein Entfernen des IOW zu jeder Zeit (bzw. seinen Ausfall) bemerken muss. Damit die Daten schnell genug in den PC kommen, greife ich gesteuert durch einen eigenen Timer (timeSetEvent() Funktion aus der Win32-Api) auf den IOW zu.
Ich vermute nun, dass ein Ausstecken des IOW während eines aus der CLR heraus laufenden Zugriffs auf die iowkit.dll, die selbige zum Absturz bringt. Ich werde versuchen, dass über GetLastError() herauszufinden. Manchmal funktioniert der Mechanismus und manchmal wieder nicht. Das ist Glückssache. Das bestärkt mich in meinem Verdacht.
Ein vom Steuerprogramm unbemerkter Ausfall des IOW's hätte böse Folgen für die gesteuerte Anlage und die Menschen, die daran Arbeiten. Ich muss mir da also was einfallen lassen.
Marc
-
friend-of-rq
- Posts: 389
- Joined: Sun Feb 13, 2005 1:22 pm
- Location: Gerblingerode / Duderstadt
- Contact:
Hallo Rumo,
setze doch einen zweiten IOW (redundant) ein,
dann solltest Du alle Anschlüsse (Ports) galvanisch trennen,
damit Du den IOW erst gar nicht zum aufhängen bringst.
Die Teile laufen sehr stabil, wenn man nicht zu lange Leitungen an
den Ports verwendet (EMV) .
Ich verwende einige IOWs durchgehend, zur Datenerfassung ohne Probleme,
da geht es aber nicht um 5 Tonnen die bewegt werden.
Linux scheint mir da eher geeignet zu sein, als Ein Windows Rechner für solche heiklen Aufgaben.
mfg
R.Greinert
setze doch einen zweiten IOW (redundant) ein,
dann solltest Du alle Anschlüsse (Ports) galvanisch trennen,
damit Du den IOW erst gar nicht zum aufhängen bringst.
Die Teile laufen sehr stabil, wenn man nicht zu lange Leitungen an
den Ports verwendet (EMV) .
Ich verwende einige IOWs durchgehend, zur Datenerfassung ohne Probleme,
da geht es aber nicht um 5 Tonnen die bewegt werden.
Linux scheint mir da eher geeignet zu sein, als Ein Windows Rechner für solche heiklen Aufgaben.
mfg
R.Greinert
Hallo Marc,
weg ist?
Wieviel Spielraum lässt dir die externe Hardware? Ist es OK wenn Windows da mal 1/2 sekunde Überlegt?
Böse Folgen für Menschen müssen bei einem solchen Projekt definitiv ausgeschlossen werden. Für einen Unfall mit Personschaden der von einem Windows Timing-Problem in deiner Software verursacht wurde, wird die Berufsgenossenschaft deinen Kopf fordern und auch bekommen...
Eberhard
Das hört sich für mich eher nach einer Aufgabe für eine SPS-Steuerung an. Ich kann mich wohl damit anfreunden das ein "normales" Betriebssystem als Mensch-Maschine Schnittstelle und zur Überwachung eingesetzt wird, aber für eine direkte Ansteuerung wäre mir persönlich ein Echtzeitsystem lieber. (Wobei man RealTime-Linux und IOW auch gleich wieder vergessen , da sich wohl USB und Echtzeit-Anwendungen eher ausschliessen.)Rumo wrote: Nur in meinem Fall sind die Anforderungen etwas andere. Der IOW und die zugehörige Klassensammlung wird von mir genutzt um Drehwinkel eines zweiachsigen Systems (Gewicht ca. 5 t) in den steuernden Rechner zu übertragen. ....
Die Frage ist, wie lange dauert es, bis Windows bemerkt hat das der IOW
Damit der Soll-Ist-Vergleich zuverlässig funktioniert, muss stets gewährleistet sein, dass der IOW
1. Seine Daten mit einem garantierten zeitlichen Abstand liefert (ist erfüllt)
2. Immer verfügbar ist.
Bedeutet im Umkehrschluss, dass ich ein Entfernen des IOW zu jeder Zeit (bzw. seinen Ausfall) bemerken muss.
weg ist?
Wieviel Spielraum lässt dir die externe Hardware? Ist es OK wenn Windows da mal 1/2 sekunde Überlegt?
Ich glaube eigentlich nicht dass die IowKit-abstürzt. Die Funktionen zum lesen vom IOW sind über verschiedene Mutexe gut abgeschirmt. Das Hauptproblem ist , dass man beim Lesen gar nicht mitbekommt, das der IOW entfernt wurde. Das ist einer der Vorteile der Linux-Version, mit der man etwas leichter auf Hardware Fehler prüfen kann.Damit die Daten schnell genug in den PC kommen, greife ich gesteuert durch einen eigenen Timer (timeSetEvent() Funktion aus der Win32-Api) auf den IOW zu.
Ich vermute nun, dass ein Ausstecken des IOW während eines aus der CLR heraus laufenden Zugriffs auf die iowkit.dll, die selbige zum Absturz bringt.
Wie mein alter Chef einmal sagte : Es ist mir egal wieviel Geld ihr auf den Baustellen vernichtet, aber wenn Blut fließt ist der Spass vorbei!"Ein vom Steuerprogramm unbemerkter Ausfall des IOW's hätte böse Folgen für die gesteuerte Anlage und die Menschen, die daran Arbeiten. Ich muss mir da also was einfallen lassen.
Böse Folgen für Menschen müssen bei einem solchen Projekt definitiv ausgeschlossen werden. Für einen Unfall mit Personschaden der von einem Windows Timing-Problem in deiner Software verursacht wurde, wird die Berufsgenossenschaft deinen Kopf fordern und auch bekommen...
Eberhard
Ihr teilt meine Bedenken :-) Ich hatte als Alternativlösung einen Microcontroller vor Augen. Das werde ich jetzt auch in die Tat umsetzen. Ein AVR-Controller der Firma Atmel wird mich durch das Projekt Retten. Da brauche ich keine Abstriche bei der Geschwindigkeit und erst recht nicht im Bereich der Sicherheit zu machen. Eine halbe Sekunde Windows-Nirvana ist definitiv zu gefährlich. Und meinen Kopf der Berufsgenossenschaft spenden - das möchte ich natürlich auf gar keinen Fall :-)
Marc
Marc
-
Guido Körber
- Site Admin
- Posts: 2876
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Ich möchte an dieser Stelle nur anmerken, dass wir für sowas natürlich auch keine Produkthaftung übernehmen...
Also den IO-Warrior als Schnittstelle zur Kommunikation mit so einem System zu verwenden ist kein Problem, aber die Sicherheitsfunktionen sollten auf keinen Fall auf der Kommunikation zwischen IO-Warrior und Rechner aufbauen, das ist nicht hinreichend sicher zu gewährleisten.
Also den IO-Warrior als Schnittstelle zur Kommunikation mit so einem System zu verwenden ist kein Problem, aber die Sicherheitsfunktionen sollten auf keinen Fall auf der Kommunikation zwischen IO-Warrior und Rechner aufbauen, das ist nicht hinreichend sicher zu gewährleisten.
Moin Guido,
das ist absolut klar. Da es sich um eine Eigenentwicklung in unserem Hause handelt, liegt das Risiko des Konzeptes auch auf unser Seite. Echtzeit ist eben mit Windows kein Thema. Da kann der Io-Warrior sowieso mal gar nichts dafür.
Die Geschwindigkeit des Bausteins ist eh fantastisch. In meinen Tests waren die Timing-Werte immer exakt so wie erwartet. Nur die Sicherheit ist eben mit Windows nicht zu gewährleisten. Wird dann doch ein Microcontroller. Der ist schnell genug und hat echte Interrupts. Das schafft Sicherheit. Klagen kommen jedenfalls keine - zumindest nicht von uns :-)
Marc
das ist absolut klar. Da es sich um eine Eigenentwicklung in unserem Hause handelt, liegt das Risiko des Konzeptes auch auf unser Seite. Echtzeit ist eben mit Windows kein Thema. Da kann der Io-Warrior sowieso mal gar nichts dafür.
Die Geschwindigkeit des Bausteins ist eh fantastisch. In meinen Tests waren die Timing-Werte immer exakt so wie erwartet. Nur die Sicherheit ist eben mit Windows nicht zu gewährleisten. Wird dann doch ein Microcontroller. Der ist schnell genug und hat echte Interrupts. Das schafft Sicherheit. Klagen kommen jedenfalls keine - zumindest nicht von uns :-)
Marc
Moin Eberhard,
die Lösung ist interessant. Macht das Entwickeln einer eigenen Firmware für den Atmel-Controller (in Sachen USB) überflüssig. Es gibt zwar viele sehr brauchbare Beispiele, aber der Teufel steckt ja immer im Detail.
Anbei: Kannst Du mir sagen, welche Geschwindigkeiten über das SPI des Io-Warrriors in der Praxis erreicht werden können ? Ist das komfortabel und leicht projektierbar ? Ich habe damit noch nie gearbeitet, weiß aber, das der Atmel-AVR meiner Wahl das Interface unterstützt. Wenn nötig mache ich für die Frage einen neuen Thread auf. Nur, um nichts zu vermischen.
Marc
die Lösung ist interessant. Macht das Entwickeln einer eigenen Firmware für den Atmel-Controller (in Sachen USB) überflüssig. Es gibt zwar viele sehr brauchbare Beispiele, aber der Teufel steckt ja immer im Detail.
Anbei: Kannst Du mir sagen, welche Geschwindigkeiten über das SPI des Io-Warrriors in der Praxis erreicht werden können ? Ist das komfortabel und leicht projektierbar ? Ich habe damit noch nie gearbeitet, weiß aber, das der Atmel-AVR meiner Wahl das Interface unterstützt. Wenn nötig mache ich für die Frage einen neuen Thread auf. Nur, um nichts zu vermischen.
Marc
-
Guido Körber
- Site Admin
- Posts: 2876
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact: