Stack des Warrios leeren?

[MichaelV]

Ihre Fragen,

>Wozu ein Pullup? Der IO-Warrior hat eigene intern.
kann ich nicht sagen, ich habe beide so bekommen, einer ist nackt, einer hat widerstände (an port 0.0..0.7 ) nach Warrior 5V
Beide zucken an 0.0. Der Eine war schon mal kurzzeitig verbaut.

>Ist das irgend was an Kabel an dem IO-Warrior?
An den Ports 0.1..0.7 kurze kabel 5cm, an 0.0 ist nichts dran

>Wo hängt der Pullup dran? An der USB Versorgung?
am Warrior 5V .

>Ist ein Hub zwischen Rechner und IO-Warrior?
nein direkt, c.a. 1.5m usb kabel

>Ist die USB Versorgungsspannung in Ordnung? Da haben wir schon "interessante" Sachen erlebt, z.B. 3,5V statt 5V.
kann ich nicht sagen, werde morgen mal messen, ich gehe aber davon aus.

Ich werden mal ein kurzes usb kabel testen.

Michael

[Christoph Jung]

So ich habe jetzt mal gut eine Stunde das Programm laufen lassen.



Und keine Probleme.
Ich häng an dem USB direkt vom PC (ohne externem Hub) mit einem 30cm USB kabel.

[MichaelV]

Hallo,
ich habe den einen warrior mit nach hause genommen. Ein hochwertiges USB Kabel genommen und alle 5cm Kabel abgelötet. Die USB - Spannung gemessen, ist ca. 5.1V.
Es kommen keine Signale auf Port 0.0 wenn die Platine da liegt. Nehme ich die Platine in die Hand und schwenke Sie zB. vor meiner Schreibtischlampe (mit getakteter Energiesparlampe), kommen Signale auf 0.0. (und nur auf diesem Port)
Hier ist mMn. etwas sehr empfindlich.

Kann das was mit einer Masse zu tun haben?
Sollten wir die Warrior abschirmen?
Ich werde versuchen Port 0.0 erstmal nicht zu benutzen.

Ich danke erstmal
Michael

[Guido Körber]

OK, jetzt ist bei mir der Groschen gefallen was da schief geht :)

Ich gehe mal davon aus, dass auf dem Starterkit alle Bauteile drauf sind? Und alle drei Jumper sind aufgesteckt?

Dann ist auch der IR Empfänger an P0.0 angeschlossen und der reagiert auf Licht, eigentlich nur auf die richtige Modulationsfrequenz, aber schnelle Lichtwechsel, oder eine Energiesparlampe erzeugen halt auch Impulse.

[MichaelV]

Ha,
es ist alles bestückt, auch die jumper sind drauf. So kanns gehen. Ganzen Tag rumsuchen und dann sowas. Das Vertrauen in die Technik kehrt langsam zurück.

Michael

[Guido Körber]

Da nichts mehr kam nehme ich mal an, dass das Ziehen des Jumpers das Problem behoben hat?

[MichaelV]

Ja, die Störungen sind verschwunden!

[MichaelV]

Wie gesagt die Sörungen treten nicht mehr auf, allerdings hängt sich nach Aussage des Auftraggebers die Steuerung in IowKitReadNonBlocking immer mal auf.

Der Aufbau ist wie gesagt folgender:
-zwei Warrior 24 an einem Rechner
-Eine Applikation mit 3 Threads,
1. Mainthread der Applikation
2. Zwei Threads die die Daten vom Warrior abholen (und so ggf. gleichzeitig auf iowkit.dll zugreifen) und die Ergebnisse an den Mainthread liefern.

Kann es sein, dass die DLL nicht so richtig threadfest ist?
Gruss Michael Vanderheyden

[Christoph Jung]

Die Fehleraussage ist leider nicht wirklich hilfreich.

Welche DLL wird denn genutzt, die 1.4 oder 1.5 ?
Bisher ist uns solch ein Fall nicht bekannt dass die DLL (1.5 Version) Probleme mit Threads hat.

[stakler]

Ich bin über Google auf diese Diskussion aufmerksam geworden als ich ein ähnliches Problem hatte wie eingangs beschrieben. Der Threadverlauf erwies sich als äußerst nützlich. Vielen Dank dafür!

[MichaelV]

Hallo,

Ich beschreibe es nochmal, es gibt an einem Rechner zwei Warrior.
Es gibt einen Mainthread (die Applikation ansich)
und 2 identische Threads, die die Warrior bedienen. Diese Threads lesen die Ports und zwar alle ca. 10ms. Hierzu benutzen sie
am Ende diese Funktion:

const ULONG rc = IowKitReadNonBlocking(a_iowHandle, IOW_PIPE_IO_PINS, (PCHAR) &rep24, IOWKIT24_IO_REPORT_SIZE);

In dieser Funktion, die vom jeweiligen Thread aufgerufen wird, bleibt es stehen.
Es kann also durchaus vorkommen, dass IowKitReadNonBlocking mit dem Warriorhandle des einen Threads und gleichzeitig
IowKitReadNonBlocking mit dem anderen Warriorhandle aufgerufen wird.
Globale Daten oder sowas innerhalb von IowKitReadNonBlocking sicher "toedlich".

Wir verwenden die Version 1.5.

Ich habe keine Idee, es tritt halt nicht immer auf, ich kann es nicht definiert reproduzieren.

Gruss Michael Vanderheyden

[Christoph Jung]

Am besten verhindern, dass beide Thread gleichzeitig auf die Lesefunktion zugreifen um erstmal auszuschließen, dass der Fehler daher rührt.
Vorausgesetzt der Fehler rührt daher. Aber da sich das nicht direkt reproduzieren lässt ist es schwer einzuschätzen.

Evtl. eine boolsche variable erstellen auf die beide Threads zugreifen können und sich so gegenseitig aussperren können. So könnte man theoretisch ein gleichzeitige Zugriff auf ReadNonBlocking() vermeiden.

[MichaelV]

Hallo,

Das der Fehler daher rührt kann ich nicht mit Bestimmtheit sagen, möglich wäre ja z.B. auch, dass der Warrior aus irgendeinem Grund seine USB Verbindung verliert.

Michael

[friend-of-rq]

Hallo zusammen,

ich verwende die IO-Warrior mit dem IOW-Socketserver (IOWSS) in meiner Haussteuerung,

ich kann nur sagen die DLL läuft über Monate stabil ...

habe gerade mal nach gesehen 898383 IOW-Zugriffe in 1835450 Sekunden (~21 Tage) ...

Das Problem was Du hast, mehrere Thread lesen den Stack, welche Daten gehören zu welchen Thread,
Du musst in deiner Anwendung ein Thread verwenden welches ausschließlich mit dem IOW kommuniziert, die anderen Thread müssen dann über dieses mit den IOWs arbeiten.

Ich habe genau für diesen Fall: mehrere Programme oder auch Thread die auf einen oder mehrere IOWs zugreifen wollen,
den IOW-Socket-Server geschrieben ...

@ MichaelV anschauen und testen kostet nichts :-)

Ablauf_2.jpg (44.71 KiB) Viewed 9456 times

Im IOWSS gibt es dafür die Möglichkeit TAGs mitzugeben oder man schaltet einfach die Funktion IOW-PIN-ON

Code: Select all

10	IOWarrior bezogene Kommandos Port-IN (PIN)

10.1	IOW-PIN-ON  [IOW-ID]
Beispiel: IOW-PIN-ON 1
IOWPINON{}=ACK				

10.2	IOW-PIN-OFF  [IOW-ID]
Beispiel: IOW-PIN-OFF 1
IOWPINOFF{}=ACK

10.3	IOW-GET-PIN-STYLE  [IOW-ID]
Beispiel: IOW-GET-PIN-STYLE 1
IOWGETPINSTYLE{}=0

10.4	IOW-SET-PIN-STYLE  [IOW-ID] [STYLE] 					[saveUser]
Beispiel: IOW-SET-PIN-STYLE 1
IOWSETPINSTYLE{}=ACK
IOWSETPINSTYLE{}=150 Expect value(2) PIN-Output Style (0-1)

Alle Clients die diese Funktion aktiviert haben, bekommen bei jedem Event 
(Änderungen an den Ports) automatisch eine Nachricht vom Server.

STYLE=0 (dezimal)
PIN=1 255 255 255 255 ... 255
    | |   |   |   |       |
    | |   |   |   |        -- Port(6) IOW56
    | |   |   |   |                   ...
    | |   |   |    -- Port(3) IOW40   IOW56
    | |   |    ------ Port(2) IOW40   IOW56
    | |    -- Port(1) IOW24   IOW40   IOW56
    |  ------ Port(0) IOW24   IOW40   IOW56
     -- IOW-ID

STYLE=1 (Hex)
PIN=1 FFFFFFFF...FF
    | | | | |    |
    | | | | |     --------- Port(6) IOW56
    | | | | |                       ...
    | | | |  ------ Port(3) IOW40   IOW56
    | | |  -------- Port(2) IOW40   IOW56
    | |  -- Port(1) IOW24   IOW40   IOW56
    |  ---- Port(0) IOW24   IOW40   IOW56
     -- IOW-ID

Gruss Ralf

[MichaelV]

Hallo zusammen,

danke fuer die Anregungen Ralf.
Das Problem ist ein bischen, dass wir unser Budget fuer den Auftrag schon lange aufgebraucht haben. Und der Auftraggeber auch nicht sehr erfreut ist.

Das Programm, was den Messablauf loggt, liest in den Zwei Threads auch noch je ein PAX Processmeter aus.
Der Status wird erfasst und an den Hauptthread übertragen um angezeigt und in einer Datenbank geloggt zu werden.
Die Paxe haengen auch an USB Ports wie die Warrior (also insgesamt 4 Geraete)
Nehme ich den Aufruf zum Lesen vom Warrior (ReadNonBLocking) raus, läuft das Programm ohne Probleme.

Wenn jemand definiert betätigen kann, dass die DLL nicht threadfest ist, koennte ich die Aufrufe gegeneinander absichern.
Das habe ich noch nicht probiert.

>
ich verwende die IO-Warrior mit dem IOW-Socketserver (IOWSS) in meiner Haussteuerung,
ich kann nur sagen die DLL läuft über Monate stabil ...

Du hast nur einen Thread?

>
Das Problem was Du hast, mehrere Thread lesen den Stack, welche Daten gehören zu welchen Thread,
Du musst in deiner Anwendung ein Thread verwenden welches ausschließlich mit dem IOW kommuniziert, die anderen Thread müssen dann über dieses mit den IOWs arbeiten.

Das kann ich nicht nachvollziehen. Wenn jeder Warrior ein Handle hat (und das hat er ja) sollten die Daten des jeweiligen Warriors mit
diesem Handle als Schluessel gehalten werden. Und sollten sich somit nicht stören.

Ist die DLL nun Threadfest oder nicht?

Michael