Mehrere angeschlossene IOW´s, nur einen nutzen

[Guido Körber]

Die Verwendung veralteter, nicht mehr gewarteter Software ist mit Sicherheit kein Ansatz um einen zuverlässigeren Betrieb zu gewährleisten. Was bei dem Versuch zwei Versionen der DLL parallel zu betreiben herauskommt weiss ich nicht, da weiss ich nur was unsere Antwort auf eine entsprechende Supportanfrage sein wird: Aktuelle DLL verwenden.

Wenn Sie eine sichere Abschottung haben wollen gibt es nur den Weg ausreichend viele Chips zu bestellen und die mit einer eigenen ProductID, dann können Sie die DLL so modifizieren, dass sie nur Ihre eigenen IO-Warrior bedient.

[Matthias]

"Die Verwendung veralteter, nicht mehr gewarteter Software ist mit Sicherheit kein Ansatz um einen zuverlässigeren Betrieb zu gewährleisten."
Da haben sie meine volle Zustimmung. Wenn aber die aktuelle Software mit einer Einschränkung aufwartet, die den zuverlässigen Betrieb ebenso nicht gewährleistet, macht es für mich an dem Punkt keinen Sinn die aktuellste Version zu verwenden. Ganz im Gegenteil. Es macht für mich ja z.B. keinen Sinn einen 56er IOW zu unterstützen, wenn ich definitiv keinen einsetzen werde.

"Was bei dem Versuch zwei Versionen der DLL parallel zu betreiben herauskommt weiss ich nicht"
Wenn ich eine hätte würde ich´s testen...

"Wenn Sie eine sichere Abschottung haben wollen gibt es nur den Weg ausreichend viele Chips zu bestellen und die mit einer eigenen ProductID, dann können Sie die DLL so modifizieren, dass sie nur Ihre eigenen IO-Warrior bedient."
Dabei würden zwangsläufig auch unterschiedliche DLL´s auf dem System sein, und ich wäre wieder in meinem C-Dilemma. Davon mal ab, welche Menge ist "ausreichend"?

Gruß
Matthias

[Christoph Jung]

Die DLL ist Open-Source, also kann man selber probieren. Allerdings wird das wie Herr Körber schon schrieb wird das nicht von uns supportet und alles was dann schief geht geht auf eigenes Risiko. Was man in der DLL ändern muss ist in der iowkit.c zu finden. Dort die Strings umbennenen (einfach eine zahl anhängen) und die daraus entstehende DLL eigenständig nutzen. Das für jedes Programm einzeln. Aber wie gesagt das ist nur eine Theorie und komplett ungetestet was die Folgen für das System und die IO-Warrior angeht. Darum müssten Sie das selber machen.

Ansonsten bleiben nur die vorher beschriebenen Wege mit der Neuen Anwendung, die beides in einem vereint oder die Nutzung des Socket-Tools von friend-of-rq.

[Guido Körber]

Zwei DLLs die sich unterschiedlich identifizieren und bei den unterstützen IO-Warriors sich nicht überlappen sind unproblematisch.

Custom Chips machen wir unter der Voraussetzung, dass pro Bestellung mindestens 100 Stück, bzw. die nächste komplette Verpackungseinheit abgenommen wird. Das wären bei IOW40-S 120 Stück, bei IOW24-S 124 Stück, also abhängig von der Stangengröße. Bestellung bezieht sich dabei auf eine Lieferung, die Menge kann nicht auf mehrere Abrufe aufgeteilt werden. Einmalig sind 100 Euro für die Initialisierung der Customversion fällig.

[friend-of-rq]

Hallo zusammen,

ich habe folgendes Problem bei mir feststellen können wenn mehrere Programme mit IOWs arbeiten,

z.B. mehrere Programmen öfnnen die DLL und arbeiten mit jeweils verschiedenen IOWs, das geht auch so weit ganz gut,
nur wenn ein Programm beendet wird und dabei auch die DLL schliesst, dann geht nichts mehr ...

ich muss dazu sagen ich verwende wie Matthias eine im Programmpfad abgelegte IOWKIT-DLL,
also hat jedes Programm seine eigene ... vieleicht liegt es daran ?

mir ist noch nicht ganz klar, warum Matthias ein EEPROM zum identifizieren nimmt, TYPE und SN sind doch eindeutig aus
der DLL auszulesen um dann die Handle-Nummer des ausgesuchtem IOW der Anwendung zuzordnen.

Dabei wäre es sehr Hilfreich wenn die SN auf dem Aufkleber vom IOW mit aufgedruckt würde,
so muss man nicht immer erst mit einer Software z.B. ALL-IN-ONE die jeweilige SN auslesen und zuordnen.

[Christoph Jung]

Warum es mit der 1.5 DLL nicht läuft liegt daran, dass die DLL sich Speicher vom System holt und sich im gleichen zug nur dem einen Programm zuwendet. Wer zuerst kommt malt zuerst in diesem Fall. Auch wenn man in jeden Programmpfad die DLL reinmacht wird das Ergebnis das selbe sein.
Die Speicherpfade werden durch Mutexe geschützt die einen eindeutigen Namen benötigen. Wenn der Name schonmal vergeben wurde ist also Schicht im Schacht.

