IowRead() - Statusänderung verdoppelt sich

methusalem · Post by **methusalem** » Sun Jan 22, 2006 11:39 pm

Moin,

mir ist kein bessere Betreff eingefallen :-(

Ich habe folgende Methode, die einzig und allein den Port0.0 in einer Endlosschleife zu Testzwecken überwacht. Ich nutze dazu das blokierende Read aus der dll.

Code: Select all

void Modultest::on_resetButton_clicked(){
	IOWKIT40_IO_REPORT rep;
	ULONG res;
	IOWarrior iow;
	iow.Open();

	while(1){
		res = iow.Read((PCHAR) &rep);
		fprintf(stderr,"%02x %02x %02x %02x  ", rep.Bytes[0], rep.Bytes[1], rep.Bytes[2], rep.Bytes[3]);
		if(rep.Value & (1<<0)){
			fprintf(stderr,"Port0.0 = 1\n");
		}else{
			fprintf(stderr,"Port0.0 = 0\n");
		}
	}

Hier der Code der die iowkit.h kapselt:

Code: Select all

Header:
	ULONG Read(PCHAR rep, ULONG numPipe=IOW_PIPE_IO_PINS, ULONG length=IOWKIT40_IO_REPORT_SIZE, int=0);

Source:
ULONG IOWarrior::Read(PCHAR rep, ULONG numPipe, ULONG length, int number){
	return IowKitRead(iow[number].devHandle, numPipe, rep, length); 
}

iow[number].devHandle enthält hier das Handle des USB Moduls mit der Nummer 0

Das funktioniert alles wunderbar ... aber ich bekomme folgende Ausgabe:

Code: Select all

fe ff ff ff  Port0.0 = 0
fe ff ff ff  Port0.0 = 0
ff ff ff ff  Port0.0 = 1
ff ff ff ff  Port0.0 = 1
fe ff ff ff  Port0.0 = 0
fe ff ff ff  Port0.0 = 0
ff ff ff ff  Port0.0 = 1
ff ff ff ff  Port0.0 = 1

Wie kann das sein? Jede Portänderung wird zweimal angezeigt! Das kann doch beim blockierenden lesen eigentlich garnicht sein. Als erstes hab ich an einen prellenden Schalter gedacht. Aber da müsste ja dann auch das prellen (Portänderung) an der Ausgabe zu sehen sein.

Hat jemand ne Vermutung, woran das liegen könnte? Oder sehe ich mal wieder den Wald vor lauter Bäumen nicht.

Guido Körber · Post by **Guido Körber** » Mon Jan 23, 2006 12:32 am

Nö, das Prellen muss nicht so offensichtlich zu sehen sein.

Da sich Kontaktprellen im Bereich weniger Millisekunden bewegt schafft es der IO-Warrior nicht unbedingt den jeweils neuen Zustand zu übertragen, bevor der sich möglicherweise schon wieder geändert hat. Dann wird der zuletzt festgestellte Zustand übertragen.

Tatsächlich ist es sogar so, das durch die Übertragung alle 8msec ziemlich sicher der zweite Report bereits den statischen Zustand enthält. Die meisten Kontakte haben sich nach 3-4 msec beruhigt.

methusalem · Post by **methusalem** » Mon Jan 23, 2006 8:33 am

Guido Körber wrote:Nö, das Prellen muss nicht so offensichtlich zu sehen sein.

Da sich Kontaktprellen im Bereich weniger Millisekunden bewegt schafft es der IO-Warrior nicht unbedingt den jeweils neuen Zustand zu übertragen, bevor der sich möglicherweise schon wieder geändert hat. Dann wird der zuletzt festgestellte Zustand übertragen.

Tatsächlich ist es sogar so, das durch die Übertragung alle 8msec ziemlich sicher der zweite Report bereits den statischen Zustand enthält. Die meisten Kontakte haben sich nach 3-4 msec beruhigt.

OK, ich dachte ja auch erst an prellen! Was mich aber nun iritiert, ist die Tatsache, das diese doppelung sehr konstant ist. Also immer zwei mal die gleiche Meldung! Prellen Schalter immer so konstant? Das ganze tritt auch unabhängig vom Schalter auf. Ich werde heute mal versuchen einen entprellten Schalter zu bekommen.

Deine Aussage nach, siehst du keinen offensichtlichen Fehler in meinem Code?

wayoda · Post by **wayoda** » Mon Jan 23, 2006 9:40 am

Ist für die read-Funktion vielleicht ein Timeout gesetzt?
Wie ist der Rückgabewert von read?

Eberhard

methusalem · Post by **methusalem** » Mon Jan 23, 2006 10:02 am

wayoda wrote:Ist für die read-Funktion vielleicht ein Timeout gesetzt?
Wie ist der Rückgabewert von read?

Also ich habe keinen Timeout geschrieben. Der steht also auf dem Standardwert.

Den Rückgabewert habe ich hier noch garnicht ausgewertet. Mal sehen, ob ich heute noch dazu komme, dann baue ich das ein.

Was mir aber noch eingefallen ist: Ich hatte gestern noch ein Sleep(25) in die Endlosschleife eingebaut. Und wenn ich mich richtig entsinne, blieb es bei dem Ergebnis. Das würde aber das prellen nicht ausschließen, oder?
Wenn ich das richtig verstanden habe, liest auch IowKitRead() aus dem Report Stapel der DLL. Wenn der Schalter also prellt, dann landen die Reports dazu im Stapel und IowKitRead() liest die von da, trotz Sleep(). Ist das richtig so?

Guido Körber · Post by **Guido Körber** » Mon Jan 23, 2006 10:06 am

Also bitte noch mal meine Antwort durchlesen. Es ist das Kontaktprellen und es ist genau das Verhalten was zu erwarten ist.

methusalem · Post by **methusalem** » Mon Jan 23, 2006 10:24 am

Guido Körber wrote:Also bitte noch mal meine Antwort durchlesen. Es ist das Kontaktprellen und es ist genau das Verhalten was zu erwarten ist.

Ich habe dir doch mit keinem Wort wiedersprochen! Eher im Gegenteil, ich versuche das prellen zu bestätigen und zu verstehen ... was mir nämlich am liebsten wäre!

Guido Körber · Post by **Guido Körber** » Mon Jan 23, 2006 10:26 am

Ganz einfach: Kontakt schliesst nach 0V, IO-Warrior erzeugt daraufhin einen neuen Report. Kontakt öffnet durch Prellen nochmal, IO-Warrior erzeugt einen weiteren Report, der aber nicht sofort gesendet werden kann. Kontakt schliesst wieder, IO-Warrior erzeugt einen weiteren Report und überschreibt den noch wartenden.

methusalem · Post by **methusalem** » Mon Jan 23, 2006 11:02 am

Guido Körber wrote:Ganz einfach: Kontakt schliesst nach 0V, IO-Warrior erzeugt daraufhin einen neuen Report. Kontakt öffnet durch Prellen nochmal, IO-Warrior erzeugt einen weiteren Report, der aber nicht sofort gesendet werden kann. Kontakt schliesst wieder, IO-Warrior erzeugt einen weiteren Report und überschreibt den noch wartenden.

Prima! Danke für die Erklärung. So in der Art hatte ich mir das auch schon gedacht.

Frage eines E-techniklaien: Können Lichtschranken auch prellen? Ich vermute ja, bin mir aber nicht sicher.

Guido Körber · Post by **Guido Körber** » Mon Jan 23, 2006 12:01 pm

Nur wenn der Lichtstrahl irgendwie instabil ist, also flackernde Lampe oder zitternde Blende.

wayoda · Post by **wayoda** » Mon Jan 23, 2006 2:24 pm

Ich bin jetzt auch überzeugt vom Kontaktprellen, aber habe mich einfach gewundert warum ich dieses Verhalten nie beobachtet hatte, obwohl ich Taster der billigsten Machart verwendet habe ?

Lösung:
Ich verwendet Linux und da wird bei zwei aufeinanderfolgende Reports von den IO-Pins mit den gleichen Zuständen der letzte Report verworfen.
Die Verdopplung der Zustände findet also unter Linux nicht statt, bzw sie ist nicht sichtbar für den Anwender.

Die nächste Frage wäre also: Bug or Feature ?
Eberhard

methusalem · Post by **methusalem** » Mon Jan 23, 2006 2:29 pm

wayoda wrote:...
Die nächste Frage wäre also: Bug or Feature ?
Eberhard

Für mich ist es an dieser Stelle ein Bug, da ich dies nun für Windows von Hand überprüfen muss.

Für mich die nächste Frage: Wo unterscheiden sich die Bibliotheken für Windows & Linux noch? Unter Linux gibts wohl einen Stapel mit max. 16 Reports und unter Windows nur 8. Das ist im Moment aber noch nicht so schlimm für mich.

Das obige Verhalten ist für mich aber schon relevant, da ich mit den QT Bibliotheken eine platformunabhängige Applikation schreibe!

Gibts noch mehr Unterschiede? Steht das in der Doku? Ich hab nix gefunden!

Robert Marquardt · Post by **Robert Marquardt** » Mon Jan 23, 2006 2:43 pm

wayoda wrote: Ich verwendet Linux und da wird bei zwei aufeinanderfolgende Reports von den IO-Pins mit den gleichen Zuständen der letzte Report verworfen.

Wenn das in Treiber oder Lib steckt dann ist das eher Bug.

wayoda · Post by **wayoda** » Mon Jan 23, 2006 2:47 pm

Robert Marquardt wrote: Wenn das in Treiber oder Lib steckt dann ist das eher Bug.

Linux-Bug oder Windows-Bug ???

methusalem wrote: Das obige Verhalten ist für mich aber schon relevant, da ich mit den QT Bibliotheken eine platformunabhängige Applikation schreibe!

Gibts noch mehr Unterschiede? Steht das in der Doku? Ich hab nix gefunden!

Steht nicht alles in der Doku, ich werde die mir bekannten Unterschiede als neues Topic posten, dauert aber etwas.

Eberhard

Robert Marquardt · Post by **Robert Marquardt** » Mon Jan 23, 2006 2:51 pm

Wenn Linux-Treiber oder Linux-Lib bei gleichen Reports einen verwirft, dann ist das ein Bug.