Mehrere angeschlossene IOW´s, nur einen nutzen

[Matthias]

Hallo!
Nachdem ich den "Hardwarekrams" jetzt soweit durch habe bin ich auf ein unschönes Verhalten in der dll gestoßen, welches auch schon in dem Artikel http://www.codemercs.de/phpBB2/viewtopi ... wrapheader beschrieben ist.
Ich habe 2 Anwendungen die vollkommen unterschiedliche Aufgaben ausführen sollen. Jede Anwendung hat einen IOW. Da mir die Unterscheidung per Seriennummer viel zu schlecht erscheint (ich protokolliere doch keine Seriennummern...) habe ich dafür jedem IOW ein eeprom spendiert, über den ich den jeweils richtigen erkenne. Das klappt auch einzelnd - aber leider macht die Funktion IowKitCloseDevice Lib "iowkit" (ByVal iowhandle As Long) nicht das was ich erhofft habe ;-) Ich ging davon aus, dass nur der IOW mit dem Handle geschlossen wird. Die Doku schreibt dazu "IowKitCloseDevice() closes all open devices". Das ist sehr ungünstig.

Mein Code (vb6) sieht so aus:

Code: Select all

Public Function Connect_IOW(Optional EEProm_Address As i24C01Address = [A0h-000 (160)], Optional EEPromValue As String = "")
Dim buf(0 To 18) As Byte, iowhandle As Long, usehandle As Long, i As Integer
    
    usehandle = 0
    iowhandle = IowKitOpenDevice()
    If (iowhandle = 0) Then
        RaiseEvent ConnectError([Kein IOW verfuegbar])
        exit function
    End If
    
    For i = 1 To IowKitGetNumDevs
        iowhandle = IowKitGetDeviceHandle(i)
            Debug.Print "ProductID: " & IowKitGetProductId(iowhandle)
        IowKitGetSerialNumber iowhandle, buf(0)
            Debug.Print "SerialNumber: " & CStr(buf)
        
        EnableIIC iowhandle, 1
        
        If ReadOut24C1(iowhandle, EEProm_Address, EEPromValue) Then
            If usehandle > 0 Then
                RaiseEvent ConnectError([Doppelter IOW])    '2 gleiche Geräte, nur den ersten verwenden
                'IowKitCloseDevice (iowhandle)              '<- Das klappt nicht
            Else
                RaiseEvent ConnectToIOW(iowhandle)
                usehandle = iowhandle
            End If
        Else
            Debug.Print "Falscher IOW " & iowhandle & "!"
            'IowKitCloseDevice (iowhandle)              '<- Das klappt nicht
    End If
    Next
    
    If usehandle = 0 Then RaiseEvent ConnectError([Kein passender IOW]): Exit Function
    
    Debug.Print ReadOut24C1(usehandle, EEProm_Address)  'Ist immer leer, wenn IowKitCloseDevice gerufen wurde
    
    Connect_IOW = myhandle
End Function

Der richtige IOW wird auch erkannt, wenigstens wenn ich kein CloseDevice einbaue.
Wie gebe ich den, für diese Anwendung falschen, IOW wieder frei?
Gibt es dafür schon eine Lösung?

Gruß
Matthias

[Christoph Jung]

Das ist ein Problem im Konzept der 1.5 DLL durch die Einbindung des IOW56 und der Thread-festigkeit. Lässt sich leider nicht vermeiden wenn man mit der DLL arbeitet. Und die Weiterentwicklung wird sich auf unbestimmte Zeit verschieben, weil der dafür verantwortliche Entwickler leider verstorben ist.

[Matthias]

Ok, damit kann ich die 1.5er dll also nicht sicher nutzen. Wie ärgerlich...
Gibt es noch ein älteres SDK? Den 56er IOW brauche ich nicht.
Oder hat vielleicht schon ein C´ler die dll dahingehend modifiziert?

Gruß

[friend-of-rq]

Hallo Matthias,

