Absturz der Relaiskarte bei Ansteuerung

Hallo zusammen, ich habe ein Problem mit meiner Relaiskarte... Leider hat anscheinend noch niemand mit diesem Modell gearbeitet. Zumindest habe ich noch keine Beiträge hierzu gefunden. Ich arbeite mit LabVIEW 8.6 unter Windows XP Pro, meine Messkarte ist eine Meilhaus Redlab miniLab 1008 mit der Relaiskarte ME-UBRE
Ziel des Projekts ist es, eine vollautomatisierte Anlage zu bauen. Dazu versuche ich im Moment, die Motoren und Magnetventile fehlerfrei anzusteuern. Leider funktioniert es nicht so, wie ich mir das vorstelle. Zwar lassen sich die Ventile und Motoren über das Programm schalten, nach teilw. drei bis vier Klicks bekomme ich dann aber immer wieder die "keine Rückmeldung-Fehlermeldung" von Windows. In Einzelfällen muss dann sogar komplett LabVIEW neu gestartet werden, einmal hat sich auch der PC insgesamt aufgehängt. Da ich noch ein ziemlich blutiger Anfänger in Sachen LabVIEW bin, kann es sein, dass ich irgendwelche einfachen Grundlagen nicht beachtet habe?
Im Anhang habe ich das VI mal abgelegt. Ich hoffe, mir kann jemand helfen.
Grüße,

Janni

Anzeige

' schrieb:bekomme ich dann aber immer wieder die "keine Rückmeldung-Fehlermeldung" von Windows.

Zitat:In Einzelfällen muss dann sogar komplett LabVIEW neu gestartet werden, einmal hat sich auch der PC insgesamt aufgehängt.

Klinkt so, als ob sich der Device-Treiber aufhängt.

Zitat:kann es sein, dass ich irgendwelche einfachen Grundlagen nicht beachtet habe?

Das kann ich so ohne weiteres nicht sagen. Aber folgendes:

Sequenziere mal die vier Blöcke. Mach dazu eine Flache Sequenzstruktur mit vier Cases. In jeden Case setzt du einen Block rein. Theoretisch könnte der Device-Treiber ohne die Sequenzierung durcheinander kommen.

Außerdem:
Möglicherweise haben die Mailhaus-SubVIs einen Error-Ausgang (wenn auch nur einen Fehlercode), den man auswerten kann. Also: Kucken und überprüfen.

Und:
Wenn aus dem ersten SubVIs (das mit dem Auxport-Anschluss) ein Handle herauskommt - dann sollte dieses SubVI vor der While-Schleife ausgeführt werden. Auch das Mehrfachausführen wäre dann nicht gut. Einfach den Handle auf alle SubVIs mit FIRSTRORTA-Anschluss geben. (Und nicht vergessen den Handle nach der Schleife wieder zu schließen.)

Danke erstmal für die Tipps. Ich habe das soweit mal ausprobiert (überarbeitete Version im Anhang), es stürzt jetzt nicht mehr komplett ab, allerdings hängt sich der Treiber/die Karte immernoch auf. Und zwar immer dann, wenn ich als letztes einen der Motoren abschalte. Die Ventile kann ich so viel und schnell hintereinander schalten, wie ich lustig bin. Nur wenn ich erst alles andere und zum Schluss einen der Motoren abstelle oder einfach nur einen Motor an und danach wieder ausstelle hakt da irgendwas und es dauert dann immer ca. 30 sek - 1min bis man wieder irgendetwas bedienen kann.
Die Fehlermeldungen haben leider nichts ergeben. Laut dem Programm läuft alles fehlerfrei.
Und ich finde irgendwie keine n Befehl, mit dem ich DCfgPort schließen oder beenden kann...

' schrieb:(überarbeitete Version im Anhang)

So hab ich mir das vorgestellt.
Hier ist im übrigen die Beschreibung zu deinen SubVIs.

Zitat:einfach nur einen Motor an und danach wieder ausstelle hakt da irgendwas

Also nur alleine das Ein- und wieder Ausschalten eines Motors kann zu einem "Fehler" führen?
Da tippe ich jetzt aber eher auf einen Hardwaredefekt oder auf eine unerlaubte Einsatzweise der Hardware. Möglicherweise sollte aber auch zwischen den einzelnen SubVI-Aufrufen (DBitOut.VI) eine Wartezeit von z.B. 20ms. sein.

Zitat:Und ich finde irgendwie keine n Befehl, mit dem ich DCfgPort schließen oder beenden kann

Laut Beschreibung ist sowas auch nicht nötig. Einen Handle, der gelöscht werden müsste gibt es nicht. Die SubVIs machen wahrscheinlich nur primitive IO-Befehle.

Wie immer mein Tip:
Verwende eine Karte von NI, da kannst Du den DAQmx-Treiber verwenden. Damit kannst Du die Karte wesentlich einfacher programmieren.

Gruß Markus

So, ich hab dann mal in die einzelnen Cases jeweils eine Wartezeit von 100ms eingebaut. Jetzt blinkt zwar manchmal ganz kurz (für einen Bruchteil einer Sekunde) eine Fehlermeldung auf, aber insgesamt hakt es nicht mehr...
Jetzt ist nur die Frage, ob ich versuchen sollte, den Fehlermeldungen auf den Grund zu gehen, oder mich freuen soll, dass es jetzt läuft?!

PS: Danke für die Bechreibung!

@Y-P: Ich hab die Einkäufe nicht gemacht... mir wurde die Hardware so vorgesetzt...

' schrieb:So, ich hab dann mal in die einzelnen Cases jeweils eine Wartezeit von 100ms eingebaut.

Zitat:Jetzt blinkt zwar manchmal ganz kurz (für einen Bruchteil einer Sekunde) eine Fehlermeldung auf

Das kann nicht sein. Normalerweise.

Als Wartezeit hast du bestimmt "Wait.VI" genommen, nicht "Metronom.VI" (das ist auch richtig so). Dein Schleifendurchlauf dauert zwar immer noch (nur) 1000ms, aber jeder einzelne Case dauert jetzt 100ms. Da die Fehlermeldungen in den Cases nur eineinziges Mal ausgegeben werden - müssen sie für 1000ms in der Anzeige erscheinen. Diese eine Sekunde ist aber nicht "für einen Bruchteil einer Sekunde". Hier besteht also eine Inkonsistenz zwischen dieser deiner Aussage und dem, was ich von deinem Sourcecode noch im Kopf habe.

Zitat:Jetzt ist nur die Frage, ob ich versuchen sollte, den Fehlermeldungen auf den Grund zu gehen, oder mich freuen soll, dass es jetzt läuft?!

Beides! (Eigentlich nur ersteres: Wenn du dich freust, dass dein Programm jetzt richtig geht, hat das den Touch, als ob du hoffst und wünscht, dass es gehen möge. Beides zeugt eher von Glauben als von Wissen ... ^_^)

Hab jetzt nebenbei noch ein bißchen dran rumgespielt, die Laufzeit der While-Schleife variiert und wenn die auch bei 100ms liegt, dann zeigen sich nur kleine Verzögerungen, wenn man sehr schnell und sehr häufig hintereinander die Geräte startet und wieder stoppt... Also ich glaube zumindest, damit klarzukommen... Zumindest jetzt...weiß ja noch nicht, was passiert, wenn ich das ganze ins Hauptprogramm einbinde...

Wegen der Anzeige: Kann es vllt sein, dass die Anzeige so träge ist, dass ich die Fehlermeldung erst kurz vor Ablauf der einen Sekunde angezeigt bekomme? Die blinkte wirklich immer nur ganz kurz auf.

' schrieb:dann zeigen sich nur kleine Verzögerungen, wenn man sehr schnell und sehr häufig hintereinander die Geräte startet und wieder stoppt

Diese Verzögerungszeit scheint durch die SubVIs (die mit den DLLs) zu kommen. Das hieße aber, dass die DLL selber so lange, also zu lange, braucht. Das halte ich für nciht richtig.

Zitat:Kann es vllt sein, dass die Anzeige so träge ist,

Nein.
Im Normalfall ist die Anzeige nicht träge. Eher sogar schnell. Anormale Fälle wären, wenn der Recher zu langsam ist oder das BD zu viel Zeit beansprucht. Was sagt denn überhaupt der Taskmanager von Windows bezüglich Prozessorauslastung?

Zitat:Die blinkte wirklich immer nur ganz kurz auf.

Nur ganz kurz aufblinken heißt ja, dass der Text, der mal reingeschrieben wird, sofort wieder gelöscht wird. Das sofortige Löschen aber ist unlogisch. Das würde heißen, dass der Durchlauf der While-Schleife plötzlich ganz schnell geht.