In der Tiefe: Validierungskonzept

[saft6luck]

Es werden 2 Nachrichten während des Systemstarts rein gestellt. Ich habe zu den Warteschlangen noch was ergänzt.

D.h. wenn der Inhalt (=Wert) der Abfragebedingung durch den then Zweig geändert wird, weil z.B. die abgefragte Variable geändert wird, kann es passieren, dass sofort, also im gleichen Zyklus(!), auch noch der else Zweig bearbeitet wird?

Und das sowohl in der Hauptebene, als auch in Verschachtelungen?

Was macht das für einen Sinn?

[enertegus]

Werden 2 Telegramme in den Puffer gestellt, eines im Moment des Systemstarts und eines 1ms später oder werden die tatsächlich während des Systemstarts generiert? Erscheint mir wichtig für das Verständnis.

Es werden 2 Nachrichten während des Systemstarts rein gestellt. Ich habe zu den Warteschlangen noch was ergänzt.

[enertegus]

Habe nun den Fehler mit stime ausgebessert und noch ergänzt um das Thema Warteschlangen.

[makki]

Ganz ehrlich, das was ich gerade denke schreib ich lieber nicht..
Weil das wird sonst entweder als Polemik, Angriff auf die 1980er Siemens-SPS-Denke (und das schreibe ich schon gerne) verstanden oder sonstwie falsch verstanden

Makki

[pio]

Also sogar die, die es gar nicht benötigen, stimmen dafür. Sozusagen Zielgruppenübergreifend

[SnowMaKeR]

Wenn ich meine Umfrage anschaue, ist die deutliche Mehrheit der Teilnehmer für meinen Vorschlag,

Da muss ich aber kurz sagen, dass ich dafür gestimmt habe, weil ich es praktisch finde und ich weniger Nachdenken muss.
Nicht weil ich es benötige.

[pio]

.. aber nachdem es möglich war im Eibstudio die Telegrammrate zu begrenzen (ich hab jetzt max 19/sec eingestellt) wurden es viel weniger Telegramme, ...

Mein Problem sind nicht die Anzahl Telegramme pro Sekunde (ich habe übrigens die Empfehlung von Enertex eingestell, d.h. 7 / sec), sondern dass ich so 5 Sekunden brauche, bis alle Variablen up to date sind. In dieser Zeit macht der Code Sachen, die er nicht soll, da Variablen eben noch nicht den richtigen Wert haben.

Ob eine "eval" Funktion eine Verbesserung ist, wage ich zu bezweifeln, weil man damit den EIBPC ausser Betrieb setzen kann.

Lies meinen anderen Post. Das war mein Problem.

Generell wird es immer verschiedene Geräte mit verschiedenen Zielgruppen geben müssen und auf Dauer muß enertegus sich entscheiden, welche Zielgruppe er mit dem EibPC ansprechen will.

Wenn ich meine Umfrage anschaue, ist die deutliche Mehrheit der Teilnehmer für meinen Vorschlag, und der ist Zielgruppenunabhängig. (Es sei denn, Du betrachtest Installationen, bei denen keine GA durch die Abfrage des Systemstarts eingelesen werden soll, als eine eigene Zielgruppe, die sich gravierend von dem Rest unterscheidet.)

[saft6luck]

Noch einmal zum eigentlichen Thema (Version vom 20.09.):

• Es wird sowohl stime(32) also auch stime(33) verwendet und beide Male auf die 32. Sekunde nach der vollen Minute hingewiesen. Anfangs dachte ich mir, dass das bei stime(33) schon sein könnte, irgendwie, so genau brauche ich das ja nicht. Aber mit dem neuen Beispiel würde ich das stime(33) als Fehler interpretieren.
  
• Wie hat man folgenden Satz am Ende des Dokumentes zu deuten? "Mit obiger Überlegung wird klar, weshalb beim Systemstart auf 1/2/3 sowohl AUS als auch EIN geschrieben wird.": Werden 2 Telegramme in den Puffer gestellt, eines im Moment des Systemstarts und eines 1ms später oder werden die tatsächlich während des Systemstarts generiert? Erscheint mir wichtig für das Verständnis.

