Eigene Ereignisse auslösen

[Sir Rufo]

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;

[Sir Rufo]

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 :)

[akurka]

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

[Sir Rufo]

Zitat:

Zitat von akurka (Beitrag 1260305)

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).

Es fehlt eigentlich die Beschreibung, was wirklich über die Com-Schnittstelle ankommt.
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?

[akurka]

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

[akurka]

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

[Jonas Shinaniganz]

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ß

[akurka]

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 :
http://www.antonkurka.ch/KurkaAGSeiten/Kurka_AG.htm => Bedienungsnleitung

Gruss Anton

[Jonas Shinaniganz]

Okay also hast du die Komponenten schon installiert?
Der Rest ist soweit richtig.

Hier das Beispiel. Anhang 41263

Bei Fragen, gerne.:-D

[akurka]

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:

Form1 : TForm1;
// Dein Globaler Datensatz. Dein Design solltest du ändern, damit der Datensatz nicht mehr gobal ist.
// Hier könnte man den Datensatz auch einfach in die Klasse TForm verschieben
GloDatensatz : TDatensatz;

Ist es so zu verstehen, dass ich aus anderen Units(Form1,2..X) gar kein Zugriff habe auf die Meldungs Daten ?
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.