In der Tiefe: Validierungskonzept

[saft6luck]

Genau, gut geschrieben, Uwe! Vielen Dank!

[Uwe!]

gut geschrieben! Danke!

[anlo007]

Wenn man Probleme hat, kann man sich auch Variablen für Zwischenergebnisse definieren und anzeigen lassen. Damit kann man sehr wohl die einzelnen Schritte in einer IF then else Anweisung anzeigen lassen.

Ich finde die Diskussion hier etwas unsinnig, der EibPC ist keine grosse Siemens-Steuerung. Bei einer SPS wie der Siemens werden nur zu jeder Zeit alle vorhandenen Ein- und Ausgänge ausgewertet, was verhältnismäßig einfach und trivial ist, trotzdem benötigt man einige Wochen der Schulung um selbst die kleinsten Ansätze zu programmieren.

Der KNX-Bus hat eine andere Aufbau und versendet Informationen nur gelegendlich bzw. bei Änderungen. Eine Auswertung ist deshalb bedeutend komplizierter.

Wenn Enertex jetzt eine Krücke gefunden hat, damit wir einfachen Häuslebauer damit einfach umgehen können und der EibPC alles das macht, was wir wollen, so ist dies eine große Leistung. Es ist generell einfach, auf mehrfache If Verzweigungen zu verzichten und Verschachtelungen wegzulassen, wenn man mit dem Ergebnis nicht zurechtkommt.

Vielleicht sollte Enertex einfach die Verschaltelung blockieren, damit ihr mit eurer SPS-Erfahrung auch mit dem EibPC umgehen könnt.

Unterm Strich seit ihr 2 die einzigen, die sich Seitenweise darüber aufregen, alle anderen haben offensichtlich keine Probleme damit, darüber solltet ihr mal nachdenken.

[saft6luck]

Fassung des Einblickes vom 17.09.10:

"Ändert man das Beispiel wie folgt:
[highlight=epc]
a=AUS
b=1
c='1/2/3'b01
if change(a) then {
if b==2 then write('1/2/3'b01,EIN) endif
if b==1 then write('1/2/3'b01,AUS);b=2 endif
} endif
[/highlight]
so wird nun bei der ersten Änderung von a die erste innere if-Anweisung ungültig, aber die Abfragebedingung steht
auf 0b01, da ja die Variable b noch auf 1 steht. Die zweite innere if-Anweisung wird aber ausgeführt. Beim nächsten
(und allen weiteren) wird diese ausgeführt."

"Diese" bezieht sich hier auf die "zweite innere if-Anweisung". Das ist sicherlich nicht gemeint, oder?

[saft6luck]

Den Debugger sollte man erweitern, denn die Werte der Variablen werden ohne Zeitbezug angezeigt. Bei kurzen Timings oder bei Zählern oder Toggel-Flags ändert sich der Wert schneller als man klicken kann. Eine Liste mit automatisch updatenden Variablen vermisse ich daher auch.

Zum Thema Debugger hätte ich auch noch 3:
- Anzeige aller aktuell laufender Timer (sehe ich als sehr wichtig an)
- Historie der Variablenwerte (Debugcode und nur augewählter Variablen?)
- Breakpoints (im laufenden Code) auch mit Trigger auf bestimmte Variablenwerte

[enertegus]

Wie gesagt, bei einer sehr großen Anzahl von GAs ist die Sortierfunktion des Debuggern nicht ausreichend

Du kannst auch nach markierten Variablen sortieren lassen. Dann stehen die ausgewählten immer oben oder ganz unten (je nach Sortierung)

Im Übrigen brich nicht immer gleich in Tränen aus.

Bin halt ein Weichei...

[IBFS]

