[EibParser] In der Tiefe: Validierungskonzept

[enertegus]

Wie angekündigt, für alle die Spass an der Erkundung der innersten Vorgänge im EibPC haben.
Ich hoffe es wird etwas verständlicher, und für alle die hier lesen und denken "Bahnhof", "Ägypten" etc. sei es ein Trost: Das braucht man nur, wenn man richtig tief in die Programmierung einsteigen will. Morgen gibt es dafür ein paar weitere einfache Dinge, ja und sogar Lehrvideos auf Youtube mit der Steffi...

Aber hier zum Thema Validierung.

Lob in den Danke-Thread, Tadel einfach runterschlucken

EDIT: Noch ein paar Änderungen. Langsam wird's was...

[enertegus]

Wie angekündigt, für alle die Spass an der Erkundung der innersten Vorgänge im EibPC haben.

Es sind noch Tippfehler drinne

[saft6luck]

Nun ja, Lob ist evtl. ein wenig zu viel gesagt: Danke für den Einblick!

Zum Thema Kritik bleibe ich natürlich bei der konstruktiven

Nur schnell 'reingehackt':

- Generell glaube ich nicht, dass ein 'gewöhnliches', 'interaktives' Programm anders abläuft, als die Programmausführung im eibPC: in einer Endlosschleife wird auf Signale des Benutzers gewartet und dann ein Programmteil ausgeführt ... und wieder gewartet. Verstehe daher den Sinn dieser Aussage nicht. Der Profi wundert sich eher über die Vorstellungen des Autors.
- Eine parallele Ausführung der Prozesse bzw. Anweisungen trifft evtl. im FPGA zu, wenn im eibPC jedoch keiner verbaut ist, wird wohl sicherlich alles sequenziell abgearbeitet. Also entweder Hinweis auf besondere HW oder streichen.
- Nocheinmal: Multithreading hat nichts mit 'Ausführung in einem Zyklus' zu tun.
- Verständlichkeit: Setzt bei mir aus, wenn man Befehle aus anderen Programmiersprachen verwendet, den Sinn ähnlich wählt und dann in einen SPS-Kontext setzt, der dann als einfacher dargestellt wird.
- Variablen definieren heißt Deklaration, entweder explizit oder implizit, im eibPC wohl explizit.
- Beispiel Variablen erweitern: Wenn y sich also nur ändert, wenn sich der Wert ändert, wie kann ich dann y immer updaten, auch wenn sich der Wert nicht ändert? Beispiel: mehrfaches Empfangen eines Triggertelegrammes.
- Womit wird die "optimale Performance" belegt? Wenn ein Telegramm nur alle 40 ms eintrifft und der eibPC für die Abarbeitung aller Abhängigkeiten nur einen Zyklus benötigt, wartet er immer mind. 39 ms?
- Funktionen zur Verarbeitung: Funktionen werden abhängig von der Funktion und/oder dem Argument ausgewertet (siehe z.B. stime(32), Argument ändert sich nicht, Funktion wird aber mehrfach ausgewertet). Wie passt das ins Schema?
- Funktionen zur Ausgabe: Wenn man in der Hauptebene nur Deklarationen (optimaler weise mit einem speziellen Kommando, wie z.B. Set a=0b1), Zuweisungen und if zulassen würde, bräuchte man sich den Kopf nicht so verrenken.
- Das if verhält sich wie eine Funktion, auch wenn der Wert des Arguments sich nicht ändert?! Warum dieser Hinweis? Ist es relevant, dann bitte Beispiel.
- 1. Beispiel Verschachtelung von if-Anweisungen: Fehler? if ist unabhängig von a. Erklärung scheint so fehlerhaft.
- "'1/2/3'b01 wird zwar bei jedem Telegramm „invalid“, reicht aber dieses Signal nicht an die if-Anweisung weiter, wenn das eintreffende Telegramm (auf dieser Gruppenadresse) den gleichen Wert hat wie das letzte." scheint inkonsequent: Das Signal muss doch EIN sein und sich geändert haben. Ist change() gemeint?
- 2. Beispiel: Sollte auf jeden Fall auch im normalen Teil des Handbuches beschrieben sein - kommt das noch? Zusammenhang hier?
- Beispiel Verschachteln von if: Wieso baut der Compiler das Konstrukt um und wie sieht es dann aus? Text insgesamt überladen und unverständlich, schlechte Struktur und somit erst nach mehrmaligem Lesen annähernd zu verstehen. Wieso wird zur Beschreibung der Problematik nun ein weiteres Beispiel angeführt, ohne das bisherige zu erläutern, wobei dessen Beschreibung wieder verständlich aber umständlich ist?
- Geändertes Beispiel: Was bedeutet "Beim nächsten (und allen weiteren) wird diese ausgeführt." in diesem Zusammenhang?
- Bitte beim letzten Beispiel explizit darauf eingehen, warum bei systemstart() das if die Befehle im then Zweig invalidiert, wenn systemstart() doch 0b1 wird. Was würde ein else Zweig hier machen?

