Posts by Marino

    Gruss Marino

    Hi,


    nachdem nun die Diskrepanz sichtbar geworden ist, dass es eben Anwender gibt, welche aufgrund der Anwendungen, einige wenige, dafür Komplexe Funktionen benötigen, welche sie einfach einbinden können, ist es jetzt an der Zeit auf SFC zurückzukommen.

    Diese Eben wurde in IEC eingeführt, um:

    1. übersichtliche Abläufe, ohne unnötige Detailinformationen übersichtlich darzustellen
    2. eine starr sequenziellen Ablauf zu erzwingen, damit unerwartete Parallel-Reaktionen unterbunden sind.
    3. in Programmierung ungeschultes Personal, eine Möglichkeit in die Hand zu geben, Störfälle sehr effizient ohne Programmierkenntnisse zu analysieren.

    (nur damit nun nicht wieder moniert wird :an_1:, unbekannter Begriff: SFC = Sequential Funktion Chart)


    Diese Blöcke, welche in sich z.B. FUP oder direkt Lua beinhalten, werden im Ablauf nur mit einer Ja/Nein Abfrage vorangetrieben.

    Das bedeutet, dass der unbedarfte User nur diese Blöcke zueinander in den Ablauf einbinden muss.

    Dazu muss er also im Extremfall auch FUP nicht beherrschen.

    Für die Eingabe hat jeder Block eine Tabelle, welche die notwendigen Eingänge und die resultierenden Ausgänge beinhaltet.

    Diese muss nun mit mit den entsprechenden Knoten, Weichen, Signale und Zugnummern ausgefüllt werden.

    Die Abfragen zur Weiterschaltung desgleichen. Das können direkte Meldungen von EEP sein, oder auch Und/Oder Verknüpfungen aus mehreren Bedingungen.


    Da das Ganze also in drei Ebenen vorliegt, sollten die Meisten damit klarkommen, und so trotzdem auch die komplexesten Bedürfnisse abdecken können.


    Ps.#1

    Wer dem User dabei helfen will, einfache Weiterschaltungen zu ermöglichen ohne dass er dazu selber zu FUP greifen muss, setzt seine Funktionen so auf, dass immer die Weiterschaltbedingung im PB schon kreiert wird. Dann liegt der Merker schon in der Tabelle der Funktion vor, des Blocks vor und der User muss nur noch diesen Namen zur Bedingung eintragen.

    #2

    Ich werde bei Gelegenheit mit dem Beispiel der Zugzielanzeige zeigen, wie solches realisiert werden kann.

    Dabei wird sichtbar werden, das ungeachtet der Komplexität des Blocks, die Funktionstauglichkeit gewährleistet ist.

    Nun Oliver,


    dieses Dilemma hast Du bei Lua auch, nur ist die Übersicht nicht vergleichbar.

    Das Hauptproblem bei diesen Sachen ist erfahrungsgemäss nämlich nicht die Verknüpfung, sondern zu erkennen welche Schritte, um ein Ziel zu erreichen, notwendig sind. Zumeist wird nämlich da und dort immer mal was vergessen...

    Dazu, wie viele komplexe Funktionen braucht Du den?


    EEP Funktionen sind doch keine Datenverarbeitung, Kommunikationssysteme, oder astronomische Grössen die bearbeite werden müssen. Das allermeiste läuft doch auf boolescher Ebene ab. Regler oder mathematische Berechnungen oder was auch immer, kommen da ja überhaupt nicht vor.

    Zumeist sind das doch lediglich einfache Abfragen welche mit AND oder OR direkt verknüpfbar sind.

    Ich versuche bei meinen Projekten, wann immer möglich, die Ausgänge einzeln zuzuweisen.

    Wo sich aus aus Gründen der Parallelität Unsicherheiten ergeben, setze ich Merker, welche ich hernach zusammenfasse. Dadurch bleiben die Gebilde kurz und durchschaubar.


    Man kann natürlich auch mit der Kirche ums Dorf laufen, aber zumeist kommen die Menschen zur Kirche.

    Mir geht es nicht darum, wie sich eine beliebige Funktion aus kleinen Logik-Bausteinen zusammenbauen lässt. Mir geht es darum, dass der Anwender dies eben NICHT so kleinteilig tun muss.


    Der Anwender will eine Funktion "Fülle mir den Zugzielanzeiger", die er mit den Daten seines Zuges beschicken will. Er will diese Funktion nicht erst bauen müssen. Er will die Funktion "Sortiere meine Zugliste nach dem Zugziel", er will keinen Sortieralgorithmus programmieren.

    Dabei muss aber immer bedacht werden, dass je komplexer eine Funktion gehalten wird, um so spezifischer wird diese. Das bedeutet, dass jede Abweichungen zu diese Funktion wahrscheinlich nicht ausgeführt werden kann. Daraus folgt: Es ist eine neue zu schreiben

    Also lieber kleinkarierter und dafür flexibler!

    Hier, die Anzeige in FUP


    https://up.picr.de/34828863gz.jpg


    Mit solchen Funktionen habe ich früher immer Textanzeigen direkt beschrieben und über Modem auf Pager weitergeleitet. Dazu habe ich der Regel nie eine Tabelle bemüht...

    Heute geht das via HTML5 direkt zu den Tablets


    Ps, wenn EEP dazu eine Tabelle verlangt, rufe ich einfach die erste Zeile auf, welche ich mit der gezeigten Funktion jeweils neu überschreibe. Resultat, ich habe nur noch einen nummerierten Tabellenplatz für jede Anzeige.

    Denkt bitte immer an Boole, dessen Aussagen stimmen eben. Und so kann ich mit wenige grundsätzlichen Operanden

    Aber denke Du auch bitte daran, dass das System für Anwender geeignet sein soll, die nichts mit klassischer Programmierung am Hut haben, Leuten, die keine Ahnung haben, was XOR oder NAND bedeutet.


    Alleine schon die Schaltung eines Zugzielanzeigers am Bahnhof nach den Routendaten eines einfahrenden Zuges würde hier schon ziemlich kompliziert werden.

    Wenn Du mir schreibst, welche Parameter da gewünscht sind, kann ich Dir das mal zusammenstellen.


    Als einfaches Beispiel mal von der Zugnummer aus: Nutze dazu jedoch die Standard, nicht in deutsch, sonst muss ich alle benötigten Funktionen in Deutsch noch mal erzeugen. Die Ausgabe erfolgt direkt in String

    Ein Moment brach ich dazu aber schon... biBa

    Ja richtig Oliver,


    Aber ich weiss aus Erfahrung, dass die meisten Probleme und Aufgaben mit sehr wenigen Funktionen realisiert werden können. Denkt bitte immer an Boole, dessen Aussagen stimmen eben. Und so kann ich mit wenige grundsätzlichen Operanden ~20 das meiste lösen (mit Konsequenz ist sogar alles erreichbar, was aber dann schon recht kompliziert; daher auch un- überschaubar werden kann).

    Diese Operanden gehören, als direkt zugreifbare FNK, zum Grundgerüst jeder FUP Oberfläche.

    Diese dienen in der Regel dazu mathematische Grund-Operationen durchzuführen und/oder Vergleiche zu BOOLESCHE Variablen zu führen, welche mit AND, OR, XOR verknüpft werden. Das ist in > 90% der Programmierung wirklich ausreichend.

    Sonderfunktionen und komplexe PB sind aber jederzeit wie gezeigt erzeugbar...


    Also soo gewaltig ist das nun wirklich nicht!


    Das wird ja alleine schon daran sichtbar, dass in ST als IF/THEN und Schleifen lediglich 8 Strukturen vorliegen.

    Dabei sind keine Möglichkeiten zur Manipulation vom Speicher vorhanden, was ja auch Sinn macht, weil da schon in eine sehr tiefe Ebene gegriffen wird. Für solches muss ich dan schon auf C zurückgreifen das natürlich via Pointer direkt adressiert werden kann. Solches ist in Lua jedoch auch nicht möglich; also in sich schon in EEP obsolet.

    Ja Oliver,


    Aber glaub mit, ich tue mich auch schwer Euch das klar zumachen, wie das im Grunde alles zusammenhängt.

    Es ist wirklich nicht einfach das, was man täglich macht, und daher gedankenlos einsetzt, anderen zu eröffnen.


    Bin ja schliesslich kein Lehrer...

    Hi,

    nach Deiner Aussage hast Du also schon eine Ahnung von Programmierung :aa_1: (wollte das ja auch gar nie in Zweifel ziehen.)

    Quote

    Dein Code aus dem Beispiel erschließt sich mir von der Logik her schon. Es ist ja nur eine halbwegs simple verschachtelte IF-THEN-Abfrage. Nur ohne Kontext habe ich keine Ahnnung, was dieser Code bewirkt. Für mich sind es so nur irgendwelche Variablen-Zuweisungen, die auf irgendwelchen Vergleichen beruhen,

    Das eben wollte ich ja auch demonstrieren. Es ist oft sehr schwierig, zu durchschauen, was da in Code genau vorliegt. Wenn das nicht richtig durchschaut werden kann, wie will man dann solches Editieren?

    Einer der Hauptgründe, warum ich eben für übergeordnete Graphik plädiere!

    Quote

    Und die Grafik, die Du dann als Visualisierung dieses Codes gezeigt hast, ist erst einmal nur ene Box, in die zwei Linien hineinführen und vier wieder heraus. Ohne Kontext und Kenntnis des von Dir benutzen Systems, weiß ich nicht, was in der Box passiert. Ich wäre also trotz Programmierkenntnissen nicht in der Lage, das in Code umzusetzen, was ich in der Grafik sehe

    Diese Aussage hingegen erstaunt mich. Das ist ja gerade die Idee des Ganzen...

    Diese Box https://up.picr.de/34825280yv.jpg ist genau das, was im Script zu finden ist.

    => Funktionsname ( => #151)


    Dort sind ja auch die Eingangs- (die hineinführenden Anschlüsse) und Ausgangs- (die hinaufführenden Anschlüsse) -Variablen deklariert. (Die in der Box zusätzlich existierenden Lokal-Variablen sind unsichtbar)


    Für den User bleibt also, - nur diese Eingänge sind zu belegen -, da der Code in sich ja konsistent ist. Der User muss daher nur wissen was er hineinführen muss und erhält aus diesem PB die Antwort. Um den Code der in der Box ist, muss er sich nicht kümmern.


    jetzt klar?

    Das kann ich nur unterstreichen. Es geht hier um Lua bei EEP, aber zu zeigst hier Beispiele aus Deiner Arbeit, die praktisch nicht nachvollziehbar sind..


    Das einzige, was mir auf dem eben geposteten Bild auffällt ist, dass da einmal "Operateur", einmal "Operaeur" und einmal "Oerateur" steht.


    Vermutlich hast Du ja sogar gar nicht einmal unrecht mit der grafischen Oberfläche. Aber so überzeugst Du damit niemanden.

    Ja Oliver,

    da sind mir wohletliche Fehler unterlaufen - aber weisst Du was:

    Das ist dem Prozessor wirklich Wurst.

    Der interessiert sich nicht für die Namensvergabe, das ist für ihn nur ein Zeiger, welcher auf eine Adresse zeigt, in welcher er den Datensatz holt bez. hinschreibt. Das einzige Kriterium, um das es dabei geht ist: jeder Speicherplatz hat einen eigenen Namen und wenn er später falsch geschrieben wird findet er das Gewünschte nicht.

    Zu Deinem Text vielleicht mal eine Frage:

    Schreibst Du selber Lua Code? Wenn ja, warum erschliesst sich Dir dann mein Code nicht.

    Das der für eine andere Aufgabe aufgesetzt ist hat ja eigentlich keinen Einfluss. Trüge er andere Bezeichner, z.B. Gleis-Nummer so kann man eine solche Auswahlschaltung doch durchaus auch in EEP anwenden!

    damit ist hoffentlich auch der Untrschied zwischen Programmierung und Parametrierung klar geworden.

    Der Programmierer erstellt den Code

    Der Anwender versieht diesen mit seine Variablen, seien das nun Gleis-, Signal-, Weichen- oder Zug-Adressen.

    Er Parametriert!

    Das wäre aus meiner Sicht noch einmal ein neuer Ansatz:

    • Einige Lua-Programmierer erstellen Komponenten, die die Implementierung von hinreichend generischen Schnittstellen darstellen.
    • Andere (oder dieselben) erstellen graphische Elemente, die diese Schnittstellen präsententieren.
    • Irgendjemand (wahrscheinlich von Trend, damit es in EEP eingebunden wird,) erstellt eine graphische Benutzeroberfläche, auf der diese graphischen Elemente platziert und verknüpft werden können.
    • Das tatsächliche Auswählen, Platzieren und Verknüpfen wäre dann die Aufgabe des EEP-Anwenders (Anlagenbauers), und damit die Parametrierung.

    Genau so...


    Es ist ja eine Tatsache, dass viele User sich nicht mit Lua auseinandersetzten wollen/können.

    Das ist doch wirklich egal und eines Jeden Recht, aus welchen Gründen auch immer, dass anders zu sehen als ich. Es ist doch keiner das Mass aller Dinge...


    Ich denke mir einfach, dass es gut wäre jedem die Möglichkeiten von Lua zur Verfügung zu stellen. Eben auch jenen, welche logische Verknüpfungen haben möchten, dieses Lua aber einfach nicht als gangbaren Weg wahrnehmen, bez. der Aufwand einfach zu gross wird. Ob solche Hilfen dann genutzt werden, dazu habe ich doch schlicht nichts zu sagen.


    Daher finde ich eben, dass eine Graphische Oberfläche wirklich einigen diese zusätzlichen Möglichkeiten öffnen könnte.

    Daneben ist es eben auch so, dass auch ich, lieber mit, in sich geschlossenen Funktionen, in komplexen Abläufen besser Erweiterungen einbauen kann.

    Das mögen nun Einige anders sehen, aber die Tatsache bleibt bestehen, dass bei Grossanlagen eben diese Technik sich durchgesetzt hat. Zumal sie die Möglichkeit eröffnet, dass Aufgaben in Blöcke aufgeteilt besser, zum Teil gar durch verschiedene Personen, abgearbeitet werden können.


    Warum also bei EEP solches, nicht realisieren wollen, ein Credo sein soll, kann ich wirklich nicht einsehen und glaube auch nicht, dass das der Hersteller so sieht.


    Dabei möchte ich auch mal zu den Äusserungen von nicht Lua-Freak's sagen:

    Das was wir hier diskutieren ist erschlisst sich nicht einfach so. Um das, was ich mir vorstelle für Andere zugänglich zu machen, ist dann schon noch ein schönes Stück Weg zu machen.


    Was man nicht erkannt hat, das erscheint auch nicht als wünschbar. Das sage ich nun, weil immer wieder gesagt wird man könne mit meinen Beispielen nichts anfangen.

    Das verstehe ich durchaus, nur ist es recht schwierig etwas zu zeigen, das noch nicht existiert. Das sind doch z.Z. Gedankenspiele und Erwägungen. Die Ausführung solcher Dinge braucht aber ziemlich viel Planung und ist nicht von Heute auf Morgen realisiert!


    Gruss Marino

    nun, wie auch immer...


    Hier zeige ich nun, wie ein solcher PB in das Programm via FBD (Graphische Oberfläche) eingebunden werden kann.


    https://up.picr.de/34825280yv.jpg


    Nehmen wir mal an:

    1. jemand hat ein spezifisches Problem.
    2. Ein andere ist nun bereit, den Lua-Code dazu zu erstellen und dafür ein FB zur Verfügung zu stellen.
    3. Ist das nun genauso schwierig, das Einzubinden wie den LuaCode zu schreiben?
    4. Ist es schwierig hier zu verfolgen was da abläuft?

    Es ist via Graphik wirklich so, dass der LuaCode, welcher hier dahinter liegt direkt arbeitet, und immer genau das ausführt was programmiert wurde.


    Ps.

    damit ist hoffentlich auch der Untrschied zwischen Programmierung und Parametrierung klar geworden.

    Der Programmierer erstellt den Code

    Der Anwender versieht diesen mit seine Variablen, seien das nun Gleis-, Signal-, Weichen- oder Zug-Adressen.

    Er Parametriert!

    Hi Oliver, & alle, die das Gleiche wünschten. Habe die Variablennamen im Skript #151 getauscht.


    Schon deshalb, weil in Lua die erwähnten Konventionen sinnlos sind.

    Unter Lua gibt es ja zur Datenverarbeitung nur einen Datentyp Double-Integer, der nicht explizit erwähnt werden muss.


    Hoffe, dass der Code jetzt besser ankommt...


    I_ = Eingang

    Q = Ausgang

    Lk= Lokale variable

    hi klioli,


    ich verstehe schon, was Du meinst. Das war aber eben durch das Leitsystem gegeben...


    Andererseits:

    Dazu gibt es in der Steuerungstechnik Konventionen

    1. Stelle I = Input, Q = Output, M = Merker (Global), Lokal oft ohne Vorzeichen wie eben auf unserem Leitsystem.

    2. x = BOOL, b = BYTE, w = WORD, r = REAL, i = INTEGER,

    und die Kombinierer dazu d = double , s = short, l = long
    darauf folgend 1. Zeichen Grossbuchstaben, bis 3 folgende Konsonanten und den letzten Konsonant.

    (Die Erfahrung hat gelehrt, dass gekürzte Worte durch die Konsonanten-folge besser erkennbar sind)

    Im Steuerungscode jedoch oft der Platz für das Ausschreiben der Variablen bei komplexen Rechnungen fehlt;

    insbesondere dann, wenn mehrere Argumente einer Funktion mitgegeben werden müssen.


    Deswegen hier: 1.Zeichen I, Q, ohne

    Oprt = Operator

    Spkt = Sonder Piket

    Hi,


    ich habe vor einiger Zeit einmal George Boole => https://de.wikipedia.org/wiki/George_Boole verwiesen.

    Er hatte damals die sogenannt klassische Logik auf lediglich zwei Zustände reduziert, TRUE und FALSE,

    Sein tragendes Argument war, dass jedes Problem auf mehrere Glieder mit ja/Nein reduziert, schlussendlich zum richtigen Ergebnis des Gesamten führt.


    Darauf gründet die Boolesche Algebra, auf die jede Programmierung fusst.


    Wir hier beschäftigen uns z.Z. mit dem Thema, wie solches nun am einfachsten in EEP umzusetzen ist!

    Ich persönlich vertrete die These, dass das auf den Visuellen Eben viel effizienter und für ungeübte einfacher nachzubilden ist, als via Skripts, welche mitunter zu recht kryptischen und undurchschaubaren Gebilden führt...


    Ihr dürft mir glauben, ich weiss von was ich hier spreche, den auch mir fällt es oft schwer, solche Codes in Script zu durchschauen.


    Dazu ein einfaches Beispiel: Das ist in sich ein Funktionsblock, da dieser >1 Rückgabewert hat

    Das Ganze dient lediglich dazu, die Eingangs-Variablen den Ausgangs-Variablen entsprechend zuzuweisen.

    Es wird benutzt, um auf einer Tabelle eines Leitsystem, durch Auswahl die Alarme an die Operateure (8 Pers.) oder an das Piket (die gleichen 8Pers.) automatisch weiterleiten zu lassen.

    Was wird hiermit erreicht, und welchen Zustand unterbunden?

    Wie schnell könnt Ihr das tatsächlich entschlüsseln?

    Wenn Ihr es wünscht, kann ich das Ganze auch mal in FB zeigen.

    Dabei wird hier jedoch im Unterschied zu Lua anstelle von Integer eben mit BYTE Binär verfahren (16# = Hex)

    Das Prinzip jedoch sollten auch Lua-Texter durchaus lesen können.


    1. Variablentabelle die umfasst lediglich 2 Ein- und Aus-Gänge plus 2 Zwischenresultate.

    Habe nun alle Variablen auf Wunsch ausgetauscht!

    Class Identifire Type Initial Comment
    VAR_INPUT
    I_Operateur BYTE 16#00 set operator
    VAR_INPUT I_Piket
    BYTE 16#00 set emergency
    VAR Lk_Operateur BYTE 16#00 sel operator
    VAR Lk_Piket BYTE 16#00 sel emergency
    VAR_OUTPUT Q_Operateur BYTE 16#00 if operator
    VAR_OUTPUT Q_Piket BYTE 16#00 if emergency


    2. Hier das zugehörige Skript:

    Im Kopf (Header) finden sich alle Variablen ab 'ST' folgt der eigentliche Code

    (Dabei hier in Code, da der ST-Code sonst falsch formatiert erscheint)

    Ps.

    Beachtet bitte, dass hier die Operatoren "=" Gleich, ">" Grösser bedeuten und die Zuweisung mit ":=" geschrieben sind.

    Vielleicht hier noch eine Erklärung, warum das hier in BYTE geschrieben ist. Das liegt daran, dass so direkt die Booleschen Ausgänge Bit-Weise geschrieben werden können. So können zum Beispiel Anzeigelampen an den Ausgängen direkt den Status anzeigen.

    Hi,


    Ich sehe schon, dass ich offensichtlich, von einer anderen Ebene aus eine Automation betrachte.

    Da ich viele Anlagen programmiert habe, welche zueinander verkettet waren, ist mir bewusst, dass in der Regel zuerst immer aufgegliedert werden muss, welche Bedingungen für eine Weiterschaltung erfüllt sein müsse.


    Um solches zu erreichen benötige ich einige Sensoren. Diese aber können in der Regel nur dann eine Weiterschaltung erzeugen, wenn auch weiter Bedingungen gegeben sind.


    Das bedeutet, dass eben Schaltpunkte nicht direkt mit z.B. einer Weiche verbunden sind, sondern dazwischen noch andere Bedingungen erfüllt sein müssen.


    Ein Beispiel zum Gesagte:

    • Wir habe in einem Bahnhof 2. Einfahrten aus verschiedenem Ursprung und 2 welche wegführen. Im Bahnhof hat es 4 Gleise (2 je Richtung & 2 je Destination) Daraus folgt:
      1. Einfahrt 1 => Destination 1 = Gleis 1
      2. Einfahrt 1 => Destination 2 = Gleis 3
      3. Einfahrt 2 => Destination 1 = Gleis 1
      4. Einfahrt 2 => Destination 2 = Gleis 3

    Frage an Euch: Welche Informationen werden nun benötigt, damit die Sicherheit dieser Station immer gewährleistet ist. => Einfahrsignal wird nur im sicheren Zustand freigegeben!

    Alle Eventualitäten, wie z.B. Verschiebung der Zugabfolge (aufgrund von Verspätungen) müssen abgesichert sein.

    Ich werde Euch später vorstellen, wie ich solche effizient realisiere, und erklären, warum dazu die Programmierung in Lua prinzipiell prädestiniert ist. Wie Lua aber bedient wird, dass ist die Frage, um die es mir hier geht.

    Ich werde alle drei Eben aus-programmieren; wenn jemand Lust hat, kann er ja den direkten Lua-Code erstellen, das würde mir einiges an Weg einsparen; welche ich so vorstellen werde.

    Hernach kann jeder für sich selber ersehen, mit welcher Oberfläche das Problem am einfachsten realisiert werden kann, und welches schlussendlich zur Fehlersuche und insbesondere für spätere Ergänzungen; z.B. Einbau eine weiteren Gleis; am Effizientesten ist.


    Überlegt Euch:

    Wer nun solches wissen möchte, soll mir das Bekanntgeben, ich suche schliesslich nicht Aufgaben, an die keiner Interesse hegt...


    Wenn ja, werde ich das unter einer neuer Rubrik tun, damit das Ganze nicht zerzaust vorliegt

    Zum Beispiel and, or, while, do, false, function oder end. Andere, zu denen es kein ähnlich lautendes deutsches Wort gibt, kann man dann schnell lernen. Zum Beispiel if für falls, else für andernfalls und true für wahr.


    if & else wurde früher bei Simens, Festo (z.B. bei Quikstepper) und Anderen deutschsprachigen mit:

    Wenn / Dann

    wiedergegeben, der Eine oder Andere wird das vielleicht schon mal gehört haben...