Probleme mit TTL-Signalen vom Parallelport

[Stephanie Glahs]

Stephanie Glahs schrieb:

Ist aber damit auch mein Problem gelöst, oder war das jetzt erstmal nur
um
meine Schnittstelle etwas mehr zu schonen?

Eher letzteres, meiner Ansicht nach. Das stört mich schon die ganze Zeit
an diesem Thread, daß das ursprüngliche Problem ganz aus dem Blickfeld
gerät. So wichtig es sein mag, die Betriebsdaten der Bauelemente
einzuhalten -- ich möchte wetten, daß das bei Deinem Problem keine Rolle
spielt. Zur Überprüfung reicht ein Voltmeter. Wenn ein High-Ausgang
mindestens 3V gegen Masse produziert - bei angeschlossenem Crydom-Modul
natürlich - muß es gehen.

Du hast selber geschrieben, daß es monatelang funktioniert hat. Seit
wann funktioniert's nicht mehr? Was hat sich geändert?

Also, es hat immer funktioniert und es wird auch weiterhin funktionieren.
Ich steuere Heizungsschütze, Ventilatoren und die Hupe für die
Pausensignalisierung
in einer Fertigungshalle.
Als ich nun die Hupe in Betrieb nahm, machte es sich erstmal bemerkbar, das
da wohl das Hupenrelais schaltet, wenn es nicht schalten soll. Sonst sind
halt mal
die Ventilatoren gelaufen, wenn sie vielleicht nicht mußten, da viel das
nicht so auf.
Also gehe ich davon aus, das das Problem schon von Anfang an besteht.
Erst dachte ich, Schleifstaub hat sich auf der Platine abgesetzt, in der
Halle wird
nämlich Metall geschliffen und ich habe die Platine noch nicht endgültig
verstaut,
weil ich noch in der Testphase bin. Aber auch ein Reinigen der Platine
brachte keinen
Erfolg. Das das Betriebssystem mir da irgendwie reinhaut glaub ich nicht,
denn ich
benutze Win98 und die Datenregister der Schnittstelle und nicht die
Statusregister.

Ich setze einmalig die Pegel an der Schnittstelle und dann erst wieder bei
der nächsten
Änderung. Dazwischen muß irgendwie etwas passieren, was einen Highpegel auch
an
anderen Relais auslöst, als an dem gewünschten. Meißtens wohl schon beim
setzen der
Pegel...

Ich habe die Platine mit der Lötseite stumpf auf einer Pappe liegen... ich
hoffe das macht
mir hier keiner zum Verhängnis...

Stephanie

 

[Jan-Hinnerk Reichert]

Stephanie Glahs wrote:

[Relais am Parallelport]

Jetzt das Problem:
Von Zeit zu Zeit zieht ein nicht angesteuertes Relais mit an, auch
wenn es eigentlich gar nicht aktiviert sein dürfte.

Benutzt Du Windows?

Falls ja, könnte es sein, daß Windows nach Plug&Play-Geräten am
Parallel-Port sucht?

Für WindowsXP sollte folgender Patch für die Registry das Plug&Play
für den Parallel-Port deaktivieren.

http://www.student.dtu.dk/~s991363/avr/avrdude/winxp1.reg

Habe das selber nie probiert ;-)

/Jan-Hinnerk

 

[Juergen Hannappel]

"Stephanie Glahs" <sg@gla-wel.de> writes:


[...]

Ich setze einmalig die Pegel an der Schnittstelle und dann erst wieder bei
der nächsten
Änderung. Dazwischen muß irgendwie etwas passieren, was einen Highpegel auch
an
anderen Relais auslöst, als an dem gewünschten. Meißtens wohl schon beim
setzen der
Pegel...

Das hoert sich so an, als ob die Relais dann auernd an sind und nicht
nur mal kurz. Ist dem so?
Wenn ja: Was zeigt denn ein DVM am Relaiseingang, wenn der aus sein
sollte, das Relasi aber an ist?

--
Dr. Juergen Hannappel http://lisa2.physik.uni-bonn.de/~hannappe
mailto:hannappel@physik.uni-bonn.de Phone: +49 228 73 2447 FAX ... 7869
Physikalisches Institut der Uni Bonn Nussallee 12, D-53115 Bonn, Germany
CERN: Phone: +412276 76461 Fax: ..77930 Bat. 892-R-A13 CH-1211 Geneve 23

 

[Stephanie Glahs]

