Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 19 von 19

Thema: Digitale Eingänge mit TwinCat auslesen

  1. #11
    sucb76 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    15.12.2015
    Beiträge
    24
    Danke
    5
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    screen999.png

    So sieht das Programm aus. Simpler geht es ja eigentlich nicht, sollte man meinen. Zählt aber nicht hoch.

  2. #12
    Registriert seit
    24.02.2009
    Beiträge
    1.242
    Danke
    23
    Erhielt 276 Danke für 235 Beiträge

    Standard

    Ist das dein Hauptprogramm (also direkt mit der Task verknüpft) oder ist das ein zusätzliches Programm, das von dir selber aufgerufen werden muss, damit es abgearbeitet wird?
    Wenn Bausteine nichts machen, dann meisten weil sie oder ihr übergeordneter Baustein garnicht aufgerufen werden.
    Ich gehe mal davon aus, das du den Test-Code in ST in einem anderen Baustein ausgeführt hast?

    Du kannst ja mal Spassenshalber die Ablaufkontrolle aktivieren, nur um sicher zu gehen. =Link - Ablaufkontrolle=
    Sänd from mei Kombjudder mitse Dastadurr.

  3. Folgender Benutzer sagt Danke zu MasterOhh für den nützlichen Beitrag:

    sucb76 (15.03.2016)

  4. #13
    sucb76 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    15.12.2015
    Beiträge
    24
    Danke
    5
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Es ist ein Unterprogramm, welches auch in MAIN aufgerufen wird. Ich habe nun anstatt FUP einen Zähler direkt in ST geschrieben mithilfe einer Flankenerkennung anhand eines Beispiels hier aus dem Forum. Jetzt funktioniert es! Warum weiß ich nicht, aber damit bin ich erstmal zufrieden. Evtl. kriege ich es auch noch mit FUP ans Laufen....

  5. #14
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    749
    Danke
    27
    Erhielt 164 Danke für 142 Beiträge

    Standard

    Wenn jemand auf ST umsteigt, kann ich das nur befürworten. Trotzdem wäre es interessant, herauszufinden, warum das nicht funktioniert hat, denn an der Sprache wird es kaum liegen.
    Es könnte sein, dass das PRG "KWH" mit dem Eingang nicht zurechtkommt. Deklariere den "Eingang1 AT %IX12.0:BOOL" mal in Deinem Hauptprogramm und verpasse dem PRG "KWH" eine VAR_INPUT "Eingang1:BOOL". Beim Aufruf von "KWH" musst Du dann den "Eingang1" aus dem Hauptprogramm an den "Eingang1" von "KWH" übergeben. Sollte es dann funktionieren, wäre das ein guter Grund mehr, auf den Aufruf von Programmen aus anderen Programmen zu verzichten und stattdessen
    Funktionsbausteine zu verwenden.

  6. Folgender Benutzer sagt Danke zu StructuredTrash für den nützlichen Beitrag:

    sucb76 (15.03.2016)

  7. #15
    Registriert seit
    16.03.2014
    Beiträge
    359
    Danke
    74
    Erhielt 45 Danke für 38 Beiträge

    Standard

    Hallo StructuredTrash,
    das sehe ich ähnlich mit ST aber ob PRG versus FB besser ist:
    Ich habe für mein Miniheizungsprojekt viele PRG-Teile geschrieben, jedoch saubererweise niemals IO´s in diesen verwendet, sondern nur vie VAR_INUT genutzt.
    Syntaktisch exakt wie bei einem FB !
    Wenn ich doch niemals diesen Code mehrfach verwende, warum sollte ich ihn dann als FB deklarieren ?
    Für´s Debuggen ist ein einfaches PRG ja noch simpler als ein FB !?

    FB´s nutze ich nur, wenn ich ihn mehrfach brauche...

    Oder gibt es hierbei Unterschiede, welche ich noch nicht gelernt habe ?

    BTW: Mir ist bewusst, das ein PRG völlig autark von der SPS getaktet o.ä. werden kann.
    Aber ansonsten sollte es doch das gleiche wie ein "einmaliger" FB sein oder ?

    Beste Grüße
    Shrimps

  8. #16
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    749
    Danke
    27
    Erhielt 164 Danke für 142 Beiträge

    Standard

    @shrimps:
    Sag niemals Nie. Ich habe mein erstes TC-Projekt auch so geschrieben wie Du, aus genau den Gründen, die Du nennst. Zwei Jahre später habe ich mich darüber geärgert, als unsere Konstrukteure mir eine Maschine vorsetzten, an der alles doppelt vorhanden war. Ansonsten hast Du recht, die Unterschiede merkt man nur, wenn man Böses vorhat (oder aus Versehen tut). Z. B. stehen die Daten der Programme nicht zwangsläufig in einem zusammenhängenden Block, die Instanzdaten von FBs
    in einem PRG dagegen schon.

  9. Folgender Benutzer sagt Danke zu StructuredTrash für den nützlichen Beitrag:

    shrimps (15.03.2016)

  10. #17
    Registriert seit
    09.11.2007
    Ort
    Rhein Main (Darmstadt)
    Beiträge
    663
    Danke
    61
    Erhielt 112 Danke für 80 Beiträge

    Standard

    Zitat Zitat von shrimps Beitrag anzeigen
    Hallo StructuredTrash,
    das sehe ich ähnlich mit ST aber ob PRG versus FB besser ist:
    Ich habe für mein Miniheizungsprojekt viele PRG-Teile geschrieben, jedoch saubererweise niemals IO´s in diesen verwendet, sondern nur vie VAR_INUT genutzt.
    Syntaktisch exakt wie bei einem FB !
    Wenn ich doch niemals diesen Code mehrfach verwende, warum sollte ich ihn dann als FB deklarieren ?
    Für´s Debuggen ist ein einfaches PRG ja noch simpler als ein FB !?

    FB´s nutze ich nur, wenn ich ihn mehrfach brauche...

    Oder gibt es hierbei Unterschiede, welche ich noch nicht gelernt habe ?

    BTW: Mir ist bewusst, das ein PRG völlig autark von der SPS getaktet o.ä. werden kann.
    Aber ansonsten sollte es doch das gleiche wie ein "einmaliger" FB sein oder ?

    Beste Grüße
    Shrimps

    Der Hauptunterschied ist, dass Du einen FB unter verschiedenen Namen mehrfach instanzieren kannst und musst.

    Ein PRG ist immer automatisch und genau einmal instanziert.

    Ich halte es für einen Nachteil, dass man aus einem PRG einen anderen PRG aufrufen kann, dadurch können zumindest theoretisch Rekursionen auftreten. PRG1 ruft PRG2 auf, welches wiederum möglicherweise PRG1 aufruft, was dann natürlich PRG2 aufruft ...

    Die SPS hängt dann ewig und wird abstürzen. Das ist Theorie, vielleicht wird es auch in den Implementationen der diversen Compiler überprüft.

    Ich selber halte mich an die Regel:

    1 Hauptprogramm ruft FUNCTIONS auf oder instanziert die FB und ruft sie auf.

    FB ruft FUNCTIONS auf oder instanziert weitere FB und ruft sie auf. (Ich meine, gleiche FB Typen können im FB nicht instanziert werden.)

    FUNCTIONS können nur FUNCTIONS aufrufen. FUNCTIONS können keine FB instanzieren somit auch nicht aufrufen.

    Alle diese Regeln sind begründet in der Erfahrung, dass man defensiv programmieren sollte, um die Übersicht nicht zu verlieren.
    Fehler werden somit auf der Compiler Ebene schon unmöglich gemacht.
    Das ist dann auch der Vorteil der SPS, sie ist fast nicht vom Anwendungs Programmierer zum Absturz zu bringen.

    Wer tricksen möchte oder sich für clever genug hält, kann sich immer noch ein rohes Embedded System nehmen und mit ASM oder C ein vollkommen freies Feld für sich erobern.
    Als Freelancer immer auf der Suche nach interessanten Projekten.
    Zitieren Zitieren Gründe liegen in der Betriebssicherheit  

  11. #18
    sucb76 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    15.12.2015
    Beiträge
    24
    Danke
    5
    Erhielt 0 Danke für 0 Beiträge

    Standard

    So wie von StructuredTrash beschrieben, funktioniert es ebenfalls!

  12. #19
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    749
    Danke
    27
    Erhielt 164 Danke für 142 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Ok, dann wäre das geklärt. Mein Tip sollte allerdings nicht dazu dienen, PRG-Aufrufe aus PRGs salonfähig zu machen. Ich kann RobiHerb nur zustimmen und den Einsatz von FBs empfehlen. Ein PRG ist ja sozusagen ein global verfügbarer FB, entsprechend hoch ist die Gefahr, dass man ihn versehentlich in einem Zyklus mehrfach oder gar aus verschiedenen Tasks heraus aufruft.

Ähnliche Themen

  1. Micromaster 440, digitale Eingänge progr. mit BOP
    Von inging im Forum Antriebstechnik
    Antworten: 0
    Letzter Beitrag: 05.12.2012, 15:14
  2. B&R X20BC0087 digitale eingänge forcen
    Von kag1@softsolution.at im Forum HMI
    Antworten: 3
    Letzter Beitrag: 14.03.2011, 08:51
  3. 358 Digitale Eingänge Erfassen und Auswerten
    Von Hector im Forum Simatic
    Antworten: 25
    Letzter Beitrag: 13.07.2010, 10:13
  4. Kabel für Digitale Eingänge
    Von klaus1 im Forum Elektronik
    Antworten: 5
    Letzter Beitrag: 12.05.2010, 21:01
  5. Adressierung digitale Eingänge S7 CPU224
    Von lan12 im Forum Simatic
    Antworten: 11
    Letzter Beitrag: 13.09.2008, 13:09

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •