![]() |
Eigene Ereignisse auslösen
Hallo
Folgende Situation : //---------------------------------- T_CNCStatus = packed record Kopf :byte; ZBETR :byte; ZREFE :byte; FLAG :byte; // //usw. total 16 Byte SMAXH :byte; end; //record //-------------------------------- var Status :T_Status;{Status-Satz} //---------------------------------------- Wie kann ich ein Ereigniss erzeugen wenn sich der Wert des Bytes im Status.ZBETR ändert ? Die var Status wurde beschrieben durch Daten die von rs232 kommen. mfg Anton |
AW: Eigene Ereignisse auslösen
Kommt der Packed record als Array of Byte aus der RS232 und wird dann in record abgelegt? Oder wird jeder einzelne Wert von "Irgendwem" beschrieben?
|
AW: Eigene Ereignisse auslösen
Hallo Zeras
Ja, der Record wird ausschliesslich durch RS232 abgefüllt . Allerdings kann es passieren (in Mehrheit der Fälle), dass die Daten exakt die gleichen sind. Der ZBETR = Betriebswahl ändert nicht so schnell, ich soll aber nur bei einer Aenderung ein Erreignis (OnChange ) haben. Gruss Anton |
AW: Eigene Ereignisse auslösen
Wenn die Daten über die RS232 reinkommen, musst du diese ja bewerten.
Beispiel: Wenn 16 Zeichen im Puffer sind, dass du dann was machst. Wenn weniger Zeichen da sind, dann noch warten, bis 16 Zeichen im Puffer sind. Erst dann die Bewertung machen. Nebenbei solltest du noch einen Timeout nutzen, damit, wenn einmal zu wenig Zeichen kommen, diese dann verworfen werden und neu angefragt werden. Ich weiß zwar nicht, welche RS232 Unit du hast, aber bei den meisten kann man abfragen, wieviel Zeichen im Puffer sind. Wenn dann diese 16 Zeichen ausgewertet sind, kannst du dich auf dein Byte konzentrieren, welches du prüfen willst. |
AW: Eigene Ereignisse auslösen
Hallo Zeras
Ja, dass ist im bisherigem (pascal)Programm so, aber das ist nicht umbedingt OOP like(resp Delphi like). Ich soll vielleicht erwähnen das der Status eine Globale var ist. Ausserdem befinde ich mich in x_te Menü(x_te Form) und die Componente für Async32(auch Ereignis gesteuert) läuft völlig autonom. Ich möchte nicht wieder in das alte Schema von Polling hinein kommen. Ich möchte nur feststellen können, ob sich die Betriebswahl geändert hat, und falls es so war, wird in das y_te Menue(y_te Form) gewechselt. Uebrigens läuft die Komponennte Async32(rs232) auf dem Form1 (also Haupt programm). mfg Anton |
AW: Eigene Ereignisse auslösen
Wie liest du denn die Daten von Async aus?
Dann kannst du dich doch nur in die Empfangsroutine mit reinhängen und dann prüfen. Von allein wird da kein Ereignis kommen. Vielleicht hilft ein wenig Code von dir weiter. |
AW: Eigene Ereignisse auslösen
Zitat:
Nach Empfang und Auswertung des aktuellen Records wird dessen Inhalt z.B. in sowas wie
Delphi-Quellcode:
gespeichert. (falls die einzelnen Statuswerte nicht schon irgendwo existieren)
FLastCNCStatus: T_CNCStatus;
Bei der Auswertung kann man nun die Alten mit den neuen Werten vergleichen und bei einem Unterschied dann das gewünschte Ereignis auslösen. |
AW: Eigene Ereignisse auslösen
Hallo Himitsu,
Soviel ich in der letzte Zeit gelesen habe, soll Delphi eine Ereigniss orientierte Sprache. Selbstverständlich kann man es mit Vergleich alt/neu lösen, das ist sogar bereits im meinem uraltem Pascalprogramm so realisiert. Aber ich will es ja neu schreiben. Ich meinte, ahnlich wie die standard Ereignisse wie z.Bsp OnClick sollte man auch eigene Ereigniss "OnChange" für die Variableaenderung definieren können. Das wäre doch eleganter. Die Menues Umschaltung wird dann nur durch das Ereigniss gestartete Methode bewerkstelligt. Sollte das nicht durch überschreiben der Standard Ereignisse aus TControl möglich sein ? Durch die Definition eines eigenen Typs ? Nun bin ich da ein bisschen überfordert, wie es da weiter gehen soll. Vielleicht weisst Du ein ähnliches Beispiel ? mfg Anton |
AW: Eigene Ereignisse auslösen
Überlege mal, wie man zu einem Ereignis kommt.
Man muss intern überprüfen und dann sehen, ob der Status sich geändert hat. Der beste Zeitpunkt ist, wie schon oben beschrieben, die Empfangsorutine. Die läuft ereignisgesteuert. Und da wirst du dich reinhängen müssen. Soweit, wie ich weiß, läuft bei den RS232 Units um Hintergrund ein schneller Timer, der prüft, ob neue Daten im Hardwareempfangspuffer liegen und holt diese dann ab. Damit werden dann Ereignisse wie OnReceived etc. erstellt. Prüfe also im Ereignis OnReceived oder ähnlich ab, ob 16 Bytes da sind und lege diese in einem separaten Puffer ab. Wenn dann wieder 16 Bytes da sind, vergleichst du dann die neuen Daten mit den Alten Daten und wenn sich der Status geändert hat, machst du dann deine Routine. |
AW: Eigene Ereignisse auslösen
Ja, Delphi ist im Grunde eine objekt-orientierte Programmiersprache (OOP), welche viel mit Events arbeitet, aber von Alleine passiert das auch nichts.
Was man machen kann, ist seinen Code in entsprechende Klassen aufzuteilen und die Events/Property entsprechend auszulegen. Also z.B. gibt es dann irgendwo ein SMAXH-Property, welches im Setter prüft, ob sich der aktuelle Wert ändert und wenn ja, dann wird ein entsprechendes Ereignis ausgelöst.
Delphi-Quellcode:
(nun nur noch alle nötigen Werte entsprechend dieser Property-Vorlage anlegen)
procedure DoChange; // hier drin wird das OnChange-Event ausgelöst
FMyProp: Integer; procedure SetMyProp(Value: Integer); property MyProp: Integer read FMyProp write SetMyProp; function GetMyPropX(Index: Integer): Integer; // man kann auch einen Getter/Setter für mehrere Property benutzen procedure SetMyPropX(Index, Value: Integer); property MyPropA: Integer index 1 read GetMyPropX write SetMyPropX; property MyPropB: Integer index 2 read GetMyPropX write SetMyPropX; property MyPropC: Integer index 3 read GetMyPropX write SetMyPropX; procedure TMyClass.SetMyProp(Value: Integer); begin if Value = MyProp then Exit; FMyProp := Value; DoChange; end; |
AW: Eigene Ereignisse auslösen
Wenn du T_CNCStatus anfassen kannst, wovon ich ausgehe, ist folgendes denkbar:
1. Erweiterung von T_CNCStatus um Property 2. Erweiterung von T_CNCStatus um Event
Delphi-Quellcode:
type
T_CNCStatus = packed record private FZbetr: byte; procedure SetZbetr(const Value: byte); public OnZbetrChange : TNotifyEvent; Kopf : byte; property Zbetr : byte read FZbetr write SetZbetr; end; implementation procedure T_CNCStatus.SetZbetr(const Value: byte); begin // hier könntest du vorher überprüfen ob sich der Wert wirklich geändert hat. FZbetr := Value; if Assigned(OnZbetrChange) then OnZbetrChange(nil); end; |
AW: Eigene Ereignisse auslösen
Hallo Jonas, vielen Dank , das ist es, was ich gesucht habe !
Die übrige Bytes aus Status records werden zwar benötigt, aber müssen keine ereignis auslösen. Ist es richtig, dass die Typendeklaration für Status dann insgesamt wie folgt aussehen wird : T_CNCStatus =packed record private FZbetr: byte; procedure SetZbetr(const Value: byte); public OnZbetrChange : TNotifyEvent; Kopf :byte; Zbetr :byte; ZREFE :byte; FLAG :byte; POSA1 :byte; POSA2 :byte; STACK :byte; ZAUTO :byte; ZOUT1 :byte; ZOUT2 :byte; ZINP1 :byte; ZINP2 :byte; VORSL :byte; {VORSCHUB} VORSH :byte; DAOUTL :byte; {DA1} DAOUTH :byte; SMAXH :byte; property Zbetr : byte read FZbetr write SetZbetr; end; {record} mfg Anton |
AW: Eigene Ereignisse auslösen
Wenn du diesen Record aber vom Comport oder einem Stream einliest, dann wird direkt auf den Speicher zugegriffen und das Property umgangen.
Der Setter wird nur benutzt, wenn über das Property etwas zugewiesen wird. |
AW: Eigene Ereignisse auslösen
Hallo Himitsu,
danke für den Hinweis, wenn ich also Dein Beispiel auf meine Anwendung anpasse, ist es so Richtig : //zuerst Typendeklaration TMyClass = procedure DoChange; // hier drin wird das OnChange-Event ausgelöst FMyProp: Byte; procedure SetMyProp(Value: Byte); property MyProp: Byte read FMyProp write SetMyProp; (* ich benötige nur ZBETR für Ereigniss auslösen, also darf ich es weglassen function GetMyPropX(Index: Integer): Integer; // man kann auch einen Getter/Setter für mehrere Property benutzen procedure SetMyPropX(Index, Value: Integer); property MyPropA: Integer index 1 read GetMyPropX write SetMyPropX; property MyPropB: Integer index 2 read GetMyPropX write SetMyPropX; property MyPropC: Integer index 3 read GetMyPropX write SetMyPropX; *) Implementation procedure TMyClass.SetMyProp(Value: Byte); begin if Value = MyProp then Exit; FMyProp := Status.ZBETR; DoChange; end; |
AW: Eigene Ereignisse auslösen
Also an den Record selber würde ich keinerlei Events binden.
Statt dessen würde ich eine Klasse (z.B. abgeleitet von
Delphi-Quellcode:
) nehmen, welche die Nachrichten empfängt und dann den gesamten Record bei einer Änderung weiterreicht.
TThread
Ein Beispiel hatte ich in einem anderen Zusammenhang schon mal geschrieben ![]() Das Beispiel funktioniert zwar so nicht mit Delphi 7 beschreibt aber die generelle Vorgehensweise. |
AW: Eigene Ereignisse auslösen
Zitat:
Mal ganz von den bisherigen Beiträgen abgesehen. Das Vorhaben mutet an wie die Bastellösung eines seriellen TDatapackage. Welches über Events verfügt und auch ansonsten eigentlich keine Wünsche offen lässt. edt: Und noch eine Anmerkung. Da du einen Record verwendest gehe ich davon aus das die Daten des Records zusammengehörig sind. Wenn du jetzt bei Änderung von Zbetr auf ein OnChance reagierst sind vielleicht die anderen Felder noch nicht neu belegt. Du verwendest also in deiner Aktualisierungs/Verarbeitung-Routine eventuell Daten die noch zur Hälfte aus den alten Werten bestehen. |
AW: Eigene Ereignisse auslösen
Zitat:
Dann geht der Wert direkt in das Feld und wird nicht über das Property umgeleitet. |
AW: Eigene Ereignisse auslösen
Hallo,
Da der Record nur durch RS232 abgefüllt wird, werde ich beim Empfang fertig ein Flag setzen, und beim beginn des Empfangs natürlich rücksetzen. Dies lässt sich leicht lösen in der OnRXBuff procedur. Das wäre dann die Freigabe um die Daten zu lesen. (die Status Daten von der CNC werden nur gelesen). Es scheint mir, dass Ihr Experten euch nicht ganz einig sind, ist das so ? mfg Anton |
AW: Eigene Ereignisse auslösen
Zitat:
Delphi-Quellcode:
Der Trick hierbei ist es, die möglichen zeitlichen Überschneidungen so gering wie nur möglich zu halten. Da die Daten aber zunächst in eine lokale Variable geschrieben werden reduziert sich die Überschneidung auf das Auslesen/Setzen des Record-Inhalts und ist daher sehr kurz.
type
TMyClass = class( TThread ) private FCS : TCriticalSection; FStatus : TCNCStatus; procedure SetStatus( const Value : TCNCStatus ); function GetStatus : TCNCStatus; protected procedure Execute; override; public property Status : TCNCStatus read GetStatus; end; procedure TMyClass.Execute; var LStatus : TCNCStatus; begin inherited; while not Terminated do begin // Warten auf ein Empfangs-Signal // Irgendwie den Status empfangen LStatus := ... // öffentlichen Status setzen SetStatus( LStatus ); end; end; procedure TMyClass.SetStatus( const Value : TCNCStatus ); begin FCS.Enter; try FStatus := Value; finally FCS.Leave; end; end; function TMyClass.GetStatus : TCNCStatus; begin FCS.Enter; try Result := FStatus; finally FCS.Leave; end; end; |
AW: Eigene Ereignisse auslösen
Zitat:
Zitat:
Ich empfehle serielle Datenpakete zu verwenden. AsyncPro bietet das kostenlos. Stichwort Songbeamer |
AW: Eigene Ereignisse auslösen
Zitat:
|
AW: Eigene Ereignisse auslösen
Reden wir aneinander vorbei? Den Setter kann man nicht umgehen, es handelt sich doch um eine globale Version des Records. Oder wird die komplette Record-Variable überschrieben?
|
AW: Eigene Ereignisse auslösen
Zitat:
Delphi-Quellcode:
machen wie du möchtest, sie werden trotzdem ohne den Setter zu benutzen geändert.
strict private
|
AW: Eigene Ereignisse auslösen
Ja aber an irgendeiner Stelle muss ja der Record belegt werden, ob jetzt dann oder davor. In dem Moment fliegt dann das Event.
Delphi-Quellcode:
Aber das hilft jetzt glaube ich nicht wirklich dem Suchenden
TMyRec = record
strict private FNichtBeschreibbar: Boolean; procedure SetNichtBeschreibbar(const Value: Boolean); public property NichtBeschreibbar : Boolean read FNichtBeschreibbar write SetNichtBeschreibbar; end; var Form1: TForm1; implementation {$R *.dfm} { bla } procedure TMyRec.SetNichtBeschreibbar(const Value: Boolean); begin FNichtBeschreibbar := Value; end; procedure TForm1.FormCreate(Sender: TObject); var MyRec : TMyRec; MyRec2 : TMyRec; begin MyRec.NichtBeschreibbar := True; MyRec2.NichtBeschreibbar := False; // dann halt hier MyRec := MyRec2; // und nicht hier end; |
AW: Eigene Ereignisse auslösen
Hallo Sir Rufo
Danke für Dein Vorschlag, etwas ist mir nicht ganz klar. Zitat:
(// Warten auf ein Empfangs-Signal resp. // Irgendwie den Status empfangen) Nur taucht da ein anderes Problem auf. Von der CNC kommt nicht nur Status, sondern auch andere Meldungen mit unterschiedliche länge, die müssen dann in den etsprechenden Records gespeichert werden (für spätere Anzeige) wobei dies natürlich auch im Hintergund soll ablaufen. Die Reihenfolge der Meldungen ist beliebig ! Gruss Anton |
AW: Eigene Ereignisse auslösen
Zitat:
|
AW: Eigene Ereignisse auslösen
akurka, poste doch mal bitte wo du den Record befüllst, wenn das möglich ist.
Ich empfehle dir nochmals (weil es eine wirklich durchdachte Implementation ist) einen Blick in die AsyncPro Bibliothek zu werfen (speziell Datapackages). Es gibt auch eine gute Dokumentation dazu. |
AW: Eigene Ereignisse auslösen
Zitat:
Wenn du dem Record einen Event spendierst und dann den Record aus einem Stream lädst, dann ist auch die Zuweisung für den Event entweder leer (im besten Fall) oder der Event zeigt irgendwo ins Nirwana und die Hütte fliegt dir um die Ohren. Betrachte einen Record so, wie du einen einfachen Typen wie z.B. ![]() |
AW: Eigene Ereignisse auslösen
@akurka
Im OOP-Geschäft muss man etwas abstrakter denken (damit das auch Sinn macht und das Leben vereinfacht). z.B. Die Komponente für den Com-Port sorgt für den Datenaustausch (Protokoll) und nicht mehr. Sie weiß, wie groß die Pakete sind (ist Bestandteil des Protokolls) und übergibt diese Pakete an eine weitere Instanz, die weiß, wie man aus diesen Paketen (eine Handvoll Bytes) sinnvolle Strukturen erzeugt. Etwas Ähnliches (mit Klassen) gibt es hier ![]()
Delphi-Quellcode:
In die andere Richtung geht es genauso (nur umgekehrt).
unit BaseDataFactory;
interface uses System.Generics.Collections, System.Classes, System.SysUtils, BaseData; type TBaseDataClass = class of TBaseData; TBaseDataFactory = class private class var _Types : TDictionary<Byte, TBaseDataClass>; protected class constructor Create; class destructor Destroy; public class function CreateFromStream( AStream : TStream ) : TBaseData; class procedure RegisterType( AType : Byte; AClass : TBaseDataClass ); end; implementation { TBaseDataFactory } class constructor TBaseDataFactory.Create; begin _Types := TDictionary<Byte, TBaseDataClass>.Create; end; class function TBaseDataFactory.CreateFromStream( AStream : TStream ) : TBaseData; var LType : Byte; LSize : Byte; LData : TBytes; LClass : TBaseDataClass; begin AStream.Read( LType, SizeOf( LType ) ); AStream.Read( LSize, SizeOf( LSize ) ); SetLength( LData, LSize ); AStream.Read( LData, LSize ); LClass := _Types[LType]; // Bei einem unbekannten Typen wird hier eine Exception geworfen Result := LClass.Create( LData ); end; class destructor TBaseDataFactory.Destroy; begin _Types.Free; end; class procedure TBaseDataFactory.RegisterType( AType : Byte; AClass : TBaseDataClass ); begin _Types.AddOrSetValue( AType, AClass ); end; end. Einer weiß, wie man aus einer Informationsstruktur (z.B. ein Record) eine Byte-Folge machen kann, übergibt diese Byte-Folge an jemand anderes, der Byte-Folgen versenden kann, der wiederum weiß, dass das über den Com-Port erfolgen muss. |
AW: Eigene Ereignisse auslösen
Okay vielleicht fällt es mir auch nur zu schwer, mich da in etwas hineinzudenken was ich nicht sehe :) In dem was du sagst stimme ich zu.
akurka, schau einmal hier in den Guide. In der Sektion Datapackages. ![]() Diese Bibliothek ist so mächtig das der serielle Stream vor ihr erzittert :] |
AW: Eigene Ereignisse auslösen
Betrachten wir das doch mal ganz abstrakt aus der Sicht der Anwendung:
Es gibt da so einige Daten-Pakete, die empfangen und gesendet werden können. Mehr interessiert die Anwendung an diesem Punkt nicht. Wann und warum ist egal. Wenn, dann muss die Anwendung reagieren und wenn die Anwendung etwas senden will, dann muss das auch einfach passieren. Wie das passiert, ist der Anwendung an diesem Punkt auch egal. Damit kann man jetzt eine abstrakte Klasse definieren, die diese Anforderungen (Senden von Daten und Events beim Empfang von Daten) erfüllt.
Delphi-Quellcode:
type
TCNC_Data1 = record ... end; TCNC_Data2 = record ... end; TCNC_Command1 = record ... end; TCNC_Command2 = record ... end; TCNC_Data1_Event = procedure ( Sender : TObject; Value : TCNC_Data1 ) of object; TCNC_Data2_Event = procedure ( Sender : TObject; Value : TCNC_Data2 ) of object; TAbstractCNC_Talker = class abstract private FOnReceiveData1 : TCNC_Data1_Event; FOnReceiveData2 : TCMC_Data2_Event; public procedure Send( Value : TCNC_Command1 ); overload; virtual; abstract; procedure Send( Value : TCNC_Command2 ); overload; virtual; abstract; property OnReceiveData1 : TCNC_Data1_Event read FOnReceiveData1 write FOnReceiveData1; property OnReceiveData2 : TCNC_Data2_Event read FOnReceiveData2 write FOnReceiveData2; end; |
AW: Eigene Ereignisse auslösen
In diesem Zuge wäre es auch interessant zu wissen, was exakt über die serielle Schnittstelle hineinkommt und welche Records (Struktur/Inhalt) dabei rauskommen sollen. Das gleiche auch für den umgekehrten Fall (die Anwendung sendet).
Daraus kann man sich dann auch sehr schön Test-Szenarios bauen, wo man den Com-Port durch etwas ersetzt, was diese Daten liefert/entgegennimmt und dann schaut, ob das Erwartete auch am anderen Ende herauskommt. Dann spart man sich den Aufbau einer kompletten CNC-Maschine mit Com-Anschluss :) |
AW: Eigene Ereignisse auslösen
Liste der Anhänge anzeigen (Anzahl: 2)
Hallo
Vielen Dank für Euere Bemühungen aber meine Verwirrung ist jetzt definitiv komplett. Ich glaube am besten statt tropfenweise Informationen, sende ich zugleich die Beschreibung der gesammte Programmstruktur wie es jetzt im altem Pascal Programm ablauft. Siehe Beilage(Globale Variablen :NC__09= hier sollen die div.Meldungen von der CNC gespeichert, CNC_PC_comm.txt = Gesamtbeschreib der Kommunikation CNC zu PC). Mein Ziel ist das ganze in Delphi zu portieren. Was nicht geändert werden kann sind die Meldungen von der CNC (ist zwahr auch von mir(grosste Teil VHDL) aber das möchte ich lieber nicht anfassen). Ich habe einige der Async Pakete angeschaut und u.a das ProfAsync, damit auch einige Testprogramme gemacht. Jetzt bin anfänglich bei der Version 7 aber immer noch nicht brauchbars. Ich wäre froh, wenn eine von Euch Experten mir ein Vorschlag macht für das Gesamtkonzept, weil ich langsamm überzeugt bin das es an dem mangelt. Gruss Anton |
AW: Eigene Ereignisse auslösen
Zitat:
Ich würde ja mal vermuten, dass da ein Header (wie groß?) kommt und danach die Daten, oder wie erkennst du, was für Daten du gerade bekommst? |
AW: Eigene Ereignisse auslösen
Hallo ,
Noch ein Zusatz : Das ZBETR im Status Meldung (Record Status) entscheidet darüber in welchem Menü man sich befindet (es hat 16 mögliche Betriebswahl stellungen). Bei der Aenderung von ZBETR soll möglist schnell in ein anderes Menü gewechselt werden. Darum meine Frage wegen eigene Ereignisse. Gruss Anton |
AW: Eigene Ereignisse auslösen
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo Sir Rufo,
So kompliziert ist es nicht : im erste Byte (MldgTyp) wird definiert, um was für Meldung es sich handelt (ist eine Nummer). Diese entscheidet darüber, wie lang die Meldung sein wird. Siehe getblk, Putblk, Hauptprogr. Diese Meldungen werden in verschiedenen Records gespeichert und sollen aus allen Menüs zugreiffbar sein (Global var) In der Beilage eine kurze Beschreibung der Empfangs/Sende proceduren. Gruss Anton |
AW: Eigene Ereignisse auslösen
Also noch mal etwas ausführlicher, gerne morgen auch mit Codebeispiel.
1. Die Async-Pro Bibliothek bietet dir die Klasse TComport und TDatapacket (der Rest aus der Bibliothek ist für dieses Projekt nicht nötig). 2. Du kannst zur Designzeit ein TComport und ein TDatapacket auf das leere Formular eines neuen Projektes ziehen. Das TComport Objekt mit den nötigen Werten, die vereinbart sind, belegen. Dem TDatapacket sein Comport zuweisen. 3. Das TDatapacket schnappen, dort deine Start und End Kondition angeben (Das ist meist der einzig kniffelige Teil, je nach dem wie gut das Protokoll ist). Wenn du aber eine Start-Kondition hast, hast du schon mal das Glück das du durch deine Struktur genau sagen kannst wie viele Byte-Daten du erwartest. Es wäre also möglich das Packet Ende durch die Package-Size zu bestimmen. Damit wäre dem erkennen des Paketes im seriellen Stream genüge getan. Das TDatapacket könne also als Variablenname z.B. heißen wie dein Record + Datapacket. 4. Das OnPacket des TDatapacket belegen und dort auf die richtige Oberfläche wechseln. Ich rate dir an dieser Stelle von Sir Rufos (wie immer sehr wertvollen Beiträgen) ab, empfehle dir weiterhin, eine sehr gut durchdachte und fertige Bibliothek zu nehmen. Auch wenn es sicherlich für die Programmierpraxis und den Weg deutlich besser wäre, Sir Rufos Ansatz zu verfolgen. Das was ich beschrieben habe, kann man sich in 30 min zusammenklicken. Gruß |
AW: Eigene Ereignisse auslösen
Hallo Jonas,
vielen Dank für Deine Empfehlung. Habe zuerst mal die Bibliothek & Guide downloaded. Die Doku ist sehr umfangreich, nun will ich mir zuerst ein Ueberblick veschaffen. Heute mache ich sowieso nicht viel ( ist mein Trainingstag in der Kletterhalle). Ich bin gespannt auf Dein Codebeispiel. Es ist so, dass die Kommunikation über RS232 bei dem CNC-Bedienprogramm ein Schlüsselelement ist. Darf ich annehmen, dass mittels AsyncPro sich die Meldungs Records im Hintergrund abfüllen lassen,unabhhängig von uebrigem Programm ? Das jeweils aktuelle Menü soll nur erfahren das eine neue Meldung(z.Bsp Istwert u.a.) vorhanden ist und dann anzeigen. So stelle ich es mir vor. Bis jetzt hat man das mittels Vergleich alt/neu gemacht, ich denke mit dem AsycPro lässt sich das aber eleganter lösen oder ? Was das bestehende Pascal Programm macht ( den ich umschreiben will) ist ersichtlich in der Bedienungsanleitung, siehe : ![]() Gruss Anton |
AW: Eigene Ereignisse auslösen
Liste der Anhänge anzeigen (Anzahl: 1)
Okay also hast du die Komponenten schon installiert?
Der Rest ist soweit richtig. Hier das Beispiel. Anhang 41263 Bei Fragen, gerne.:-D |
AW: Eigene Ereignisse auslösen
Hallo Jonas,
Vielen Dank für den Code Beispiel. Etschuldige, dass ich mich so lange nicht gemeldet habe. Im moment habe ich ein Problem mit FPGA(VHDL) der schnellstens gelöst sein muss. Beim ersten Durchsicht vom AsycProf suchte ich vergebens nach "onCts" Event. Den brauche ich um nachfolgend den ersten Byte einzulesen, weil dort die Information ist wie lang die gesamte Meldung ist. Folgende Problem: Zitat:
Dann geht es so nicht, ich muss von überall die Daten der Meldungen Vergleichen / resp. Anzeigen. Ein Event brauche ich nur für den einzigen Fall, nämlich wenn sich der Status.ZBETR ändert. Die Daten aus anderen Meldungen müssen nur im Hintergrund empfangen werden und für die momentan aktive Form.. zugänglich sein.Natürlich muss ich wissen ob sich die Daten geändert haben, aber das wird bereits in den jeweiligen Units bereits getan. Ich habe eine generelle Frage: Die bisherige Programm Modulle arbeiten alle nach dem Prinzip: repeat... //Hier werden die empfangene Meldungen Angezeigt.. // verglichen mit div. Konstanten und fals eine Eingabe // erfolgt, diese als Meldung über RS232 an den CNC zu //senden. until Status.BETR = StatusAlt.Betr. Es ist mir klar, dass dies dem Windows Konzept wiederspricht. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz