COM_EVENT()

Alle Fragen um die Programmierung, die sich sonst nicht kategorisieren lassen. Von Makro bis Codeblock, von IF bis ENDIF

Moderator: Moderatoren

Antworten
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

COM_EVENT()

Beitrag von Jan »

Hallo,

folgendes Problem: Ich steuere eine Türschaltung an. Das geschieht über den COM-Port. Sobald sich jemand mit dem korrekten Barcode oder RFID autorisiert hat, wird über den gleichen COM ein Signal zur Türöfffnung gesendet.

Soweit klappt das alles auch.

Jetzt kommt das Aber: Ich muß auch die Möglichkeit haben, zwischendurch mal extern die Tür zu öffnen. Und da hakt es. Da in dem oben erklärten Thread der COM-Port durch das erfoderliche COM_EVENT geblockt ist, kommen die manuellen Öffnen-Befehle nicht durch. Erst dann, wenn der COM_EVENT irgend etwas empfängt, weil jemand seinen Chip da dran hält. Aber das ist natürlich vollkommen daneben.

Wie bekomme ich das hin, das ich einerseits auf eine Autorisierung warten kann, andererseits aber auch dazwischen grätschen kann?

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: COM_EVENT()

Beitrag von HaPe »

Hallo Jan !
Wie bekomme ich das hin, das ich einerseits auf eine Autorisierung warten kann, andererseits aber auch dazwischen grätschen kann?
Mich welchem Tool bzw. welchen Funktionen öffnest du den COM-Port?
- Xbase++-Funktionen
- Öffnen wie eine Windows-Datei mit open, read und write
- externes Tool
- ...

Ich verwende dazu (in VFP) entweder das MSCOM-Control oder das SuperCOM.OCX.
Da kann ich trotz aktivierem Event-(Handler) fürs Empfangen problemlos etwas senden ... :)
--
Hans-Peter
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: COM_EVENT()

Beitrag von Jan »

Hans-Peter,

dafür nehm ich die COM-Funktionen aus Xbase++. Ehemals Tools.

Da steht auch drin, das COM_EVENT sich anders verhält als in den Clipper-Tools. Aber was genau anders ist weiß ich jetzt nicht. Ist auch egal, denn ich muß es nehmen wie es ist.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: COM_EVENT()

Beitrag von HaPe »

Hallo Jan !
dafür nehm ich die COM-Funktionen aus Xbase++. Ehemals Tools.
Welchen Com_ReadMode hast du eingestellt?
--
Hans-Peter
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: COM_EVENT()

Beitrag von Jan »

Hallo Hans-Peter,

da hab ich nichts eingestellt, also den Standard. Das ändert ja aber wohl auch nichts, denn das Read kommt erst nach COM_EVVENT(). Und das stoppt alles, bis irgendwas ankommt.

Ich muß es irgendwie schaffen, den COM_EVENT() zu unterbrechen. Das scheint aber nicht so einfach zu sein. Nicht mal ein COM_CLOSE() geht in dieser Wartezeit.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: COM_EVENT()

Beitrag von Martin Altmann »

Hmm, nur mal so als Tipp:
Warum lagerst Du die COM-EVENT()-Behandlung nicht in einen eigenen Thread aus? Dann kannst Du in deinem Eventhandling mittels Thread-Kommunikation wechselweise Deine Türschließanlage und den Zweitweg pollen.

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: COM_EVENT()

Beitrag von Jan »

Hallo Martin,

nette Idee. Hab ich aber schon längst gemacht. Primär, weil ich mehrere Türen mit unterschiedlichen Com-Ports überwachen muß, und dann zuerst, ohne Threads für jeden Port, der erste COM_EVENT() alle weiteren Ports blockiert hat. Aber auch diesen Reingrätsch-Mechanismus habe ich daher direkt in einen anderen Thread verlegt.

Und aus genau dem Grund funktioniert das auch nicht mit dem reingrätschen. Der betreffende Port steckt in der COM_EVENT()-Schleife fest. Da nützt auch ein anderer Thread nichts. Weil der in dem ersten Thread so lange stecken bleibt, bis der da was geliefert bekommen hat.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: COM_EVENT()

Beitrag von HaPe »