Insgesamt wird zu wenig auf die problematischen, fehlerträchtigen Fälle eingegangen.

[enertegus]

Der Profi wundert sich eher über die Vorstellungen des Autors.

So,So..

- Eine parallele Ausführung der Prozesse bzw. Anweisungen trifft evtl. im FPGA

Es wird sich auf die Ausführung innerhalb des Zyklusses bezogen.

- Nocheinmal: Multithreading hat nichts mit 'Ausführung in einem Zyklus' zu tun.

Das ist richtig: Gemeint ist, dass alle Aufgaben parallel ausgeführt werden und zudem (das ist wohl die Kritik) innerhalb der Zeitscheibe.

- Womit wird die "optimale Performance" belegt?

Nun ich wollte nicht den FW-Code und unsere internen Dinge allzusehr ausbreiten. Entweder Du glaubst mir dies einfach (ich denke es ist nachvollziehbar) oder Du lässt es bleiben.

- Funktionen zur Verarbeitung: Funktionen werden abhängig von der Funktion und/oder dem Argument ausgewertet (siehe z.B. stime(32), Argument ändert sich nicht, Funktion wird aber mehrfach ausgewertet). Wie passt das ins Schema?

Das wäre eine Erweiterung Wert: Zeitfunktionen werden von einem gesondertem Scheduler invaldiert.

- Bitte beim letzten Beispiel explizit darauf eingehen, warum bei systemstart() das if die Befehle im then Zweig invalidiert, wenn systemstart() doch 0b1 wird. Was würde ein else Zweig hier machen
Insgesamt wird zu wenig auf die problematischen, fehlerträchtigen Fälle eingegangen.

Wie gesagt, ich wollte einen Einblick geben. Dir trau ich es zu, dass Du es verstehst.

[makki]

@energetus: nach dem lesen dieses versteh ich auch das von gestern besser

Makki

[saft6luck]

Es wird sich auf die Ausführung innerhalb des Zyklusses bezogen.
[...]
Das ist richtig: Gemeint ist, dass alle Aufgaben parallel ausgeführt werden und zudem (das ist wohl die Kritik) innerhalb der Zeitscheibe.

Es geht um den Sinn dieser Aussage, der mir eher zur Verwirrung dient, als zur Erklärung, denn diese ist falsch. Der Code wird sequenziell ausgeführt. Niemand braucht sich Gedanken darüber machen, welche Anweisung schneller Ausgeführt wird, als die andere. Vielmehr ist es wichtig, welche Anweisung vor/nach einer anderen Anweisung ausgeführt wird. Es gibt eine Reihenfolge (siehe auch die 2 Beispiele am Ende der Erläuterungen). Also sollt eher auf die Ausführungsreihenfolge eingegangen werden.

Nun ich wollte nicht den FW-Code und unsere internen Dinge allzusehr ausbreiten. Entweder Du glaubst mir dies einfach (ich denke es ist nachvollziehbar) oder Du lässt es bleiben.

Gut, ich steck es in die Schublade "Überzeugt mich nicht."

Wie gesagt, ich wollte einen Einblick geben. Dir trau ich es zu, dass Du es verstehst.

Es geht bestimmt nicht um mich. Es war lediglich eine Redigierung deines Textes. Wenn du glaubst, der Text sei so der gewollte "Einblick" kann ich nur sagen: Ich erwarte mir nicht nur einen Einblick, sondern eine verständliche Anleitung. Momentan lässt sie wesentliche Fragen offen.

[enertegus]

. Der Code wird sequenziell ausgeführt.

Das trifft aber auch für multithreading Systeme zu, welche nur 1 CPU haben. Innerhalb einer Zeitunschärfe eben nicht.

Es gibt eine Reihenfolge (siehe auch die 2 Beispiele am Ende der Erläuterungen). Also sollt eher auf die Ausführungsreihenfolge eingegangen werden.

Was ja auch geschehen ist.

Es war lediglich eine Redigierung deines Textes. Wenn du glaubst, der Text sei so der gewollte "Einblick" kann ich nur sagen: Ich erwarte mir nicht nur einen Einblick, sondern eine verständliche Anleitung. Momentan lässt sie wesentliche Fragen offen.