"Jan-Hinnerk Reichert" <hinni@despammed.com> schrieb im Newsbeitrag
news:buoi77$jdral$1@news.hansenet.net...

Stephanie Glahs wrote:

[Relais am Parallelport]

Jetzt das Problem:
Von Zeit zu Zeit zieht ein nicht angesteuertes Relais mit an, auch
wenn es eigentlich gar nicht aktiviert sein dürfte.

Benutzt Du Windows?

Falls ja, könnte es sein, daß Windows nach Plug&Play-Geräten am
Parallel-Port sucht?

Für WindowsXP sollte folgender Patch für die Registry das Plug&Play
für den Parallel-Port deaktivieren.

http://www.student.dtu.dk/~s991363/avr/avrdude/winxp1.reg

Ich benutze Windows98 und das Datenregister...

Kann das da auch passieren?

Stephanie

 

[Uwe Hercksen]

Stephanie Glahs schrieb:

Ist aber damit auch mein Problem gelöst, oder war das jetzt erstmal nur um
meine Schnittstelle etwas mehr zu schonen?

Hallo,

nicht zur Schonung, sondern um den höheren möglichen Strom im Low
Zustand auch wirklich zu benutzen.

Du kannst aber trotzdem noch Probleme mit ungünstigem, störempfindlichen
Aufbau haben oder auch dadurch das das Betriebssystem zwischendurch mal
auf den Port zugreift.

Bye

 

[Stephanie Glahs]

"> [...]

Ich setze einmalig die Pegel an der Schnittstelle und dann erst wieder
bei
der nächsten
Änderung. Dazwischen muß irgendwie etwas passieren, was einen Highpegel
auch
an
anderen Relais auslöst, als an dem gewünschten. Meißtens wohl schon beim
setzen der
Pegel...

Das hoert sich so an, als ob die Relais dann auernd an sind und nicht
nur mal kurz. Ist dem so?

Ja, das ist so...

Wenn ja: Was zeigt denn ein DVM am Relaiseingang, wenn der aus sein
sollte, das Relasi aber an ist?

Was ist denn ein Relasi??? ----Scherz...
Konnte leider noch nicht messen, aber ich denke mal ein ordentliches High.
Sonst würde das Relais ja nicht durchschalten.

Das Problem muß irgendwo an der Schnittstelle selbst liegen. Oder auf meiner
Platine, aber da hab ich nur die Leitungen gezogen, Schaltungstechnisch
nichts
aufregendes, natürlich auf gute Trennung zwischen den Leiterbahnen geachtet.

Wenn ich ein anderes Relais auf High schalte, was kann den Nachbareingang
dann mit auf High ziehen, obwohl ich LowPegel draufgebe? Das ist glaub ich
die Frage dieses Threads.
Denn wenn der Pegel einmal oben ist, merkt das meine Software nicht, erst
bei
der nächsten Regelung kommt wieder ein Low zu dem Port und könnte ihn damit
wieder runterziehen...

Stephanie

 

[Martin Schönegg]

die Parallelportausgänge sind nicht direkt mit dem
Schnittstellenschaltkreis
verbunden, sondern über Strombegrenzungswiderstände. Die daraus
resultierende "Hochohmigkeit" ( IMO ca. 1kOhm)

Definitiv nicht, sonst könntest Du jegliche schnellere Datenrate glatt
vergessen.

Martin

 

[Stefan Heinzmann]

Stephanie Glahs schrieb:

Also, es hat immer funktioniert und es wird auch weiterhin funktionieren.
Ich steuere Heizungsschütze, Ventilatoren und die Hupe für die
Pausensignalisierung
in einer Fertigungshalle.
Als ich nun die Hupe in Betrieb nahm, machte es sich erstmal bemerkbar, das
da wohl das Hupenrelais schaltet, wenn es nicht schalten soll. Sonst sind
halt mal
die Ventilatoren gelaufen, wenn sie vielleicht nicht mußten, da viel das
nicht so auf.
Also gehe ich davon aus, das das Problem schon von Anfang an besteht.
Erst dachte ich, Schleifstaub hat sich auf der Platine abgesetzt, in der
Halle wird
nämlich Metall geschliffen und ich habe die Platine noch nicht endgültig
verstaut,
weil ich noch in der Testphase bin. Aber auch ein Reinigen der Platine
brachte keinen
Erfolg. Das das Betriebssystem mir da irgendwie reinhaut glaub ich nicht,
denn ich
benutze Win98 und die Datenregister der Schnittstelle und nicht die
Statusregister.