Bei der 1.4 ist das alles noch nicht implementiert und somit wir der Speicher auch nicht geschützt. Daher bewirkt ein einziger IowKitCloseDevice() das alle devices geschlossen werden, da sie allem im selben Speicher liegen und somit alle weg sind.
Daher wurde das in der 1.5 komplett geändert um solche Fehler zu verhindern. Mehrere IO-Warrior mit mehreren Programmen laufen zu lassen ist darum so "unsicher" weil man nie weiß was macht das Programm mit den Daten, funkt jemand dazwischen. Wenn man z.B. die HID-API direkt verwendet umgeht man sowas, kann aber auch viel kaputt machen, so dass Daten nicht mehr stimmen oder beim IO-Warrior (oder anderen USB-Geräten) nicht mehr ankommen und so Messungen verfälscht werden oder Schlimmers.

[Matthias]

"mehrere Programmen öfnnen die DLL und arbeiten mit jeweils verschiedenen IOWs, das geht auch so weit ganz gut"
wie jetzt - wie geht das? genau da liegt doch mein problem! Wie machst du das.
Wenn ich Anwendung A aufrufe kann ich mit IOW A reden. Starte ich dann Anwendung B um mit IOW B zu verbinden bekomme ich keine IOW´s mehr angezeigt.
Das klappt bei mir nur, wenn der eine IOW nicht angeschlossen ist während die andere Anwendung startet.

" eine im Programmpfad abgelegte IOWKIT-DLL"
das ist für Windows absolut ok.

"mir ist noch nicht ganz klar, warum Matthias ein EEPROM zum identifizieren nimmt, TYPE und SN sind doch eindeutig aus
der DLL auszulesen um dann die Handle-Nummer des ausgesuchtem IOW der Anwendung zuzordnen.
Dabei wäre es sehr Hilfreich wenn die SN auf dem Aufkleber vom IOW mit aufgedruckt würde,
so muss man nicht immer erst mit einer Software z.B. ALL-IN-ONE die jeweilige SN auslesen und zuordnen."
Bei den Preisen für die kleinen EEProms mache ich mir keine Arbeit mit der Pflege von Listen mit Seriennummern.

Gruß
Matthias

[Mike D]

Mal einen gewagten, ungetesteten Einwurf:
Was, wenn jedes Programm seine eigene, umbenante DLL nutzt?

Mike

[Christoph Jung]

Das ist das selbe, als wenn man die DLLs in einen seperaten Ordner packt. Der Inhalt, also der Code bleibt der selbe.

[Matthias]

Wo ich das gerade lese...
"Bei der 1.4 ist das alles noch nicht implementiert und somit wir der Speicher auch nicht geschützt. Daher bewirkt ein einziger IowKitCloseDevice() das alle devices geschlossen werden, da sie allem im selben Speicher liegen und somit alle weg sind.
Daher wurde das in der 1.5 komplett geändert um solche Fehler zu verhindern"
Wie jetzt, genau das macht die 1.5er doch. Einmal close, alles dicht. Oder verstehe ich den Post falsch?

[Christoph Jung]

Ja ist ein wenig blöd ausgedrückt. Fakt ist, dass IowKitCloseDevice ALLE Handles des IO-Warrior schließt egal ob nun 1.4 und 1.5.
1.5 Managed alles mit Globalem Speicher. Daher ist ein erneutes Öffnen, bzw. schließen aus einem anderen Programm nicht mehr möglich.
Also Programm 1 läuft und hat die Macht an sich gerissen. Programm 2 hat somit keine Befugnisse irgendwas zu machen. Weder Connect noch Close.

[Guido Körber]

Bei der 1.4 ist das Problem, dass Programm 1 dem Programm 2 die DLL mit zumacht wenn es einen iowKitClose aufruft.

[Matthias]

Ok, ein verbinden ist also weiterhin möglich. Ich verstehe. Aber mal ne ganz dumme Frage - warum erwartet IowKitCloseDevice überhaupt ein IOWHandle. War es denn irgendwann mal möglich ein einzelnes Gerät zu schließen? Sonst wäre hier ein IowKitCloseDevices() doch irgendwie sinnvoller gewesen.

@Ralf Greinert
Benutzen sie die 1.4er DLL?

Wenn ja, kann ich das SDK noch irgendwo herbekommen?

Gruß

[Guido Körber]

Die IOWkit DLL ist ursprünglich mal für einen einzelnen IO-Warrior vorgesehen gewesen und war als Samplecode gedacht, nicht als fest einbetonierte Instanz. In der Praxis hat sich dann allerdings ergeben, dass fast niemand auch nur das kleinste Detail an der DLL geändert hat, sondern sie so benutzt wie sie von uns geliefert wird.

Dadurch gibt es in der DLL einige Erblasten. Das handle gehört mit dazu. Ich bin mir nicht mal sicher, ob das intern wirklich noch benötigt wird.

[Christoph Jung]

Es ist doch jetzt egal ob es das irgendwann mal konnte oder welche Beweggründe dahinterstecken. Und nein Sie können nicht mit einem zweiten Programm auf den schon genutzen oder irgend einen anderen IO-Warrior zugreifen. Die 1.5 mach alles dicht und lässt keine Kommunkation von anderen Programmen auf sich zu, solange sie an das andere gebunden ist.