StellSi-Hilfewiki - Benutzerbeiträge [de]

Development:Anforderungen Rangieren

2021-03-06T12:55:30Z

BorisM: /* Vorschläge und Anmerkungen zur Realisierung */

== Klassische Anwendungsfälle ==

* Richtungswechsel mit Lokumlauf mit und ohne Zugnummernwechsel
* Zug zwischenzeitlich auf einem Abstellgleis abstellen, bevor man ihn für die nächste Zugfahrt wieder hervor holt.
* Nahgüterzug, der manchmal eine bestimmte Wagengruppe enthält, manchmal nicht.
* Ein Wagen für den Güterschuppen, einer für die Rampe, ein paar weitere für die Übergabe, und die sind in zufälliger Reihenfolge im Zug.
* Ein Ablaufberg.
* Kurswagen: Übergang einer Wagengruppe von einem Zug auf einen anderen mit Hilfe einer fremden Lok
* Ein Güterzug kommt gemischt an, Lok Weg, mit Rangierlok alle Wagen mit Ziel 1 in Gleis A, mit Ziel 2 in Gleis B, danach wieder zusammensetzen.
* Bahnhofsrangierloks
* Einfahrt das Güterzugs in ein Hauptgleis, ausziehen auf Ausfahrgleis oder Ausziehgleis und in ein Nebengleis drücken. Selbes in entgegengesetzter Richtung.
* Einfahrt als Rangierfahrt (theoretisch seit einiger Zeit zulässig, in der Praxis nicht üblich)
* (Flügeln)
* Störfall: Vorzeitiges wenden eines Zuges (z.B. bei Bahnhöfen mit Gleisen im Einrichtungsbetrieb, Umsetzen auf Gleis mit ASig)
* Lok aus
* Loktausch mit Lok aus dem BW (Loktausch in der Dampflokzeit, Kopfbahnhof, ...)
* (Lokmeldeanlage München Hbf -> Lokmeldungen über Zugmeldeanlage)
* Verstärken/Schwächen (z.B. S-Bahn München)
* Britische Variante des Bahnbetriebs
* Anschlussbedienung (Anst, Awanst, ggf. kombiniert mit ZLB)
* (Sperrfahrten/Baugleis)
* (Einfahrt ins besetzte Gleis ohne Sh2)

== Fragestellungen, die aus dem Konzept heraus kommen sollen ==

* Bei Spurplanstellwerken:
** Wann trennt sich ein Fahrzug vom Zug und wie viele
** Wo wendet eine Rangierfahrt, wartet sie mglw. eine gewisse Länge vor einem Ls, um einen weiteren Zug davor zu lassen
** Wann vereinigen sich Züge und wie geht es mit dem Ergebnis weiter
* Bei klassischen Ls-Armen Stellwerken zusätzlich:
** Wie merkt die Rf, dass sie in einem klassischen Bereich ist?
** Sie muss dem Ww den Zielabschnitt vorschlagen, bis wohin sie vorziehen können dürfen will.(Bis hinter Weiche 2.)
** Der Ww muss sie dann zum vorziehen auffordern
* Bei Rangierbereichen zudem:
** Stellen von Weichen und bedienen der Schlüssel
* Unterschiedliche zeitliche Regelungen, je nach "Epoche" gibt es teilweise massive Unterschiede in den Abläufen.
* Wie Flexibilität für unterschiedliche Regelungen im Ausland herstellen (Scripting?) sowie auch betriebsstellenbezogene Besonderheiten.

== Vorschläge und Anmerkungen zur Realisierung ==

* Rangieren, Zugleitbetrieb, Anschlussbedienungen, Sperrfahrten.... sind nicht das gleiche, benötigen aber teilweise vermutlich die gleichen Mechanismen -> Synergien prüfen, ggf. gemeinsam planen.
* Zugfahrten sollten nicht beendet und separat fortgeführt werden müssen, wenn sie dies im Vorbild auch nicht tun, auch beim nachsortieren eines Nahgüterzuges.
* Schiebeloks sollten nicht selbst wissen, welcher Zug als nächstes kommt, sondern die Anweisungen sollten im Zug stehen
* Sofern Wegfindemechanismen zum Einsatz kommen, sollten diese bezüglich ZLB abgeklopft werden.
* Bei Wegvorgaben (Fahrplan, Vereinbarung der Rangierfahrt) sollten es möglich sein vorzugeben:
** Nur Start und Ziel
** bestimmte Wegpunkte (bis hinters LS, bis vor Signal xy)
** bestimmte Gleisgruppen
** Dynamisch definierbare Bedingungen für die Fortsetzung (z.B. Vorliegen eines Funkgesprächs)
*** Funkgespräche sollten vom Wortlaut her sowohl im Fahrplan als auch in der stwa als auch in einer stwb vorgegeben werden können)
** Vorgabe von Handlungen (z.B. Schlüssel aus Schlüsselsperre entnehmen, Weiche von Hand umstellen/zurückstellen, Schlüssel wieder in Schlüsselsperre einsperren, Meldung über Funk abgeben)

== Mutmaßlich separate Konzepte ==

* Ausziehgleis liegt beim Fdl des benachbarten Gbf (Rangieren über Streckenanschluss) => Automatische Rückkehr der Rangierfahrten
* Automatische Rückkehr einer Schiebelok
* Entkuppeln während der Fahrt von Schiebeloks und Abstoßbetrieben sowie der vermutlich ähnlich gelagerte Ablaufbetrieb und dem Bewegen von Einzelwagen mit Hand ("Verschieben") (Hinweis: Ablaufberg muss auch Oberammergau-Sicher sein)
* Ladegut-Konzept, Verbindung zu Rangieren sind Be- und Entladevorgänge.

Development:Anforderungen Rangieren

2021-03-06T12:52:42Z

BorisM: /* Vorschläge und Anmerkungen zur Realisierung */

== Klassische Anwendungsfälle ==

* Richtungswechsel mit Lokumlauf mit und ohne Zugnummernwechsel
* Zug zwischenzeitlich auf einem Abstellgleis abstellen, bevor man ihn für die nächste Zugfahrt wieder hervor holt.
* Nahgüterzug, der manchmal eine bestimmte Wagengruppe enthält, manchmal nicht.
* Ein Wagen für den Güterschuppen, einer für die Rampe, ein paar weitere für die Übergabe, und die sind in zufälliger Reihenfolge im Zug.
* Ein Ablaufberg.
* Kurswagen: Übergang einer Wagengruppe von einem Zug auf einen anderen mit Hilfe einer fremden Lok
* Ein Güterzug kommt gemischt an, Lok Weg, mit Rangierlok alle Wagen mit Ziel 1 in Gleis A, mit Ziel 2 in Gleis B, danach wieder zusammensetzen.
* Bahnhofsrangierloks
* Einfahrt das Güterzugs in ein Hauptgleis, ausziehen auf Ausfahrgleis oder Ausziehgleis und in ein Nebengleis drücken. Selbes in entgegengesetzter Richtung.
* Einfahrt als Rangierfahrt (theoretisch seit einiger Zeit zulässig, in der Praxis nicht üblich)
* (Flügeln)
* Störfall: Vorzeitiges wenden eines Zuges (z.B. bei Bahnhöfen mit Gleisen im Einrichtungsbetrieb, Umsetzen auf Gleis mit ASig)
* Lok aus
* Loktausch mit Lok aus dem BW (Loktausch in der Dampflokzeit, Kopfbahnhof, ...)
* (Lokmeldeanlage München Hbf -> Lokmeldungen über Zugmeldeanlage)
* Verstärken/Schwächen (z.B. S-Bahn München)
* Britische Variante des Bahnbetriebs
* Anschlussbedienung (Anst, Awanst, ggf. kombiniert mit ZLB)
* (Sperrfahrten/Baugleis)
* (Einfahrt ins besetzte Gleis ohne Sh2)

== Fragestellungen, die aus dem Konzept heraus kommen sollen ==

* Bei Spurplanstellwerken:
** Wann trennt sich ein Fahrzug vom Zug und wie viele
** Wo wendet eine Rangierfahrt, wartet sie mglw. eine gewisse Länge vor einem Ls, um einen weiteren Zug davor zu lassen
** Wann vereinigen sich Züge und wie geht es mit dem Ergebnis weiter
* Bei klassischen Ls-Armen Stellwerken zusätzlich:
** Wie merkt die Rf, dass sie in einem klassischen Bereich ist?
** Sie muss dem Ww den Zielabschnitt vorschlagen, bis wohin sie vorziehen können dürfen will.(Bis hinter Weiche 2.)
** Der Ww muss sie dann zum vorziehen auffordern
* Bei Rangierbereichen zudem:
** Stellen von Weichen und bedienen der Schlüssel
* Unterschiedliche zeitliche Regelungen, je nach "Epoche" gibt es teilweise massive Unterschiede in den Abläufen.
* Wie Flexibilität für unterschiedliche Regelungen im Ausland herstellen (Scripting?) sowie auch betriebsstellenbezogene Besonderheiten.

== Vorschläge und Anmerkungen zur Realisierung ==

* Zugfahrten sollten nicht beendet und separat fortgeführt werden müssen, wenn sie dies im Vorbild auch nicht tun, auch beim nachsortieren eines Nahgüterzuges.
* Schiebeloks sollten nicht selbst wissen, welcher Zug als nächstes kommt, sondern die Anweisungen sollten im Zug stehen
* Sofern Wegfindemechanismen zum Einsatz kommen, sollten diese bezüglich ZLB abgeklopft werden.
* Bei Wegvorgaben (Fahrplan, Vereinbarung der Rangierfahrt) sollten es möglich sein vorzugeben:
** Nur Start und Ziel
** bestimmte Wegpunkte (bis hinters LS, bis vor Signal xy)
** bestimmte Gleisgruppen
** Dynamisch definierbare Bedingungen für die Fortsetzung (z.B. Vorliegen eines Funkgesprächs)
*** Funkgespräche sollten vom Wortlaut her sowohl im Fahrplan als auch in der stwa als auch in einer stwb vorgegeben werden können)
** Vorgabe von Handlungen (z.B. Schlüssel aus Schlüsselsperre entnehmen, Weiche von Hand umstellen/zurückstellen, Schlüssel wieder in Schlüsselsperre einsperren, Meldung über Funk abgeben)

== Mutmaßlich separate Konzepte ==

* Ausziehgleis liegt beim Fdl des benachbarten Gbf (Rangieren über Streckenanschluss) => Automatische Rückkehr der Rangierfahrten
* Automatische Rückkehr einer Schiebelok
* Entkuppeln während der Fahrt von Schiebeloks und Abstoßbetrieben sowie der vermutlich ähnlich gelagerte Ablaufbetrieb und dem Bewegen von Einzelwagen mit Hand ("Verschieben") (Hinweis: Ablaufberg muss auch Oberammergau-Sicher sein)
* Ladegut-Konzept, Verbindung zu Rangieren sind Be- und Entladevorgänge.

Development:Anforderungen Rangieren

2021-03-06T12:49:24Z

BorisM: /* Fragestellungen, die aus dem Konzept heraus kommen sollen */

== Klassische Anwendungsfälle ==

* Richtungswechsel mit Lokumlauf mit und ohne Zugnummernwechsel
* Zug zwischenzeitlich auf einem Abstellgleis abstellen, bevor man ihn für die nächste Zugfahrt wieder hervor holt.
* Nahgüterzug, der manchmal eine bestimmte Wagengruppe enthält, manchmal nicht.
* Ein Wagen für den Güterschuppen, einer für die Rampe, ein paar weitere für die Übergabe, und die sind in zufälliger Reihenfolge im Zug.
* Ein Ablaufberg.
* Kurswagen: Übergang einer Wagengruppe von einem Zug auf einen anderen mit Hilfe einer fremden Lok
* Ein Güterzug kommt gemischt an, Lok Weg, mit Rangierlok alle Wagen mit Ziel 1 in Gleis A, mit Ziel 2 in Gleis B, danach wieder zusammensetzen.
* Bahnhofsrangierloks
* Einfahrt das Güterzugs in ein Hauptgleis, ausziehen auf Ausfahrgleis oder Ausziehgleis und in ein Nebengleis drücken. Selbes in entgegengesetzter Richtung.
* Einfahrt als Rangierfahrt (theoretisch seit einiger Zeit zulässig, in der Praxis nicht üblich)
* (Flügeln)
* Störfall: Vorzeitiges wenden eines Zuges (z.B. bei Bahnhöfen mit Gleisen im Einrichtungsbetrieb, Umsetzen auf Gleis mit ASig)
* Lok aus
* Loktausch mit Lok aus dem BW (Loktausch in der Dampflokzeit, Kopfbahnhof, ...)
* (Lokmeldeanlage München Hbf -> Lokmeldungen über Zugmeldeanlage)
* Verstärken/Schwächen (z.B. S-Bahn München)
* Britische Variante des Bahnbetriebs
* Anschlussbedienung (Anst, Awanst, ggf. kombiniert mit ZLB)
* (Sperrfahrten/Baugleis)
* (Einfahrt ins besetzte Gleis ohne Sh2)

== Fragestellungen, die aus dem Konzept heraus kommen sollen ==

* Bei Spurplanstellwerken:
** Wann trennt sich ein Fahrzug vom Zug und wie viele
** Wo wendet eine Rangierfahrt, wartet sie mglw. eine gewisse Länge vor einem Ls, um einen weiteren Zug davor zu lassen
** Wann vereinigen sich Züge und wie geht es mit dem Ergebnis weiter
* Bei klassischen Ls-Armen Stellwerken zusätzlich:
** Wie merkt die Rf, dass sie in einem klassischen Bereich ist?
** Sie muss dem Ww den Zielabschnitt vorschlagen, bis wohin sie vorziehen können dürfen will.(Bis hinter Weiche 2.)
** Der Ww muss sie dann zum vorziehen auffordern
* Bei Rangierbereichen zudem:
** Stellen von Weichen und bedienen der Schlüssel
* Unterschiedliche zeitliche Regelungen, je nach "Epoche" gibt es teilweise massive Unterschiede in den Abläufen.
* Wie Flexibilität für unterschiedliche Regelungen im Ausland herstellen (Scripting?) sowie auch betriebsstellenbezogene Besonderheiten.