Ich setze einmalig die Pegel an der Schnittstelle und dann erst wieder bei
der nächsten
Änderung. Dazwischen muß irgendwie etwas passieren, was einen Highpegel auch
an
anderen Relais auslöst, als an dem gewünschten. Meißtens wohl schon beim
setzen der
Pegel...

Ich habe die Platine mit der Lötseite stumpf auf einer Pappe liegen... ich
hoffe das macht
mir hier keiner zum Verhängnis...

Ich sicher nicht. Ich mache das selber ebenso. Daß man dabei wegen der
220V aufpassen muß brauche ich ja wohl nicht extra betonen (will keine
Eulen nach Athen tragen...)

Also habe ich das richtig verstanden: Die Hupe schaltet unvermittelt an,
ohne daß sonst irgendwas passiert, und bleibt dann an bis die Software
ein neues Datenbyte zum Port schreibt? Passiert auch mal das Umgekehrte,
daß etwas ausgeschaltet wird wenn's an sein sollte? Kann man den
Zeitpunkt der Fehlschaltung mit was anderem in Verbindung bringen?
Betrifft die Fehlschaltung nur einen Ausgang oder kommen dann alle
Ausgänge durcheinender?

Das mit dem Betriebssystem würde ich nicht unterschätzen. Üblicherweise
sucht das Betriebssystem beim Hochfahren an den Anschlüssen nach Geräten
(Plug and Pray...). Das führt natürlich zu Datenverkehr, was bei Deinem
Aufbau dazu führen müßte daß beim Hochfahren des Rechners die Relais
klappern. Erst nach dem Starten Deiner Applikation geht dann alles in
den richtigen Zustand. Ich weiß nicht ob ich es gut finden würde wenn
bei jedem Hochfahren des Rechners die Hupe in der Fabrikhalle kurz tönen
wurde ;-)

Das kann man bestimmt irgendwie abstellen, aber dazu kenne ich die
Internas von Windows nicht gut genug.

Was ich auch nicht weiß ist inwiefern Windows während des Betriebs
Kontrollabfragen an den Druckerport macht, vielleicht um neu
angeschlossene Geräte zu entdecken. Falls das der Fall ist könnte das
durchaus Deine Schwierigkeiten erklären.

Nur zur Kontrolle: Ist es so daß Du bisher jedes Crydom-Relais mit dem
positiven Anschluß an einen Datenpin und mit dem negativen Anschluß an
die Masse des Druckerports angeschlossen hast, mit keinem weiteren
Bauteil parallel oder in Reihe? Es gibt auch keine Querverbindungen
zwischen einzelnen Relais, und die Leitungen sind so gelötet daß sie
sich nicht gegenseitig berühren können? Versteh mich richtig, ich halte
Dich nicht für blöder als mich selber; auch mich haben schon die
dümmsten Sachen für Stunden genarrt. Bei Litzen können einzelne
Drähtchen beim Löten "danebengehen" und recht unauffällig ziemlich
dämliche Effekte erzeugen...

Gruß
Stefan

 

[Uwe Hercksen]

Stephanie Glahs schrieb:

Also, es hat immer funktioniert und es wird auch weiterhin funktionieren.
Ich steuere Heizungsschütze, Ventilatoren und die Hupe für die
Pausensignalisierung
in einer Fertigungshalle.
Als ich nun die Hupe in Betrieb nahm, machte es sich erstmal bemerkbar, das
da wohl das Hupenrelais schaltet, wenn es nicht schalten soll. Sonst sind
halt mal
die Ventilatoren gelaufen, wenn sie vielleicht nicht mußten, da viel das
nicht so auf.
Also gehe ich davon aus, das das Problem schon von Anfang an besteht.
Erst dachte ich, Schleifstaub hat sich auf der Platine abgesetzt, in der
Halle wird
nämlich Metall geschliffen und ich habe die Platine noch nicht endgültig
verstaut,
weil ich noch in der Testphase bin. Aber auch ein Reinigen der Platine
brachte keinen
Erfolg. Das das Betriebssystem mir da irgendwie reinhaut glaub ich nicht,
denn ich
benutze Win98 und die Datenregister der Schnittstelle und nicht die
Statusregister.

Ich setze einmalig die Pegel an der Schnittstelle und dann erst wieder bei
der nächsten
Änderung. Dazwischen muß irgendwie etwas passieren, was einen Highpegel auch
an
anderen Relais auslöst, als an dem gewünschten. Meißtens wohl schon beim
setzen der
Pegel...