[IBFS]

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.

Bis zu diesem Satz - wo es dann anfing in das persönliche zu gehen fand ich die Unterhaltung sachlich.

Ich denke schon selber und brauche keine Argumente zu leihen, nur weil mehrere dieselbe Meinung haben, die anders als deine ist, haben die nicht unbedingt voneinander abgeschrieben.
---
Auch wenn du es nicht verstehst, meine Aussage ist Richtig. Durch das abbremsen wird der Abfragezyclus insgesamt viel schneller.
---
Und ich lasse mir auch nicht von dir den Mund verbieten.

Ich verstehe nur nach wie vor nicht, das ein Thema, was angeblich
nur drei Leute interessiert so ins Negative gezogen wird.

Ich möchte mal wissen wie viele ROs hier mitlesen und froh darüber
sind das Jemand ihnen die Fragen stellt.

Ich habe durch SLs Fragen auch schon einiges für mich übernehmen
können. Es kann ja nicht jeder eine GIRA-HS zu Hause haben.

Frank

P.S.
Im Forum gibt es genug Themen, wo Seitenlang referiert wird, die mich
nicht interesssieren und die auch manchmal ausufern. Aber die
Beträgeschreiben deswegen geringzuschätzen ins falsch. Seid froh das
die Beteilung so gut ist hier.

Stellt euch mal vor es ist FORUM und keiner geht hin.

[SnowMaKeR]

Ich versteh euch nicht.
Ich weiß ja, jammern gehört zum g´schäft, aber...

Im übrigen seit Ihr längst total OT.
Jetzt wieder brav und schön spielen.

[Uwe!]

Alles wird gut.

ich bin völlig entspannt und hab alles gesagt.



Aber ich nehm Deine Aussage als Versprechen

[saft6luck]

[QUOTE=anlo007;118546]Ich denke schon selber und brauche keine Argumente zu leihen, nur weil mehrere dieselbe Meinung haben, die anders als deine ist, haben die nicht unbedingt voneinander abgeschrieben.[/QUTOE]
Ich habe nur das Wort "Polemik" entliehen, würde ich so nicht schreiben!!!

Auch wenn du es nicht verstehst, meine Aussage ist Richtig. Durch das abbremsen wird der Abfragezyclus insgesamt viel schneller.

Wenn ich viele Read() auf den Bus lege und die Antworten benötige, um die restliche Logik zu bedienen, dauert es mit einer Telegrammratenbegrenzung länger bis die Antworten eintreffen. Soweit klar?

Wenn die Logiken nun schon Ergebnisse auf den Bus schreiben (während die Antworten ja noch ausstehen) , werden diese auch trotz der Ratenbegrenzung auf den Bus geschrieben, da es einen Puffer gibt. Auch klar, oder?

Also können die aktuell auf den Bus geschriebenen Telegramme fehlerhafte Auktionen auslösen, z.B. um 13:00 Rollo runter weil Helligkeit auf 0 oder Heizung ein weil Temperatur auf 0°C etc.

Folgerung: Die Datenratenbegrenzung hilft als nicht.

Und ich lasse mir auch nicht von dir den Mund verbieten.

Würde ich bestimmt nicht wagen, nur könnte ich dir gerne 2 Postings von dir anführen, in denen du vorschlägst, dass andere sich eine andere Plattform für ihre Projekte suchen. Ist das eine Art des "Mund verbietens?"

[enertegus]

So jetzt ist genug, beruhigt Euch wieder.
Alles wird gut.

[anlo007]

Das ist schon wieder diese 'macht bloß nichts zu kompliziert für die Benutzer' Polemik (entliehen von Uwe!), die immer zieht. Nur wieso denkst du, musst du das mal wieder anbringen?

Ich denke schon selber und brauche keine Argumente zu leihen, nur weil mehrere dieselbe Meinung haben, die anders als deine ist, haben die nicht unbedingt voneinander abgeschrieben.