== Vorschläge und Anmerkungen zur Realisierung ==

* Zugfahrten sollten nicht beendet und separat fortgeführt werden müssen, wenn sie dies im Vorbild auch nicht tun, auch beim nachsortieren eines Nahgüterzuges.
* Schiebeloks sollten nicht selbst wissen, welcher Zug als nächstes kommt, sondern die Anweisungen sollten im Zug stehen
* Sofern Wegfindemechanismen zum Einsatz kommen, sollten diese bezüglich ZLB abgeklopft werden.

== Mutmaßlich separate Konzepte ==

* Ausziehgleis liegt beim Fdl des benachbarten Gbf (Rangieren über Streckenanschluss) => Automatische Rückkehr der Rangierfahrten
* Automatische Rückkehr einer Schiebelok
* Entkuppeln während der Fahrt von Schiebeloks und Abstoßbetrieben sowie der vermutlich ähnlich gelagerte Ablaufbetrieb und dem Bewegen von Einzelwagen mit Hand ("Verschieben") (Hinweis: Ablaufberg muss auch Oberammergau-Sicher sein)
* Ladegut-Konzept, Verbindung zu Rangieren sind Be- und Entladevorgänge.

Development:Anforderungen Rangieren

2021-03-06T12:46:50Z

BorisM: /* Klassische Anwendungsfälle */

== Klassische Anwendungsfälle ==

* Richtungswechsel mit Lokumlauf mit und ohne Zugnummernwechsel
* Zug zwischenzeitlich auf einem Abstellgleis abstellen, bevor man ihn für die nächste Zugfahrt wieder hervor holt.
* Nahgüterzug, der manchmal eine bestimmte Wagengruppe enthält, manchmal nicht.
* Ein Wagen für den Güterschuppen, einer für die Rampe, ein paar weitere für die Übergabe, und die sind in zufälliger Reihenfolge im Zug.
* Ein Ablaufberg.
* Kurswagen: Übergang einer Wagengruppe von einem Zug auf einen anderen mit Hilfe einer fremden Lok
* Ein Güterzug kommt gemischt an, Lok Weg, mit Rangierlok alle Wagen mit Ziel 1 in Gleis A, mit Ziel 2 in Gleis B, danach wieder zusammensetzen.
* Bahnhofsrangierloks
* Einfahrt das Güterzugs in ein Hauptgleis, ausziehen auf Ausfahrgleis oder Ausziehgleis und in ein Nebengleis drücken. Selbes in entgegengesetzter Richtung.
* Einfahrt als Rangierfahrt (theoretisch seit einiger Zeit zulässig, in der Praxis nicht üblich)
* (Flügeln)
* Störfall: Vorzeitiges wenden eines Zuges (z.B. bei Bahnhöfen mit Gleisen im Einrichtungsbetrieb, Umsetzen auf Gleis mit ASig)
* Lok aus
* Loktausch mit Lok aus dem BW (Loktausch in der Dampflokzeit, Kopfbahnhof, ...)
* (Lokmeldeanlage München Hbf -> Lokmeldungen über Zugmeldeanlage)
* Verstärken/Schwächen (z.B. S-Bahn München)
* Britische Variante des Bahnbetriebs
* Anschlussbedienung (Anst, Awanst, ggf. kombiniert mit ZLB)
* (Sperrfahrten/Baugleis)
* (Einfahrt ins besetzte Gleis ohne Sh2)

== Fragestellungen, die aus dem Konzept heraus kommen sollen ==

* Bei Spurplanstellwerken:
** Wann trennt sich ein Fahrzug vom Zug und wie viele
** Wo wendet eine Rangierfahrt, wartet sie mglw. eine gewisse Länge vor einem Ls, um einen weiteren Zug davor zu lassen
** Wann vereinigen sich Züge und wie geht es mit dem Ergebnis weiter
* Bei klassischen Ls-Armen Stellwerken zusätzlich:
** Wie merkt die Rf, dass sie in einem klassischen Bereich ist?
** Sie muss dem Ww den Zielabschnitt vorschlagen, bis wohin sie vorziehen können dürfen will.(Bis hinter Weiche 2.)
** Der Ww muss sie dann zum vorziehen auffordern
* Bei Rangierbereichen zudem:
** Stellen von Weichen und bedienen der Schlüssel

== Vorschläge und Anmerkungen zur Realisierung ==

* Zugfahrten sollten nicht beendet und separat fortgeführt werden müssen, wenn sie dies im Vorbild auch nicht tun, auch beim nachsortieren eines Nahgüterzuges.
* Schiebeloks sollten nicht selbst wissen, welcher Zug als nächstes kommt, sondern die Anweisungen sollten im Zug stehen
* Sofern Wegfindemechanismen zum Einsatz kommen, sollten diese bezüglich ZLB abgeklopft werden.

== Mutmaßlich separate Konzepte ==

* Ausziehgleis liegt beim Fdl des benachbarten Gbf (Rangieren über Streckenanschluss) => Automatische Rückkehr der Rangierfahrten
* Automatische Rückkehr einer Schiebelok
* Entkuppeln während der Fahrt von Schiebeloks und Abstoßbetrieben sowie der vermutlich ähnlich gelagerte Ablaufbetrieb und dem Bewegen von Einzelwagen mit Hand ("Verschieben") (Hinweis: Ablaufberg muss auch Oberammergau-Sicher sein)
* Ladegut-Konzept, Verbindung zu Rangieren sind Be- und Entladevorgänge.

Development:Anforderungen Rangieren

2021-03-06T12:45:23Z

BorisM: /* Klassische Anwendungsfälle */

== Klassische Anwendungsfälle ==

* Richtungswechsel mit Lokumlauf mit und ohne Zugnummernwechsel
* Zug zwischenzeitlich auf einem Abstellgleis abstellen, bevor man ihn für die nächste Zugfahrt wieder hervor holt.
* Nahgüterzug, der manchmal eine bestimmte Wagengruppe enthält, manchmal nicht.
* Ein Wagen für den Güterschuppen, einer für die Rampe, ein paar weitere für die Übergabe, und die sind in zufälliger Reihenfolge im Zug.
* Ein Ablaufberg.
* Kurswagen: Übergang einer Wagengruppe von einem Zug auf einen anderen mit Hilfe einer fremden Lok
* Ein Güterzug kommt gemischt an, Lok Weg, mit Rangierlok alle Wagen mit Ziel 1 in Gleis A, mit Ziel 2 in Gleis B, danach wieder zusammensetzen.
* Bahnhofsrangierloks
* Einfahrt das Güterzugs in ein Hauptgleis, ausziehen auf Ausfahrgleis oder Ausziehgleis und in ein Nebengleis drücken. Selbes in entgegengesetzter Richtung.
* Einfahrt als Rangierfahrt (theoretisch seit einiger Zeit zulässig, in der Praxis nicht üblich)
* (Flügeln)
* Störfall: Vorzeitiges wenden eines Zuges (z.B. bei Bahnhöfen mit Gleisen im Einrichtungsbetrieb, Umsetzen auf Gleis mit ASig)
* Lok aus
* Loktausch mit Lok aus dem BW (Loktausch in der Dampflokzeit, Kopfbahnhof, ...)
* Verstärken/Schwächen (z.B. S-Bahn München)
* Britische Variante des Bahnbetriebs
* Anschlussbedienung (Anst, Awanst, ggf. kombiniert mit ZLB)
* (Sperrfahrten/Baugleis)

== Fragestellungen, die aus dem Konzept heraus kommen sollen ==

* Bei Spurplanstellwerken:
** Wann trennt sich ein Fahrzug vom Zug und wie viele
** Wo wendet eine Rangierfahrt, wartet sie mglw. eine gewisse Länge vor einem Ls, um einen weiteren Zug davor zu lassen
** Wann vereinigen sich Züge und wie geht es mit dem Ergebnis weiter
* Bei klassischen Ls-Armen Stellwerken zusätzlich:
** Wie merkt die Rf, dass sie in einem klassischen Bereich ist?
** Sie muss dem Ww den Zielabschnitt vorschlagen, bis wohin sie vorziehen können dürfen will.(Bis hinter Weiche 2.)
** Der Ww muss sie dann zum vorziehen auffordern
* Bei Rangierbereichen zudem:
** Stellen von Weichen und bedienen der Schlüssel

== Vorschläge und Anmerkungen zur Realisierung ==

* Zugfahrten sollten nicht beendet und separat fortgeführt werden müssen, wenn sie dies im Vorbild auch nicht tun, auch beim nachsortieren eines Nahgüterzuges.
* Schiebeloks sollten nicht selbst wissen, welcher Zug als nächstes kommt, sondern die Anweisungen sollten im Zug stehen
* Sofern Wegfindemechanismen zum Einsatz kommen, sollten diese bezüglich ZLB abgeklopft werden.

== Mutmaßlich separate Konzepte ==

* Ausziehgleis liegt beim Fdl des benachbarten Gbf (Rangieren über Streckenanschluss) => Automatische Rückkehr der Rangierfahrten
* Automatische Rückkehr einer Schiebelok
* Entkuppeln während der Fahrt von Schiebeloks und Abstoßbetrieben sowie der vermutlich ähnlich gelagerte Ablaufbetrieb und dem Bewegen von Einzelwagen mit Hand ("Verschieben") (Hinweis: Ablaufberg muss auch Oberammergau-Sicher sein)
* Ladegut-Konzept, Verbindung zu Rangieren sind Be- und Entladevorgänge.

Aufbau Bibliothek SpDrS60

2017-06-30T21:12:28Z

BorisM:

[[Kategorie:Aufbau Bibliotheken Bauformen]]
[[Kategorie:SpDrS60]]
= Ringleitungen =
== Tastenversorgung ==
Die Spannungsversorgung der Tasten des Stelltisches zählt nicht offiziell zu den Ringleitungen, da diese Schaltung im Original über den Tischverteiler und nicht über die einzelnen Relaisgruppen läuft. In StellSi wird die Spannungsversorgung der Tasten allerdings über Ringleitungen nachgebildet.

* <code>RingleitungParallel A1_Weichentasten;</code>
* <code>RingleitungParallel A2_Zugstrtasten;</code>
* <code>RingleitungParallel A3_Rangierstrtasten;</code>
* <code>RingleitungParallel Gruppentasten;</code>