Ich habe die Platine mit der Lötseite stumpf auf einer Pappe liegen... ich
hoffe das macht
mir hier keiner zum Verhängnis...

Hallo,

also wenn man so liest was Du für Lasten daran hast, wie es aufgebaut
ist und wie Du vorgehst dann ist es sehr wahrscheinlich das Du Probleme
mit Störungen hast.
Dann hast Du offenbar noch 230 V Netz direkt an der Platine und hast die
Platine nur auf einer Pappe liegen, na hoffentlich langt da mal niemand
aus Versehen dran.
Bei Windows 98 musst Du übrigens schon von unerwünschten Zugriffen des
Betriebssytems auf den Parport ausgehen.

Kaufe was ordentliches Fertiges!

Bye

 

[Uwe Hercksen]

Stephanie Glahs schrieb:

Ich benutze Windows98 und das Datenregister...
Kann das da auch passieren?

Hallo,

ja! Nun glaub es doch endlich!
Beim Identifizieren eines Druckers muß Windows dem doch Signale schicken
und schauen was zurück kommt, dafür reicht das Statusregister alleine
nicht, dazu muss Windows auch das Datenregister benutzen.
Natürlich wird das so gemacht das ein Drucker dabei nichts druckt.

Bye

 

[Stephanie Glahs]

Also ich werde jetzt mal folgendes versuchen. Ich schreibe momentan
immer nur einmal das Byte zum Port, wenn sich irgendein Schaltzustand
ändern soll. Das mache ich jetzt anders, ich werde alle 200ms das
Byte zum Port feuern, dann werden wir mal sehen, wer hier den längeren
Atem hat...
Habe sogar zwischendurch die Connection zum Port geclosed, das werde
ich auch unterlassen...
Werde berichten, was es gebracht hat...

Stephanie

 

[Stefan Heinzmann]

Stephanie Glahs schrieb:

Also ich werde jetzt mal folgendes versuchen. Ich schreibe momentan
immer nur einmal das Byte zum Port, wenn sich irgendein Schaltzustand
ändern soll. Das mache ich jetzt anders, ich werde alle 200ms das
Byte zum Port feuern, dann werden wir mal sehen, wer hier den längeren
Atem hat...

Dir ist schon klar, daß Du dadurch das Problem maskierst, anstatt es zu
lösen? Wenn's zu was gut ist dann dazu, herauszufinden, ob Windows
dazwischenfunkt. Wenn ja, sollte man das Übel schon an der Wurzel packen...

Habe sogar zwischendurch die Connection zum Port geclosed, das werde
ich auch unterlassen...

Das könnte den entscheidenden Unterschied machen. Ich würde erwarten,
daß Windows nicht dazwischenfunkt solange der Port geöffnet ist.

Werde berichten, was es gebracht hat...

Wie oft tritt der Fehler denn auf, muß man da jedesmal 14 Tage warten?
(Sowas hatte ich auch schon...)

Gruß
Stefan

 

[Martin Lenz]

Stephanie Glahs schrieb:

Also, es hat immer funktioniert und es wird auch weiterhin funktionieren.
Ich steuere Heizungsschütze, Ventilatoren und die Hupe für die
Pausensignalisierung
in einer Fertigungshalle.
Als ich nun die Hupe in Betrieb nahm, machte es sich erstmal bemerkbar, das
da wohl das Hupenrelais schaltet, wenn es nicht schalten soll. Sonst sind
halt mal
die Ventilatoren gelaufen, wenn sie vielleicht nicht mußten, da viel das
nicht so auf.
Also gehe ich davon aus, das das Problem schon von Anfang an besteht.
Erst dachte ich, Schleifstaub hat sich auf der Platine abgesetzt, in der
Halle wird
nämlich Metall geschliffen und ich habe die Platine noch nicht endgültig
verstaut,
weil ich noch in der Testphase bin. Aber auch ein Reinigen der Platine
brachte keinen
Erfolg. Das das Betriebssystem mir da irgendwie reinhaut glaub ich nicht,
denn ich
benutze Win98 und die Datenregister der Schnittstelle und nicht die
Statusregister.

Das glaubst du zumindest... Unter Win98 habe ich schon erlebt, daß ich

