Hallo zusamen,
ich habe mit ein Delphi 6 ein Programm geschrieben mit dem ich 16 Bits
als Eingang und 16 Bits als Ausgang steuern kann. Dazu verwende ich
die DLL da ich die Eingänge jederzeit "pollen" will. Da die Version mit
der "Komponente" blockiert, bis eine Änderung an den IO-Pins stattfindet
habe ich mich für die DLL entschieden.
Ich initalisiere zuerst den Port 0&1 als Eingang. und Port 2&3 aus Aus-
gang dh. Ich schreibe jeweils FF FF und 00 00 in den Port. (IoKitWrite)
Danach lese ich ich mit IowKitReadImmediate 32 Bit zurück um den
Zustand von zwei Pins auszulesen.
UND DAS GEHT NICHT AUF ANHIEB.
Schreibe ich irgendwas in den Port 2 oder 3 dann wird ab diesem Moment
auch Port 0&1 richtig rückgelesen. Das mache ich auch mit "IoKitWrite"
Der selbe Effekt passiert mit wenn ich das Demoprogramm
aus "USB Warrior SDK\Windows\Samples\Simple IO\Delphi\LEDs DLL"
verwende. Hier werden ja TImergestuert die Ports eingelesen. Aber erst
wenn ich auf eine LED klicke wird der Port richtig angezeigt.
Danke
ROBERT Hoffmann
IowKitReadImmediate geht nur nach einem write (Delphi)
Moderator: Guido Körber
-
robert.ferralux
- Posts: 8
- Joined: Wed Dec 06, 2006 4:36 pm
- Location: Lkrs. Augsburg
Hallo,
ich weiß auch nicht woran es liegt, aber würde empfehlen auf IowKitReadNonBlocking umzusteigen.
Begründung siehe hier
http://www.codemercs.de/phpBB2/viewtopic.php?t=832
Eberhard
ich weiß auch nicht woran es liegt, aber würde empfehlen auf IowKitReadNonBlocking umzusteigen.
Begründung siehe hier
http://www.codemercs.de/phpBB2/viewtopic.php?t=832
Eberhard
-
robert.ferralux
- Posts: 8
- Joined: Wed Dec 06, 2006 4:36 pm
- Location: Lkrs. Augsburg
Hallo,
danke erst mal für die Antwort.
(*) Unten findet ihr eine kurze Beschreibung meines Programmes!
Habe nun mitlerweile mein Projekt von der SDK-Version 1.4 auf die SDK
Version 1.5 umgestellt, wobei die DLL die Versionnummer 2.0.0.0 hat.
Jetzt habe ich auch IOWKitReadNonBlocking zur Verfügung.
Die IOWKitVersion ist 1.0.2.1 die Seriennummer des IOW40: $F3D
Aber leider funktioniert das auch noch nicht 100%. Im Gegensatz zu
"ReadImmediate" bleibt das Programm zwar nicht hängen, aber es wird
NICHT der MOMENTANE aktuelle Wert des Ports zurückgelesen.
Wenn ich nacheinander mit 8 Write-Befehlen auf dem Port 2 8 Bits
hintereinander setzte(ähnlich Lauflicht, Bit setzen/zum IOW senden und
dann wieder setzten/senden und wieder setzten/senden usw.), muß ich
auch auch 8x einen ReadNonBlocking machen, bis ich wieder $FF als Wert
des Portes zurückbekomme. Die Zwischenwerten die ich bekomme sind
$01,$03,$07,$0F usw.
Würde ich ReadImmediate verwenden, bekomme ich den aktuellen
Portinhalt ($FF) sofort zurück. Aber nach "n"-Zugriffen mit ReadImm.
bleibt mein Programm hängen.
Ich kann gerne den Source hier veröffentlichen oder "posten"
Gruß und schon mal danke an alle die mir helfen wollen.
ROBERT
(*) Ich arbeite an einem Prüfgerät zum Dauertesten von Relais. Bevor
ich den eigentlichen Prüfablauf programmiere möchte ich mir einen
"Debugger" für die PG-Hardware programmieren.
Dazu habe ich im Prinzip 4 Buttons und 32 LEDs und 16 Checkboxen
auf meiner Form.
Klicke ich auf den "Button 1 oder 2" sollen jeweils "8 LEDs" auf dem
Form den aktuellen Zustand des Ports 0 und 1 anzeigen.
14 Eingänge werden vom Prüfgerät verwendet und 2 Bit sind für den
Staus (Versorgungen vorhanden oder nicht) des Prüfgerätes reserviert.
(Das kriege ich nicht so zum Laufen)
Gleich bei "FormCreate" schreibe ich in den Port 0 und 1 $FF um diese
als Eingänge nutzen zu können und in die Ports 2 und 3 $00 um diese
als ausgeschaltete Eingänge nutzen zu können.
(Das funktioniert auch schon)
Klicke ich auf den "Button 3 oder 4" soll das mit den 2x 8 Checkboxen
eingestellte Bitmuster an die Ports 2 und 3 des IOW ausgegeben werden.
(Das funktioniert auch schon)
danke erst mal für die Antwort.
(*) Unten findet ihr eine kurze Beschreibung meines Programmes!
Habe nun mitlerweile mein Projekt von der SDK-Version 1.4 auf die SDK
Version 1.5 umgestellt, wobei die DLL die Versionnummer 2.0.0.0 hat.
Jetzt habe ich auch IOWKitReadNonBlocking zur Verfügung.
Die IOWKitVersion ist 1.0.2.1 die Seriennummer des IOW40: $F3D
Aber leider funktioniert das auch noch nicht 100%. Im Gegensatz zu
"ReadImmediate" bleibt das Programm zwar nicht hängen, aber es wird
NICHT der MOMENTANE aktuelle Wert des Ports zurückgelesen.
Wenn ich nacheinander mit 8 Write-Befehlen auf dem Port 2 8 Bits
hintereinander setzte(ähnlich Lauflicht, Bit setzen/zum IOW senden und
dann wieder setzten/senden und wieder setzten/senden usw.), muß ich
auch auch 8x einen ReadNonBlocking machen, bis ich wieder $FF als Wert
des Portes zurückbekomme. Die Zwischenwerten die ich bekomme sind
$01,$03,$07,$0F usw.
Würde ich ReadImmediate verwenden, bekomme ich den aktuellen
Portinhalt ($FF) sofort zurück. Aber nach "n"-Zugriffen mit ReadImm.
bleibt mein Programm hängen.
Ich kann gerne den Source hier veröffentlichen oder "posten"
Gruß und schon mal danke an alle die mir helfen wollen.
ROBERT
(*) Ich arbeite an einem Prüfgerät zum Dauertesten von Relais. Bevor
ich den eigentlichen Prüfablauf programmiere möchte ich mir einen
"Debugger" für die PG-Hardware programmieren.
Dazu habe ich im Prinzip 4 Buttons und 32 LEDs und 16 Checkboxen
auf meiner Form.
Klicke ich auf den "Button 1 oder 2" sollen jeweils "8 LEDs" auf dem
Form den aktuellen Zustand des Ports 0 und 1 anzeigen.
14 Eingänge werden vom Prüfgerät verwendet und 2 Bit sind für den
Staus (Versorgungen vorhanden oder nicht) des Prüfgerätes reserviert.
(Das kriege ich nicht so zum Laufen)
Gleich bei "FormCreate" schreibe ich in den Port 0 und 1 $FF um diese
als Eingänge nutzen zu können und in die Ports 2 und 3 $00 um diese
als ausgeschaltete Eingänge nutzen zu können.
(Das funktioniert auch schon)
Klicke ich auf den "Button 3 oder 4" soll das mit den 2x 8 Checkboxen
eingestellte Bitmuster an die Ports 2 und 3 des IOW ausgegeben werden.
(Das funktioniert auch schon)
-
Christoph Jung
- Posts: 670
- Joined: Sun Oct 08, 2006 3:43 pm
- Location: Germany / Berlin
- Contact:
Also erstmal ist die iowkit.dll Version2.0 die 1.5. D ist uns leider ein fehler in der Benennung unterlaufen.
Zu ReadNonBlocking:
Die Funktion leifert nur werte zurück, wenn sich was geändert hat.
Sprich du schickst ja neue daten hin und der IOW schickt dann den aktuellen wert zurpck. Wenn ich das anhand des lauflichtes ist also die werte $01, $03, $05, etc.
Warum das mit ReadImediate abschmiert ist halt das, dass du zu schnell versuchst daten zu lesen und der IOW nicht hinterherkommt und das programm zum abrauchen bringt. Hast du eine Zeitbegrenzung fürs lesen drin?
Also so erklär ich mir das. Sagt mir, wenn ich mich irre.
Du könntest aber mal die schleife dazu posten.
Zu ReadNonBlocking:
Die Funktion leifert nur werte zurück, wenn sich was geändert hat.
Sprich du schickst ja neue daten hin und der IOW schickt dann den aktuellen wert zurpck. Wenn ich das anhand des lauflichtes ist also die werte $01, $03, $05, etc.
Warum das mit ReadImediate abschmiert ist halt das, dass du zu schnell versuchst daten zu lesen und der IOW nicht hinterherkommt und das programm zum abrauchen bringt. Hast du eine Zeitbegrenzung fürs lesen drin?
Also so erklär ich mir das. Sagt mir, wenn ich mich irre.
Du könntest aber mal die schleife dazu posten.
-
Guido Körber
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Der IO-Warrior wird vom Systen alle 8msec nach neuen Daten gefragt, schneller geht es nicht den Status zurück zu melden. Der IO-Warrior sendet bei jeder Änderung an den Eingängen ein Datenpaket (Report), zumindest wenn die Änderungen nicht zu schnell hintereinander passieren, andernfalls kann der neue Report den letzten überschreiben wenn dieser noch nicht abgeholt wurde.
Die Reports werden von der DLL gebuffert. IowKitRead und IowKitReadNonBlocking liefern die Daten aus diesem Buffer. IowKitReadImmediate dagegen sendet ein Kommando an den IO-Warrior um den aktuellen Zustand zu lesen.
Die Reports werden von der DLL gebuffert. IowKitRead und IowKitReadNonBlocking liefern die Daten aus diesem Buffer. IowKitReadImmediate dagegen sendet ein Kommando an den IO-Warrior um den aktuellen Zustand zu lesen.
-
robert.ferralux
- Posts: 8
- Joined: Wed Dec 06, 2006 4:36 pm
- Location: Lkrs. Augsburg
Danke euch beiden für die schnelle Antwort:
Guido Körber:
Der IO-Warrior wird vom Systen alle 8msec nach neuen Daten gefragt,
schneller geht es nicht den Status zurück zu melden.
Das ist schnell genug für meine Anwendung
Die Reports werden von der DLL gebuffert. IowKitRead und
IowKitReadNonBlocking liefern die Daten aus diesem Buffer.
IowKitReadImmediate dagegen sendet ein Kommando an den
IO-Warrior um den aktuellen Zustand zu lesen.
Dann ist doch ReadImmediate doch die richtige Funktion für mein Problem!
Christoph Jung:
Warum das mit ReadImediate abschmiert ist halt das, dass du zu
schnell versuchst daten zu lesen und der IOW nicht hinterherkommt
und das programm zum abrauchen bringt.
Hast du eine Zeitbegrenzung fürs lesen drin?
Also so erklär ich mir das. Sagt mir, wenn ich mich irre.
Du könntest aber mal die schleife dazu posten.
Ich habe keine "Zeitschleife" drin sondern löse den Vorgang über
"klicks" auf einen Button aus. So ein Klick sollte doch ein paar msec
dauern. Ich habs nochmal probiert. Alle Sekunde mal drauf und nach
10 Tastenklicks stand das Programm.
HIER DER SOURCEAUSZUG
{*** USB-Warrior einstellen ***}
procedure TForm1.InitIOPorts;
begin
{*** Richtung auf den Ports vorbereiten ***}
PortVal0 := $FF; // alles Eingang "high"
PortVal1 := $FF; // alles Eingang "high"
PortVal2 := $00; // alles Ausgang "low"
PortVal3 := $00; // alles Ausgang "low"
{*** Richtung auf den Ports setzten ***}
Report.ReportID := 0;
Report.Bytes[0] := PortVal0; // Eingang "high"
Report.Bytes[1] := PortVal1; // Eingang "high"
Report.Bytes[2] := PortVal2; // Ausgang "low"
Report.Bytes[3] := PortVal3; // Ausgang "low"
IowKitWrite (IOWarriors[1], IOW_PIPE_IO_PINS, @Report, IOWKIT40_IO_REPORT_SIZE);
{*** Ports einlesen ***}
GetInPorts;
end;
{*** Daten vom USB-Warrior lesen ***}
procedure TForm1.GetInPorts;
var Value : dword;
BytesRead : byte;
begin
{*** Ports einlesen ***}
if IowKitReadImmediate(IOWarriors[1], Value) then
begin
PortVal0 := Value and $000000FF shr 0; // Eingang
PortVal1 := Value and $0000FF00 shr 8; // Eingang
PortVal2 := Value and $00FF0000 shr 16; // Ausgang rücklesen
PortVal3 := Value and $FF000000 shr 24; // Ausgang rücklesen
PGisON := not(PortVal0 and $80 = $80);
UUTisON := not(PortVal0 and $40 = $40);
Label9.Caption := 'Read sucsessful';
end
else
Label9.Caption := 'No Data avaiable';
{*** zu Debugzwecken *** }
Label10.Caption := IntToHex(PortVal0,2);
Label11.Caption := IntToHex(PortVal1,2);
Label12.Caption := IntToHex(PortVal2,2);
Label13.Caption := IntToHex(PortVal3,2);
end;
Gruß bis bald
und danke
ROBERT
Guido Körber:
Der IO-Warrior wird vom Systen alle 8msec nach neuen Daten gefragt,
schneller geht es nicht den Status zurück zu melden.
Das ist schnell genug für meine Anwendung
Die Reports werden von der DLL gebuffert. IowKitRead und
IowKitReadNonBlocking liefern die Daten aus diesem Buffer.
IowKitReadImmediate dagegen sendet ein Kommando an den
IO-Warrior um den aktuellen Zustand zu lesen.
Dann ist doch ReadImmediate doch die richtige Funktion für mein Problem!
Christoph Jung:
Warum das mit ReadImediate abschmiert ist halt das, dass du zu
schnell versuchst daten zu lesen und der IOW nicht hinterherkommt
und das programm zum abrauchen bringt.
Hast du eine Zeitbegrenzung fürs lesen drin?
Also so erklär ich mir das. Sagt mir, wenn ich mich irre.
Du könntest aber mal die schleife dazu posten.
Ich habe keine "Zeitschleife" drin sondern löse den Vorgang über
"klicks" auf einen Button aus. So ein Klick sollte doch ein paar msec
dauern. Ich habs nochmal probiert. Alle Sekunde mal drauf und nach
10 Tastenklicks stand das Programm.
HIER DER SOURCEAUSZUG
{*** USB-Warrior einstellen ***}
procedure TForm1.InitIOPorts;
begin
{*** Richtung auf den Ports vorbereiten ***}
PortVal0 := $FF; // alles Eingang "high"
PortVal1 := $FF; // alles Eingang "high"
PortVal2 := $00; // alles Ausgang "low"
PortVal3 := $00; // alles Ausgang "low"
{*** Richtung auf den Ports setzten ***}
Report.ReportID := 0;
Report.Bytes[0] := PortVal0; // Eingang "high"
Report.Bytes[1] := PortVal1; // Eingang "high"
Report.Bytes[2] := PortVal2; // Ausgang "low"
Report.Bytes[3] := PortVal3; // Ausgang "low"
IowKitWrite (IOWarriors[1], IOW_PIPE_IO_PINS, @Report, IOWKIT40_IO_REPORT_SIZE);
{*** Ports einlesen ***}
GetInPorts;
end;
{*** Daten vom USB-Warrior lesen ***}
procedure TForm1.GetInPorts;
var Value : dword;
BytesRead : byte;
begin
{*** Ports einlesen ***}
if IowKitReadImmediate(IOWarriors[1], Value) then
begin
PortVal0 := Value and $000000FF shr 0; // Eingang
PortVal1 := Value and $0000FF00 shr 8; // Eingang
PortVal2 := Value and $00FF0000 shr 16; // Ausgang rücklesen
PortVal3 := Value and $FF000000 shr 24; // Ausgang rücklesen
PGisON := not(PortVal0 and $80 = $80);
UUTisON := not(PortVal0 and $40 = $40);
Label9.Caption := 'Read sucsessful';
end
else
Label9.Caption := 'No Data avaiable';
{*** zu Debugzwecken *** }
Label10.Caption := IntToHex(PortVal0,2);
Label11.Caption := IntToHex(PortVal1,2);
Label12.Caption := IntToHex(PortVal2,2);
Label13.Caption := IntToHex(PortVal3,2);
end;
Gruß bis bald
und danke
ROBERT
-
robert.ferralux
- Posts: 8
- Joined: Wed Dec 06, 2006 4:36 pm
- Location: Lkrs. Augsburg
Ich glaube auch das das Problem aus dieser Richtung kommt, oder eswayoda wrote:Das scheint mir das gleiche Problem zu sein wie in dem Thread auf den ich schon vorher verwiesen habe. Einmal sind es Timerevents die nicht ankommen, hier sind es eben onKlick-Button-Events.
Ich befürchte hier gibts ein Problem in der IowKit-Library.
Eberhard
liegt am Windows.
Aber ich habe ein Lösung auf die mich Christoph gebracht hat:
Ich verwende jetzt "ReadImmediate" da diese Funktion ja ein echtes Port-
abbild zur verfügung stellt und vor dem ReadImmediate habe ich ein
TimeOut mit "IOWKitSetTimeOut" eingebaut.
Man merkt zwar, das das Lesen sich ab und zu aufhängt, aber nach einer
Sekunde kann man weiterarbeiten.
Gruß und allen danke für die Hilfe
ROBERT