Das hat absolut nichts mit der Telegrammratenbegrenzung zu tun, denn dadurch werden die Antworten der Read()-Anweisungen nur noch weiter verzögert. Warten ist angesagt und nicht abbremsen.

Auch wenn du es nicht verstehst, meine Aussage ist Richtig. Durch das abbremsen wird der Abfragezyclus insgesamt viel schneller.

Und ich lasse mir auch nicht von dir den Mund verbieten.

[saft6luck]

4. Der Ton macht die Musik! Und das ist letztlich das einzige was mich an saft6luck stört. Und das werde ich mir auch in Zukunft erlauben zu sagen. Das er gute Ideen mit einbringt steht auf einem anderen Blatt, das eine hat aber erst mal nichts mit dem anderen zu tun. Und ohne für andere Teilnehmer sprechen zu wollen: ich bin mir Recht sicher , dass ich nicht der einzige bin, bei dem saft6luck aneckt.

Da du mich ja nun schon wieder angreifst, werde ich auch im Forum antworten. Für dich steht weiterhin der Weg der Email offen (wie schon geschrieben!).

Wenn dich also der Ton stört und wohl auch viele andere, für die du nicht sprechen willst aber doch tust, dann solltest du dich auch darauf beschränken und nicht planlos den Inhalt meiner Postings attackieren.

Das Problem mit sehr vielen Telegrammen beim Systemstart hatte ich auch einige Zeit, aber nachdem es möglich war im Eibstudio die Telegrammrate zu begrenzen (ich hab jetzt max 19/sec eingestellt) wurden es viel weniger Telegramme, da der Bus dann auch Zeit hat auf die Anfragen zu antworten, und es gehen auch weniger Antworten verloren.

Das hat absolut nichts mit der Telegrammratenbegrenzung zu tun, denn dadurch werden die Antworten der Read()-Anweisungen nur noch weiter verzögert. Warten ist angesagt und nicht abbremsen.

Ob eine "eval" Funktion eine Verbesserung ist, wage ich zu bezweifeln, weil man damit den EIBPC ausser Betrieb setzen kann.

Mir ist völlig unverständlich, wie man sich an einer einzelnen Funktion so hochziehen kann, besonders wenn man nicht versteht, dass nicht hierdurch der eibPC ausser Betreib gesetzt wird. Die fehlende Dokumentation des Validierungsschemas war das Problem, gepaart mit einer schlechten Ausfallsicherheit. Wenn du schon so argumentierst, sollte man wohl das write() verbieten!

[..]Neben dem EibPC für Häuslebauer gibt es ja noch das wiregate, da kann man auf LINUX-Basis alles selbst prgrammieren. Wäre das nicht das passendere Gerät für euch. Ich selbst habe das wiregate um viele Temperaturen auf den BUS zu bringen, dafür ist es für mich einmalig, fertige Plugins zu installieren ist auch OK, aber selbstständig im Linux etwas zu programmieren kann ich nicht, da fehlen mir die Kenntnisse.

Ich möchte aber nicht, das der EibPC auf Dauer genau so ein High-Tech Teil wird, den ich als Häuslebauer nicht mehr bedienen kann, nur weil Enertegus allen Forderungen von professionellen Programmierern hier im Forum nachläuft.

Das ist schon wieder diese 'macht bloß nichts zu kompliziert für die Benutzer' Polemik (entliehen von Uwe!), die immer zieht. Nur wieso denkst du, musst du das mal wieder anbringen? Niemand, aber auch wirklich niemand hat hier Änderungen gefordert, eingebracht oder angedacht, die etwas verkomplizieren. Es soll einfacher werden, indem man die vorhandene Logik erklärt. Wenn du ja schon alles verstanden hast und hattes, bist du ja eh schon fein raus. Evtl. sollten wir einfach jeden Thread mit 'macht bloß nichts zu kompliziert für die Benutzer' anfangen?

Im übrigen ist ein besserer Debugger wohl nichts komplizierteres, oder? Ich für meinen Teil sehe z.B. gerne die Timer. Ohne deren Zustand zu kennen ist es nicht einfacher, sondern komplizierter, oder?