Bitte Hinweise im [[#Tastenrelais|Abschnitt „Tastenrelais“]] beachten.

= Aufbau Relaisgruppen =
== Tastenrelais ==
Im SpDrS60 werden Tasten durch die Anschaltgruppe mit Spannung versorgt. Die Tasten sind dabei vier Gruppen zugeordnet: Weichentasten, Rangierstraßentasten, Zugstraßentasten sowie Gruppentasten. Die Kontakte der Tasten werden gruppenbezogen über den Tischverteiler mit Spannung versorgt, und können so gruppenweise durch die Anschaltgruppen abgeschaltet werden (z.B. be Tastenstörungen).

Im Gegensatz zum Original erfolgt die Prüfung der Ringleitung in dieser Bibliothek in der Relaisgruppe - kommt von einem Tischfeld das Signal, dass eine Taste gedrückt wurde, muss also zwingend immer noch zusätzlich die entsprechende Ringleitung auf Spannung überprüft werden!

Aufbau Bibliothek SpDrS60

2017-06-29T09:55:57Z

BorisM: /* Tastenversorgung */

[[Kategorie:Aufbau Bibliotheken Bauformen]]
[[Kategorie:SpDrS60]]
= Ringleitungen =
== Tastenversorgung ==
Die Spannungsversorgung der Tasten des Stelltisches zählt nicht offiziell zu den Ringleitungen, da diese SChaltung im Original über den Tischverteiler und nicht über die einzelnen Relaisgruppen läuft. In StellSi wird die Spannungsversorgung der Tasten allerdings über Ringleitungen nachgebildet.

A1_Weichentasten
A2_Zugstrtasten
A3_Rangierstrtasten
Gruppentasten

Bitte Hinweise im Abschnitt "Tastenrelais" beachten.

= Aufbau Relaisgruppen =
== Tastenrelais ==
Im SpDrS60 werden Tasten durch die Anschaltgruppe mit Spannung versorgt. Die Tasten sind dabei vier Gruppen zugeordnet: Weichentasten, Rangierstraßentasten, Zugstraßentasten sowie Gruppentasten. Die Kontakte der Tasten werden gruppenbezogen über den Tischverteiler mit Spannung versorgt, und können so gruppenweise durch die Anschaltgruppen abgeschaltet werden (z.B. be Tastenstörungen).

Im Gegensatz zum Original erfolgt die Prüfung der Ringleitung in dieser Bibliothek in der Relaisgruppe - kommt von einem Tischfeld das Signal, dass eine Taste gedrückt wurde, muss also zwingend immer noch zusätzlich die entsprechende Ringleitung auf Spannung überprüft werden!

Aufbau Bibliothek SpDrS60

2017-06-29T09:54:12Z

BorisM:

[[Kategorie:Aufbau Bibliotheken Bauformen]]
[[Kategorie:SpDrS60]]
= Ringleitungen =
== Tastenversorgung ==
A1_Weichentasten
A2_Zugstrtasten
A3_Rangierstrtasten
Gruppentasten

Bitte Hinweise im Abschnitt "Tastenrelais" beachten.

= Aufbau Relaisgruppen =
== Tastenrelais ==
Im SpDrS60 werden Tasten durch die Anschaltgruppe mit Spannung versorgt. Die Tasten sind dabei vier Gruppen zugeordnet: Weichentasten, Rangierstraßentasten, Zugstraßentasten sowie Gruppentasten. Die Kontakte der Tasten werden gruppenbezogen über den Tischverteiler mit Spannung versorgt, und können so gruppenweise durch die Anschaltgruppen abgeschaltet werden (z.B. be Tastenstörungen).

Im Gegensatz zum Original erfolgt die Prüfung der Ringleitung in dieser Bibliothek in der Relaisgruppe - kommt von einem Tischfeld das Signal, dass eine Taste gedrückt wurde, muss also zwingend immer noch zusätzlich die entsprechende Ringleitung auf Spannung überprüft werden!

Kategorie:Aufbau Bibliotheken Bauformen

2017-06-29T09:48:45Z

BorisM:

Die Seiten dieser Kategorie machen bauformspezifische Festlegungen zu bestimmten Bibliotheken. Hier werden z.B. Ringleitungsnamen, Vorgaben zum Skriptaufbau etc. genannt. Diese Seiten sollten vor dem Erstellen eigener (z.B. stellwerkspezifischer) Relaisgruppen gelesen werden.
[[Kategorie:Neue Bauform]]

Kategorie:Aufbau Bibliotheken Bauformen

2017-06-29T09:47:53Z

BorisM: Die Seite wurde neu angelegt: „Die Seiten dieser Kategorie machen bauformspezifische Festlegungen zu bestimmten Bibliotheken. Hier werden z.B. Ringleitungsnamen, Vorgaben zum Skriptaufbau et…“

Tutorial:Erstellen neuer Bauformen

2017-06-29T09:46:13Z

BorisM:

StellSi wurde in Hinblick auf eine möglichst große Flexibilität programmiert. Daher kann StellSi leicht um weitere Stellwerksbauformen erweitert werden.

Wie StellSi selbst untergliedert sich die Erstellung dabei in drei Bereiche:
* Den [[Stelltisch]], mit der Erstellung neuer [[Tischfeld]]er -> [[Tutorial:Erstellen neuer Tischfelder|Tutorial]]
* Die [[Relaisanlage]], mit der Erstellung neuer [[Relaisgruppe]]n -> [[Tutorial:Erstellen neuer Relaisgruppen|Tutorial]]
* Die [[Aussenanlage]], mit der Erstellung neuer [[Signal]]e -> [[Tutorial:Erstellen neuer Signale|Tutorial]]

[[:Kategorie:Aufbau Bibliotheken Bauformen|Aufbau der Bibliotheken spezifischer Bauformen]]

== Dinge, für die ich noch keinen Vernünftigen Ort habe ==
=== Benennungsrichtlinien ===
Benennungsrichtlinien für stwb:
* klein geschriebener Anfangsbuchstabe.
* Ein Begriff als camelCase (z.B. steuerungTasten)
* Verschiedene Begriffe durch _ getrennt (z.B. suh1912_relaisgruppen)

Benennungsrichtlinien für Ordner: (ToDo: Warum um alles in der Welt habe ich dort abweichende Vorgehensweisen etabliert????????)
* Nur kleinbuchstaben, kein _, Trennung durch -
* Die Unterordnernamen images, sounds, internal (für interne stwbs) und _common (allgemeiner Unterordner für Bauformübergreifende Dinge) sind ggf. zu verwenden.

Benennungsrichtlinien für Dateien (z.B. SVG):
* Nur die allgemeinen Regeln, nur a-z, A-Z, 0-9, _, -, keine Leer- oder Sonderzeichen.

Benennungsrichtlinien für vnames innerhalb von stwbs:
* klein geschriebener Anfangsbuchstabe.
* Nur a-z, A-Z, 0-9, _, -, keine Leer- oder Sonderzeichen.

=== Fenster -> Debug -> Signalliste ===
* L = Fenster leeren
* H = Alle Daten seit Programmstart wiederherstellen. Achtung: Das Zeichnen der Liste dauert ewig. Hilfreich sein kann das Laden von kleinen Stellwerken oder '''vorher''' einen geeigneten Filter auszuwählen!

* W-> Schnittstelle sendet Signal (Vorbereitung)
* ->W Schnittstelle sendet Signal (Ausführung) (Zusatz = bedeutet Wert hat sich nicht geändert.)
* W<- Schnittstelle empfängt Signal
* E-> Schnittstelle sendet Ereignis (Vorbereitung, Rest analog)
* ->| Schnittstelle sendet syncrones Signal
* <-| Schnittstelle empängt syncrones Signal
* W<-f Freie Eingangslogik empfängt (nur Empfänger werden seperat markiert)
* W<-a AngelScript empfängt (nur Empfänger werden seperat markiert, Anfang des Methodenaufrufes wird durch { Ende durch } markiert.)
* --a Diverse AngelScript-Methodenaufrufe, die in der Signalliste auftauchen. Es können auch die Zusätzte -init-f (Freie Eingangslogik), s (Schnittstele), ve (VerschlussregisterElement) oder vf (VerschlussFahrstrasse) auftauchen. Sie geben an, welche Methoden, die automatisch aufgerufen werden, gefunden wurden.

=== Außenanlage -> Nachbarstellwerk ===
Die Funktion, mehrere Außenanlagen zu verbinden erfordert im Moment größere Mengen an Konfigurationseinstellungen. Ich bin mir inzwischen nicht sicher, ob ich das dauerhaft so behalte oder nicht früher oder später Konzepte einsetze, die mit weniger Konfiguration auskommen.

* Allgemeine Hinweise:
** Sämmtliche konfigurationen finden in der Außenanlage statt.
** Es gilt wie bereits an anderer Stelle geschreiben: Der Streckenanschluss sollte sich auf Höhe des Einfahrsignals des Nachbarbahnhofs befinden.
* Registerkarte Nachbar
** Gruppenname: Bei beiden Stellwerken der gleiche Wert. Typischer Wert: "Astadt-Bstadt"
** Nachbarcode: Typsicher Wert: DS100-Abkürzung des Nachbarn.
** Version: Geben sie hier eine beliebige Version ein. Das Feld wird später einmal dazu verwendet, sich verändernde Schnittstellen zum Nachbarn festzustellen. Mit der StellSi-Version hat das nichts zu tun. Derzeit können sie z.B. einfach 1.0.0.0 angeben. (Der Standardwert ist eine ungültige Version, das sollte natürlich geändert werden.)
* Streckenanschluss => Produkte
** Abkürzung: Nur für Spezialanwendungen mit Drittsimulationen
** Eigenes: Lassen sie sich eine zufällig Uuid generieren und geben sie als Produkt den Namen des Bahnhofes ein
** Fügen Sie dann über Plus ein fremdes Produkt hinzu und kopieren sie dazu die Uuid und den Produktnamen des korespondierenden Streckenanschluss in der anderen Außenanlage.
* Streckenanschluss => Nachbar
** Fügen Sie alle Gleise und Signale zwischen dem Esig des Nachbarn (Streckenanschluss) und dem eigenen Esig (Höhe Streckenanschluss des Nachbarn) sowie den Streckenanschluss selbst hinzu. Wenn ihr Bahnhof als Esig ein echtes Signal hat, können Sie es ebenfalls hinzufügen.
** Wählen Sie am Streckenanschluss Kontrolle abgeben.
** Die Namen von Signalen müssen kreuzweise übereinstimmen. Eines der Signale muss als Kontrolle abgeben markiert sein und eine Relaisgruppe besitzen, die "nachbargesteuert" ist und daher Aktionen des Signals über das Netzwerk direkt ausführt.
** Der Streckenanschluss verhält sich so ähnlich wie ein Signal.
** Sie können auch für das eigene und das fremde Produkt den selben Namen für Signale oder Gleise verwenden.
** Gleise, bei denen Kontrolle abgeben angehakt ist, geben Züge, die zum Nachbarn fahren an diesen ab, sobald sie das Gleis betreten.
** Mehrere Gleise können den selben Namen haben, etwa wenn sie in der einen Außenanlage das Gleis zweigeteilt haben, weil sie das Vorsignal zum Einfahrsignal eingebaut haben, auf der anderen Außenanlage aber nicht. Die Summe der Gleislängen von Gleisen mit gleichem Namen sollte bei beiden Simulationen aber wenn möglich gleich sein.
* Verbindung herstellen
** Im deaktiverten Editmodus: Streckenanschluss => Nachbar auswählen => Verbinden um über Netzwer zu verbinden, oder um zu sehen, ob der Streckenanschluss verbunden ist.
** Wenn Sie beide betroffenen Außenanlagen laden wird die Verbindung beim laden automatisch hergestellt.
** Wenn Sie etwas geändert haben oder eine Meldung wollen, können Sie über Extras->Verbinden mit anderen lokalen Außenanlagen Verbindungen trennen oder neue Verbindungen wieder aufbauen.
** Wenn Außenanlagen lokal verbunden sind werden die Nachbarn im Fernsprecher ausgeblendet. Wenn Sie über Netzwerk verbunden sind wird Freitext anstatt formelle Buttons angeboten.

[[Kategorie:Neue Bauform|!]]

Aufbau Bibliothek SpDrS60

2017-06-29T09:45:53Z

BorisM: Die Seite wurde neu angelegt: „Kategorie:Aufbau Bibliotheken Bauformen Kategorie:SpDrS60“

[[Kategorie:Aufbau Bibliotheken Bauformen]]
[[Kategorie:SpDrS60]]

Tutorial:Erstellen neuer Bauformen

2017-06-29T09:41:36Z

BorisM:

StellSi wurde in Hinblick auf eine möglichst große Flexibilität programmiert. Daher kann StellSi leicht um weitere Stellwerksbauformen erweitert werden.

Wie StellSi selbst untergliedert sich die Erstellung dabei in drei Bereiche:
* Den [[Stelltisch]], mit der Erstellung neuer [[Tischfeld]]er -> [[Tutorial:Erstellen neuer Tischfelder|Tutorial]]
* Die [[Relaisanlage]], mit der Erstellung neuer [[Relaisgruppe]]n -> [[Tutorial:Erstellen neuer Relaisgruppen|Tutorial]]
* Die [[Aussenanlage]], mit der Erstellung neuer [[Signal]]e -> [[Tutorial:Erstellen neuer Signale|Tutorial]]

[[Kategorie:Aufbau Bibliotheken Bauformen|Aufbau der Bibliotheken spezifischer Bauformen]]

== Dinge, für die ich noch keinen Vernünftigen Ort habe ==
=== Benennungsrichtlinien ===
Benennungsrichtlinien für stwb:
* klein geschriebener Anfangsbuchstabe.
* Ein Begriff als camelCase (z.B. steuerungTasten)
* Verschiedene Begriffe durch _ getrennt (z.B. suh1912_relaisgruppen)

Benennungsrichtlinien für Ordner: (ToDo: Warum um alles in der Welt habe ich dort abweichende Vorgehensweisen etabliert????????)
* Nur kleinbuchstaben, kein _, Trennung durch -
* Die Unterordnernamen images, sounds, internal (für interne stwbs) und _common (allgemeiner Unterordner für Bauformübergreifende Dinge) sind ggf. zu verwenden.

Benennungsrichtlinien für Dateien (z.B. SVG):
* Nur die allgemeinen Regeln, nur a-z, A-Z, 0-9, _, -, keine Leer- oder Sonderzeichen.

Benennungsrichtlinien für vnames innerhalb von stwbs:
* klein geschriebener Anfangsbuchstabe.
* Nur a-z, A-Z, 0-9, _, -, keine Leer- oder Sonderzeichen.

=== Fenster -> Debug -> Signalliste ===
* L = Fenster leeren
* H = Alle Daten seit Programmstart wiederherstellen. Achtung: Das Zeichnen der Liste dauert ewig. Hilfreich sein kann das Laden von kleinen Stellwerken oder '''vorher''' einen geeigneten Filter auszuwählen!

* W-> Schnittstelle sendet Signal (Vorbereitung)
* ->W Schnittstelle sendet Signal (Ausführung) (Zusatz = bedeutet Wert hat sich nicht geändert.)
* W<- Schnittstelle empfängt Signal
* E-> Schnittstelle sendet Ereignis (Vorbereitung, Rest analog)
* ->| Schnittstelle sendet syncrones Signal
* <-| Schnittstelle empängt syncrones Signal
* W<-f Freie Eingangslogik empfängt (nur Empfänger werden seperat markiert)
* W<-a AngelScript empfängt (nur Empfänger werden seperat markiert, Anfang des Methodenaufrufes wird durch { Ende durch } markiert.)
* --a Diverse AngelScript-Methodenaufrufe, die in der Signalliste auftauchen. Es können auch die Zusätzte -init-f (Freie Eingangslogik), s (Schnittstele), ve (VerschlussregisterElement) oder vf (VerschlussFahrstrasse) auftauchen. Sie geben an, welche Methoden, die automatisch aufgerufen werden, gefunden wurden.

=== Außenanlage -> Nachbarstellwerk ===
Die Funktion, mehrere Außenanlagen zu verbinden erfordert im Moment größere Mengen an Konfigurationseinstellungen. Ich bin mir inzwischen nicht sicher, ob ich das dauerhaft so behalte oder nicht früher oder später Konzepte einsetze, die mit weniger Konfiguration auskommen.

* Allgemeine Hinweise:
** Sämmtliche konfigurationen finden in der Außenanlage statt.
** Es gilt wie bereits an anderer Stelle geschreiben: Der Streckenanschluss sollte sich auf Höhe des Einfahrsignals des Nachbarbahnhofs befinden.
* Registerkarte Nachbar
** Gruppenname: Bei beiden Stellwerken der gleiche Wert. Typischer Wert: "Astadt-Bstadt"
** Nachbarcode: Typsicher Wert: DS100-Abkürzung des Nachbarn.
** Version: Geben sie hier eine beliebige Version ein. Das Feld wird später einmal dazu verwendet, sich verändernde Schnittstellen zum Nachbarn festzustellen. Mit der StellSi-Version hat das nichts zu tun. Derzeit können sie z.B. einfach 1.0.0.0 angeben. (Der Standardwert ist eine ungültige Version, das sollte natürlich geändert werden.)
* Streckenanschluss => Produkte
** Abkürzung: Nur für Spezialanwendungen mit Drittsimulationen
** Eigenes: Lassen sie sich eine zufällig Uuid generieren und geben sie als Produkt den Namen des Bahnhofes ein
** Fügen Sie dann über Plus ein fremdes Produkt hinzu und kopieren sie dazu die Uuid und den Produktnamen des korespondierenden Streckenanschluss in der anderen Außenanlage.
* Streckenanschluss => Nachbar
** Fügen Sie alle Gleise und Signale zwischen dem Esig des Nachbarn (Streckenanschluss) und dem eigenen Esig (Höhe Streckenanschluss des Nachbarn) sowie den Streckenanschluss selbst hinzu. Wenn ihr Bahnhof als Esig ein echtes Signal hat, können Sie es ebenfalls hinzufügen.
** Wählen Sie am Streckenanschluss Kontrolle abgeben.
** Die Namen von Signalen müssen kreuzweise übereinstimmen. Eines der Signale muss als Kontrolle abgeben markiert sein und eine Relaisgruppe besitzen, die "nachbargesteuert" ist und daher Aktionen des Signals über das Netzwerk direkt ausführt.
** Der Streckenanschluss verhält sich so ähnlich wie ein Signal.
** Sie können auch für das eigene und das fremde Produkt den selben Namen für Signale oder Gleise verwenden.
** Gleise, bei denen Kontrolle abgeben angehakt ist, geben Züge, die zum Nachbarn fahren an diesen ab, sobald sie das Gleis betreten.
** Mehrere Gleise können den selben Namen haben, etwa wenn sie in der einen Außenanlage das Gleis zweigeteilt haben, weil sie das Vorsignal zum Einfahrsignal eingebaut haben, auf der anderen Außenanlage aber nicht. Die Summe der Gleislängen von Gleisen mit gleichem Namen sollte bei beiden Simulationen aber wenn möglich gleich sein.
* Verbindung herstellen
** Im deaktiverten Editmodus: Streckenanschluss => Nachbar auswählen => Verbinden um über Netzwer zu verbinden, oder um zu sehen, ob der Streckenanschluss verbunden ist.
** Wenn Sie beide betroffenen Außenanlagen laden wird die Verbindung beim laden automatisch hergestellt.
** Wenn Sie etwas geändert haben oder eine Meldung wollen, können Sie über Extras->Verbinden mit anderen lokalen Außenanlagen Verbindungen trennen oder neue Verbindungen wieder aufbauen.
** Wenn Außenanlagen lokal verbunden sind werden die Nachbarn im Fernsprecher ausgeblendet. Wenn Sie über Netzwerk verbunden sind wird Freitext anstatt formelle Buttons angeboten.

[[Kategorie:Neue Bauform|!]]

Development:Design Grafikraster

2017-05-08T07:54:38Z

BorisM: Die Seite wurde neu angelegt: „= Ziel = Das Grafikraster braucht dringend erweiterte Funktionen, um das angenehmere Erstellen von Anlagenteilen zu ermöglichen. Ziel ist ein möglichst groß…“

= Ziel =
Das Grafikraster braucht dringend erweiterte Funktionen, um das angenehmere Erstellen von Anlagenteilen zu ermöglichen. Ziel ist ein möglichst großer Komfort und intuitive Bedienbarkeit für den Stellwerksbauer. Beispiele:
* Ein "Rand" sollte automatisch erstellt werden können (z.B. Rand des Stelltisches)
* Es sollten unterschiedliche Zeilenhöhen/Spaltenbreiten realisiert werden können
* Ein Anlagenelement (Stelltisch, Blockkasten, ...) sollte mit einem einzigen Grafikraster realisiert werden können. Es werden keine manuellen Grafikraster benötigt!

Herausforderungen bieten dabei u.a. folgende Bauformen (bitte ergänzen!):
* EZMG (Trennung Leuchtmeldertafel sowie drei Tastenfelder)
* Felderblock mit seinen verschiedenen Etagen,der Möglichkeit weitere Bauteile an das Holz zu schrauben etc. (Anmerkung: Wie gehen wir hier mit dem Teil um, der Blocksperren, Fahrstrassenhebel etc enthält, was spezifisch zur Stellwerksbauform ist?)

Wunschliste (hier bitte alles Eintragen was man gern hätte, ohne die Realisierbarkeit zu betrachten):
* Flexible Spalten/Zeilenbreiten: Grafikraster passt sich selbst an Tischfeldgrößen an
* Möglichkeit, mehr als ein Element in ein Feld zu packen, was sich automatisch aufstapelt (z.B. Tastensperre, darunter manchmal Anschalter)
* Evtl. Subunterteilung von Zellen durch ein Untergrafikraster?

Anforderungen (Liste der umzusetzenden Funktionen):
* Grafikrasterbezogene Parameter, die an die Tischfelder weitergegeben werden können (z.B. Farbe Stelltisch o.ä.
* Automatische Erstellung von Randfeldern, Leerfeldern, ....
* Realisierung unterschiedlicher Zeilen/Spaltenbreiten möglich

[[Kategorie:Design_Stelltisch]]

Kategorie:Design Stelltisch

2017-05-08T07:41:17Z

BorisM:

[[Kategorie:Design_Allgemein]]

Kategorie:Design Stelltisch

2017-05-08T07:40:34Z

BorisM: Leere Seite erstellt

Development:Anforderungen Fahrplan

2015-12-27T14:12:52Z

BorisM:

== Basisanforderungen ==
{| class="wikitable sortable"
! Anforderung
|-
| Zugfahrten
|-
| Rangierfahrten
|-
| Gescheiter Editor (wie immer)
|-
| Am Besten mit einer JIT-Editierfähigkeit (alles Editierbar, was noch nicht benötigt verarbeitet wurde)
|-
| Rangierfahrteneinprogrammierung sollte eher Autonom ablaufen, und nicht viel Nutzerinteraktion benötigen
|-
| Verknüpfung von Zugfahrten außerhalb des Stellwerks (z.B. aus Zug 4711 wird außerhalb des Stellwerksbereich Zug 4712, Zug hat Wendezeit von x Minuten). Mit dieser Information ist es möglich die Verschleppung von Verspätungen auf rückkehrende Züge zu simulieren. Außerdem kann ein Zug vorzeitig gewendet werden, und das System weiß wie es vorzugehen hat.
|}

[[Kategorie:Anforderungen]]

Development:Design UndoRedo

2015-12-09T12:34:19Z

BorisM: /* Member list */

Status: Entwurf zur Diskussion

= Grundgedanken =
Das UndoRedo-System wird von den Klassen, die speicherbare Member besitzen, transparent intern gelöst. Dabei wird in den entsprechenden Setter-Methoden der Wert nicht mehr direkt gesetzt, sondern stattdessen das nötige UndeRedoObjekt generiert und an den UndoRedoManager übergeben. Dieser führt dann das Kommandoobjekt aus. Die Schnittstelle der Klasse nach außen wird dadurch nicht beeinflusst.

Eine Änderung des Zustandes der Klasse muss dabei immer zu einem konsistenten Datenstand führen. Daher gelten folgende Regeln:
1) Datenduplikation muss vermieden werden
2) Alle Klassen, die von Daten einer anderen Klasse abhängen, müssen bei einer Änderung benachrichtigt werden. Dafür kann z.B. das Beobachtermuster genutzt werden. Auf diese Art müssen z.B. die GUI-Elemente des Editors benachrichtigt werden, aber natürlich auch die eigentliche Simulationslogik u.ä.

= Klassenhierarchie =
TODO in Klassendiagramm umwandeln
(Beispielhaft: DateiVerwaltung)
enthält genau einen
UndoRedoManager
enthält Liste
UndoRedoObjekt
ist Basisklasse von
UndoRedoGeneric<typedef TypeData, TODO Funktionen die Verhalten spezifizieren>
UndoRedo{SpeziellerName}

TODO Präfix UndoRedo so in Ordnung oder lieber "Command" o.ä.?

= Klassen =
== UndoRedoManager ==
=== Konstruktor ===
Nimmt entgegen:
1) Wert, der gesetzt werden soll
2) Objekt, bei dem der Wert gesetzt werden soll
3) Do-Methode des Objekts, bei dem der Wert gesetzt werden soll
4) Undo-Methode des Objekts, bei dem der Wert gesetzt werden soll

