OnChangeValue ?

[TiGü]

Zitat von akurka:

Wird es punkto Rechenzeit überhaupt etwas bringen mit dem setter, wenn ich den Wert der Variable pollen muss ??
Gruss Anton

Eigentlich nicht, denn dein Hauptproblem ist ja nicht das Aktualisieren des Formulars.
Da scheinst du ja mit den Vergleich von Alt- zu Neuwert nur zu erneuern, wenn du es musst.

Das Pollen scheint dein eigentliches Problem zu sein.
Hier wären mal konkrete Zahlenwerte gefragt.

Verbraucht dein Abfragethread ungewöhnlich viel CPU-Arbeit im Task-Manager?
Wenn ja, wieviel Prozent?

Wie oft pollst du denn? Mit welcher Frequenz oder im welchen Intervall?
Wenn du das nicht beantworten kannst, dann hast du einen Abfragethread, der stumpf im Execute die serielle Schnittstelle ausliest.
Dann erklärt sich der Ressourcenhunger.

[akurka]

Hallo Mavarik
Entschuldige die späte Antwort. Ich musste nach den ersten Antworten
schnell weg.
Du hast es richtig angesprochen, woher soll der Event kommen ?

Leider bringt es nichts auf Empfang der Meldungen vom RS232 zu triggern.

Der Grund ist, dass es z.Bsp mehrere Status oder Istwert Meldungen die genau gleich sind, also müssen gar nicht berücksichtigt werden.

Du kanst Dir das so vorstellen wenn z.Bsp die CNC Achsen gar nicht in
Bewegung sind wird im Prinzip immmer der gleiche Istwert öbermittelt.
Ab un zu mal bedingt durch Regelung gibt es ein Unterschied +/-1 um
dies aber u.U.in Abständen von Sekunden. Die Status-, Istwert-, Endlage- usw. werden aber in Abständen von ca. 50 - 100 mS empfangen.Es gibt also ganze menge Meldungen die nicht relevant sind.

Auf der andere Seite gibt es Situationen wo eine sehr schnelle Reaktion notwendig ist, darum die relativ kurzen Zeitabstände.

Die jetztige Polling Rate bei 4 Achsen ist ca. 50 mS, es ist ein Kompromiss.

Wenn man eine Taste drückt hat man die Methode OnKeyPress, ohne das
man die Taste ständig abtasten muss.
So etwas stelle ich mir vor aber für die Aenderung einer Variable.

Soviel ich weiss werden die Tastaur-Nachrichten im Supervisor Modus des uP's abgearbeitet, und damit sind auch die Windows Message verfügbar.

Ob so etwas auch für Memory ànderungen gibt entzieht sich meiner Kenntnis.

Vermutlich ist das bestehende, zugegeben etwas holprige Lösung
gleich das optimale.
Aber ich will es genau abklären ob es der Wahrheit letzter Schluss Schluss ist.
Gruss Anton

[noisy_master]

Ich mische mich jetzt auch mal kurz ein:
das mit dem OnKeyPress ist recht einfach zu erklären:
Wenn du eine Taste drückst generiert deine Tastatur einen Interrupt. Dieser wird von diversen Treibern "aufgefangen" und dann als Windows Message versendet...und auf dies Message reagieren dann halt entsprechende Komponenten.

Ist aber eine gaaannnzz doll abstahierte Darstellung.

Wenn du nun deine CNC dazu bringen könntest Nachrichten über die RS232 nur dann zu senden, wenn sich auch was geändert hat hättest du auch ein "event" auf das du reagieren könntest.
Ansonsten bleibt dir halt nur übrig die Infos von der CNC "kontinuierlich" auszulesen und das ist dann halt Polling....

[akurka]

Hallo Dirk
Danke, jetzt ist mir klar, dass ich kein OnChangeValue machen kann.
Bei der CNC wird es schwierig, resp. mit sehr grossem Aufwand verbunden (FPGA Aenderungen).

Aber vielleicht im Empfangs Thread für den COM Port nach jedem MeldungsEmpfang ein Vergleich zu machen und damit den Event auszulösen.
Während dem ein Byte empfangen wird kann man den vorherigen testen.
Mal versuchen.

Das Polling später im Programm tut u.a. auch der Empfang über den COM Port behindern, das habe ich bereits festgestellt wenn ich die Baudrate erhöht habe.

Besten Dank für den Tipp.
Anton

[Perlsau]

Ich verstehe noch immer nicht, wo das Problem sein soll. Was ich bisher, nachdem nun weitere Informationen vorliegen, verstanden habe:

1. Eine CNC-Maschine sendet bei Änderung eines ihrer Parameter einen Bytecode an die serielle Schnittstelle.
2. Ein eigenständiger Thread pollt diesen Input im Millisekunden-Abstand.
3. Weicht der eingegangene Byetcode vom voherigen ab, soll ein Ereignis ausgelöst werden.

Hier muß man sich doch einfach nur den eingegangenen Bytecode merken und mit dem aktuellen vergleichen. Weist der neue Bytecode Unterschiede zum gespeicherten Bytecode auf, wird der neue Bytecode gespeichert und danach ein Ereignis ausgelöst, auf das eine Methode in der aufrufenden Unit oder Form reagiert. Da der gemerkte Bytecode außerhalb des pollenden Threads nicht verändert wird, ist auch keine Synchronisation notwendig.

Nachtrag: Es gibt doch diese AsyncPro-Komponente, mit der man, soweit ich informiert bin, alles handeln kann, was mit seriellen Schnittstellen zusammenhängt. Ich bin mir sicher, daß diese Komponentensammlung auch die Möglichgkeit beinhaltet, einen Com-Port zu überwachen und bei gewissen Änderungen ein Ereignis auszulösen:
The TApdComPort is designed to interface with a standard RS-232 or RS-485 serial port via the Windows communication drivers. (Quelle: DevGuide, S. 11)

Triggers and trigger handlers

Async Professional uses the term "trigger" for any serial port action that can cause its communications dispatcher to generate a VCL event. There are four types of triggers:

• Data available – received data ist available
• Data match trigger – a particular character or character string was received.
• Status trigger – a status event occured
• Time trigger – a timer expired.

Quelle: Reference Guide, Seite 22

[Mavarik]

Zitat von akurka:

Leider bringt es nichts auf Empfang der Meldungen vom RS232 zu triggern.

Selbstverständlich... Du scheinst etwas wirre Vorstellungen zu haben... Event vom Memory usw... alles Quark!

Die Kommunikation mit der CNC-Maschine läuft über die RS-232 Schnittstelle. PUNKT.

Also muss man die eingehenden Daten - je nach Baudrate - mit für heutige Rechner wenig CPU Last - SOWIESO einlesen...

Das ist der einzige Kommunikations-Kanal hier werden dann die Datenpakete auseinander genommen... Wenn dann eine Änderungen eintritt, die für die Software relevant ist, sendet der RS-232 Treiber eine Windows-Message. Bingo damit hast Du Deinen Event-Trigger... Ohne zu pollen!

[Perlsau]

Genau so

[akurka]

Hallo mitenand,

mit der AsyncPro rennt Ihr offene Türe ein, ich verwende es bereits.
Dirk hat schon recht, dass ich falsche Vorstellung von
den OnChange... Methoden hatte.
Ja nun man lernt nie aus.
Besten Dank für die Unterstützung von Euch allen.

Gruss Anton

[Perlsau]

Zitat von akurka:

Hallo mitenand, mit der AsyncPro rennt Ihr offene Türe ein, ich verwende es bereits.

Das "Ihr" ist unzutreffend, denn der Vorschlag kam bislang allein von mir. Und ich bin weder adelig noch mehrere ...

Wenn du AsyncPro bereits verwendest, dann werden da auch Ereignisse ausgelöst, wenn am Comport ein Signal eintrifft. Wieso verwendest du das nicht so, wie es in den Manuals steht? Leider kann ich nichts weiter dazu sagen, da du uns bislang verschwiegen hast, daß du AsyncPro einsetzt, und somit auch kein Code vorliegt, der zeigt, wie du das anwendest.

Vermutlich wäre es das Beste, du würdest erstmal das Handbuch zu AsyncPro studieren, bevor du eine Komponente aus dieser Sammlung verwendest.

[akurka]

Hallo Perlsau
Entschuldige, war falsch,ich habe schon Dich gemeint-
Ich habe das AsyncPro darum nicht erwähnt weil ist es im Form1 verwende und zwar in einem
Thread der die Empfangene Meldungen direkt in Globale Variable abspeichert.

Da gibt es in Abständen von 50mS z.Bsp Status.CNC Meldungen und es kommen bis zu 10 Meldungen die genau gleich sind.
Mich interessiert aber nur, wenn sich etwas verändert hat, und so bin ich auf die doofe Idee gekommen es wäre nett eine OnChangeValue Erreigniss zu haben.

Ja nu manchmal hat man ein Brett vor dem Kopf, vor allem wenn man allein arbeitet und
mit niemandem die doofe Ideen diskutieren kann.

Mir jetzt auch klar das es am besten ist, die Meldungen im EmpfangsThread auf Gleichheit
zu testen. Für gar nichts ist das Exploit doch nicht gewesen, ich habe etwas mehr gelernt
über OOP.

Vielen Dank für Deine Erklärungen betr.setter und nicht zu ungut.
Heute schneit es wie verrückt im Engadin, so habe jede menge Zeit den EmpfangsThread
zu ändern.

Wenn es dich Interessiert für was das ganze ist :
http://www.antonkurka.ch/KurkaAGSeiten/Kurka_AG.htm

An dem Delphi Programm bin ich mit unterbrüchen schon fast zwei Jahren dran.
Da die Hardware jetzt endlich richtig funktioniert, kann ich mich jetzt voll mit
der Bedienungs Software (Delphi) beschäftigen.

Ubrigens habe ich mir erlaubt Dein Profil anzuschauen,sehr interessant Dein Werdegang.
Du hast die ganze Entwicklung praktisch von Anfang an miterlebt.

Gruss Anton