ich habe deswegen den IOW-Socket-Server entwickelt,

mehrere Programme können alle angeschlossenen IOWs nutzen, egal welcher Type IOW 24/40/56
die Befehle sind für alle IOWs gleich, es besteht sogar die Möglichkeit das sich mehrere Programme einen IOW auch übers Netz teilen, das Managment übernimmt der Socket-Server.

Auf meiener Seite gibt es eine Beta Version ...

Eine Überarbeitete Version die ich bereits selber nutze (Alpha-Test) wird demnächs veröffentlicht.

mfg
R.Greinert

[Matthias]

Hallo Herr Greinert,
ich habe mir den Socket-Server schon angesehen. Grundsätzlich geht das aber in eine andere Richtung. Meine Anwendungen kommunizieren schon über´s internet Netz. Da es aber ausschließlich intern abläuft nutze ich hierfür SMB-Mailslots & Named Pipes um konfigurationsfrei bleiben zu können (so brauche ich mir keine Gedanken darüber zu machen, ob ein Port auf der Serverseite verfügbar ist bzw. wie ich danach den Port an die Clients weiterleite.)

Das grundsätzliche Problem was ich sehe ist die zukünftige Verwendbarkeit. Im Moment bin ich vielleicht bei meinen Kunden der erste, der einen IOW einsetzt - aber was ist wenn sich das Produkt mehrfach verkauft und plötzlich ein 2. Produkt mit einem IOW "unter der Haube" zum Einsatz kommt. Dann stehe ich mit einem langen Gesicht in der Ecke und schäme mich ;-)

Ok, das ist vielleicht etwas übertrieben gedacht, aber es ist halt nicht auszuschließen. In dem Falle müßte jeder ihren Socket-Server einsetzen, oder aber über meine Pipes reden wollen. Das ist aber irgendwie noch abwägiger.

Es gibt hier doch bestimmt jemanden, der in C fit genug ist die Funktion CloseDevice umzumodeln... Oder bin ich wirklich der einzige der diese Funktion braucht?

Gruß
Matthias

[Guido Körber]

Das ist nicht ganz trivial, die Verwaltung welchem Programm welcher IO-Warrior oder welcher Teil davon gehört, hat es in sich. Mit einer einfachen DLL ist das nicht erschlagen. Wir werden demnächst das Projekt API 2.0 wieder anfassen, einen Zeitplan dazu kann ich aber noch nicht angeben.

[Matthias]

Hallo Herr Körber!
"...nicht ganz trivial, die Verwaltung welchem Programm welcher IO-Warrior..."
Ist verständlich, für mich stellt es aber wirklich ein großes Problem dar. Auf eine neue API warten, mit der irgendwann begonnen wird ist aber leider keine Lösung, da wird mir die Zeit ausgehen.

Wenn ich den Beitrag von Herrn Jung richtig verstehe ist mein Problem direkt auf die 1.5er dll bezogen. Welche Nachteile würde ich denn durch eine ältere Version erfahren, und vor allem - wo bekomme ich eine her? Wenn ich es richtig lese ist die Übergabe des Handles an IowKitCloseDevice nur aus kompatiblitätsgründen zur 1.4er dll vorhanden. Also muss die Version es ja noch gekonnt haben...

Gruß
Matthias

[Christoph Jung]

Wenn es so einfach wäre die Funktionen umzuschreiben, dann hätten wir sicher schon eine neuere Version herausgebracht. Aber leider ist das nicht so einfach.

Es gibt eine ältere Version 1.4, in der man zumindest mit unterschiedlichen Programmen auf einen IO-Warrior zugreifen kann (hab nur kurz getest ob man mit 2 Programmen auf einen IOW24 connecten kann). Allerdings sind dort einige Funktionen nicht enthalten, wie z.B. IowKitReadNonBlocking() oder die unterstützung für den IOW56 und einige sicherheitsrelevanter dinge wie Threadsicherheit und der gleichen.

