[Featurewunsch] GA Zustände immer verfügbar halten

[saft6luck]

Könnte man das GA-Management im eibPC nicht deutlich verbessern, wenn man ein automatisches Management der GA-Zustände einführt?

Also z.B.
- speichert sich der eibPC die Zustände aller GAs, auch wenn diese im Code (noch) nicht verwendet werden. (evtl. nur bekannte wegen Speicherplatz?)
- Wird der Wert einer GA benötigt, wird sie automatisch gelesen, falls bisher nicht verfügbar.
- die aktuellen GA-Zustände werden durch einen Programm-Upload NICHT gelöscht!
- natürlich kann man die GA-Zustandstabelle löschen bzw. updaten lassen.

[EPIX]

- die aktuellen GA-Zustände werden durch einen Programm-Upload NICHT gelöscht!

halte ich für nicht sinnvoll: es wird sich der Zustand während dem Prog.update sicher bei einigen GA ändern: was dann?

Ich kenn' das Thema vom HS. da kann man GAs "remanent" setzen - es kann aber auch manchmal die Ursache für "mysteriöse" Zustände sein...

"Schön" wäre halt ein einfacheres Handling der Remantspeicherung: einfach einen haken setzen und gut ist's - OHNE die Kümmerei um den Datentyp und BlaBla - da ist der HS ein Vorbild (trotz der Uralt-Software): die externen GA's und internen Variablen (IKO) werden einfach durch setzen der Parameter definiert:
- Vorbelegung
- Schrittweiten bei Änderungen
- Max. Wert
- Min. Wert
- Remanenz

[saft6luck]

halte ich für nicht sinnvoll: es wird sich der Zustand während dem Prog.update sicher bei einigen GA ändern: was dann?

Darum geht es im weitest gehenden Sinne ;-)
Der eibPC löscht beim Upload immer sein GA-Gedächtnis.

Ich kenn' das Thema vom HS. da kann man GAs "remanent" setzen - es kann aber auch manchmal die Ursache für "mysteriöse" Zustände sein...

Ja, mag sein. Es geht aber nicht um Remanentspeicher, sondern ein entkoppeltes Management der GA Zustände.

Besser erklärt:

Es soll 2 Einheiten im eibPC geben, das eibPC-Programm und den Rest.
Im Rest steckt auch das GA-Management, welches die aktuellen Zustände speichert.

Auch ein Upload des eibPC-Programms soll diese Zustände nicht antasten, genauso soll die Speicherung der Zustände während eines Uploads weitergehen. Beides läuft parallel.

=> Der eibPC hält also ein Abbild der Anlage im Speicher (Umfang kann man drüber reden).

[bmx]

Gute Idee,

ich bin !!!

Das ist in der Wirkung dann sowas in etwa wie ein eibd mit aktivem Cache. Nur wenn der EibPC neu gebootet wird, wird auch der Cache gelöscht und vom dahinterliegenden Programm werden die benötigten GA neu angefordert.

Gruß,
Bernd

[cds]

Wenn ich ehrlich bin scheint hier die Lösung für ein Problem postuliert zu werden das es gar nicht gibt.

InitGA ist implementiert. Bedarf auch nur einen Haken. Was braucht man mehr als bei Programmstart alle relevanten Stati abzufragen?
Damit ist garantiert das diese a) Verfügbar und b) aktuell sind.
Ich sehe keinen Vorteil da irgendwelche Hintergrundprozesse mitlaufen zu lassen.

Und jetzt komm mit bitte keiner mit "Buslast". Wer macht denn in einer Tour irgendwelche Updates das dies zum Problem wird?

[bmx]

Das eine ist das Betriebssystem mit dem der EibPC läuft und das andere die Firmware die das Programm ausführt.

Es wird aber nicht jedesmal das Betriebssystem des EibPC neu gestartet wenn ein Programm geladen wird sondern nur die Firmware selber.