Für die Anregungen bin ich ja grundsätzlich dankbar - und habe ja schon nachgelegt. Was ist da nun noch unklar?

[enertegus]

@energetus: nach dem lesen dieses versteh ich auch das von gestern besser

seufz.

[Uwe!]

Alles in allem: Sehr gut und hilfreich! Und für die gedachte Zielgruppe glaube ich genau richtig geschrieben.

Ein paar Fehler und Fragen hab ich aber:


S.112:
vor

tan(2.0f32)

fehlt eine Variable

o=stime(32)

steht schon im 1. Beispiel, wird aber erst weiter unten erklärt

Die zweite Anweisung würde sonst im Zyklustakt des Enertex® EibPC den Bus beschreiben.

warum nur die Zweite, die erste doch auch?

'1/2/3'b01 wird zwar bei jedem Telegramm „invalid“, reicht aber dieses Signal nicht an die if-Anweisung weiter, wenn das eintreffende Telegramm (auf dieser Gruppenadresse) den gleichen Wert hat wie das letzte.

widerspricht sich für mch mit der Aussage

Dabei wird y im übrigen nur dann ungültig, wenn sich der Wert der Gruppenadresse tatsächlich geändert hat.

S.113:

Zum Beispie, fehlt noch die Erläuterung was passiert

[enertegus]

S.112:
vor fehlt eine Variable

Für den Sinn einer Zuweisung hast Du recht, aber gültige Syntax ist es. Der tan wird berechnet, es wird halt nix damit gemacht.

steht schon im 1. Beispiel, wird aber erst weiter unten erklärt

Ok,pass ich an.

warum nur die Zweite, die erste doch auch?

Richtig - es wird nur nicht der Wert geändert. Ich pass das an..

widerspricht sich für mch mit der Aussage

Das Verhalten von if ist da eben anders. Hier reicht ein invalid der Abfragebedingung aus, ohne dass diese sich ändern muss. Siehe auch
"Wenn die Abfrage -
bedingung ungültig wird, so wird if neu ausgewertet und zwar unabhängig davon, ob sich die Abfragebedingung vom
Wert her ändert."

Irgendwie hab ich da was gelöscht. Muss ich nochmals uploaden...
EDIT: Erledigt...

[saft6luck]

Das trifft aber auch für multithreading Systeme zu, welche nur 1 CPU haben. Innerhalb einer Zeitunschärfe eben nicht.

Was willst du denn mit der Aussage: "alle Anweisungen parallel in einem Zyklus abgearbeitet werden" sagen?

Bist du der Meinung, wenn ich das Zeitfenster nur weit genug aufmache, wird jede Ausführung des Codes zum Multithreading?

Was ja auch geschehen ist.

Sag ich ja, nur warum "parallele Verarbeitung" wenn dann doch nicht?

Für die Anregungen bin ich ja grundsätzlich dankbar - und habe ja schon nachgelegt. Was ist da nun noch unklar?

z.B.
"Die If-Anweisung verhält sich wie eine Funktion, deren Argument die Abfragebedingung darstellt. Wenn die Abfragebedingung ungültig wird, so wird if neu ausgewertet und zwar unabhängig davon, ob sich die Abfragebedingung vom Wert her ändert. Da die Abfragebedingung aber nur invalid werden kann, wenn sich deren Wert ändert, ist de facto eine ungültige Abfragebedingung auch eine veränderte Abfragebedingung."

Da frag ich mich, warum nun das Verhalten von if anders sein soll, wenn am Ende doch wieder nur die Änderung des Wertes der Abfragebedingung relevant ist. Steht evtl. im Zusammenhang mit dem Beispiel über systemstart() und der Aussage, dass der then-Zweig grundsätzlich invalidiert wird, aber Antworten auf meine Fragen gibst du ja nicht und so ist das halt nicht zu verstehen.

Mein Tip ist: Nimm dir mein Posting vor, Zeile für Zeile, vergleich es mit dem Redigierten Text und versuch den Text als Anwender mit gefährlichem Halbwissen zu sein. Was kannst du dann besser beschreiben?

[enertegus]

Bist du der Meinung, wenn ich das Zeitfenster nur weit genug aufmache, wird jeder Ausführung des Codes zum Multithreading?

Sicher (zumindest so wie formuliert).

Da frag ich mich, warum nun das Verhalten von if anders sein soll, wenn am Ende doch wieder nur die Änderung des Wertes der Abfragebedingung relevant ist.

Für die Verschachtelung ist es dann wie erklärt relavant. Aber ich pass das gerne auch nochmal an.

Was kannst du dann besser beschreiben?

