Hallo JuergenSchm ,
Dazu wüsste ich jetzt keine Lösung, doch inspiriert mich #15 zur Lösung meines Problems mit Immo-Strassenbahnsignalen, deren Steuerung über Kps nur halbwegs funktioniert.
Guy
Hallo JuergenSchm ,
Dazu wüsste ich jetzt keine Lösung, doch inspiriert mich #15 zur Lösung meines Problems mit Immo-Strassenbahnsignalen, deren Steuerung über Kps nur halbwegs funktioniert.
Guy
Hallo Guy ( Messina ),
ja, so etwas in der Art, "mache etwas, wenn das Tor aufgeht" verwende ich auch.
Und da ich auch durch eine einfache Maßnahme (Modulo-Prüfung eines Zählers) verhindere, dass diese Prüfung alle 20ms erfolgt, ist die von Michael89 genannte Mehrbelastung der EEPMain auch nicht relevant.
Hallo Michael,
womit uns EEP17 überrascht
also soviel darf ich dir sagen, eine Callback-Funktion für Immos ist nicht dabei.
Hallo Jürgen,
Und da ich auch durch eine einfache Maßnahme (Modulo-Prüfung eines Zählers) verhindere, dass diese Prüfung alle 20ms erfolgt, ist die von Michael89 genannte Mehrbelastung der EEPMain auch nicht relevant.
ok, dann führst du die Prüfung wahrscheinlich nicht mehr 5 Mal, sondern nur noch 1 Mal die Sekunde oder alle x Sekunden aus. Wenn ich das für eine größere Anzahl Türen mache und die Prüfung dazwischen vielleicht noch etwas umfangreicher geschrieben ist, dann ist das irgendwann trotzdem relevant. Ich verstehe hier ehrlich gesagt nicht warum man sich der vorhandenen Lösung über das Signal verweigert. Was das von euch angesprochene Türthema angeht, so ist es denke ich hier sinnvoller das Ereignis bereits am Auslöser abzufangen, sodass
mache etwas, wenn das Tor aufgeht
eben direkt im KP der das Tor öffnet oder parallel zum Lua-Befehl der das Tor öffnet ausgelöst wird. Damit erfasst man jedoch nicht dass händische Öffnen, dass stimmt dann schon.
Gruß Michael
Hallo Michael ( Michael89 ),
eventuell willst Du Dich auch anderen Möglichkeiten verweigern.
Erstens, ich verwende ebenfalls die CallBack-Funktion und verweigere mich dieser nicht.
Aber wenn ich für ein Tor, bei dem etwas passieren soll, wenn es geöffnet wird, diese Lösung einsetze, dann ist das kein Performance-Problem für EEP, sonst wäre wohl jede Zeile in der EEPMain ein solches.
Aber Du kannst mir gern eine "OnKlick"-Lösung nennen und ich werde diese sofort einsetzen.
Ich will dieses Tor nicht durch einen Kontaktpunkt öffnen, sondern durch "anklicken" und wenn auf, dann solll etwas passieren.
Und außerdem und ohne eine interne Codezeile von EEP zu kennen.
Wenn ich weiß oder besser, einschätzen kann, wie groß oder besser klein der Unterschied für ein Programm ist, ob eine "kleine" Prüfung (auch für die "OnKlick"-Funktionalität muss es eine Prüfung in EEP geben, die "ständig" ausgeführt wird) durch ein compiliertes oder interprediertes Stück Programmcode ausgeführt wird, dann kannst Du mir glauben, auch Du würdest den Unterschied in der Anlage nicht feststellen.
Hallo Jürgen,
das mit dem Verweigern bezog sich auf die Ausgangsfrage und da ging es nicht um ein Tor.
Mit meinen Ausführungen zur EEPMain beziehe ich mich nur auf Funktionen die sich gleichwertig anders lösen lassen. Man sollte die Main so schlank wie sinnvoll möglich halten finde ich.
Gruß Michael
möchte er gern die Funktionalität für Immo-Achsen
Die Achsen sind erst später dazugestoßen. Ursprünglich wollte ich nur zwei Eingabefelder im Eigneschaftendialog analog zu Kontakten z.B. mit der dahinter liegenden Aktivität.
Unten der Hauptschalter, der alle anderen Teilbereiche steuert, allerdings ganz ohne Lua.
Auch eine Lösung ... aber ich schwimme gerade mal auf der LUA-Welle herum
so will er mit einem Schalter Lua ab- und an- schalten.
Nein, das kann ich ja vielleicht auch über den RCode lösen. Der Gedanke war, mit verschiedenen "Stellungen" oder Schaltungen verschiedene Aktivitäten aus zu lösen.
Abe der erweiterte Gedanke, verschieden Scriptblöcke (Funktionen) an eine Achsenstellung zu binden gefällt mir immer noch.
Das andere ist tatsächlich nur "Schönheits"-Bauchweh. Mit dem Anlagenschalter und Callback passt das dann schon.
... an eine Achsenstellung zu binden
... was meinst du, woher die ganzen Bewegungsauslöser für die Schaufel kommen?
Abfrage von Achsenstellungen. Ob Immo oder Rollmaterial ist ja vom Prinzip her egal.
Entschuldigt bitte, dass ich immer so "unnötige" Fragen stelle.
Und vielen dank für die vielen Ansätze.
Aus meinem ursprünglichen Gedanken entwickelten sich auch erst die weiteren.
Und ich bin immer wieder überrascht, welche Wege solche Diskussionen nehmen.
[Keine Kritik an anderen!]: Eben habe ich mir den Thread nochmal von vorne angesehen. Irgendwie habe ich für mich den Eindruck, als ob einige Beiträge erst später aufscheinen. Immer wieder stoße ich auf Beiträge zwischendurch, die mir entgangen zusein scheinen. Vielleicht mache ich da auch was falsch. Aber vielleicht verliere ich auch meinen Rücksprungpunkt aus den Augen, wenn ich antworte auf beiträge davor oder welche aufscheinen, während ich schreibe. Da muss ich mich noch umgewöhnen.
wenn Du eine, im Moment für Dich nur schwer zu überwinden Aversion gegen eine bereits integrierte Funktionalität
Nicht wirklich. Worüber ich immer wieder stolpere, ist die Tatsache, dass man immer wieder nach Funktionalität an Stellen suchen muss bzw. nach Modellen, auf die man mit einfacher Logik nicht kommt. Eben hier: Warum ein Gleis, wenn ich doch nur schalten will.
Und ja natürlich macht es Spaß, mit vorhandenen Materielien Neues zusammenzustellen. Das war ich bis Anfang der Neunziger des vorherigen jahrhunderts auch gewöhnt und es war nötig zu basteln. Das muss ich dann hier auch wieder intensiver beleben.
Ich könnte mir vorstellen, dass dir mit diesen Möglichkeiten für deine Ziele „Tür und Tor geöffnet sind“.
Dieser Beitrag führt mich zu einer mir gefallenden Methodik. Auf das Beispiel bezogen würde dann eine Script-Achse an die Torachse gekoppelt sein und bei voller Öffnung dann die eingetragene Funktion auslöst (im einfachsten fall, die Lok losfahren zu lassen z.B. Aber mit diesen EEP-LUA-Funktionen muss ich mich dann mal befassen. Womöglich ist da sowas schon drin. Danke für dieses Beispiel.
Mein Fazit:
Mit meinen Ideen ist es wohl wie bei den Patenten: Es werden viele Patente angemeldet, aber ob sie sich durchsetzen, entscheidet die Zukunft und oft auch wie lange an gewiohnten Methoden festgehalten wid.
Ich danke euch herzlich für eure Geduld mit mir und meinen manchmal anderen Gedankenwegen.
Und insofern ist meine Anfangsproblematik beantwortet. Danke.
Abfrage von Achsenstellungen. Ob Immo oder Rollmaterial ist ja vom Prinzip her egal.
Ja klar, aber ein Gedanke mit der Script_Achse war umgekehrt: Wenn eine Achsenstellung erreicht wird, soll ein Ereignis "Führe eingetragene Funktion aus" ausgelöst werden. Aber wie bei meiner Patent-Metapher, manche Gedanken sind nützlicher, andere nicht so sehr und für wieder andere hat keiner eine Anwendungsidee und dann gibt es für einige auch bereits Workarounds mit gleicher bzw. ähnlicher Wirkung.
Und wie oben beschrieben: Für diese Achsen-Funktionen muss ich erst noch "Grundlagen"-Forschung betreiben.
... war umgekehrt: Wenn eine Achsenstellung erreicht wird, soll ...
NICHT umgekehrt,
wenn ein bestimmter Winkel/Achsstellung erreicht ist, löse nächste/andere Bewegung aus
wenn ein bestimmter weiterer Winkel/Achsstellung erreicht ist, löse weitere/andere Bewegung aus
NICHT umgekehrt,
wenn ein bestimmter Winkel/Achsstellung erreicht ist,
Ja schon, aber da fragst du ja in einer Schleife ab, bis die Stellung erreicht ist, also läuft da ein polling-script, das dann die Funktion auslöst, wenn es "erfüllt" ist. Bei mir soll, erst wenn die Einstellung auf eine andere gesetzt wird (ob OnKlick oder per Script) ein Ereignisscript die eingetragene Script-Funktion auslösen. Das Pollen findet garnicht statt.
Und zusätzlich belastet solches Polling immer das gesamte System. Und wenn ich dann noch einbeziehe (hoffentlich erinnere ich das richtig), dass EEP nur einen Prozessor-Thread benutzt (oder war das nur ein Kern, aber mehrere virtuelle Threads?), dann passiert, solange in einer Schleife (While/Until) gepollt, wird nichts anders(?)
Und zusätzlich belastet solches Polling immer das gesamte System.
Da "übertreibst" du gedanklich etwas. Das ganze EEP (bzw. der ganze PC) ist "Polling"!?
Es muss immer auf irgend etwas reagiert werden.
solange in einer Schleife (While/Until) gepollt
... da genau liegt der Hase im Pfeffer, das programmiert man/ich eben ohne diese "Bremsen".
Kannst Du eventuell einen Signal-Zähler benutzten um Dein Ziel zu ereichen?
Es gibt zwei Signal-Zähler mit Zahlen von 0-9 und von 0-98.
Ist zwar ein Signal, aber das kann mit Funktion "EEPOnSignal" angesprochen werden und damit die Lua-Funktion aufgerufen werden.
Mit if- und elseif Abfragen kann dann mit jeder aufgerufenen Zahl ein anderer Befehl ausgeführt werden.
Nachteil bei der Handbedienung ist das eine Zahl nach der anderen aufgerufen wird.
Mit Kontaktpunkten kann man aber den Signalzähler auf eine gewünschte Zahl setzen und damit den an diese Zahl gebundenen Befehl ausführen lassen.
Kannst Du eventuell einen Signal-Zähler benutzten um Dein Ziel zu ereichen?
Die sind mir auch schon aufgefallen. Schöne Funktionen.
Aber viellleicht denke ich auch verquer.
Und wenn ich nach meinem eigenen Prinzip folge, alles was man nicht richtig formulieren kann, hat man nicht richtig durchdacht, muss ich hier noch an meinen Formulierungen arbeiten. Und zugegegbener Maßen, habe ich hier eine Idee, ohne wirklich eine echte Anwendung zu haben.
Das ganze EEP (bzw. der ganze PC) ist "Polling"!?
Natürlich hat jedes Spiel eine Hauptschleife. Entweder schleifen-laufzeitgesteuert oder in einer "konstanten" Zeitschleife. Aufgrund der getakteten LUA-Main-Schleife (5x pro Sekunde) in EEP vermutlich zweitere. Aber egal. Da nur ein Thread genutzt wird, hält jedes Polling die Schleife "an".
da genau liegt der Hase im Pfeffer, das programmiert man/ich eben ohne diese "Bremsen".
Gibt es da ein paar Links zum Programmieren ohne "Bremsen"? (Hier im Forum oder im Handbuch oder ...?)
... ein paar Links zum Programmieren ohne "Bremsen"?
... mit ein paar Links ist das eben nicht getan.
Das gehört zu den Grundlagen der Programmierung, so, wie man zum Schreiben auch erst mal das Alphabet lernen muss.
Stichwort: Schritt(zähler)- oder Merker-Programmierung.
Beispiel:
if Schritt==5 then "stepfunction(5)"
(5)
- du fragst ein (Ziel-)Ereignis ab
- ist es eingetreten
--- erhöhe Schritt auf 6
- ist es NICHT eingetreten
--- belasse Schritt auf 5
Ende der Abfrage --- keinerlei Wartezeit oder Verzögerung
so kann man übrigens auch eigene Timer programmieren
ist eben ein hoher Aufwand an Programmierung, aber extrem flexibel und sicher
mit ein paar Links ist das eben nicht getan.
Damit meinte ich ich die Stellen im Forum, an denen sowas schon mal diskutoert wurde, wenn ich das richtig erinnere. Habe ich aber nicht mehr gefunden oder mit falschen Suchkriterien gesucht.
Aber wie ich sehe, ist das, was du meinst, wohl ziemlich genau das, was ich in
Regelmäßige Funktionsaufrufe im EEPMain-Takt - Funktionsliste und Zeittaktsteuerung
mit euch zusammen schon für mich herausgefunden habe. Danke.
Das Prinzip ist also schon sehr alt, aber immer noch wirkungsvoll: Irgendwo wird ein Flag gesetzt oder entsteht eine Bedingung, dass woanders (ggf. regelmäßig im Spiel-Haupt-Zyklus) abgefragt wird und auf dass dann ggf. reagiert wird.
Ist eigentlich einfacher, als es sich für EEP immer anhört. Dann ist das ja auch schon geklärt. Danke.
P.S. @Administration: Wenn keine Einwände bestehen, kann der Thread sicherlich geschlossen werden.
Hi all
Die Diskussion hier wegen Anlagenstart hat mich erinnert, dass ich seinerzeit einen ganz einfachen Anlagenstart in einer Anlage eingebaut hatte. Das Prizip habe ich in der kleinen Anlage, die mit den untenstehenden Link herunter geladen werden kann, nachgestellt. Ich betone, es geht hier nur um den Anlagendstart.
Edit Mod. schlingo: [Link auf private Cloud entfernt]
Gruss Hans