Das ist doch gerade der Debugger. Der zeigt sowohl das Abbild der GAs im EibPC als auch die Variablen. Man die Verändern und sieht die Reaktion (http://www.youtube.com/watch?v=jVaGNypxbao).

Ich dachte da eher an ein selbst vervorständigbare Tabelle:

GA ----------------- WERT ----------------- DATENTYP

wo ich ohne UPDATEN-TASTE nur die Varablen in der Liste sehe,
die ich sehen will. Am besten wäre,man könnte die GAs mit der
Hand eintragen und je nach Zweck oder Etage, verschiedene
Variablenlisten anlegen. So kenne ich das von "meiner" SIEMENS-SPS
und ich finde das sehr angenehm und auf des Wesentliche reduziert.

Dieses in Listen Rumgesuche und rumgescrolle kenne ich z.B. von
Codesys und das geht mir echt auf den Keks. Das sieht bei Demos mit
10 Variablen imer ganz hübsch aus, aber wenn man, wie z.B. in manchen
SPS-Programmen 2000 Variablen hat, na dann gute Nacht Scrollrad.

Es ist nunmal besser, wenn ich jede Änderung dieser Vaiablen in der
Userliste direkt sehen kann ohne immer erst KLICK-KLICK-KLICK zu
machen. In der Statuszeile muss ich ja auch nicht "UPDATE"
drücken.

Wie gesagt, bei einer sehr großen Anzahl von GAs ist die Sortierfunktion
des Debuggern nicht ausreichend, für GAs von zwei Zimmer mag
der Debugger ausreichend sein, aber das ist ja nicht der Reglefall.

Im Übrigen, an meinen SPS-Programmen wird auch ständig rumgemault
brich nicht immer gleich in Tränen aus. Wenn ich das jedesmal machen
würde, soviel Taschentücher hätte ich garnicht.

Frank

[enertegus]

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.

Das ist doch gerade der Debugger. Der zeigt sowohl das Abbild der GAs im EibPC als auch die Variablen. Man die Verändern und sieht die Reaktion (http://www.youtube.com/watch?v=jVaGNypxbao).

[enertegus]

@enertegus
Der EibPC im Zusammenhang mit dem KNX-Bus ist da so ein Mittelding

Da mußt du schon Geduld haben. schließlich müssen WIR Enduser deine Ideen erst einmal verstehen.

Unguldig bin ich doch nicht, das schmerzt mich, dieser Vorwurf.

Nur die Leute die wirklich verstehen was passiert, könnten die EibPC-Kiste richtig ausnutzen.

Ich gib mir doch alle Mühe. Nochmal

[enertegus]

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

1. Ich habe da bereits was ergänzt zum Thema zeitgesteuerte Variablen. After wird z.B. gar nicht erst erlaubt im then Zweig. Grundsätzlich werden die Zeitfunktionen behandelt wie der Rest.
[highlight=epc]
if Taste then {
if htime(12,00,00) then {
machwas()
} endif
}endif
[/highlight]
machwas() würde nur ausgeführt, wenn Taste exakt um 12:00:00 auf EIN geht. Besser daher chtime, dann würde machwas() aufgerufen, wenn Taste nach 12:00 und vor Mitternacht auf EiN geht.
Ich werde das ergänzen. Irgendwann wird das schon noch klar, hoffe ich.
2. zum Else zweig siehe letztes Beispiel, ist quasi eine negierte if-Anweisung mit then Zweig.

Ich habe über 20 Jahre Programmiererfahrung

habe ich auch nie angezweifelt.

Zu einem Produkt gehört eine Anleitung.

Deswegen ist das ja (wie man sicher bemekrt hat) ein Teil des nächsten Handbuchs.

Wenn du die 10% der Anwender

Nun, das waren10%, von denen aber 98% mit der bereits erhaltenen Erklärung zufrieden sind bzw. geht es dann höchstens noch um einen Unklarheit und weniger um eine Grundsatzdiskussion. Es ist wohl jedem klar, dass wir grundsätzlich von diesem Konzept nicht abweichen werden, auch nicht einen C-Compiler oder ähnliches bereitstellen.

viel GuK-Kosten sparen. Sieh es einmal von der Seite.

Diejenigen, die das so im intensiv einsetzen, kaufen nur einen EibPC. Die, die mehr als einen kaufen, finden es eher schön einfach, weil die essentiellen Dinge einfach zu erledigen sind. Das macht auch den wirtschaftlichen Erfolg aus.
Ich selbst sehe aber ein, dass der Kunde schon fragen darf, wenn es in die Tiefe geht und deswegen hier diese Erklärungen. Und wenn es sich nicht mit seinen Programmiererfahrungen deckt und er was neues lernen will, soll das hier auch möglich sein. Enertex lässt sich da auf die Kunden ein und eine "kontinuierlicher Verbesserungsprozess" ist durchaus im Sinne von Enertex. Immerhin habe ich ja auch die eval-Funktion eingebaut. Ist quasi dein Kind.
EDIT
Unter http://www.youtube.com/results?search_query=eibpc&aq=f gibt es Instruktionen für den Anfang. Das bewegt eigentlich die meisten Anwender. Oder man schau sich die Makrolib 1.008 an.Dort sind auch nahezu triviale Makros drinne, aber diese sind gewünscht und gebraucht.

[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

[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

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

[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]

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?