auf die Schnittstelle (serielle) mit Port-in/out Befehlen geschrieben
hatte, das war auch zurückzulesen, nur auf den Leitungen ist nichts
angekommen. Wenn das Betriebssystem der Meinung ist, daß gerade jemand
anderer die Schnittstelle hat, dann spiegelt es dir was vor. Ähnliches
habe ich auch schon mit der Druckerschnittstelle erlebt. Es war
notwendig, dem OS zu erklären, daß da kein Drucker dranhängt, um externe
Dinge steuern zu können. Das waren bei mir Optokoppler ohne zusätzliche
5V Versorgung, also zw. GND und Datenpin geschaltet. Die Widerstände für
höheren Strom gerechnet. Da der Port ja nur für 1mA _bei TTL Pegeln_
spezifiziert ist, muß ich mit höherem Spannungsabfall bei höherem Strom
rechnen.
Ich hatte allerdings auch schon eine MultiIO Karte deren Parport bei
Belastung mit 100 Ohm gg. GND noch 4,5V geliefert hat - das wollte ich
aber nicht dauertesten

Martin

 

[Martin Lenz]

Stephanie Glahs schrieb:

"MaWin" <me@privacy.net> schrieb im Newsbeitrag
news:01c3e0dc$c41f04e0$0100007f@amdk6-300...
Stephanie Glahs <sg@gla-wel.de> schrieb im Beitrag
buoa18$k708r$1@ID-206789.news.uni-berlin.de>...

Laut Crydom Datenblatt typischer Eingangsstrom von 3 mA. Das muß die
Parallele Schnitstelle abkönnen, und das tut sie auch, es läuft schon
seit
Monaten so.

3mA ist recht wenig, aber hast du jemals nachgemessen, wie viel fliessen ?
Ohne Vorwiderstand ist das eher Glueckssache. Manch ein Parallelport macht
1.6mA, ein anderes 2.4mA, wieder eins 4mA, ein anderes 20mA,. ....

Also ich bin nicht doof, aber das habe ich nicht verstanden. Sorry---

+5V
|
220R
|
Crydom
|K
-+ Druckerausgang

Also... lese ich daraus richtig, das ich den Pluseingang des Crydom mit
einem
220R an 5V legen soll und dann den Negativeingang des Crydom mit Low-Pegeln
aus der Parallelschnittstelle ansteuern soll?

So kann man das machen, wenn man eine ext. Spannungsquelle verwenden

will. Die 3mA sind sicher nicht das Problem, vor allem du hast ja
Probleme mit ungewolltem einschalten, und nciht mit Aussetzern. Ich
tippe auf die Software/das Betriebssystem.

Martin

 

[Stephanie Glahs]

"Stefan Heinzmann" <stefan_heinzmann@yahoo.com> schrieb im Newsbeitrag
news:buoku1$93o$06$1@news.t-online.com...

Stephanie Glahs schrieb:

Also ich werde jetzt mal folgendes versuchen. Ich schreibe momentan
immer nur einmal das Byte zum Port, wenn sich irgendein Schaltzustand
ändern soll. Das mache ich jetzt anders, ich werde alle 200ms das
Byte zum Port feuern, dann werden wir mal sehen, wer hier den längeren
Atem hat...

Dir ist schon klar, daß Du dadurch das Problem maskierst, anstatt es zu
lösen? Wenn's zu was gut ist dann dazu, herauszufinden, ob Windows
dazwischenfunkt. Wenn ja, sollte man das Übel schon an der Wurzel
packen...

Habe sogar zwischendurch die Connection zum Port geclosed, das werde
ich auch unterlassen...

Das könnte den entscheidenden Unterschied machen. Ich würde erwarten,
daß Windows nicht dazwischenfunkt solange der Port geöffnet ist.

Genau daran hab ich jetzt nämlich auch gedacht...

Werde berichten, was es gebracht hat...

Wie oft tritt der Fehler denn auf, muß man da jedesmal 14 Tage warten?
(Sowas hatte ich auch schon...)

Ne, schon relativ oft, konnte aber noch nicht zählen, auf jeden Fall
mehrmals
täglich...

Stephanie

 

[Martin Lenz]

Stephanie Glahs schrieb:

"Jan-Hinnerk Reichert" <hinni@despammed.com> schrieb im Newsbeitrag
news:buoi77$jdral$1@news.hansenet.net...
Stephanie Glahs wrote:

[Relais am Parallelport]

Jetzt das Problem:
Von Zeit zu Zeit zieht ein nicht angesteuertes Relais mit an, auch
wenn es eigentlich gar nicht aktiviert sein dürfte.

Benutzt Du Windows?