Insofern kann es durchaus so gestaltet werden, das alle GA die vom Bus kommen oder an ihn gesendet werden in einem zusätzlichen Programm (oder Thread oder wie auch immer) zwischengespeichert werden. Ob dann ein Aufruf von initga dazu führt, das tatsächlich der Bus abgefragt wird oder aber der Zwischenspeicher konsultiert wird, kann dem Programm vom EibPC damit schnurz sein.

Und natürlich ist Buslast ein Problem, wenn Du jeweils beim Programmstart wie jetzt aktuell implementiert zig GA abfragen mußt damit die Visu stimmt.

Wenn Du mal ein kompliziertes Makro entwickelt und debuggt hast, dann wirst Du wissen was damit gemeint ist.

Gruß,
Bernd

[cds]

Womit immer noch der Anwendungsbereich sehr eingeschränkt ist.
Grundsätzlich verbaut man irgend einen Rechner ja nicht um ihn permanent upzudaten, sondern das passiert in der Entwicklungsphase häufiger, und nimmt dann ab.
Ich weiß nicht wir der eibd oder der HS das implementiert haben, aber alles was über "Ich cache grundsätzlich alles was auf dem Bus kommt" wird nicht funktionieren.
Dann braucht es entsprechend noch einen Layer das das Matching der Nachrichten zwischen Cache und Applikation übernimmt.
Ich könnte mir vorstellen das das irgendwann Speicher- und CPU Last mäßig nicht mehr passt, denn immerhin ist der eibPC ja auf "klein und sparsam" optimiert - anders als eben Rechner mit eibd oder der HS.

[saft6luck]

Womit immer noch der Anwendungsbereich sehr eingeschränkt ist.
Grundsätzlich verbaut man irgend einen Rechner ja nicht um ihn permanent upzudaten, sondern das passiert in der Entwicklungsphase häufiger, und nimmt dann ab.

Meine Erfahrung mit dem eibPC ist, dass jede Übertragung des Programms meine mir wertvolle Zeit kostet, denn es vergehen mehrere Minuten bis das Programm wieder läuft, die GAs eingelesen sind und dann das "debuggen" beginnen kann.

Je später in der Entwicklungsphase, desto länger dauert diese Prozedur.

Je seltener ich dann update, desto mehr Fehler unterlaufen mir wieder (abgesehen von den immer umfangreicher werdenden Änderungen) und umso mehr Zeit muss investiert werden.

Ich weiß nicht wir der eibd oder der HS das implementiert haben, aber alles was über "Ich cache grundsätzlich alles was auf dem Bus kommt" wird nicht funktionieren.
Dann braucht es entsprechend noch einen Layer das das Matching der Nachrichten zwischen Cache und Applikation übernimmt.

Jetzt ist die bisherige Idee ja eigentlich nur ein aufgebohrter Cache. Du siehst ein unüberwindbares Problem beim Matching zur Applikation hin. Stellt sich mir die Frage, wo der Unterschied zur jetzigen Implementierung im eibPC ist? Merkt sich der eibPC die Zustände während des Programmlaufs nicht? Ist hier kein Matching notwendig? Alles unlösbar?

Für mein Gefühl geht es um eine Spezialisierung. Der GA-Zustandsspeicher und dessen Management soll eigenständig sein und so das Löschen der Daten nicht mehr "nötig" sein, die Zustandswerte vom Bus werden durch den Programmupload schließlich nicht "falsch".

Gleichzeitig kann man eine "benötigte" GA automatisch vom Bus anfragen. Dann bräuchte man nicht entscheiden, welche GA soll in den InitGA. Aus meiner Sicht müssten eh alle verwendeten GAs rein. Ich will nicht auf "0°C" Temperaturwerte schauen, nur weil der Wert erst in 10 Minuten wieder kommt, ich mir aber das InitGA sparen will.

Ich könnte mir vorstellen das das irgendwann Speicher- und CPU Last mäßig nicht mehr passt, denn immerhin ist der eibPC ja auf "klein und sparsam" optimiert - anders als eben Rechner mit eibd oder der HS.

Am Besten wäre also, jegliche weitere Optimierung zu zerreden, begründet durch "Vorstellungen und Vermutungen"?