SFCTip macht einfach weiter...

vegaS
2007-03-21
2007-03-23
  • vegaS - 2007-03-21

    hallo zusammen,

    ich programmiere zur Zeit an einer Anlage mit 7 Zylindern.

    Den Ablauf wollte ich dieses mal nicht wieder mit einer Schrittkette () in ST realisieren,

    sondern mit AS.

    Das funktioniert soweit ganz gut - doch jetzt hänge ich am SFCTip.

    Es schaltet Schritte weiter, obwohl die Weiter-Bedingung (Transition) gar nicht wahr wurde.

    Bei Alternativen scheint es einfach den linken Zweig zu schalten.

    Wozu soll das gut sein?

    Bei mir führt es zu dem Problem, dass ich einen Schritt weiter schalten kann,

    obwohl die erste Endlage noch gar nicht erreicht ist. (=crash)

    Wie ist das mit dem SFCTip gedacht und wie wird es verwendet?

    vielen Dank,

    vegaS

     
  • mwatermann - 2007-03-21

    moin,

    poste doch mal zB einen screenshot der transitionen, oder poste den projekt teil. klingt merkwürdig.

     
  • vegaS - 2007-03-21
    PROGRAM Abl_Automatik_Betrieb
    VAR_INPUT
       SFCReset: BOOL := FALSE;
       SFCTipMode: BOOL := FALSE;
       SFCTip: BOOL := FALSE;
    END_VAR
    VAR_OUTPUT
       SFCError: BOOL;
    END_VAR
    

    Von aussen (dem aufrufenden Programm) setze ich im Tipp-Betrieb SFCTipMode := TRUE und SFCTip auf den Wert des Tipp-Tasters.

    So ist es möglich die Schritte und somit den Anlage zu "tippen".

    Das Problem ist, dass es im Tippbetrieb um einen Schritt weiter geht

    (immer der linke) obwohl die Transition gar nicht wahr geworden ist.

    Ich finde keine Möglichkeit sinnvoll - also nur wenn erlaubt - in den nächsten Schritt zu tippen.

    Muss ich jetzt "AND SFCTip" in jede Transition meiner Schrittkette einfügen!?

    Was macht der TipMode dann für einen Sinn?

    danke,

    vegaS

     
  • vegaS - 2007-03-23

    Ui, ich sehe wir beide verwenden CoDeSys in der Praxis und eine gewisse

    Seelenverwandtschaft auch, wegen dem in Klammer gesetzten " (=crash) "

    Ich verwende auch eine Anlage, bei der sich Achsen kreuzen müssen

    und Ausschieber nur betätigt werden dürfen, wenn das Gegenstück in

    entsprechender Position ist.

    Es ist bei mir kein harter Crash aufgetreten aber der derzeitige

    TIP-Betrieb ist der Wahnsinn!!! Wenigstens im Handbuch und der Hilfe

    müsste explizit auf diese (Fehl-)-Funktion hingewiesen werden.

    Ich kann mir immer noch nicht vorstellen, wo man diese Art von Tipbetrieb

    brauchen kann!

    Anders ausgedrückt: Bei einer Anlage, die mit diesem Tip-Modus betrieben

    werden kann, kann man sich das Erstellen von Transitionen gleich völlig sparen,

    da es offensichtlich keine ernsthaften "Bedingungen" zwischen den Schritten gibt.

    Leider ist die Version 3.0 nicht für alles frei gegeben.

    Ein Handbuch finde ich bisher auch nicht.

    Ich verzichte jetzt auf den SFCTip-Betrieb und habe überall ein

    (...) AND myTIP eingebaut.

    Gruß,

    vegaS

     
  • Ralph Holz - 2007-03-23

    Hallo Miteinander,

    irgendwie fühle ich mich hier jetzt gedrängt sowohl meine als auch die 3S sicht ein bischen zu erleutern.

    Ich muss euch völlig recht geben der Tipmode ist für die Inbetriebnahme einer Machine (wo sich irgendwas bewegt zu 96% sinnlos) und schon garnicht verwendbar um dem Bediner/Benutzer damit ein Tippen zu ermöglichen, deshalb stand und steht bei mir fast allen Transitionen der ausdruck "AND wsb" die Variable wsb ist im Automatikbetrieb eben True und im Tippbetrieb eben flankengetriggert. Ich habe damit ziemlich gut gelebt besonderst weil ich diese wsb dann gegebenenfalls auch mal weglassen konnte.

    Ich habe mich gerade gestern mit einem CoDeSys Entwickler unterhalten wie das den jetzt in 3.x werden soll.

    Die beiden Tipmodi entweder nur Tip unabhängig von der Transition und Tip oder Transition sind für die reine Softwareentwicklung also ohne vorhandene Hardware gedacht. Das bleibt auch in 3.x so wird aber um einen "Servicemode" erweitert der dann auch die Möglichkeit hat Transition und Tip. Es wird hierbei auch über eine konfigurierbarkeit pro Transition nachgedacht, dann könnte jeder genau das tun was er will.

    Ich weis nicht wie offt ich den folgenden abschnitt noch schreiben werden:

    Mit CoDeSys 3.X kann (und wird auch nie können) keine Hardware die heute mit 2.3 programmierbar ist programmiert werden.

    Vielleicht wird es mal von dem einen oder anderen Hardwarehersteller ein Firmwareupdate des Laufzeitsystems geben. Das heist natürlich auch umgekehrt 3.X Hardware kann nicht mit CoDeSys 2.3 programmiert werden.

    Grüße aus Kempten

    Ralph

     

Log in to post a comment.