Man kann das ganze auch zu fuß machen indem man auf die DLL verzichtet und die reinen HID-Funktionen nutzt. Allerdings muss man hier einiges beachten und sich selber um Sicherheit und Stabilität kümmern.

[Matthias]

"Wenn es so einfach wäre die Funktionen umzuschreiben, dann hätten wir sicher schon eine neuere Version herausgebracht. Aber leider ist das nicht so einfach."
Ok :-(

"Es gibt eine ältere Version 1.4, in der man zumindest mit unterschiedlichen Programmen auf einen IO-Warrior zugreifen
kann (hab nur kurz getest ob man mit 2 Programmen auf einen IOW24 connecten kann)."
Wobei ich das ja gar nicht möchte. Ich möchte mit 2 Programmen auf 2 IO-Warrior zugreifen. Also, jedem sein eigen.

"Allerdings sind dort einige Funktionen nicht enthalten, wie z.B. IowKitReadNonBlocking() oder die unterstützung für den IOW56 und einige sicherheitsrelevanter dinge wie Threadsicherheit und der gleichen."
ReadNonBlocking ist natürlich sehr ärgerlich, IOW56 ist mir wie gesagt egal und die Threadsicherheit - das müsste ich mir anschauen.

Gibt es da denn noch ein SDK zu?

Gruß
Matthias

[Christoph Jung]

Ich habe da nochmal eine Frage bezüglich der Nutzung des Programms, weil Sie so auf IowKitCloseDevice() aus sind.

Was sollen Sie genau machen?

A) Wollen Sie mit einem Programm unterschiedliche IO-Warrior ansprechen, bzw. den richtigen Auswählen?
B) Wollen Sie mehrere Programme gleichzeitig laufen lassen und die IO-Warrior ansprechen?
C) Wollen Sie beides gleichzeitig?


Wenn Sie A) wollen, dann machen Sie es grundlegend falsch in ihrem Quellcode. Die Funktion IowKitGetDeviceHandle() sollte mit einem Array genutzt werden. SO lassen sich die einzelnen IO-Warrior ansprechen. Da braucht man kein CloseDevice aufrufen.

Zu B) Das ist nicht möglich, da die DLL sich im prinzip nur einmal aufrufen lässt. Dafür ist dann die Application mit den Sockets sehr interessant, dich sich auch sehr gut kocal als Dienst nutzen lassen würde (tolles Tool :D )

Zu C) wie bei B) das selbe.

[Matthias]

Da gebe ich doch gerne Auskunft...

Ich habe 2 IO Warrior. Jeder davon hat eine Anwendung die drauf zugreifen soll. Ich möchte also IOW A mit Anwendung A und IOW B mit Anwendung B laufen lassen.
Das Problem das ich habe liegt auch nicht am "hier und jetzt". Die eine Anwendung wird eh ein NT-Service, da könnte ich die Aufrufe meiner beiden IOW´s dann auch durchschleusen - das hilft mir aber nichts wenn ich es verkaufen will.
In dem Moment wo ein anderer Hersteller den IOW nutzt (das kann und will ich nicht ausschließen) kommt es zwangsläufig zum Konflikt. Dann gewinnt immer die 1. Anwendung, und die danach startenden bekommen nichts.

Da hilft mir keine 3. Lösung, wie ein vorgeschalteter Dienst der übersetzt - es sei denn jeder nutzt ihn. Ansonsten muß ich darauf hoffen, dass der andere direkt über die HID-Funktionen geht. Wie sich das dann untereinander verhält müsste aber auch geklärt werden.

Ich bin nicht ohne Grund noch immer auf VB6 (obwohl ich auch VS 2008 Std. besitze...). Ich liebe einfache Anwendungen die ohne Installation und damit ohne "Nebenwirkungen" laufen. Dazu habe ich eine Anwendung die mir meine Exe und sämtliche DLL´s / OCX´en in eine einzelne Exe packt. Da bei meinen Kunden oftmals sehr spezielle Anwendungen laufen die nicht unbedingt mit einem Update einer Systemdatei zurechtkommen (habe ich einmal mit einer Verblisterungsmaschine erlebt grrr.) habe ich mich für diesen "altmodischen" Weg entschieden, weil der mir nie Stress bereitet hat. Wenn ich nun aber mit der Hardware so umgehe, dann erschaffe ich ganz neue Hürden, die ich im Vorwege nicht abschätzen kann.