Ich finde, es stünde einem gut zu Gesichte, in einem User-Forum wie diesem hier weniger herablassend seine Äußerungen posten.

Am Ende des Tages versuch ich wohl hier die Sache für 10% der Anwender zu erklären (das seh ich aus unseren Supportanfragen). Mir ist dabei jeder Anwender wichtig, ich hoffe das kommt zumindest rüber.

[saft6luck]

Sicher (zumindest so wie formuliert).

Ehrlich gesagt kann ich dir nicht folgen. Multitasking im weitesten Sinne, parallele Ausführung und Multithreading im speziellen haben etwas mit Laufzeit zu tun. Wenn ich Jobs parallel verarbeite, werde ich mir u.a. Gedanken über die Verfügbarkeit der Ergebnisse machen müssen. Wenn der eibPC also parallel verarbeitet, (z.B. ein write() ausführt während er 2 weitere write() ein if und eine Zuweisung bearbeitet), dann muss ich mir als Programmierer Gedanken über die Mechanismen zur Ablaufsteuerung machen müssen, damit nicht das if ausgeführt wird, bevor die Zuweisung abgearbeitet ist. Das ist aber beim eibPC nicht der Fall, oder? Hier wird alles schön sequentiell ausgeführt, jedenfalls sagen das die Beispiele. Eine parallele Ausführung bedeutet bei einem 1CPU Rechner auch nur, dass die einzelnen Berechnungen nicht 'am Stück' sondern auf 'Stückchen verteilt' ausgeführt werden und somit die Ergebnisse abhängig von der Laufzeit der einzelnen Threads verfügbar sind.

Werden z.B. alle write()-Ausgaben in eine Schlange gestellt und diese 'im Hintergrund' auf den Bus geschrieben, könnte man von paralleler Verarbeitung sprechen, nur betrifft das nicht die Abarbeitung der Befehle. Oder meinst du das?

Für die Verschachtelung ist es dann wie erklärt relavant. Aber ich pass das gerne auch nochmal an.

Die Sache mit der Verschachtelung habe ich immer noch nicht verstanden, d.h. ich kann mir keine Regel bilden, nach der ich bei der Programmierung die gewünschte Ausführung leicht verifizieren kann.
Offene Fragen sind:
- wie werden zeitgesteuerte Befehle behandelt, im then und im else Zweig.
- wie funktioniert die Invalidierung im else Zweig
- im Text steht, das das if alle Befehle im then Zweig invalidiert, später im Text wird aber jedes Kommando für sich (noch einmal?) invalidiert.

Ich finde, es stünde einem gut zu Gesichte, in einem User-Forum wie diesem hier weniger herablassend seine Äußerungen posten.

Ich empfinde es als sachlich und direkt mit einem Schuss Sarkasmus. Herablassend sollte es nicht sein. Wenn ich mir die Anzahl deiner Antworten auf konkrete Fragen, Hinweise, Wünsche und Probleme von mir ansehe, sehe ich den Schwarzen Peter aber nicht nur auf meiner Seite. Ich schätze deine Arbeit, auch wenn ich vom Validierungsschema nichts halte, dazu stehe ich. Ich habe über 20 Jahre Programmiererfahrung, u.a. im embedded Bereich mit Assembler, C, LabView, Matlab-Simulink-Stateflow-Targetlink, dSpace Autoboxen, vielen Debuggern, automatisierten Testtools, schon fast vergessenes VHDL und FPGAs, VisualC++ auch auf PDAs, Xcode und iPhone Programmierung und ... und ... und kein SPS, ja! Und noch nie sah etwas so trivial aus und hat solche Probleme bereitet, wie das Validierungschema. Da fand ich etwas Sarkasmus schon angebracht. Aber ich werde mich wohl noch mehr zurückhalten (müssen)!

Am Ende des Tages versuch ich wohl hier die Sache für 10% der Anwender zu erklären (das seh ich aus unseren Supportanfragen). Mir ist dabei jeder Anwender wichtig, ich hoffe das kommt zumindest rüber.

Zu einem Produkt gehört eine Anleitung. Wenn du die 10% der Anwender, die offensichtlich auf die Problematik gestoßen sind, mit einer Anleitung bedienen könntest, könntest du bestimmt viel GuK-Kosten sparen. Sieh es einmal von der Seite.

[IBFS]

@enertegus


Ich denke die Irritationen haben folgende Ursachen:


1.
Wie eine SPS arbeitet, wissen doch eine ganze Menge Leute - Einlesen Prozessabbild - Verabeiten - Ausgeben an das Prozessabbild

