Probleme mit neuer dll

[Joe GO!!!]

Hi,

ich schreibe ein Programm zur Zeitmessung einer Carrerabahn.
Das Programm erstelle ich mit VB 6.

Dazu sind an dem IOW (24/40/56) Lichtschranken angeschlossen.
Da die Anwendung sehr zeitkritisch ist wird der IOW über ein Timer mit dem Interval 1 abgefragt.

Bislang lief alles zu meiner Zufriedenheit.
Jetzt hab ich, damit ich auch den IOW56 ansteuern kann die alte iowkit.dll 1.2.4.0 gegen die 1.5 ersetzt.


Dabei treten folgende Probleme auf:

1. Bislang hab ich den IOW über die Funtktion iowkitReadimmediate ausgelsen. Mit der neuen dll friert das Programm jedoch nach einer nicht definierten Anzahl von Lesevorgängen über den Timer ein.

Da ja aber die Funtkion Iowkitreadnonblocking wohl zu bevorzugen ist habe ich darauf umgestellt und die Lesevorgänge funktionieren reibungslos. Damit ist das Problem eigentlich kein Problem mehr, vielmehr ein Hinweis.


2. Wenn der IOW bei laufender Software ausgezogen wird, war der Programmablauf unter der alten dll nicht gestört, das programm lief weiter, natürlich kamen keine Meßergebnisse mehr zustande - man konnte aber wenigstens den bisherigen Stand speichern.

Mit der neuen dll wird beim nächsten Aufruf der Funktion iowkitreadnonblocking das gesamte Programm geschlossen und man hat keine Chance mehr irgendwelche Einstellungen / Stände zu speichern.
(Nur um das klar zu stellen, eine solche Funktion hab ich nicht einprogrammiert)

Trotz ich schon die Suche bemüht habe, konnte ich keine passenden Beiträge zu dem Problem finden.
Gibt es eine Möglichkeit das alte Verhalten wieder herzustellen, buw. habe ich vielleicht eine zusätzliche Funktion übersehen mit der ich das umstellen kann?

Wie kann ich das Schließen des Programmes verhindern?

[towaibw]

Ich arbeite nicht mit VB6 und kann Dir somit auch nicht direkt helfen, kann aber die Unterschiede der dll Versionen (1.4/1.5) teilweise bestätigen. Hinzu kommt noch, das die 1.5er Version auch nur von einem Programm benutzt werden kann, eine zweite Benutzung liefert nur noch 0 IO-Warrior.
Mit der 1.4er Version habe ich es hinbekommen, dass Programme nach dem Abziehen eines IO-Warriors und Wiederansteckens normal weiterlaufen (alte Pin-Zuständer werden wiederhergestellt).

Ich wünschte mir auch eine 1.4er, die den IO-Warrior 56 unterstützt. Aber so viel ich weis, sind dazu Änderungen notwendig, die eben nur in der 1.5er eingearbeitet wurden.

[Joe GO!!!]

Die Fehler sind zwar nicht überlebenswichtig, ich finde es aber sehr unfein, wenn ein Programm dann einfach so abschaltet.

Viel nerviger mit der neuen dll ist es, wenn es in der VB6-Arbeitsumgebung zu einem Programmfehler in meinen Codezeilen kommt, oder ich den Programmlauf vorzeitig zum Debuggen beende, dann hängt sich die ganze VB 6 Suite auf.

Da wäre ein Workaround, bzw ein Bugfix wünschenswert.

[Christoph Jung]

Schaltet das Programm denn mit einer Fehlermeldung ab oder so als ob man es beendet? Weil wenn keine Fehlermeldung kommt liegt mit großer Warscheinlichkeit ein Fehler im Programm selber vor. Am besten mal den Debugger mit einem Breakpoint auf dem ReadNonBlocking() durchlaufen lassen und schauen was der Debugger schreibt, wenn der IOWarrior bei Betrieb abgezogen wird.

Um das Abziehen zu behandeln kann man mit dem Event WM_CHANGEDEVICE arbeiten. Das regiert auf alle Änderungen am USB und man kann so abfangen, ob der IOWarrior noch da ist oder nicht.

[wayoda]

Hallo,

Um das Abziehen zu behandeln kann man mit dem Event WM_CHANGEDEVICE arbeiten. Das regiert auf alle Änderungen am USB und man kann so abfangen, ob der IOWarrior noch da ist oder nicht.

Der Event heißt WM_DEVICECHANGE und wird leider erst ausgelöst wenn das USB-Device komplett aus dem Speicher verschwunden ist. Das kann schon mal 1-2 Sekunden dauern, der Event taugt also nicht um diesen Fehler im Vorfeld abzufangen.