Hallo Jan !
Ich muß es irgendwie schaffen, den COM_EVENT() zu unterbrechen. Das scheint aber nicht so einfach zu sein. Nicht mal ein COM_CLOSE() geht in dieser Wartezeit.
Damit muß ich feststellen, dass die Alaska-Umsetzung der RS232-Kommunikation noch unter DOS-Niveau liegt. :(

Unter DOS hatte ich in einem C-Programm bis zu vier COM-Ports gleichzeitig offen mit Event-Handler wenn Daten "reinkommen" und man konnte dennoch an die Meßgeräte die entsprechenden Befehle senden.
--
Hans-Peter
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: COM_EVENT()

Beitrag von brandelh »

Ihr redet aneinander vorbei !!!!

der COM Event und der COM Port sind doch am PC, der Taster schließt einen Stromkreis und das RFID Teil erkennt etwas und schließt einen Stromkreis.
Natürlich kann man für jeden COM Port auch ein COM_EVENT() einrichten. Du musst entweder deinem COM Port ein Signal unterschieben oder dem RFID Teil.

EIne ähnliche Konstellation habe ich vor meiner Haustür:
LichtSchalter.png
LichtSchalter.png (5.24 KiB) 6283 mal betrachtet
Lampe außen, Lichtschalter innen für außen (fix, wenn der an ist brennt Licht immer)
Außen ist ein Bewegungssensor, der kann auch den Stromkreis schließen. Wenn beide zu sind macht das nix.
Der Lampe ist es egal woher der Strom kommt (2 Taster 2 Stromkreise an einen Empfänger, hier Lampe).

Bei dir kommt es darauf an, wie "einfach" die empfangende bzw. sendende Schaltung ist.
Falls die COM Schnittstelle nur Strom auf einem PIN braucht, kannst 2 Leitungen dran legen.
Einfacher wäre es, wenn du am RFID Modul die Ausgänge (gesichert mit Dioden wegen Rückspannung) kurzschließen könntest.

In jedem Fall sollte COM_EVENT() auf ALLE ankommenden Signale der angeschlossenen Leitung reagieren.
Gruß
Hubert
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: COM_EVENT()

Beitrag von HaPe »

Hallo Hubert !
... der Taster schließt einen Stromkreis und das RFID Teil erkennt etwas und schließt einen Stromkreis.
Ich bezweifle des der RFID-Leser nur einen Strom-Kreis schließt.
Vielmehr sendet der RFID-Leser über die serielle- bzw. USB-Leitung die RFID-Kennung damit die angeschlossene Software entscheiden kann ob befugt oder unbefugt.

Ich kann mich nur wiederholen: Ein ordentlicher Treiber (per DLL und Callback-Funktion bzw. OCX mit Event-Methode) ruft die Event-Methode bzw. die Callback-Funktion auf wenn Zeichen empfangen wurden oder sich der Status diverser Leitungen geändert hat und man kann über den selben Port Daten senden ohne den Event bzw. den Callback ausschalten zu müssen.

PS: Ich habe seit 25 Jahren mit seriellen (Mess-)Geräten zu tun und hatte bisher kein Gerät bei dem man prüfen mußte ob sich der Status einer Leitung ändert. Immer wurden lesbare bzw. binär-codierte Daten als Zeichen über die Leitungen gesendet.
--
Hans-Peter
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: COM_EVENT()

Beitrag von Jan »

Ich hab das jetzt anders gelöst.

Der Com_Event() ist primitiv ausgedrückt ja nur dazu da zu schauen, ob da was ankommt. Und in dem Fall dann irgendwelchen Code auszulösen. Ich hab die Zeile jetzt rausgeschmissen. Der geht damit im Warte-Modus jetzt direkt auf Com_Count() und Com_Read(). Da ich das per Thread mache, hab ich den Intervall dort auf 1/10 Sekunde hochgesetzt, was immer noch schnell genug ist. Wenn da nichts kommt, muß ich das jetzt halt selber über eine IF-Schleife abfangen.

Aber da ich damit nicht mehr in dieser alles blockierenden Com_Event()-Schleife festsitze, kann ich halt mit dem separaten Öffnen-Signal jederzeit dazwischen gehen.

Zumindest bei den Tests bei mir auf dem Schreibtisch hat das alles sauber funktioniert.

Danke für Eure Ideen dazu.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: COM_EVENT()

Beitrag von brandelh »

Ich hatte nicht verstanden, dass der PC das öffnen Signal über die gleiche Leitung senden soll.

Bei den Türoffnern gibt es einfache Modelle, die einfach mit Strom einen Magneten ziehen ...
und Anlagen die miteinander kommunizieren (da geht nix ohne Protokoll).
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: COM_EVENT()

Beitrag von Jan »

Hallo Hubert,

in diesem Fall spreche ich nicht direkt die Tür an. Sondern den RFID-Leser der Zugangskontrolle. Der kann die RFID-ID an mich übertragen, und ich kann ihm dann sagen: Mach auf. Solange das in einem Abwasch war, hatte das auch funktioniert. Da ja durch das RFID dranhalten das Signal an COM_EVENT() gesendet wurde, und der damit gelöst war. Für das Auslesen der ID und für das folgende Senden des Öffnen-Signals. Problematisch war das nur, wenn der auf eine RFID-ID gewartet hat, und ich während dieses Wartens einfach so öffnen wollte.

Aber wie gesagt, jetzt warte ich nicht mehr, sondern lese all 1/10 Sekunde den COM-Port aus. Klappt ja anscheinend auch sehr gut.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: COM_EVENT()

Beitrag von brandelh »

genau, im Prinzip wie bei Inkey() entweder warten bis Tastendruck oder eigene Schleife mit inkey(.1) ...

die Bausteine der COM haben ja interne buffer somit sollte das einwandfrei funktionieren.

Wobei ich mir Com_Count() sparen und gleich Com_Read() aufrufen würde,
allerdings mit Com_ReadMode(nPort,NO_WAIT_READ_TIMEOUT ) ohne Wartezeit,
oder mit max. 0.06 Sek : Com_ReadMode(nPort,WAIT_READ_TIMEOUT ,5 )

PS: ich bin wirklich verblüfft, was in den CaToolsIII für Clipper schon alles vorhanden war,
aber Threads machen das Ganze mit Xbase++ bestimmt sicherer als die Schleifenkonstrukte unter DOS.
Ich sollte mal wieder mit Hardware basteln ... ;-)
Gruß
Hubert
Antworten