2.
Wie bestimmte PC-Applikationen arbeiten wissen auch schon ein ganz paar Leute.

3.
Der EibPC im Zusammenhang mit dem KNX-Bus ist da so ein Mittelding
Der KNX-BUS ist nicht wie bei einem PROFIBUS oder CAN-BUS, der an eine
SPS-angeschlossen ist ein ständig pollender BUS sondern überträgt nur
wenn etwas passiert (Sensor), wenn was geschaltet werden soll oder STATUS-Abragen ausgeführt werden.

Dadurch ist der Zustand des Prozessabbildes im EibPC nach dem Einschalten desselben UNGLEICH des realen Zustandes.

Auch kann man anderes als bei eine SPS den AUSGANG :=1 nicht in
ständig herunterschreiben sondern nur nach Anlauf des EibPC oder
wenn DAS ERSTE MAL ein IF-THEN-KONSTRUT zuschlägt.

DAHER MUSS MANN SICH MERKEN DAS MAN SCHON GESENDET HATTE.
Sonst wird ja der BUS zugemüllt.

Das ist einer der wichtigesten Unterschiede.


Der EibPC ist eine Sonderkonstrukt mit einem Sonder-Validierungsschema, was ihr dafür
erfunden habt. Das könnt in voller Perfektion nur ihr verstehen.

Das ist so als würde jemand noch nie was von einer SPS gehört haben und muss sich erst
das Verständnis erarbeiten. Da mußt du schon Geduld haben. schließlich müssen WIR
Enduser deine Ideen erst einmal verstehen. Der EibPC ist nun mal was eigenes mit eigenen
Regeln und eigenen Konzept. Da mußt du durch enertegus, ob du willst oder nicht.
Nur die Leute die wirklich verstehen was passiert, könnten die EibPC-Kiste richtig ausnutzen.

  
SPS:  
IF Bedingung THEN 
                SETZE Ausgang
                          ELSE
                RESET Ausgang
         ENDIF;

  
EibPC-Variante 1
IF "erste erkannte Zustandsänderung (quasi Flanke)" THEN
                SENDE Ausgang 
                          ELSE
                mache nix
         ENDIF;

  
EibPC-Variante 2
IF "Zustandsabfrage permanent" THEN
                SENDE EINMALIG Ausgang   
                          ELSE
                mache nix
         ENDIF;

Ich habe bewußt nicht die echte EibPC-Notationen verwendet.



Leider empfinden aber viele den EibPC als eine Art SPS und wundern sich,
wenn ich IF-THEN Konstrukten sich nicht einfach so verhalten wie in einer
SPS (was sehr einfach zu verstehen wäre) sondern wenn dann vom
Validierungskonzept die Rede ist usw.

Egal woher man kommt. Von der SPS-Welt oder der PC-Welt.
Er EibPC im Zusammenhang mit den KNX-Bus ist so ein Mittelding,
was man eben mit normalen gewohnten Denkweisen nicht weiterkommt.

Diese Umdenken bei gleichzeitig fast identische Funktionsnamen führt aber
letztendlich zu den andauernden Verwirrungen.

Komplizierte Erklärtungen helfen da nicht weiter, wenn man nicht die gleiche
Sprache spricht.

Was hilft sind eine Vielzahl von geprüften Codefragmenten, die man am
Ende einfach nur verwendet und wo man sich dann über grundsätzlich
Sachen keinen Kopf mehr zu machen braucht.

Aber für mich als SPS-Programmierer viel wichtiger!!!!

Wenn ich als eine Art Variablentabelle unabhängig vom Programmcode
das GEMERKTE Prozessabblid im EibPC sehen könnte, wäre sofort
klar, warum Befehl nicht ausgeführt wird.

ABER

man sieht nicht und weiß nicht den internen gemerkten Zustand im EibPC!
Das ist m.E. das wichtigste "I WANT TO HAVE" für mich.

Es macht keinen Sinn in Logfiles zu suchen, wenn man eine Aktualdaten-Liste, sortiert nach GA im EibPC hätte.

Das wäre das absolute FEATURE was es meines Wissen noch nirgens gibt.

Frank

[IBFS]

Zu einem Produkt gehört eine Anleitung. Wenn du die 10% der Anwender, die offensichtlich auf die Problematik gestoßen sind, mit einer Anleitung bedienen könntest, könntest du bestimmt viel GuK-Kosten sparen. Sieh es einmal von der Seite.

JEDE Religion braucht ihre Anleitung und die Bibel hat auch nicht nur 150 Seiten.
Und wier ich schon schrieb - der EibPC ist eine eigene Steuerungklasse.

Das habt ihr nun davon :-)

Frank