=== Methode bool hasChangesSinceLastSafe ===
return lastSafe!=actualState

=== Methode redo() ===
++actualState;
actualState->do();
emitHasChanged();

=== Methode undo() ===
actualState->undo();
--actualState;

=== Methode addCommand(UndoRedoObject* command) ===
list.delete(actualState+1, list.end();
if (!actualState->tryAppendAndRun(command))
list.append(command);
command->do();
actualState=list.end()-1;

=== Methode notifyFileHasSaved() ===
lastSafe=actualState;

=== Private Methode emitHasChanged() ===
if (lastHasChanged!=hasChangesSinceLastSave)
lastHasChanged=hasChangesSinceLastSave;
emit hasChangesChanged(lastHasChanged);

=== Signal hasChangesChanged(bool fileIsChanged) ===

=== Member undoRedoList_ ===
Liste der Undo-Redo-Objekte

=== Member lastSafe ===
Iterator auf den Listeneintrag, der dem letzten Speichern entspricht

=== Member actualState ===
Iterator auf den Listeneintrag, der gerade aktuell ist

== UndoRedoObjekt ==

=== Methode Do ===
Führt den Befehl aus, speichert den alten Wert als Vorbereitung für undo()

=== Methode Undo ===
Führt den Befehl aus, speichert den alten Wert als Vorbereitung für do() (was in dem Fall ein redo ist)

=== Methode tryAppendAndRun(UndoRedoObjekt* command) ===
wenn Typ übereinstimmt, state stimmt und das Kommandoobjekt darauf ausgelegt ist: Führe aktuelle Änderung mit der letzten Änderung zusammen. Beispiel: Ein String wird mehrere Male hintereinander geändert (z.B. jeder Buchstabe löst ein Änderungssignal aus). In dem Fall sollte nicht für jeden Buchstaben ein eigenes Kommandoobjekt erzeugt werden, das macht die Änderungen so unpraktisch...

=== Member state ===
Hält die Information, ob das Objekt ausgeführt wurde oder rückgängig gemacht wurde

[[Kategorie:Design_Allgemein_Editoren]]

Development:Design UndoRedo

2015-12-09T12:01:33Z

BorisM: /* Methode fileHasBeenSaved() */

Status: Entwurf zur Diskussion

= Grundgedanken =
Das UndoRedo-System wird von den Klassen, die speicherbare Member besitzen, transparent intern gelöst. Dabei wird in den entsprechenden Setter-Methoden der Wert nicht mehr direkt gesetzt, sondern stattdessen das nötige UndeRedoObjekt generiert und an den UndoRedoManager übergeben. Dieser führt dann das Kommandoobjekt aus. Die Schnittstelle der Klasse nach außen wird dadurch nicht beeinflusst.

Eine Änderung des Zustandes der Klasse muss dabei immer zu einem konsistenten Datenstand führen. Daher gelten folgende Regeln:
1) Datenduplikation muss vermieden werden
2) Alle Klassen, die von Daten einer anderen Klasse abhängen, müssen bei einer Änderung benachrichtigt werden. Dafür kann z.B. das Beobachtermuster genutzt werden. Auf diese Art müssen z.B. die GUI-Elemente des Editors benachrichtigt werden, aber natürlich auch die eigentliche Simulationslogik u.ä.

= Klassenhierarchie =
TODO in Klassendiagramm umwandeln
(Beispielhaft: DateiVerwaltung)
enthält genau einen
UndoRedoManager
enthält Liste
UndoRedoObjekt
ist Basisklasse von
UndoRedoGeneric<typedef TypeData, TODO Funktionen die Verhalten spezifizieren>
UndoRedo{SpeziellerName}

TODO Präfix UndoRedo so in Ordnung oder lieber "Command" o.ä.?

= Klassen =
== UndoRedoManager ==
=== Konstruktor ===
Nimmt entgegen:
1) Wert, der gesetzt werden soll
2) Objekt, bei dem der Wert gesetzt werden soll
3) Do-Methode des Objekts, bei dem der Wert gesetzt werden soll
4) Undo-Methode des Objekts, bei dem der Wert gesetzt werden soll

=== Methode bool hasChangesSinceLastSafe ===
return lastSafe!=actualState

=== Methode redo() ===
++actualState;
actualState->do();
emitHasChanged();

=== Methode undo() ===
actualState->undo();
--actualState;