Eberhard

[Christoph Jung]

Hmm....stimmt

Was mich viel mehr interessiert ist die Tatsache, dass anscheinend keine Fehlermeldung kommt (jedenfalls nach dem Post oben).

Noch eine Frage:
Wird irgendwo abgefragt, ob das lesen erfolgreich war? À la :

Code: Select all

if(IowKitReadNonBlocking(....))
{
     //Alles klar, Daten empfangen
}
else
{
     //Fehlerbehandlung, Handle unbekannt / fehlerhaft
 }

Besser wäre zwar "try...catch" aber immer eins nach dem anderen.

[Joe GO!!!]

HI,

sorry für die lange Pause...


eine Fehlermeldung erscheint nicht, das Programm verschwindet unmittelbar vom Bildschirm - mit allen geöffneten Fenstern.

Mit der alten DLL trat dieses verhalten nicht auf - daher denke ich nicht, dass das Fehlverhalten Programmbedingt ist. Zudem müsste in der SDK von VB6 dann eine Fehlermeldung kommen und nicht komplett alles geschlossen werden.
Programmfehler werden ja von der Entwicklungsumgebung normalerweise abgefangen.


Einen Versuch, das erfolgreiche Lesen sicherzustellen habe ich mit der VB Funktion:

OnErrorGoto fehlerbehandlung

IowKitReadNonBlocking (...)

End sub

Fehlerbehandlung:
Msgbox(...)


Normalerweise wird dann bei einem auftretenden Programmfehler zu der Sprungmarke fehlerbehandlung: verwiesen, aber auch dieses wird nicht ausgeführt.

[Christoph Jung]

Wenn ein Programm ohne Fehlermeldung aussteigt, dann ist das in der Regel ein zeichen dafür, dass was im Programm nicht richtig läuft. Nur weil etwas mit der alten 1.2 DLL lief und mit der neuen 1.5 nicht ist das kein Grund den Fehler nicht im eigenen Programm zu suchen. Vor allem wenn man gleich von 1.2 nach 1.5 umsteigt. Dort hat sich nämlich einiges getan (vorallem die unterstützung des IOW56, sowie das allzeit beklagte "IOW-Krallen").

Der IOW56 hat eine extra Special-Mod, die die Arbeit von ReadImmediate übernimmt. Leider hab ich die gerade nicht hier (hab urlaub) und kann erst am Montag nachschauen (oder mal das Datenblatt zum IOW56 nehmen, da stehts drin).

zu 2.
Wenn man die Abfrage im Timer richtig macht, dann sollte alles normal wieterlaufen. Da das Programm ja beendet wird heißt das für mich, dass dort nicht genug "Fehlerbehebung" betrieben wird.
Tipp: Abfangen, ob überhaut noch Daten reinkommen.

Die untere "Fehlerbehandlung" ist nicht wirlich aussagekräftig. Ein wenig mehr Infos wäre schon gut. Ich würde mir auch das Programm auf meinem System anschauen. Einfach das Projekt Zippen und an JUNG AT CODEMERCS DOT COM schichen und ich werd sehen, ob bei mir das selbe Problem besteht.

[Joe GO!!!]

Hi,

natürlich schließe ich einen Fehler im Programm nicht aus, nur da ich keine Möglichkeit habe diesen abzufangen weiß ich nicht recht, wo ich suchen soll.
Zumal im Debugg-Modus, also beim Ausführen einzelner Befehle auf Tastendruck genau bei Bestätigung und Ausführung der ReadIm.-Zeile sich die komplette Entwicklungsumgebung schließt.

Ggf. schließe ich hier einen Fehler in der VB6 Umgebung auch nicht aus, der mit der dll zum Fehler führen könnte - was sich meiner Meinung nach dadurch bestätigen könnte, dass seit der neuen dll bei einem Programmfehler, der nichts mit der IOW-dll zu tun haben braucht, die ganze Entwicklungsumgebung aufhängt. Hier sollte sich eigentlich der Debugger öffnen.


Der Fehler tritt aber sowohl beim IOW24, 40 und 56 auf - läßt sich also nicht auf einen bestimmten Chip beschränken.


In der Fehlerbehandlung meines Programmes geschieht nichts weiter, als eine Fehlermeldung auszugeben und den Timer-Lauf zu beenden.

Gerne werde ich das Projekt zippen und einsenden.
Der Service rund um die Chips ist ja echt super, da gebt ihr euch wirklich Mühe.