In der Tiefe: Validierungskonzept

[saft6luck]

Ich habs mal eingespeist. Das wird aber noch dauern...

Was spricht gegen das: (oder hast Du hier auch ein Problem festgestellt?

Ja, so ähnlich habe ich es jetzt auch.
Aber es kann doch nicht sein, dass die viel beschworene Event-getriebene Verarbeitung einen Event nicht schrittweise bearbeiten kann.
Von Divide et impera kann man da ja nicht reden, wenn man jeden Event bis ans Ende der Berechnung mitschleifen muss. Wie sieht es denn mit anderen Verschachtelungen aus, z.B. in den Command Fusion Makros?

[saft6luck]

Ich habs mal eingespeist. Das wird aber noch dauern...

Was spricht gegen das: (oder hast Du hier auch ein Problem festgestellt?
[highlight=epc]
// Rollo - Sonnenaufgang
Rollo_Sonnenaufgang_vorziehen = 7s08
Rollo_Sonnenaufgang_min_h = 07u08
Rollo_Sonnenaufgang_min_m = 00u08
Rollo_Sonnenaufgang_m = 60u08

Rollo_Sonnenaufgang_h = sunrisehour()
Rollo_Sonnenaufgang_m_s = convert( sunriseminute(), 0s08) - Rollo_Sonnenaufgang_vorziehen; /* -> Minuten: -15 <= m <= 44 */

Sonne=change( Rollo_Sonnenaufgang_m_s ) or systemstart()


if ( Rollo_Sonnenaufgang_m_s < 0s08 ) and Sonne then {
Rollo_Sonnenaufgang_m_s = Rollo_Sonnenaufgang_m_s + 60s08;
Rollo_Sonnenaufgang_h = sunrisehour() - 1u08
} endif
if Sonne then Rollo_Sonnenaufgang_m = convert( Rollo_Sonnenaufgang_m_s, 0u08 ) endif

if ( ( Rollo_Sonnenaufgang_h == Rollo_Sonnenaufgang_min_h ) and ( Rollo_Sonnenaufgang_m < Rollo_Sonnenaufgang_min_m ) ) and Sonne then {
Rollo_Sonnenaufgang_m = Rollo_Sonnenaufgang_min_m
} endif

if ( Rollo_Sonnenaufgang_h < Rollo_Sonnenaufgang_min_h ) and Sonne then {
Rollo_Sonnenaufgang_m = Rollo_Sonnenaufgang_min_m;
Rollo_Sonnenaufgang_h = Rollo_Sonnenaufgang_min_h
} endif
[/highlight]

So, ein Tag später und ... das gleiche Problem mit deinem Code. Nach dem Systemstart stimmt es zwar (-> 7:00), heute stehen die Minuten stehen aber auf 48 (->7:48), was erstens der falsche Wert für heute ist (Sonnenaufgang 6:52) und zweitens ja 00 sein sollte.

Darf ich kurz meinem Unmut freien Lauf lassen?

[SteffiEnertex]

Hallo Marc,

ich hab den Code noch etwas mit Kommentaren versehen, damit ich auf einzelne Anweisungen besser verweisen kann.


[highlight=epc]
[EibPC]

// Rollo - Sonnenaufgang
Rollo_Sonnenaufgang_vorziehen = 7s08
Rollo_Sonnenaufgang_min_h = 07u08
Rollo_Sonnenaufgang_min_m = 00u08
Rollo_Sonnenaufgang_m = 60u08


Rollo_Sonnenaufgang_h = sunrisehour()
Rollo_Sonnenaufgang_m_s = convert( sunriseminute(), 0s08) - Rollo_Sonnenaufgang_vorziehen; /* -> Minuten: -15 <= m <= 44 */

Sonne=change( Rollo_Sonnenaufgang_m_s ) or systemstart()


// Anweisung1
//wird beim systemstart durch Anweisung4 überschrieben; da Anweisungen sequenziell abgearbeitet werden
//
// wenn sich sunriseminute() ändert (täglich 1x), wird die Rollo_Sonnenaufgang_m aktualisiert
if Sonne then {
Rollo_Sonnenaufgang_m = convert( Rollo_Sonnenaufgang_m_s, 0u08 )
} endif

// Anweisung2 - wird im Moment nicht aktiv
if ( Rollo_Sonnenaufgang_m_s < 0s08 ) and Sonne then {
Rollo_Sonnenaufgang_m_s = Rollo_Sonnenaufgang_m_s + 60s08;
Rollo_Sonnenaufgang_h = sunrisehour() - 1u08

} endif

// Anweisung3 - wird im Moment nicht aktiv
if ( ( Rollo_Sonnenaufgang_h == Rollo_Sonnenaufgang_min_h ) and ( Rollo_Sonnenaufgang_m < Rollo_Sonnenaufgang_min_m ) ) and Sonne then {
Rollo_Sonnenaufgang_m = Rollo_Sonnenaufgang_min_m
} endif


// Anweisung4
// da beim Systemstart -> Rollo_Sonnenaufgang_h =6 und Sonne kurz auf EIN geht werden
// Rollo_Sonnenaufgang_m = 0; Rollo_Sonnenaufgang_h=7 gesetzt
if ( Rollo_Sonnenaufgang_h < Rollo_Sonnenaufgang_min_h ) and Sonne then {
Rollo_Sonnenaufgang_m = Rollo_Sonnenaufgang_min_m;
Rollo_Sonnenaufgang_h = Rollo_Sonnenaufgang_min_h
} endif


[/highlight]

beim Initialisieren wird durch:
[highlight=epc]
Rollo_Sonnenaufgang_m_s = convert( sunriseminute(), 0s08) - Rollo_Sonnenaufgang_vorziehen; /* -> Minuten: -15 <= m <= 44 */
[/highlight]

Rollo_Sonnenaufgang_m_s = 45 gesetzt

Rollo_Sonnenaufgang_min_h = 6
Rollo_Sonnenaufgang_min_m = 0

Beim Systemstart wird Sonne kurz auf EIN gsetzt
[highlight=epc]
Sonne=change( Rollo_Sonnenaufgang_m_s ) or systemstart()
[/highlight]

Anweisung1 setzt
Rollo_Sonnenaufgang_m = 45

Anweisung4 setzt
Rollo_Sonnenaufgang_m =0
Rollo_Sonnenaufgang_h = 7

=> 7:00

am nächsten Tag wird sunriseminute() neu berechnet.
Dadurch bekommt Rollo_Sonnenaufgang_m_s einen neuen Wert
[highlight=epc]
Rollo_Sonnenaufgang_m_s = convert( sunriseminute(), 0s08) - Rollo_Sonnenaufgang_vorziehen; /* -> Minuten: -15 <= m <= 44 */
[/highlight]

Dadurch wird diese Zuweisung neu ausgeführt:
[highlight=epc]
Sonne=change( Rollo_Sonnenaufgang_m_s ) or systemstart()
[/highlight]
Sonne geht kurz auf EIN

Dadurch wird Anweisung1 ungültig und neu ausgeführt
[highlight=epc]
if Sonne then {
Rollo_Sonnenaufgang_m = convert( Rollo_Sonnenaufgang_m_s, 0u08 )
} endif
[/highlight]

und der Wert für Minuten ändert sich.
=> 7:4x

steffi

[saft6luck]

ich hab den Code noch etwas mit Kommentaren versehen, damit ich auf einzelne Anweisungen besser verweisen kann.

Schönes Beispiel für "Die Verschachtelungen vermeiden" macht alles trivial und hilft immer
Insgesamt ist das ein wirklich banales Problem, diese Umsetzung aber chaotisch!

Das eigentliche Problem habe ich aber gefunden, denn sunrisehour() wird nicht neu zugewiesen, wenn sind sunriseminute() ändert, allerdings hatte ich die entsprechende Zuweisung erst zum Debuggen entfernt und im Debugger habe ich die Stunden auch immer entsprechend geändert ... bleibt also nur doch nur das init-Problem.

Ich werde einfach mal folgendes testen:
[highlight=epc]
// Rollo - Sonnenaufgang
Rollo_Sonnenaufgang_vorziehen = 7s08
Rollo_Sonnenaufgang_min_h = 07u08
Rollo_Sonnenaufgang_min_m = 00u08
Rollo_Sonnenaufgang_m = 60u08
Rollo_Sonnenaufgang_h = 25u08

Rollo_Sonnenaufgang_h_current = sunrisehour()
Rollo_Sonnenaufgang_m_s = convert( sunriseminute(), 0s08) - Rollo_Sonnenaufgang_vorziehen; /* -> Minuten: -15 <= m <= 44 */

if change( Rollo_Sonnenaufgang_m_s ) or systemstart() then {
Rollo_Sonnenaufgang_h = Rollo_Sonnenaufgang_h_current;
if ( Rollo_Sonnenaufgang_m_s < 0s08 ) then {
Rollo_Sonnenaufgang_m_s = Rollo_Sonnenaufgang_m_s + 60s08;
Rollo_Sonnenaufgang_h = sunrisehour() - 1u08
} endif;
Rollo_Sonnenaufgang_m = convert( Rollo_Sonnenaufgang_m_s, 0u08 );
if ( ( Rollo_Sonnenaufgang_h == Rollo_Sonnenaufgang_min_h ) and ( Rollo_Sonnenaufgang_m < Rollo_Sonnenaufgang_min_m ) ) then {
Rollo_Sonnenaufgang_m = Rollo_Sonnenaufgang_min_m
} endif;
if ( Rollo_Sonnenaufgang_h < Rollo_Sonnenaufgang_min_h ) then {
Rollo_Sonnenaufgang_m = Rollo_Sonnenaufgang_min_m;
Rollo_Sonnenaufgang_h = Rollo_Sonnenaufgang_min_h
} endif;
} endif
[/highlight]

[SteffiEnertex]

Guten Morgen Marc,

sunrisehour() wird auch neu berechnet, allerdings ändert sich der Wert (im Moment) nicht; deshalb ändert sich für den compiler nichts.

Was genau willst Du machen?
Wenn ich das richtig verstehe geht es um:
bei sonnenaufgang aber frühestens um und um x Minuten vorgezogen.

Minute= sunriseminute() - Minute_vorziehen
if sun() and chtime(Stunde,Minute,0) then write(AktorGA, WertGA) endif

Negative Werte für Minute müssen natürlich auch hier ausgeschlossen werden; daran hast Du ja schon gedacht.

steffi

[saft6luck]

Was genau willst Du machen?
Wenn ich das richtig verstehe geht es um:
bei sonnenaufgang aber frühestens um und um x Minuten vorgezogen.

Hi,

Vor allem will ich diese Zeit dann auch in der Visu darstellen, daher verwende ich (eigentlich) eine einfache Logik um diese 2 Werte, Stunden und Minuten zu berechnen und dann Aktionen davon abzuleiten.
Weitere Aktionen sind eben die Rolläden zu fahren, nicht alle zur gleichen Zeit -> mit kurzen Äbständen starten. Dann den Versatz später dynamisch berechnen zu lassen (Jahreszeitabhängig), den max. Wert über die Visu einzustellen und die Rolos von Terrassenlicht/Öffnungszustand der Türen erst später zu fahren.

Dabei würde ich die Berechnung der Zeiten von den Steuerungen gerne entkoppeln.

Minute= sunriseminute() - Minute_vorziehen
if sun() and chtime(Stunde,Minute,0) then write(AktorGA, WertGA) endif

Wenn die Überläufe weiterhin nicht dargestellt sind, die je eben auch weiterhin die Probleme verursachen gilt doch:

Minute= sunriseminute() - Minute_vorziehen
if chtime(Stunde,Minute,0) then write(AktorGA, WertGA) endif

Oder anders ausgedrückt sun() ist zumindest (= ohne die Anleitung gefragt zu haben) redundant .

[saft6luck]

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

Wird es da noch etwas geben?

[Tessi]

Also Anzeige aller laufenden Timer: OK.

Spezieller Debug-Code auf dem EibPC? Birgt grundsätzlich das Risiko, das dieser Code sich dann nicht exakt gleich dem Standard-Code verhält und schon der ist nicht ganz fehlerfrei, wie würde das erst mit dem (für die meisten ja nicht so wichtigen) Debug-Code werden?

Historie auf dem EibPC wäre wohl zu viel Datenvolumen. Aber ob der EibPC statt dessen jede Änderung rechtzeitig zwecks dortiger Historie an das EibStudio übermitteln könnte, müsste auch erst einmal geklärt werden. Wegen der zusätzlichen Last wäre das wohl auch nur Debug-Code, mögliche Probleme: siehe oben.

Breakpoints im laufenden Code:
Angesichts der Art und Weise wie der Compiler den Code für den EibPC aufbereitet stellt sich mir die Frage, wie das generell funktionieren soll, bzw. ob es dann auch so funktionieren würde/könnte, wie es sich ein C-Programmierer dann so vorstellen würde.
Und selbst wenn es dann gelänge, das System zu stoppen, was hat man dann davon? Es handelt sich hier um ein Echtzeitsystem das in einer Echtzeitumgebung läuft, die ihrerseits nichts vom Breakpoint weiß und einfach weiter läuft. Damit verändert ein Break die Situation und eine Fortsetzung des Ablaufs - so es überhaupt noch geht - liefert nicht mehr garantiert die gleichen Resultate, als hätte es den Break nie gegeben.
Ggf. bekommt der EibPC während des Breaks übertragene Bus-Telegramme nicht mit, dann wird die Sache inkonsistent und der EibPC müsste eigentlich neu gebootet werden...
Ob jemand den Aufwand treiben möchte?

[saft6luck]

Spezieller Debug-Code auf dem EibPC? Birgt grundsätzlich das Risiko, das dieser Code sich dann nicht exakt gleich dem Standard-Code verhält und schon der ist nicht ganz fehlerfrei, wie würde das erst mit dem (für die meisten ja nicht so wichtigen) Debug-Code werden?

Es ging ja nur um einen Denkanstoß zur Umsetzbarkeit. Völlig unabhängig von der tatsächlichen Umsetzung (da gibt es soooooo viele Möglichkeiten, dass ich das gar nicht vertiefen möchte) arbeiten wir bei der SW-Entwicklung von Echtzeitsystemen u.a. mit dieser Möglichkeit.

Lass es eine Historie von 300 Zyklen sein (da ändert sich praktisch nichts) und die Rechenleistung um 50% steigen, dann könnte man hiermit immer noch sehr schön den Programmlauf analysieren.

Auch bei einem Echtzeitsystem hat das am Ende keinen Einfluss auf den eigentlichen Einsatz des Systemes, da es ja nicht darum geht, die Echtzeitfähigkeit zu testen -> es kommt nicht auf Echtzeitverfügbarkeit an, denn ich kann ja nachträglich in Ruhe analysieren.

Gründe hierfür sind das Validierungsschema mit den unterschiedlichen Abarbeitungen von Events (teilweise erst im nächsten Zyklus) und das aktualisieren der Variablen erst am Ende des Zyklus, was Debugging über Variablen unmöglich macht.

Breakpoints im laufenden Code:
Angesichts der Art und Weise wie der Compiler den Code für den EibPC aufbereitet stellt sich mir die Frage, wie das generell funktionieren soll, bzw. ob es dann auch so funktionieren würde/könnte, wie es sich ein C-Programmierer dann so vorstellen würde.

Das hat erst mal nichts mit C-Programmierern im Allgemeinen zu tun, eher mit PC-Programmierern, die sich nur mit "statischer" SW am PC beschäftigen ... aber auch die haben die gleichen Probleme.
Die Ausführung des Codes zu stoppen ist jetzt ja auch keine neue Erfindung. Es wird immer gerne verwendet um die Programmausführung bis zu einem bestimmten Zeitpunkt zu verifizieren und dann entweder (mit den inzwischen unveränderten oder veränderten Bedingungen) weiter laufen zu lassen.

Es handelt sich hier um ein Echtzeitsystem das in einer Echtzeitumgebung läuft, die ihrerseits nichts vom Breakpoint weiß und einfach weiter läuft. Damit verändert ein Break die Situation und eine Fortsetzung des Ablaufs - so es überhaupt noch geht - liefert nicht mehr garantiert die gleichen Resultate, als hätte es den Break nie gegeben.

Das ist auch nicht zwangsläufig der Zweck des Breakpoints. Man will den Status-quo sichten und evtl. per Einzelschritt (was ich noch gar nicht angesprochen habe) die nächsten Schritte anschauen. Ob sich in der restlichen Welt etwas getan hat oder nicht ist ja erst relevant, wenn es auch um Events im Bereich des betrachteten Codes geht. Ob die Rollos (immer noch) richtig laufen, während ich die Lichtsteuerung in der Küche debugge ist ja einerlei.

Ggf. bekommt der EibPC während des Breaks übertragene Bus-Telegramme nicht mit, dann wird die Sache inkonsistent und der EibPC müsste eigentlich neu gebootet werden...
Ob jemand den Aufwand treiben möchte?

Neu booten zwar nicht, aber das Programm neu starten ... aber das mach ich beim Programmieren ja ständig, also warum nicht auch nach dem debuggen?

[Tessi]

Also generell bin ich auch für entsprechende Debugmöglichkeiten.
Nur habe ich in unseren Projekten zu oft erleben müssen, das Breaks und Stepping schlicht Chaos im Programmablauf und ggf. sogar im Gesammtsystem erzeugt haben und oft genug nicht zur Klärung von unerwarteten Abweichungen beigetragen haben. Erfolgreicher waren da Trace-Analysen mit Emulatoren inklusive Aufzeichnung aller interessierender Busdaten und Hardware-Signalen (Logicanalyzer, Speicherscopes). Das alles steht mir privat für den EibPC aber nicht zur Verfügung (von Busaufzeichnung per ETS mal abgesehen) und würde auch mehr Kenntnisse über die Interna des EibPCs voraussetzen, als Enertex bislang veröffentlichen möchte.

OK, Breakpoints und Debug-Code sind besser als nichts, aber ob wirklich hilfreich genug, um den zusätzlichen Entwicklungsaufwand inklusive langer Beta-Tests zu rechtfertigen? Irgend jemand muss prüfen, ob das alles auch korrekt arbeitet. Und das ist sicher nicht trivial.

[saft6luck]

OK, Breakpoints und Debug-Code sind besser als nichts, ...

Ehrlich gesagt ist das der Grund für die Anfrage.

aber ob wirklich hilfreich genug, um den zusätzlichen Entwicklungsaufwand inklusive langer Beta-Tests zu rechtfertigen? Irgend jemand muss prüfen, ob das alles auch korrekt arbeitet. Und das ist sicher nicht trivial.

Irgendwie sollte Michael ja auch mal im eibPC Fehler aufgespürt haben. Evtl. hat er ja die eine oder andere Möglichkeit bereits implementiert? Immerhin ist das ja nicht nur für den Kunden, sondern auch für die Enertex Softwareentwicklung und den Support interessant.

[Tessi]

Ich nehme mal an, das da bei Enertex eine Ebene tiefer angesetzt wird, meist will man ja nicht ein Programm sondern die Befehle/Funktionen selbst debuggen und das wird uns Anwendern wohl nicht zugänglich gemacht werden...

[enertegus]

Ich nehme mal an, das da bei Enertex eine Ebene tiefer angesetzt wird, meist will man ja nicht ein Programm sondern die Befehle/Funktionen selbst debuggen und das wird uns Anwendern wohl nicht zugänglich gemacht werden...

Yep, so isses.

[saft6luck]

Ich nehme mal an, das da bei Enertex eine Ebene tiefer angesetzt wird, meist will man ja nicht ein Programm sondern die Befehle/Funktionen selbst debuggen und das wird uns Anwendern wohl nicht zugänglich gemacht werden...

Das brauchst du mir nicht erklären
Trotzdem wird aber genauso auf Programmebene entwickelt, denn am Ende wird der Kunde Kommandos eingeben, weswegen die erstellten Funktionen auch im globalen Zusammenspiel laufen müssen.

Yep, so isses.

Wenn man aber nicht jeden im Support oder bei der Entwicklung mit einem BDM oder Emulator ausstatten will, implementieren findige Köpfe kostengünstige Varianten.

Ich stelle mir grad vor, jeder iPhone Entwickler müsste sich ein BDM anschaffen, um debuggen zu können. Aber: Ganz im Gegenteil, da kann man bis auf Assembler-Ebene über USB in Echtzeit debuggen. Und da reicht USB1.1!

[Tessi]

Das brauchst du mir nicht erklären

Aber nicht jedem Leser hier ist das auch so klar.

Trotzdem wird aber genauso auf Programmebene entwickelt, denn am Ende wird der Kunde Kommandos eingeben, weswegen die erstellten Funktionen auch im globalen Zusammenspiel laufen müssen.

Das kann Enertex aber auch mit dem C-Debugger machen, mit dem sie auch die Kommandos analysieren, wir können das nicht, denn wir bekommen weder die Sourcen, noch haben wir die zusätzliche Hardware (BDM oder gar Emulator) und Öffnen des Gehäuses geht mit Garantieverlust einher.

Wenn man aber nicht jeden im Support oder bei der Entwicklung mit einem BDM oder Emulator ausstatten will, implementieren findige Köpfe kostengünstige Varianten.

Das kostet auch Geld, und bei kleinen Unternehmen mit sehr überschaubarer Mitarbeiterzahl kann ein Emulator und ein paar BDMs immer noch billiger sein...

Ich stelle mir grad vor, jeder iPhone Entwickler müsste sich ein BDM anschaffen, um debuggen zu können. Aber: Ganz im Gegenteil, da kann man bis auf Assembler-Ebene über USB in Echtzeit debuggen. Und da reicht USB1.1!

Deren Verkaufserfolg ist auch eng mit einer großen Zahl an Apps von vielen Hobbyprogrammieren verknüpft, da amortisieren sich die Entwicklungskosten für solche Tools recht schnell.
Aber wie viele EibPCs müsste Enertex dazu mehr verkaufen und wie viele werden es nur wegen verbesserter Debugmöglichkeiten dann tatsächlich sein? Wer von denen, die noch keinen EibPC haben, würden ihn sich zulegen wenn der Debugger verbessert wird, und auch nur dann?
Ich schätze mal: Zu wenige um die Entwicklung rentabel zu machen...
Und das auf Anwenderebene bei Enertex intern schon was gibt, das über das im EibStudio verfügbare hinausgeht, glaube ich eher nicht...
Falls ich mich da aber irre, würde ich mich natürlich schon sehr freuen, wenn Enertex das auch dem ambitionierten Anwender zugänglich machen würde.