=== Methode addCommand(UndoRedoObject* command) ===
list.delete(actualState+1, list.end();
if (!actualState->tryAppendAndRun(command))
list.append(command);
command->do();
actualState=list.end()-1;

=== Methode notifyFileHasSaved() ===
lastSafe=actualState;

=== Private Methode emitHasChanged() ===
if (lastHasChanged!=hasChangesSinceLastSave)
lastHasChanged=hasChangesSinceLastSave;
emit hasChangesChanged(lastHasChanged);

=== Signal hasChangesChanged(bool fileIsChanged) ===

=== Member list ===
Liste der Undo-Redo-Objekte

=== Member lastSafe ===
Iterator auf den Listeneintrag, der dem letzten Speichern entspricht

=== Member actualState ===
Iterator auf den Listeneintrag, der gerade aktuell ist

== UndoRedoObjekt ==

=== Methode Do ===
Führt den Befehl aus, speichert den alten Wert als Vorbereitung für undo()

=== Methode Undo ===
Führt den Befehl aus, speichert den alten Wert als Vorbereitung für do() (was in dem Fall ein redo ist)

=== Methode tryAppendAndRun(UndoRedoObjekt* command) ===
wenn Typ übereinstimmt, state stimmt und das Kommandoobjekt darauf ausgelegt ist: Führe aktuelle Änderung mit der letzten Änderung zusammen. Beispiel: Ein String wird mehrere Male hintereinander geändert (z.B. jeder Buchstabe löst ein Änderungssignal aus). In dem Fall sollte nicht für jeden Buchstaben ein eigenes Kommandoobjekt erzeugt werden, das macht die Änderungen so unpraktisch...

=== Member state ===
Hält die Information, ob das Objekt ausgeführt wurde oder rückgängig gemacht wurde

[[Kategorie:Design_Allgemein_Editoren]]

Development:Design UndoRedo

2015-12-09T12:00:07Z

BorisM: /* Methode appendCommand(UndoRedoObject* command) */

Status: Entwurf zur Diskussion

= Grundgedanken =
Das UndoRedo-System wird von den Klassen, die speicherbare Member besitzen, transparent intern gelöst. Dabei wird in den entsprechenden Setter-Methoden der Wert nicht mehr direkt gesetzt, sondern stattdessen das nötige UndeRedoObjekt generiert und an den UndoRedoManager übergeben. Dieser führt dann das Kommandoobjekt aus. Die Schnittstelle der Klasse nach außen wird dadurch nicht beeinflusst.

Eine Änderung des Zustandes der Klasse muss dabei immer zu einem konsistenten Datenstand führen. Daher gelten folgende Regeln:
1) Datenduplikation muss vermieden werden
2) Alle Klassen, die von Daten einer anderen Klasse abhängen, müssen bei einer Änderung benachrichtigt werden. Dafür kann z.B. das Beobachtermuster genutzt werden. Auf diese Art müssen z.B. die GUI-Elemente des Editors benachrichtigt werden, aber natürlich auch die eigentliche Simulationslogik u.ä.

= Klassenhierarchie =
TODO in Klassendiagramm umwandeln
(Beispielhaft: DateiVerwaltung)
enthält genau einen
UndoRedoManager
enthält Liste
UndoRedoObjekt
ist Basisklasse von
UndoRedoGeneric<typedef TypeData, TODO Funktionen die Verhalten spezifizieren>
UndoRedo{SpeziellerName}

TODO Präfix UndoRedo so in Ordnung oder lieber "Command" o.ä.?

= Klassen =
== UndoRedoManager ==
=== Konstruktor ===
Nimmt entgegen:
1) Wert, der gesetzt werden soll
2) Objekt, bei dem der Wert gesetzt werden soll
3) Do-Methode des Objekts, bei dem der Wert gesetzt werden soll
4) Undo-Methode des Objekts, bei dem der Wert gesetzt werden soll

=== Methode bool hasChangesSinceLastSafe ===
return lastSafe!=actualState

=== Methode redo() ===
++actualState;
actualState->do();
emitHasChanged();

=== Methode undo() ===
actualState->undo();
--actualState;

=== Methode addCommand(UndoRedoObject* command) ===
list.delete(actualState+1, list.end();
if (!actualState->tryAppendAndRun(command))
list.append(command);
command->do();
actualState=list.end()-1;

=== Methode fileHasBeenSaved() ===
lastSafe=actualState;

=== Private Methode emitHasChanged() ===
if (lastHasChanged!=hasChangesSinceLastSave)
lastHasChanged=hasChangesSinceLastSave;
emit hasChangesChanged(lastHasChanged);

=== Signal hasChangesChanged(bool fileIsChanged) ===

=== Member list ===
Liste der Undo-Redo-Objekte

=== Member lastSafe ===
Iterator auf den Listeneintrag, der dem letzten Speichern entspricht

=== Member actualState ===
Iterator auf den Listeneintrag, der gerade aktuell ist

== UndoRedoObjekt ==

=== Methode Do ===
Führt den Befehl aus, speichert den alten Wert als Vorbereitung für undo()

=== Methode Undo ===
Führt den Befehl aus, speichert den alten Wert als Vorbereitung für do() (was in dem Fall ein redo ist)

=== Methode tryAppendAndRun(UndoRedoObjekt* command) ===
wenn Typ übereinstimmt, state stimmt und das Kommandoobjekt darauf ausgelegt ist: Führe aktuelle Änderung mit der letzten Änderung zusammen. Beispiel: Ein String wird mehrere Male hintereinander geändert (z.B. jeder Buchstabe löst ein Änderungssignal aus). In dem Fall sollte nicht für jeden Buchstaben ein eigenes Kommandoobjekt erzeugt werden, das macht die Änderungen so unpraktisch...

=== Member state ===
Hält die Information, ob das Objekt ausgeführt wurde oder rückgängig gemacht wurde

[[Kategorie:Design_Allgemein_Editoren]]

Kategorie:Design

2015-12-08T21:00:58Z

BorisM:

Überblick über alle Designfestlegungen

[[Kategorie:Entwicklung]]

Development:Design UndoRedo

2015-12-08T12:10:14Z

BorisM:

Status: Entwurf zur Diskussion

= Grundgedanken =
Das UndoRedo-System wird von den Klassen, die speicherbare Member besitzen, transparent intern gelöst. Dabei wird in den entsprechenden Setter-Methoden der Wert nicht mehr direkt gesetzt, sondern stattdessen das nötige UndeRedoObjekt generiert und an den UndoRedoManager übergeben. Dieser führt dann das Kommandoobjekt aus. Die Schnittstelle der Klasse nach außen wird dadurch nicht beeinflusst.

Eine Änderung des Zustandes der Klasse muss dabei immer zu einem konsistenten Datenstand führen. Daher gelten folgende Regeln:
1) Datenduplikation muss vermieden werden
2) Alle Klassen, die von Daten einer anderen Klasse abhängen, müssen bei einer Änderung benachrichtigt werden. Dafür kann z.B. das Beobachtermuster genutzt werden. Auf diese Art müssen z.B. die GUI-Elemente des Editors benachrichtigt werden, aber natürlich auch die eigentliche Simulationslogik u.ä.

= Klassenhierarchie =
TODO in Klassendiagramm umwandeln
(Beispielhaft: DateiVerwaltung)
enthält genau einen
UndoRedoManager
enthält Liste
UndoRedoObjekt
ist Basisklasse von
UndoRedoGeneric<typedef TypeData, TODO Funktionen die Verhalten spezifizieren>
UndoRedo{SpeziellerName}

TODO Präfix UndoRedo so in Ordnung oder lieber "Command" o.ä.?

= Klassen =
== UndoRedoManager ==
=== Konstruktor ===
Nimmt entgegen:
1) Wert, der gesetzt werden soll
2) Objekt, bei dem der Wert gesetzt werden soll
3) Do-Methode des Objekts, bei dem der Wert gesetzt werden soll
4) Undo-Methode des Objekts, bei dem der Wert gesetzt werden soll

=== Methode bool hasChangesSinceLastSafe ===
return lastSafe!=actualState

=== Methode redo() ===
++actualState;
actualState->do();
emitHasChanged();

=== Methode undo() ===
actualState->undo();
--actualState;