Falls ja, könnte es sein, daß Windows nach Plug&Play-Geräten am
Parallel-Port sucht?

Für WindowsXP sollte folgender Patch für die Registry das Plug&Play
für den Parallel-Port deaktivieren.

http://www.student.dtu.dk/~s991363/avr/avrdude/winxp1.reg

Ich benutze Windows98 und das Datenregister...
Kann das da auch passieren?

Ja.

Probiere, den Port im Hardwaremanager als "In dieser HW Konfiguration
(oder -profil ?) nicht verwenden" einzustellen, dann sollte das OS die
Finger davon lassen und du solltest ihn über die Register exklusiv
benützen können.

Martin

 

[Edzard Egberts]

Hallo Stephanie,

Das das Betriebssystem mir da irgendwie reinhaut glaub ich nicht,
denn ich
benutze Win98 und die Datenregister der Schnittstelle und nicht die
Statusregister.

für Glaubensfragen ist das hier die falsche Gruppe - Du verwendest
Hardwarezugriffe, die am Betriebssystem vorbei gehen. Funktioniert Dein
Programm noch, wenn Du beim Start die Schnittstelle mit open() öffnest
und erst wieder bei Programmende schliesst? Ich weiss ja nicht, womit Du
programmierst, aber es müsste da eine Möglichkeit geben, beim Öffnen
Flags für exklusiven Zugriff zu setzen. Entweder funktioniert dann gar
nichts mehr, oder Du hast sicher gestellt, dass Dir das Betriebssystem
nicht mehr in Deine Hardwarezugriffe hereinpfuscht (Shared-Modes und
solche Sachen).

Ich setze einmalig die Pegel an der Schnittstelle und dann erst wieder bei
der nächsten
Änderung. Dazwischen muß irgendwie etwas passieren, was einen Highpegel auch
an anderen Relais auslöst, als an dem gewünschten.

Öhm, bei so Problemen neige ich gelegentlich zu roher Gewalt - die Pegel
ständig schreiben! Das hilft gegen jede Art von Störungen (und treibt
dem Perfektionisten die Tränen in die Augen ;o). Bei Microcontrollern
kann man das ganz nett machen: Eine Timer-Routine schreibt ständig eine
Speicherstelle auf den Port und irgendwo im Hauptprogramm wird diese
Speicherstelle bearbeitet. Das geht gut, wenn es keine zeitkritische
Anwendung ist, was bei Dir nicht der Fall zu sein scheint. Wenn Du
irgendwelche Probleme beim Schreiben hast, führt das auch direkt zu
einer Reaktion (Relais fängt an zu "klappern") und Du bist wieder ein
Stück weiter.

HTH,

Ed

 

[Jorgen Lund-Nielsen]

Stephanie Glahs schrieb:

Wenn ja: Was zeigt denn ein DVM am Relaiseingang, wenn der aus sein
sollte, das Relasi aber an ist?


Was ist denn ein Relasi??? ----Scherz...

Vielleicht ein gaaanz kleines Relais? ;-)

Jorgen

 

[Martin Schönegg]

Hi,
Das Problem heisst "Windows" und umgehen kann man es mit einem der vielen
Utils, die die Ports isolieren und dem Betriebssystem damit wegnehmen. Im
Buch von Bernd Kainka: "PC-Schnitsetellen unter Windows" gibts die Port.dll
dafür. Googeln hilft da weiter, es gibt noch ein Paar derartige Teile, die
ich aber nicht brauche, die Port.dll reicht mir bisher...

Martin

 

[Edzard Egberts]

Hallo Stephanie,

Das mache ich jetzt anders, ich werde alle 200ms das
Byte zum Port feuern, dann werden wir mal sehen, wer hier den längeren
Atem hat...

das ist gar nicht nötig, denn

Habe sogar zwischendurch die Connection zum Port geclosed, das werde
ich auch unterlassen...

hier hast Du Deinen Fehler: Direkter Portzugriff und Dateizugriff über
open/close sind inkompatibel. Der Zugriff auf das Datenregister
funktioniert ohne open(), möglicherweise musst Du dann aber das
Statusregister initialisieren. Das ist auch einfach - mal auslesen, wenn
es funktioniert (also notfalls doch noch einmal open) und den Wert
danach als Standard schreiben. Dann noch den Tipp aufgreifen, den Port
im Hardwareprofil zu deaktivieren und es sollte nicht mehr hupen.
(Herrlich übrigens, wenn ich mir das vorstelle! ))

Gruß,

Ed