Also muß der Weg sein:
Anwendung startet ->
IOW´s durchlaufen -> EEProm suchen ->
EEProm da -> EEProm auslesen -> Zeichenfolge richtig -> Handle merken und die verbleibenden schließen
-> Zeichenfolge falsch -> Handle schließen und zum nächsten IOW
EEProm nicht da -> Handle schließen und zum nächsten IOW

Damit bin ich mir sicher das ich den richtigen IOW am Haken habe und alle anderen wieder freigegeben sind. Wenigstens war das der Plan, und da ich den Punkt in der PDF überlesen habe und stumpf nach dem Funktionsaufruf gegangen bin (der ja ein IOWHandle erwartet) stehe ich nun natürlich vor der Wand...

Gruß

[Christoph Jung]

So jetzt ist ein wenig Licht ins Dunkel was genau passieren soll. Das Problem ist, dass nicht beide Programms zur selben Zeit laufen können, aber das sollte ja mittlerweile klar sein. Wenn das aber nie der Fall ist, dass beie Programme zur selben zeit laufen, dann sollte es zumindest gehen, was das "Durchsuchen" der angeschlossenen IO-Warrior angeht.

Dafür einfach die IowKitGetDeviceHandle()-Funktion richtig nutzen:

Code: Select all

IOWKIT_HANDLE ioHandles[IOWKIT_MAX_DEVICES];
ULONG numDevs, i;
ioHandles[0] = IowKitOpenDevice();
if (ioHandles[0] != NULL)
{
// ... success, count devices
numDevs = IowKitGetNumDevs();
// get all IO-Warriors
for(i = 2; i <= numDevs; i++)
ioHandles[i-1] = IowKitGetDeviceHandle(i); //<-- Jeder gefundene IO-Warrior bekommt ein EIGENES Handle

//Hier die Überprüfung nach den EEPROMS oder alles andere was dann geschehen soll

// KEIN IowKitOnCloseDevice() aufrufen, sondern das gefundene Handle nutzen und die anderen einfach ignorieren oder auf "NULL" setzten um sicherzugehen


}
//Programmablauf mit dem Speziellen Handle
//IowKitCloseDevice nur aufrufen, wenn das Programm geschlossen/beendet wird !

Anonsten belibt nur noch das Komplette Konzept des Programms umzustellen, denn wenn beide Programme das selbe tun und sich 1:1 gleichen, dann macht das evtl. mehr sinn. Dafür gibt es ein schönes Beispiel von friend-of-rq mit namen "All in One" wo man das Prinzip sieht. Was mit dem 1.4 SDK ist muss ich erst abklären und ein Update der 1.5 DLL muss ich mich erst einarbeiten und das dauert ohne Doku ein wenig.

[Matthias]

"Wenn das aber nie der Fall ist, dass beie Programme zur selben zeit laufen"
öhm. Hab ich das irgendwo so geschrieben? Ne, ne. Die laufen schon gleichzeitig - also nebeneinander... Beide haben nur einen eigenen IOW, weil sie etwas anderes tun.
Und das durchsuchen klappt mit meiner, im Eingangsposting gezeigten, Funktion ja auch.

"denn wenn beide Programme das selbe tun und sich 1:1 gleichen"
Naja, 1:1 gleichen tun sie sich in soweit, das beide einen IOW nutzen. Dann ist es aber auch schon vorbei mit der Gleichheit.

Das "All in One"-Tool kenne ich. Ist super :-)

"Was mit dem 1.4 SDK ist muss ich erst abklären"
das ist nett...

"und ein Update der 1.5 DLL muss ich mich erst einarbeiten und das dauert ohne Doku ein wenig"
...aber das wäre der Hammer :-)))

Gruß
Matthias

[Guido Körber]

Die V1.4 DLL hat keinerlei Mechanismen um mehrere Applikationen gegeneinander abzuschotten, da können sogar zwei Programme auf den gleichen IO-Warrior zugreifen. Das Problem ist, dass mehrere Instanzen einer DLL nichts voneinander wissen, also keine Daten miteinander teilen.

Aber das beschriebene Problem, dass ein zweites, unbekanntes Programm auf einen IO-Warrior zugreifen will, wird sich auch mit einer neuen DLL nicht ausräumen lassen. Das andere Programm kann über HID gehen und damit an der DLL vorbei, wodurch es dann ggf. beliebig viel Chaos anrichten kann.

Die Verwendung der V1.4 DLL würde an der Stelle auch nicht helfen, da das die 1.5 DLL ausschließen würde, auf die sich die meisten Anwendungen verlassen.

Ich würde vorschlagen das Problem, da es ein nur mögliches, zukünftiges ist, in die Zukunft zu verschieben. Die IO-Warrior erfreuen sich zwar großer Beliebtheit, aber gar so viele sind dann doch noch nicht im Umlauf, dass die Gefahr so groß wäre mehrere in verschiedenen Anwendungen von verschiedenen Herstellern an einem Rechner zu finden.

[Matthias]

"Die V1.4 DLL hat keinerlei Mechanismen um mehrere Applikationen gegeneinander abzuschotten, da können sogar zwei Programme auf den gleichen IO-Warrior zugreifen"
Das Problem kann (bzw. muss) ich vernachlässigen. Da muss dann halt eine anständige Fehlerkorrektur rein. Ein Versuch wäre es auf jeden Fall wert - denke ich.
"Aber das beschriebene Problem, dass ein zweites, unbekanntes Programm auf einen IO-Warrior zugreifen will, wird sich auch mit einer neuen DLL nicht ausräumen lassen. Das andere Programm kann über HID gehen und damit an der DLL vorbei, wodurch es dann ggf. beliebig viel Chaos anrichten kann."
Das Problem kann ich nicht ausräumen, da kommt dann die Fehlerkorrektur wieder zum tragen.
"Die Verwendung der V1.4 DLL würde an der Stelle auch nicht helfen, da das die 1.5 DLL ausschließen würde, auf die sich die meisten Anwendungen verlassen."
Warum? Die 1.4 und 1.5 dürften doch eigentlich nebeneinander funktionieren. Ich kopiere ja nichts in die Systemordner. Und da Windows nach der DLL in der Reihenfolge
- Verzeichnis, in dem sich das ausführbare Modul des aktuellen Prozesses befindet
- aktuelles Verzeichnis
- Windows-Verzeichnis / System
- Path-Angaben in den Umgebungsvariablen
sollte es da kein Problem geben.

" da es ein nur mögliches, zukünftiges ist, in die Zukunft zu verschieben"
Schon, aber dann fasse ich es jetzt an und muss es "halbfertig" zurücklassen um zu einem unbestimmt späteren Zeitpunkt erneut auf das Problem zurückzukommen.

"Die IO-Warrior erfreuen sich zwar großer Beliebtheit, aber gar so viele sind dann doch noch nicht im Umlauf, dass die Gefahr so groß wäre mehrere in verschiedenen Anwendungen von verschiedenen Herstellern an einem Rechner zu finden."
Aber gerade in kleineren, sehr speziellen Lösungen könnte es vorkommen. Die Gefahr ist zu groß. Wenn ich daran denke dass ich vor 4 Wochen noch nicht einmal annähernd etwas von Elektronik wusste, und jetzt meine erste Platine in der Fertigung ist - denn kann das wirklich jeder, der nicht gerade 2 linke Hände mit jeweils 5 Daumen hat...

Gruß
Matthias