=== Methode appendCommand(UndoRedoObject* command) ===
list.delete(actualState+1, list.end();
if (!actualState->tryAppendAndRun(command))
list.append(command);
command->do();
actualState=list.end()-1;

=== Methode fileHasBeenSaved() ===
lastSafe=actualState;

=== Private Methode emitHasChanged() ===
if (lastHasChanged!=hasChangesSinceLastSave)
lastHasChanged=hasChangesSinceLastSave;
emit hasChangesChanged(lastHasChanged);

=== Signal hasChangesChanged(bool fileIsChanged) ===

=== Member list ===
Liste der Undo-Redo-Objekte

=== Member lastSafe ===
Iterator auf den Listeneintrag, der dem letzten Speichern entspricht

=== Member actualState ===
Iterator auf den Listeneintrag, der gerade aktuell ist

== UndoRedoObjekt ==

=== Methode Do ===
Führt den Befehl aus, speichert den alten Wert als Vorbereitung für undo()

=== Methode Undo ===
Führt den Befehl aus, speichert den alten Wert als Vorbereitung für do() (was in dem Fall ein redo ist)

=== Methode tryAppendAndRun(UndoRedoObjekt* command) ===
wenn Typ übereinstimmt, state stimmt und das Kommandoobjekt darauf ausgelegt ist: Führe aktuelle Änderung mit der letzten Änderung zusammen. Beispiel: Ein String wird mehrere Male hintereinander geändert (z.B. jeder Buchstabe löst ein Änderungssignal aus). In dem Fall sollte nicht für jeden Buchstaben ein eigenes Kommandoobjekt erzeugt werden, das macht die Änderungen so unpraktisch...

=== Member state ===
Hält die Information, ob das Objekt ausgeführt wurde oder rückgängig gemacht wurde

[[Kategorie:Design_Allgemein_Editoren]]

Development:Design UndoRedo

2015-12-08T11:25:35Z

BorisM: Die Seite wurde neu angelegt: „Kategorie:Design_Allgemein_Editoren“

[[Kategorie:Design_Allgemein_Editoren]]

Kategorie:Design Allgemein

2015-12-08T11:24:48Z

BorisM: Die Seite wurde neu angelegt: „Kategorie:Design“

[[Kategorie:Design]]

Kategorie:Design Allgemein Editoren

2015-12-08T11:23:48Z

BorisM: Die Seite wurde neu angelegt: „Kategorie:Design_Allgemein“

[[Kategorie:Design_Allgemein]]

Kategorie:Design

2015-12-08T11:21:27Z

BorisM:

Überblick über alle Designfestlegungen

[[Kategorie:Anforderungen]]

Kategorie:Design

2015-12-08T11:18:12Z

BorisM: Die Seite wurde neu angelegt: „Überblick über alle Designfestlegungen“

Überblick über alle Designfestlegungen

Kategorie:Entwicklung

2015-12-08T11:17:40Z

BorisM: Die Seite wurde neu angelegt: „Einstiegsseite für alle Ezntwicklungsseiten“

Einstiegsseite für alle Ezntwicklungsseiten

Kategorie:Anforderungen

2015-12-08T11:17:05Z

BorisM:

Diese Kategorie enthält alle Seiten, die Anforderungen an das Programm beschreiben.

[[Kategorie:Entwicklung]]

Development:Überarbeitung Skripting

2015-10-28T10:48:06Z

BorisM: /* Anforderungen */

= Grundlagen =
* Einführung eines zustandsbasierten Skriptsystems (im folgenden vorläufig SimpleScript genannt) als Ergänzung zu AngelScript
* Bessere Verknüpfung des zu steuernden Objekts (Relaisgruppe, Tischfeld, ...) mit dem Skripting

= Anforderungen =
= Datentypen =
* integer
* Gleitkomma
* String
* Bool?
* VHDL-inspirierter Datentyp? ( http://www.cs.sfu.ca/~ggbaker/reference/std_logic/1164/std_logic.html )
== AngelScript ==
=== Eingang von Daten von außen ===
Formulierung von SimpleScript-Ausdrücken in den Metadaten von Methoden. Ein Ausdruck pro Parameter.
Wenn sich das Ergebnis des Ausdrucks ändert, wird die Methode aufgerufen. Dies ersetzt die Auswertung des Methodennamen vollständig (bis auf Abwärtskompatibilität)

=== Ausgabe von Daten ===
Der AngelScript-Klasse wird eine automatische generierte Klasse zur Verfügung gestellt, über die ein Zugriff auf die Daten des gesteuerten Tischfeldes, Relaisgruppe, ... zur Verfügung gestellt wird. Vorbild ist die "ui"-Membervariable von mit QT Designer erstellten Widgets.

Bei einem Tischfeld sind z.B. die Schnittstellen, aber auch die GUI-Elemente (Bitmap, SVG, Taster, ...) auf diese Weise erreichbar. Realisierbarkeit von Animationen bedenken!

TODO: Einbindung von SimpleScript auch zur Ausgabe der Daten. Beispiel: Die Daten, die auf einer Schnittstelle, an der ein Tischfeld angeschlossen werden kann, ausgegeben werden sollen, sollen auch per SimpleScript generierbar sein aus den internen Daten der Relaisgruppe.

Per AngelScript ist die Zuweisung von SimpleScript-Anweisungen an externe Elemente (z.B. eine Grafik) möglich. Damit kann z.B. in verschiedenen Phasen einer Animation die Berechnungsvorschrift für Position, Drehung o.ä. dynamisch angepasst werden. TODO Effizienz beachten - sollte nicht jedes mal ein erneutes Parsen verlangen...

== SimpleScript ==
* Datenabruf von Leitungen einer SChnittstelle, reagiert auf Änderungen automatisch
* Analog dazu auch von Tastern, Zuständen (brauchen wir die noch??), ...
* TODO: Enthält geeignete Strukturen, um Relaisschaltungen zu simulieren
* Operatoren (+, -, &&, ||, ...)
* Bereitstellung von Kennlinien? (Idee aus dem Soundthesizer)
* Bereitstellung von Funktionen inklusive return-Anweisung. TODO: Wo werden die Funktionen definiert? Müssen auch in stwb zur Verfügung stehen!
* Anwendung überall, wo Daten eingehen
* Ersetzt die Eingangslogik
* Bereitstellung eines grafischen Editors (als Alternative zur Texteingabe)
* Bereitstellung Syntaxprüfung/automatische Ergänzung bei Eingabe in Textfeldern

= Realisierungsmöglichkeiten =
SimpleScript: Entwurfsmuster "Interpreter" oder http://www.antlr.org/

= Lose Gedankensammlung =
* \exists Zustand
** Input1: SimpleScript, in Abhängigket von:
*** Zustände
*** Automaten
*** Script-Interop-Automaten
*** Eingangs-Adern
** Wert: Der Wert, den das Simple-Script berechnet hat. (Wird immer automaisch aktualisiert)
* \exists Automat
** Input1: Startwert
** Input2...n:
*** Param1: Schnittstelle + Impulsname
*** Param2: Eingangsfilter: So ähnlich wie ein SimpleScript, gibt jedoch ein bool zurück, kann zugreifen auf
**** Zustände
**** Automaten
**** Script-Interop-Automaten
**** Eingangs-Adern
**** Den Wert des Signals
*** Param3: Setzwert-Script: So ähnlich wie ein SimpleScript, gibt den int zurück, den der Automat am Ende haben soll. Zugriff auf Werte wie vorhergehend.
** Wert: Den zuletzt gesetzten Wert
* \exists Eingangs-Ader
** Input1: Schnittstelle + Adername
** Wert: Den Wert der Eingangs-Ader
* \exists Ausgangs-Ader
** Input1: Schnittstelle + Adername
** Input2: Ein Automat oder Zustand, dessen Wert die Ausgangs-Ader immer haben soll.
** Gibt keinen Wert zurück
* \exists Ausgangs-Impuls
** Input 1...n:
*** Params: Analog zum Impuls. - Oder -
** Input n...m:
*** Param1: Zustand oder Automat
*** Param2: Eingangsfilter: So ähnlich wie SimpleScipt, ...
**** Zustände
**** Automaten
**** Script-Interop-Automaten
**** Eingangs-Adern
**** Den alten Wert des Zustandes
**** Den neuen Wert des Zustandes
*** Param3: Wert des Impuleses: So ähnl... Zugriff auf Werte wie vorhergehend.
** Gibt keinen Wert zurück
* \exists Script-Interop-Automat (nur Relaisanlage)
** Hat neben dem Getter und dem Changed-Event (siehe unten) auch noch einen setter.
** Wert: Der Wert, der als letztes vom Code im Setter gesetzt wurde

Alles was Werte hat, kann von einem Tischfeld abgefragt werden.

In der Relaisanlage haben alle Objekte mit Werten eine Changed(int old, int new)-Eigenschaft, zudem haben sie einen Getter.

= Aktueller Diskussionsstand =
* Zustände := SimpleScripts in Abhängigkeit von (Zustände, die vorher in der Liste definiert wurden, siehe Punkt 2; Automaten)
** Welches Script: via AS auswählbar
** Verwendung von Zyklenverhinderung statt Zyklenerkennung, wo möglich.
* Automaten, die für die Verarbeitung von Ereignissen zuständig sind.
* Alle Werte in TischfeldGrafiken Scriptierbar, ob man sie später auch auslesen kann, ist noch zu diskutieren. Möglicherweise kann man diese zwei Punkte aber auch erst einmal verschieben, nur Konzeptionell muss es bedacht werden.

[[Kategorie:Anforderungen]]
[[Kategorie:Umbauplanung_Boris]]

Development:Überarbeitung Skripting

2015-10-28T10:47:51Z

BorisM: /* Anforderungen */

= Grundlagen =
* Einführung eines zustandsbasierten Skriptsystems (im folgenden vorläufig SimpleScript genannt) als Ergänzung zu AngelScript
* Bessere Verknüpfung des zu steuernden Objekts (Relaisgruppe, Tischfeld, ...) mit dem Skripting

= Anforderungen =
= Datentypen
* integer
* Gleitkomma
* Bool?
* VHDL-inspirierter Datentyp? ( http://www.cs.sfu.ca/~ggbaker/reference/std_logic/1164/std_logic.html )
== AngelScript ==
=== Eingang von Daten von außen ===
Formulierung von SimpleScript-Ausdrücken in den Metadaten von Methoden. Ein Ausdruck pro Parameter.
Wenn sich das Ergebnis des Ausdrucks ändert, wird die Methode aufgerufen. Dies ersetzt die Auswertung des Methodennamen vollständig (bis auf Abwärtskompatibilität)

=== Ausgabe von Daten ===
Der AngelScript-Klasse wird eine automatische generierte Klasse zur Verfügung gestellt, über die ein Zugriff auf die Daten des gesteuerten Tischfeldes, Relaisgruppe, ... zur Verfügung gestellt wird. Vorbild ist die "ui"-Membervariable von mit QT Designer erstellten Widgets.

Bei einem Tischfeld sind z.B. die Schnittstellen, aber auch die GUI-Elemente (Bitmap, SVG, Taster, ...) auf diese Weise erreichbar. Realisierbarkeit von Animationen bedenken!

TODO: Einbindung von SimpleScript auch zur Ausgabe der Daten. Beispiel: Die Daten, die auf einer Schnittstelle, an der ein Tischfeld angeschlossen werden kann, ausgegeben werden sollen, sollen auch per SimpleScript generierbar sein aus den internen Daten der Relaisgruppe.

Per AngelScript ist die Zuweisung von SimpleScript-Anweisungen an externe Elemente (z.B. eine Grafik) möglich. Damit kann z.B. in verschiedenen Phasen einer Animation die Berechnungsvorschrift für Position, Drehung o.ä. dynamisch angepasst werden. TODO Effizienz beachten - sollte nicht jedes mal ein erneutes Parsen verlangen...

== SimpleScript ==
* Datenabruf von Leitungen einer SChnittstelle, reagiert auf Änderungen automatisch
* Analog dazu auch von Tastern, Zuständen (brauchen wir die noch??), ...
* TODO: Enthält geeignete Strukturen, um Relaisschaltungen zu simulieren
* Operatoren (+, -, &&, ||, ...)
* Bereitstellung von Kennlinien? (Idee aus dem Soundthesizer)
* Bereitstellung von Funktionen inklusive return-Anweisung. TODO: Wo werden die Funktionen definiert? Müssen auch in stwb zur Verfügung stehen!
* Anwendung überall, wo Daten eingehen
* Ersetzt die Eingangslogik
* Bereitstellung eines grafischen Editors (als Alternative zur Texteingabe)
* Bereitstellung Syntaxprüfung/automatische Ergänzung bei Eingabe in Textfeldern

= Realisierungsmöglichkeiten =
SimpleScript: Entwurfsmuster "Interpreter" oder http://www.antlr.org/

= Lose Gedankensammlung =
* \exists Zustand
** Input1: SimpleScript, in Abhängigket von:
*** Zustände
*** Automaten
*** Script-Interop-Automaten
*** Eingangs-Adern
** Wert: Der Wert, den das Simple-Script berechnet hat. (Wird immer automaisch aktualisiert)
* \exists Automat
** Input1: Startwert
** Input2...n:
*** Param1: Schnittstelle + Impulsname
*** Param2: Eingangsfilter: So ähnlich wie ein SimpleScript, gibt jedoch ein bool zurück, kann zugreifen auf
**** Zustände
**** Automaten
**** Script-Interop-Automaten
**** Eingangs-Adern
**** Den Wert des Signals
*** Param3: Setzwert-Script: So ähnlich wie ein SimpleScript, gibt den int zurück, den der Automat am Ende haben soll. Zugriff auf Werte wie vorhergehend.
** Wert: Den zuletzt gesetzten Wert
* \exists Eingangs-Ader
** Input1: Schnittstelle + Adername
** Wert: Den Wert der Eingangs-Ader
* \exists Ausgangs-Ader
** Input1: Schnittstelle + Adername
** Input2: Ein Automat oder Zustand, dessen Wert die Ausgangs-Ader immer haben soll.
** Gibt keinen Wert zurück
* \exists Ausgangs-Impuls
** Input 1...n:
*** Params: Analog zum Impuls. - Oder -
** Input n...m:
*** Param1: Zustand oder Automat
*** Param2: Eingangsfilter: So ähnlich wie SimpleScipt, ...
**** Zustände
**** Automaten
**** Script-Interop-Automaten
**** Eingangs-Adern
**** Den alten Wert des Zustandes
**** Den neuen Wert des Zustandes
*** Param3: Wert des Impuleses: So ähnl... Zugriff auf Werte wie vorhergehend.
** Gibt keinen Wert zurück
* \exists Script-Interop-Automat (nur Relaisanlage)
** Hat neben dem Getter und dem Changed-Event (siehe unten) auch noch einen setter.
** Wert: Der Wert, der als letztes vom Code im Setter gesetzt wurde

Alles was Werte hat, kann von einem Tischfeld abgefragt werden.

In der Relaisanlage haben alle Objekte mit Werten eine Changed(int old, int new)-Eigenschaft, zudem haben sie einen Getter.

= Aktueller Diskussionsstand =
* Zustände := SimpleScripts in Abhängigkeit von (Zustände, die vorher in der Liste definiert wurden, siehe Punkt 2; Automaten)
** Welches Script: via AS auswählbar
** Verwendung von Zyklenverhinderung statt Zyklenerkennung, wo möglich.
* Automaten, die für die Verarbeitung von Ereignissen zuständig sind.
* Alle Werte in TischfeldGrafiken Scriptierbar, ob man sie später auch auslesen kann, ist noch zu diskutieren. Möglicherweise kann man diese zwei Punkte aber auch erst einmal verschieben, nur Konzeptionell muss es bedacht werden.

[[Kategorie:Anforderungen]]
[[Kategorie:Umbauplanung_Boris]]

Development:Anforderungen Sound

2015-10-27T13:09:39Z

BorisM:

Einstellbare Werte:
* Lautstärke
* Position (Pan oder Laufzeitunterschied). Soll Position auch innerhalb eines Stellwerk variiert werden können?
* Frequenz? (wird im Soundthesizer zur Unterscheidung verschiedener Geschwindigkeiten o.ä. genutzt)
* An/aus
* Loop, einzeln. Für einzelnes auslösen ggf. Wahl zwischen bei steigender Flanke, bei fallender Flanke, oder bei beiden Flanken (Idee aus Soundthesizer), aber das ist vermutlich schon durch die ebenen vorher abgedeckt?

Verknüpfung von Sounds:
* Einleitung
* Mittelteil
* Ausleitung
* Ggf. setzen von Abbruchpunkten, d.h. Ende eines Sounds kann nicht an beliebiger Stelle erfolgen, sondern z.B. nur zwischen den einzelnen Schlägen eines langsam schlagenden Weckers, oder an geeigneten Verknüpfungspunkten zum Ausleitungssound?

Implementierung:
* Verschiedenen Soundengines möglich (ggf. sogar per Plugin?) -> Basisklasse, von der die einzelnen Engines erben, welche genutzt wird ist konfigurierbar
* Umschaltung entweder nur mit Neustart oder auch zu Laufzeit?
* Soundengine benötigt eigenen Thread (wie gehabt)
* Klasse "Soundfile" legt einzelne Datei fest, Klasse "Sound" verknüpft mehrere Dateien nach Bedingungen (z.B. Einleitungssound, Mittelteilsound, Ausleitungssound)
* Erzeugung von Objekten der Klasse Soundfile (und ggf. weiterer Klassen) per Fabrikmethode der Soundengine zur Kapselung der Implementierungsdetails der jeweiligen Soundengine

[[Kategorie:Anforderungen]]

Development:Überarbeitung Skripting

2015-10-27T13:03:04Z

BorisM: /* SimpleScript */

= Grundlagen =
* Einführung eines zustandsbasierten Skriptsystems (im folgenden vorläufig SimpleScript genannt) als Ergänzung zu AngelScript
* Bessere Verknüpfung des zu steuernden Objekts (Relaisgruppe, Tischfeld, ...) mit dem Skripting

= Anforderungen =
== AngelScript ==
=== Eingang von Daten von außen ===
Formulierung von SimpleScript-Ausdrücken in den Metadaten von Methoden. Ein Ausdruck pro Parameter.
Wenn sich das Ergebnis des Ausdrucks ändert, wird die Methode aufgerufen. Dies ersetzt die Auswertung des Methodennamen vollständig (bis auf Abwärtskompatibilität)

=== Ausgabe von Daten ===
Der AngelScript-Klasse wird eine automatische generierte Klasse zur Verfügung gestellt, über die ein Zugriff auf die Daten des gesteuerten Tischfeldes, Relaisgruppe, ... zur Verfügung gestellt wird. Vorbild ist die "ui"-Membervariable von mit QT Designer erstellten Widgets.

Bei einem Tischfeld sind z.B. die Schnittstellen, aber auch die GUI-Elemente (Bitmap, SVG, Taster, ...) auf diese Weise erreichbar. Realisierbarkeit von Animationen bedenken!

TODO: Einbindung von SimpleScript auch zur Ausgabe der Daten. Beispiel: Die Daten, die auf einer Schnittstelle, an der ein Tischfeld angeschlossen werden kann, ausgegeben werden sollen, sollen auch per SimpleScript generierbar sein aus den internen Daten der Relaisgruppe.

Per AngelScript ist die Zuweisung von SimpleScript-Anweisungen an externe Elemente (z.B. eine Grafik) möglich. Damit kann z.B. in verschiedenen Phasen einer Animation die Berechnungsvorschrift für Position, Drehung o.ä. dynamisch angepasst werden. TODO Effizienz beachten - sollte nicht jedes mal ein erneutes Parsen verlangen...

== SimpleScript ==
* Datenabruf von Leitungen einer SChnittstelle, reagiert auf Änderungen automatisch
* Analog dazu auch von Tastern, Zuständen (brauchen wir die noch??), ...
* TODO: Enthält geeignete Strukturen, um Relaisschaltungen zu simulieren
* Operatoren (+, -, &&, ||, ...)
* Bereitstellung von Kennlinien? (Idee aus dem Soundthesizer)
* Bereitstellung von Funktionen inklusive return-Anweisung. TODO: Wo werden die Funktionen definiert? Müssen auch in stwb zur Verfügung stehen!
* Anwendung überall, wo Daten eingehen
* Ersetzt die Eingangslogik
* Bereitstellung eines grafischen Editors (als Alternative zur Texteingabe)
* Bereitstellung Syntaxprüfung/automatische Ergänzung bei Eingabe in Textfeldern

= Realisierungsmöglichkeiten =
SimpleScript: Entwurfsmuster "Interpreter" oder http://www.antlr.org/

= Lose Gedankensammlung =
* \exists Zustand
** Input1: SimpleScript, in Abhängigket von:
*** Zustände
*** Automaten
*** Script-Interop-Automaten
*** Eingangs-Adern
** Wert: Der Wert, den das Simple-Script berechnet hat. (Wird immer automaisch aktualisiert)
* \exists Automat
** Input1: Startwert
** Input2...n:
*** Param1: Schnittstelle + Impulsname
*** Param2: Eingangsfilter: So ähnlich wie ein SimpleScript, gibt jedoch ein bool zurück, kann zugreifen auf
**** Zustände
**** Automaten
**** Script-Interop-Automaten
**** Eingangs-Adern
**** Den Wert des Signals
*** Param3: Setzwert-Script: So ähnlich wie ein SimpleScript, gibt den int zurück, den der Automat am Ende haben soll. Zugriff auf Werte wie vorhergehend.
** Wert: Den zuletzt gesetzten Wert
* \exists Eingangs-Ader
** Input1: Schnittstelle + Adername
** Wert: Den Wert der Eingangs-Ader
* \exists Ausgangs-Ader
** Input1: Schnittstelle + Adername
** Input2: Ein Automat oder Zustand, dessen Wert die Ausgangs-Ader immer haben soll.
** Gibt keinen Wert zurück
* \exists Ausgangs-Impuls
** Input 1...n:
*** Params: Analog zum Impuls. - Oder -
** Input n...m:
*** Param1: Zustand oder Automat
*** Param2: Eingangsfilter: So ähnlich wie SimpleScipt, ...
**** Zustände
**** Automaten
**** Script-Interop-Automaten
**** Eingangs-Adern
**** Den alten Wert des Zustandes
**** Den neuen Wert des Zustandes
*** Param3: Wert des Impuleses: So ähnl... Zugriff auf Werte wie vorhergehend.
** Gibt keinen Wert zurück
* \exists Script-Interop-Automat (nur Relaisanlage)
** Hat neben dem Getter und dem Changed-Event (siehe unten) auch noch einen setter.
** Wert: Der Wert, der als letztes vom Code im Setter gesetzt wurde

Alles was Werte hat, kann von einem Tischfeld abgefragt werden.

In der Relaisanlage haben alle Objekte mit Werten eine Changed(int old, int new)-Eigenschaft, zudem haben sie einen Getter.

= Aktueller Diskussionsstand =
* Zustände := SimpleScripts in Abhängigkeit von (Zustände, die vorher in der Liste definiert wurden, siehe Punkt 2; Automaten)
** Welches Script: via AS auswählbar
** Verwendung von Zyklenverhinderung statt Zyklenerkennung, wo möglich.
* Automaten, die für die Verarbeitung von Ereignissen zuständig sind.
* Alle Werte in TischfeldGrafiken Scriptierbar, ob man sie später auch auslesen kann, ist noch zu diskutieren. Möglicherweise kann man diese zwei Punkte aber auch erst einmal verschieben, nur Konzeptionell muss es bedacht werden.

[[Kategorie:Anforderungen]]
[[Kategorie:Umbauplanung_Boris]]

Development:Anforderungen Sound

2015-10-27T13:02:17Z

BorisM:

Einstellbare Werte:
* Lautstärke
* Position (Pan oder Laufzeitunterschied)
* Frequenz? (wird im Soundthesizer zur Unterscheidung verschiedener Geschwindigkeiten o.ä. genutzt)
* An/aus
* Loop, einzeln

Verknüpfung von Sounds:
* Einleitung
* Mittelteil
* Ausleitung
* Ggf. setzen von Abbruchpunkten, d.h. Ende eines Sounds kann nicht an beliebiger Stelle erfolgen, sondern z.B. nur zwischen den einzelnen Schlägen eines langsam schlagenden Weckers, oder an geeigneten Verknüpfungspunkten zum Ausleitungssound?

[[Kategorie:Anforderungen]]

Development:Anforderungen Sound

2015-10-27T13:01:20Z

BorisM:

Einstellbare Werte:
[*] Lautstärke

[*] Position (Pan oder Laufzeitunterschied)

[*] Frequenz? (wird im Soundthesizer zur Unterscheidung verschiedener Geschwindigkeiten o.ä. genutzt)

[*] An/aus

[*] Loop, einzeln

Verknüpfung von Sounds:
[*] Einleitung

[*] Mittelteil

[*] Ausleitung
z
[*] Ggf. setzen von Abbruchpunkten, d.h. Ende eines Sounds kann nicht an beliebiger Stelle erfolgen, sondern z.B. nur zwischen den einzelnen Schlägen eines langsam schlagenden Weckers, oder an geeigneten Verknüpfungspunkten zum Ausleitungssound?

[[Kategorie:Anforderungen]]

Development:Anforderungen Sound

2015-10-27T13:00:45Z

BorisM: Die Seite wurde neu angelegt: „Einstellbare Werte: [*] Lautstärke [*] Position (Pan oder Laufzeitunterschied) [*] Frequenz? (wird im Soundthesizer zur Unterscheidung verschiedener Geschwind…“

Einstellbare Werte:
[*] Lautstärke
[*] Position (Pan oder Laufzeitunterschied)
[*] Frequenz? (wird im Soundthesizer zur Unterscheidung verschiedener Geschwindigkeiten o.ä. genutzt)
[*] An/aus
[*] Loop, einzeln

Verknüpfung von Sounds:
[*] Einleitung
[*] Mittelteil
[*] Ausleitung
[*] Ggf. setzen von Abbruchpunkten, d.h. Ende eines Sounds kann nicht an beliebiger Stelle erfolgen, sondern z.B. nur zwischen den einzelnen Schlägen eines langsam schlagenden Weckers, oder an geeigneten Verknüpfungspunkten zum Ausleitungssound?

[[Kategorie:Anforderungen]]

Development:Anforderungen Global Schnittstellen

2015-08-20T22:45:19Z

BorisM:

{| class="wikitable sortable"
! Themengebiete
|-
| Für Performanceverbesserung: Vorbereitung darauf, intern zur Datenweitergabe (also "Addressierung") Enums o.ä. statt den "Adernamen" zu verwenden, um teure Stringvergleiche zu vermeiden. Strings sollten nur bei der Abonnierung von eingehenden Daten o.ä. sowie bei der Netzwerkkommunikation verwendet werden.
|-
| Wert bei der Datenübertragung Schnittstelle sollte ein komplexer Datentyp werden, der schlank gestaltet sein muss (Performance), aber Platz für Erweiterungen bietet (Flags, Daten zum Blinken etc)
|-
| Fernsteuerung muss sich einklinken können in die Kommunikation zwischen Stelltisch und Relaisanlage

Überlegung: Fernsteuerung ist "Men in the middle", die erkennt, welche Daten zwischen Stelltisch und Relaisanlage ausgetauscht werden. Wenn alle Adern in den Leitungen schon vor der Datenübertragung festgelegt werden, kann man hier auch einen Editor platzieren, der z.B die Festlegung von Prioritäten bei der Datenübertragung o.ä. erlaubt.
|}

= Zu überlegen =
* Kompatibilitätsprüfung beim Verbinden zweier Schnittstellen (Schnittstelle definiert Leitungen von Gegenstelle als optional oder verpflichtend, Typprüfung)

= Beschlüsse =
* Leitungen sind typisiert (int, double, string). Ggf. werden auch structs benötigt (Blinken o.ä.). Zu prüfen: Soll Schnittstelle als template realisiert werden?
* Leitungen können zu einem Stecker zusammengefasst werden
* Leitungen zwischen zwei Schnittstellen können durchgeschaltet werden (ggf. auch skriptgesteuert aktivier/deaktivierbar, z.B. bei Weichen, die je nach Weichenlage in die eine oder andere Richtung durchschalten)

[[Kategorie:Anforderungen]]
[[Kategorie:Umbauplanung_Boris]]

Development:Anforderungen Global Schnittstellen

2015-08-20T22:40:18Z

BorisM:

{| class="wikitable sortable"
! Themengebiete
|-
| Für Performanceverbesserung: Vorbereitung darauf, intern zur Datenweitergabe (also "Addressierung") Enums o.ä. statt den "Adernamen" zu verwenden, um teure Stringvergleiche zu vermeiden. Strings sollten nur bei der Abonnierung von eingehenden Daten o.ä. sowie bei der Netzwerkkommunikation verwendet werden.
|-
| Wert bei der Datenübertragung Schnittstelle sollte ein komplexer Datentyp werden, der schlank gestaltet sein muss (Performance), aber Platz für Erweiterungen bietet (Flags, Daten zum Blinken etc)
|-
| Fernsteuerung muss sich einklinken können in die Kommunikation zwischen Stelltisch und Relaisanlage

Überlegung: Fernsteuerung ist "Men in the middle", die erkennt, welche Daten zwischen Stelltisch und Relaisanlage ausgetauscht werden. Wenn alle Adern in den Leitungen schon vor der Datenübertragung festgelegt werden, kann man hier auch einen Editor platzieren, der z.B die Festlegung von Prioritäten bei der Datenübertragung o.ä. erlaubt.
|}

= Beschlüsse =
* Leitungen sind typisiert (int, double, string). Ggf. werden auch structs benötigt (Blinken o.ä.). Zu prüfen: Soll Schnittstelle als template realisiert werden?
* Leitungen können zu einem Stecker zusammengefasst werden
* Leitungen zwischen zwei Schnittstellen können durchgeschaltet werden (ggf. auch skriptgesteuert aktivier/deaktivierbar, z.B. bei Weichen, die je nach Weichenlage in die eine oder andere Richtung durchschalten)
* Kompatibilitätsprüfung beim Verbinden zweier Schnittstellen (Schnittstelle definiert Leitungen von Gegenstelle als optional oder verpflichtend, Typprüfung)

[[Kategorie:Anforderungen]]
[[Kategorie:Umbauplanung_Boris]]

Development:Anforderungen Global Schnittstellen

2015-08-20T21:23:14Z

BorisM:

{| class="wikitable sortable"
! Themengebiete
|-
| Für Performanceverbesserung: Vorbereitung darauf, intern zur Datenweitergabe (also "Addressierung") Enums o.ä. statt den "Adernamen" zu verwenden, um teure Stringvergleiche zu vermeiden. Strings sollten nur bei der Abonnierung von eingehenden Daten o.ä. sowie bei der Netzwerkkommunikation verwendet werden.
|-
| Wert bei der Datenübertragung Schnittstelle sollte ein komplexer Datentyp werden, der schlank gestaltet sein muss (Performance), aber Platz für Erweiterungen bietet (Flags, Daten zum Blinken etc)
|-
| Fernsteuerung muss sich einklinken können in die Kommunikation zwischen Stelltisch und Relaisanlage

Überlegung: Fernsteuerung ist "Men in the middle", die erkennt, welche Daten zwischen Stelltisch und Relaisanlage ausgetauscht werden. Wenn alle Adern in den Leitungen schon vor der Datenübertragung festgelegt werden, kann man hier auch einen Editor platzieren, der z.B die Festlegung von Prioritäten bei der Datenübertragung o.ä. erlaubt.
|}

= Beschlüsse =
* Leitungen sind typisiert (int, double, string). Ggf. werden auch structs benötigt (Blinken o.ä.). Zu prüfen: Soll Schnittstelle als template realisiert werden?

[[Kategorie:Anforderungen]]
[[Kategorie:Umbauplanung_Boris]]

Development:Anforderungen IDE

2015-08-15T14:35:34Z

BorisM: /* Grundüberlegungen */

= Grundüberlegungen =
StellSi sollte eine gut bedienbare IDE enthalten, die das Entwickeln und Testen von Bauformen erleichtert. Dazu sollten folgende Anforderungen erfüllt werden:
* Integration des Bibliothekseditors in den Simulator
* Im laufenden Betrieb können Skripte neugeladen werden - automatisch oder manuell durch den Nutzer?
** Variante A: Relaisgruppe wird neu initialisiert
** Variante B: Inhalt der Membervariablen und anderer Relaisgruppenbezogenen Daten bleiben erhalten, sofern die Namen gleich bleiben. Kann schieflaufen, wenn Membervariablen o.ä. dazugekommen sind
* Integration eines Quelltexteditors mit automatischen Vervollständigen (Ja, ich weiß, dass das komplex ist)
* Einheitliche GUI in allen Teilen von StellSi
* Undo/Redo (-> Einsatz Befehlsobjekte?)
* Alle Änderungen wirken sich grundsätzlich sofort aus (-> keine Bestätigungsknöpfe). Ausnahmen ggf. bei Dialogen?

= Testing =
* Integration eines Debuggers:
** "Abhören" von Verbindungen zwischen Schnittstellen (u.a. Anzeige der Werte der Leitungen)
** Setzen von Breakpoints in Skripten
** Setzen von Breakpoints im SimpleScript
** Setzen von Breakpoints bei Schnittstellenaktivitäten
** "Unittest" von Relaisgruppen o.ä.: Einbau eines Schnittstellensimulators, mit dem die Schnittstellen einer Relaisgruppe, eines TischfeldElement o.ä. gezielt stimuliert werden können
** Automatisierung von Tests?
-> Debugger muss sich in Zukunft auf das ganze Objekt (TischfeldElement, Relaisgruppe) beziehen, nicht nur auf den Angelscript-Anteil!

= TODO-Liste =
* Entwicklung der GUI von StellSi:
** Basis: GUI für die Spieler
** Einschaltbar für Stellwerkserbauer (ein oder zwei Seitenleisten?):
*** Seitenleiste für neue Elemente (Tischfelder, Relaisgruppen o.ä.)
*** Seitenleiste für Property-Editierung (heutiger Parametereditor)
** Einschaltbar für Entwickler:
*** Quelltexteditor
*** Entwicklertools
*** Testtools

[[Kategorie:Anforderungen]]
[[Kategorie:Umbauplanung_Boris]]

Development:Anforderungen IDE

2015-08-15T13:03:25Z

BorisM: /* Grundüberlegungen */

= Grundüberlegungen =
StellSi sollte eine gut bedienbare IDE enthalten, die das Entwickeln und Testen von Bauformen erleichtert. Dazu sollten folgende Anforderungen erfüllt werden:
* Integration des Bibliothekseditors in den Simulator
* Im laufenden Betrieb können Skripte neugeladen werden - automatisch oder manuell durch den Nutzer?
** Variante A: Relaisgruppe wird neu initialisiert
** Variante B: Inhalt der Membervariablen und anderer Relaisgruppenbezogenen Daten bleiben erhalten, sofern die Namen gleich bleiben. Kann schieflaufen, wenn Membervariablen o.ä. dazugekommen sind
* Integration eines Quelltexteditors mit automatischen Vervollständigen (Ja, ich weiß, dass das komplex ist)
* Einheitliche GUI in allen Teilen von StellSi
* Undo/Redo (-> Einsatz Befehlsobjekte?)

= Testing =
* Integration eines Debuggers:
** "Abhören" von Verbindungen zwischen Schnittstellen (u.a. Anzeige der Werte der Leitungen)
** Setzen von Breakpoints in Skripten
** Setzen von Breakpoints im SimpleScript
** Setzen von Breakpoints bei Schnittstellenaktivitäten
** "Unittest" von Relaisgruppen o.ä.: Einbau eines Schnittstellensimulators, mit dem die Schnittstellen einer Relaisgruppe, eines TischfeldElement o.ä. gezielt stimuliert werden können
** Automatisierung von Tests?
-> Debugger muss sich in Zukunft auf das ganze Objekt (TischfeldElement, Relaisgruppe) beziehen, nicht nur auf den Angelscript-Anteil!

= TODO-Liste =
* Entwicklung der GUI von StellSi:
** Basis: GUI für die Spieler
** Einschaltbar für Stellwerkserbauer (ein oder zwei Seitenleisten?):
*** Seitenleiste für neue Elemente (Tischfelder, Relaisgruppen o.ä.)
*** Seitenleiste für Property-Editierung (heutiger Parametereditor)
** Einschaltbar für Entwickler:
*** Quelltexteditor
*** Entwicklertools
*** Testtools

[[Kategorie:Anforderungen]]
[[Kategorie:Umbauplanung_Boris]]

Development:Überarbeitung Skripting

2015-08-15T08:50:32Z

BorisM:

Kategorie:Umbauplanung Boris

2015-08-15T08:36:09Z

BorisM: Die Seite wurde neu angelegt: „Sammlung von Änderungen, die von Boris geplant und zur Diskussion eingestellt werden.“

Sammlung von Änderungen, die von Boris geplant und zur Diskussion eingestellt werden.

Development:Anforderungen IDE

2015-08-15T08:34:38Z

BorisM: Die Seite wurde neu angelegt: „= Grundüberlegungen = StellSi sollte eine gut bedienbare IDE enthalten, die das Entwickeln und Testen von Bauformen erleichtert. Dazu sollten folgende Anforde…“

= Grundüberlegungen =
StellSi sollte eine gut bedienbare IDE enthalten, die das Entwickeln und Testen von Bauformen erleichtert. Dazu sollten folgende Anforderungen erfüllt werden:
* Integration des Bibliothekseditors in den Simulator
* Im laufenden Betrieb können Skripte neugeladen werden - automatisch oder manuell durch den Nutzer?
** Variante A: Relaisgruppe wird neu initialisiert
** Variante B: Inhalt der Membervariablen und anderer Relaisgruppenbezogenen Daten bleiben erhalten, sofern die Namen gleich bleiben. Kann schieflaufen, wenn Membervariablen o.ä. dazugekommen sind
* Integration eines Quelltexteditors mit automatischen Vervollständigen (Ja, ich weiß, dass das komplex ist)
* Einheitliche GUI in allen Teilen von StellSi

= Testing =
* Integration eines Debuggers:
** "Abhören" von Verbindungen zwischen Schnittstellen (u.a. Anzeige der Werte der Leitungen)
** Setzen von Breakpoints in Skripten
** Setzen von Breakpoints im SimpleScript
** Setzen von Breakpoints bei Schnittstellenaktivitäten
** "Unittest" von Relaisgruppen o.ä.: Einbau eines Schnittstellensimulators, mit dem die Schnittstellen einer Relaisgruppe, eines TischfeldElement o.ä. gezielt stimuliert werden können
** Automatisierung von Tests?
-> Debugger muss sich in Zukunft auf das ganze Objekt (TischfeldElement, Relaisgruppe) beziehen, nicht nur auf den Angelscript-Anteil!

= TODO-Liste =
* Entwicklung der GUI von StellSi:
** Basis: GUI für die Spieler
** Einschaltbar für Stellwerkserbauer (ein oder zwei Seitenleisten?):
*** Seitenleiste für neue Elemente (Tischfelder, Relaisgruppen o.ä.)
*** Seitenleiste für Property-Editierung (heutiger Parametereditor)
** Einschaltbar für Entwickler:
*** Quelltexteditor
*** Entwicklertools
*** Testtools

[[Kategorie:Anforderungen]]
[[Kategorie:Umbauplanung_Boris]]

Development:Anforderungen Logging

2015-08-15T08:13:18Z

BorisM: Die Seite wurde neu angelegt: „= Vorwort = Ich beschreibe hier einen Sollzustand zur Diskussion, ohne den Istzustand zu berücksichtigen. Dass ggf. das ein oder andere schon umgesetzt wurde…“

= Vorwort =
Ich beschreibe hier einen Sollzustand zur Diskussion, ohne den Istzustand zu berücksichtigen. Dass ggf. das ein oder andere schon umgesetzt wurde ist mir bewusst :-)
= Überlegungen =
* Realisierung als Singleton (Verfügbarkeit immer und überall auf geregelte Art)
* Trennung Model - View
* Realisierung unterschiedlicher Loggingstufen (Temporary, evtl. Debug_cyclic, Debug, Info, Warnung, Fehler, Fatal Error)
** Temporary-Logging ist für temporär während der Entwicklung gedacht, die anschließend nicht mehr benötigt werden, und muss in produktiven Versionen ausgebaut sein (Performance-Gründe, Vermeidung von Überfüllung des Loggings)
* Realisierung unterschiedlicher Loggingarten:
** Programmfehler
** stwb/Scripting-Fehler (gemeldet durch das PRogramm)
** Ausgaben durch Logging-Funktion im Script
* Implementierung eines Filters im View, der nach Loggingstufen und Loggingarten filtert.
* Standardmäßig werden Debug-Ausgaben im Model entweder nicht erfasst oder mengenmäßig limitiert (Performance). Das lässt sich umschalten.

= Performance, Verhinderung von Logfluten =
Das Fluten des Logs muss vermieden werden. Zyklische Nachrichten dürfen nur mit Logstufe Temporary ausgegeben werden.

Auf Debug-Level muss Loggen zyklischer Nachrichten wahrscheinlich weitgehend vermieden werden. Hier ist zu untersuchen, ob es eine Möglichkeit gibt, bei abgeschaltetem Debug-Logging das Erstellen des zu loggenden Strings zu verhindern. Ist die Abfrage, ob geloggt werden soll, erst in der Logging-Funktion selbst, dürfte zuerst das String-objekt erstellt, und dann erst entschieden werden, dass der String nicht genutzt wird. Das ist bisher allerdings eine Vermutung und noch nicht verifiziert.

Sollte es möglich sein, das Erstellen des String-Objekts zu verhindern, kann über eine weitere Debug-Stufe (Debug_cyclic) nachgedacht werden.

= Erfasste Daten =
Jede Lognachricht wird in einer eigenen Klasse erfasst. Dabei wird erfasst:
* Uhrzeit
* Logart
* Logstufe
* Lognachricht
* Ggf. Ort des Auftretens (z.B. Quelltextdatei/Zeile)

Wichtig: Performance (Speicher, Rechenzeit) beachten!

= Anbindung Views =
Beobachter-Pattern ist aus Performance-Grunden nicht geeignet.

Der Logger bietet eine Möglichkeit für Views:
* Daten abzurufen (ggf. vorgefiltert)
* Daten zu abonnieren (ggf. mit Filter)

Neu eintreffende Daten werden dann automatisch an die Views weitergegeben.

= Views =
Benötigte Views:
* Weiterleitung auf Konsole
* Grafische filterbare Liste
* Export in eine Datei/Upload auf Server/Versand per E-Mail

= Nett zu haben =
Schafft man es im Fall von Programmabstürzen Daten sowie das Log dazu zu sammeln?

[[Kategorie:Anforderungen]]
[[Kategorie:Umbauplanung_Boris]]

Development:Überarbeitung Skripting

2015-08-13T02:55:16Z

BorisM:

Development:Überarbeitung Skripting

2015-08-13T02:49:45Z

BorisM: Die Seite wurde neu angelegt: „= Grundlagen = [*] Einführung eines zustandsbasierten Skriptsystems (im folgenden vorläufig SimpleScript genannt) als Ergänzung zu AngelScript [*] Bessere V…“

= Grundlagen =
[*] Einführung eines zustandsbasierten Skriptsystems (im folgenden vorläufig SimpleScript genannt) als Ergänzung zu AngelScript
[*] Bessere Verknüpfung des zu steuernden Objekts (Relaisgruppe, Tischfeld, ...) mit dem Skripting

= Anforderungen =
== AngelScript ==
=== Eingang von Daten von außen ===
Formulierung von SimpleScript-Ausdrücken in den Metadaten von Methoden. Ein Ausdruck pro Parameter.
Wenn sich das Ergebnis des Ausdrucks ändert, wird die Methode aufgerufen. Dies ersetzt die Auswertung des Methodennamen vollständig (bis auf Abwärtskompatibilität)

=== Ausgabe von Daten ===
Der AngelScript-Klasse wird eine automatische generierte Klasse zur Verfügung gestellt, über die ein Zugriff auf die Daten des gesteuerten Tischfeldes, Relaisgruppe, ... zur Verfügung gestellt wird. Vorbild ist die "ui"-Membervariable von mit QT Designer erstellten Widgets.

Bei einem Tischfeld sind z.B. die Schnittstellen, aber auch die GUI-Elemente (Bitmap, SVG, Taster, ...) auf diese Weise erreichbar. Realisierbarkeit von Animationen bedenken!

TODO: Einbindung von SimpleScript auch zur Ausgabe der Daten. Beispiel: Die Daten, die auf einer Schnittstelle, an der ein Tischfeld angeschlossen werden kann, ausgegeben werden sollen, sollen auch per SimpleScript generierbar sein aus den internen Daten der Relaisgruppe.

Per AngelScript ist die Zuweisung von SimpleScript-Anweisungen an externe Elemente (z.B. eine Grafik) möglich. Damit kann z.B. in verschiedenen Phasen einer Animation die Berechnungsvorschrift für Position, Drehung o.ä. dynamisch angepasst werden.

== SimpleScript ==
[*] Datenabruf von Leitungen einer SChnittstelle, reagiert auf Änderungen automatisch
[*] Analog dazu auch von Tastern, Zuständen (brauchen wir die noch??), ...
[*] TODO: Enthält geeignete Strukturen, um Relaisschaltungen zu simulieren
[*] Operatoren (+, -, &&, ||, ...)
[*] Bereitstellung von Funktionen inklusive return-Anweisung. TODO: Wo werden die Funktionen definiert? Müssen auch in stwb zur Verfügung stehen!
[*] Anwendung überall, wo Daten eingehen
[*] Ersetzt die Eingangslogik
[*] Bereitstellung eines grafischen Editors (als Alternative zur Texteingabe)
[*] Bereitstellung Syntaxprüfung/automatische Ergänzung bei Eingabe in Textfeldern

= Realisierungsmöglichkeiten =
SimpleScript: Entwurfsmuster "Interpreter" oder http://www.antlr.org/

[[Kategorie:Anforderungen]]

Datei:KontexmenueSchnittstelle.png

2015-04-30T22:17:14Z

BorisM: BorisM lud eine neue Version von Datei:KontexmenueSchnittstelle.png hoch

Quelle: Südwest

Development:Anforderungen Parametereditor

2015-03-28T15:18:04Z

BorisM: Die Seite wurde neu angelegt: „==Gui== {| class="wikitable sortable" ! Anforderung allgemein |- | Änderungen werden sofort ausgeführt bei der Durchführung der Änderung |- | Der Paramet…“

==Gui==

{| class="wikitable sortable"
! Anforderung allgemein
|-
| Änderungen werden sofort ausgeführt bei der Durchführung der Änderung
|-
| Der Parametereditor befindet sich in einer Seitenleiste analog zu diversen IDE
|-
| Die Auswahl von komplexen Einstellungen (z.B. Auswahl einer Schnittstelle auf die sich verbunden wird) erfolgt über eine Art Dropdown-Menü, analog zu einer Kombobox, aber mit eigenen Widgets
|}

{| class="wikitable sortable"
! Anforderung Schnittstellenwahl
|-
| [[Datei:KontexmenueSchnittstelle.png|miniatur|left]]Vorschlag von Südwest
|-
| Ggf. mehr Filter nötig (Grobfilter + Feinfilter o.ä.)
|-
| Reiter - nicht eher sinnvoller oben?
|-
| Reiter: Problematisch bei mehr als (eigene Relaisanlage + 1 Außenanlage + 3 verknüpfte Relaisanlagen), dann wird Bedienung ziemlich eklig
|-
| Reiter: Benötigen Kurzbezeichnung von Relaisanlage/Außenanlage, die sinnvoll gewählt sein muss
|}
[[Kategorie:Anforderungen]]

Development:Anforderungen Global Schnittstellen

2015-01-12T23:25:54Z

BorisM: