Step 7 Flankenmerker in FC's

[spirit]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dass Solte so nicht werken.
Met der code
L MB10
T LD0
Wurde MB10 in LB3 gesets und nicht in LB0

Sie muste die code
L MB 10
T LB 0
Brauchen
und an ende

L LB 0
T MB 10

Joop

Aja, stimmt eigentlich Joop!

Oder aber:

L MD10
T LD 0

 

[nutellahase]

Hallo spirit! Hier hast du noch einen von Harald (PN/DP) geschriebenen Beitrag zum Thema Flankenauswertung (aus den FAQ)!
Flankenauswertung in Step 7

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn es nur ein oder zwei Flanken-Signale sind, dann könnte man auch die Flankenauswertung ausserhalb des FC machen und das fertige Impuls-Signal an einen FC-IN geben.

Zum Thema "Instanz-Variablen" für FC statt Nutzung von FB siehe auch mal hier.

Harald

 

[spirit]

Danke für die Link's - sehr interessant!


Aber alles in allem ist die Bildung der Flanken doch mehr oder weniger Kosmetik und tägt zu dem reibungslosen Ablauf (bei richtiger Anwendung einer jeden Variante) nichts bei, oder?

Es ist wohl mehr der gute Stil so zu programmieren, dass alles schön übersichtlich bleibt...

Doch aus der Wahl einer Variante A oder B sollte sich (nach meinem Verständnis) eigentlich kein Geschwindigkeitsvorteil in der SPS ergeben.

 

[RogerSchw85]

Ich verstehe die ganze Problematik nicht ganz. Einem FC sachen zu übergeben finde ich sehr unsauber. Dazu ist der FB da! Ein FC mehrmals in einem Program aufzurufen finde ich auch unsauber! Auch dazu ist der FB da! Man könnte einene FB ohne Instanz DB aufrufen, aber das finde ich sehr unsauber...

Mach zu dem FC einen DB in dem du die Flankenmerker hast... Oder reservier dir einen Bereich auf der SPS von Merkern in dem du die Flankenmerker hast...

Wo genau ist eigentlich das Problem?

Gruss

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also die Frage wegen Flanke und so ist weit abgeschwiefen.
Doch immer zu schreiben wegen der Wiederverwendung von Bausteinen ist eigentlich völlig falsch.
Man kann Funktionen, die klar definiert sind, kapseln und daraus ein sauberes Programm bauen.
Doch alles und jedes parametrierbar machen ist einfach Müll.
Es lässt sich nicht umgehen, dass man noch programmieren muss und nicht alles zusammen kopieren soll bzw kann.

Daher nicht Kanonen und Spatzen (@SM: ohne Beleidigung)


bike

 

[PN/DP]

Ich verstehe die ganze Problematik nicht ganz. Einem FC sachen zu übergeben finde ich sehr unsauber. Dazu ist der FB da! Ein FC mehrmals in einem Program aufzurufen finde ich auch unsauber! Auch dazu ist der FB da! Man könnte einene FB ohne Instanz DB aufrufen, aber das finde ich sehr unsauber...

Mach zu dem FC einen DB in dem du die Flankenmerker hast... Oder reservier dir einen Bereich auf der SPS von Merkern in dem du die Flankenmerker hast...

Wo genau ist eigentlich das Problem?

Das Problem ist da, daß die TE eine mehrfach aufrufbare Function schreiben will, genauso wie die ...zig "unsauberen" FC welche Siemens in den Bibliotheken zu Step7 mitliefert, z.B. solch üble Sachen wie SCALE und UNSCALE Wie lange programmierst Du schon? Kennst Du auch Programmierweisen welche nicht "unsauber" sind?

Harald

 

[bike]

Unsauber mit unsauber vergleichen ist doof.
Such doch in einem Programm in der Xref nach Merkern, die indirekt übergeben und verwendet werden.
Wenn ein FB seine Flanken in dem IDB speichern ist es okay, denn der IDB gehört dem FB.
Aber solch eine Vorgehensweise bei einem FC?
Ich habe vor kurzem in einem Programm einen DB gehabt, der aus einig hunderten von Bits bestand, die als Array of Bit definiert waren, doch macht es wirklich Spaß so ein Programm zu warten oder zu erweitern?


bike

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ein FC mehrmals in einem Program aufzurufen finde ich auch unsauber!

Darf ich mal fragen, was daran unsauber sein soll?

Die serienmäßigen Funktionen UND, ODER usw. benutzt Du doch sicher auch nicht nur einmal pro Programm, oder?
Warum sollte das bei selbst erstellten Funktionen D.M.n. nicht gemacht werden?

 

[PN/DP]

Vielleicht versteht er unter FC nur ein Auslagern von Programmcode aus dem OB1? (wie PB in good old Step5)

Harald

 

[bike]

Darf ich mal fragen, was daran unsauber sein soll?

Der Kollege hat aber auch geschrieben, dass das Übergeben von In/OUT unsauber ist.
Und einen FC so zu schreiben, dass er öfter verwendet werden kann, ist gut,
Doch den Baustein aufzublasen, damit er passt, ist suboptimal.
Mal versteht nichts mehr, findet keinen Fehler und ändern bitte nicht.

Suche in einem Programm nach einem MW, wenn die Nummer des Wortes als INT an einen FC übergeben wird.


bike

 

[RogerSchw85]

Zuviel Werbung?
-> Hier kostenlos registrieren

das ist meine persöhnliche meinung... Ich programmiere selbständige Funktionen eifach immer in einem FB...

Aber wie gesagt meine meinung...

Aktuell darf ich ein Programm verstehen das komplett in SCL geschriben ist, und die Werte werden vor einem FB immer in seinen Instanz DB direkt geschriben... ganz toll...

Aber egal, ich programmiere schon ein paar Jahre... Aber jeder Programmierer ist sowieso überzeugt er mache das beste...

 

[hucki]

Ich verstehe die ganze Problematik nicht ganz. Einem FC sachen zu übergeben finde ich sehr unsauber. Dazu ist der FB da!

Heißt für mich, der FC soll keine Schnittstelle haben.
Spricht m.M.n. für Haralds Vermutung:

Vielleicht versteht er unter FC nur ein Auslagern von Programmcode aus dem OB1? (wie PB in good old Step5)

Ein FC mehrmals in einem Program aufzurufen finde ich auch unsauber! Auch dazu ist der FB da!

Auch für diese Aussage gibt's sicherlich einen Grund.

Das interessiert mich einfach - und zwar völlig wertungsfrei.

 

[RogerSchw85]

Ich verstehe nicht wieso man jetzt eine riesen sache mit Flankenmerker schreiben muss, wenn man es bequem in einem FB lösen könnte... Wo liegt das der Sinn? Ausser das in 10Jahren kein Mensch mehr weis was geht?!?

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich programmiere selbständige Funktionen eifach immer in einem FB...

Auch wenn Du keine Daten hast, die über den aktuellen Zyklus hinaus gespeichert werden müssen?
Z.B. wiederkehrende Berechnungswege?

 

[RogerSchw85]

Heißt für mich, der FC soll keine Schnittstelle haben.
Spricht m.M.n. für Haralds Vermutung:



Auch für diese Aussage gibt's sicherlich einen Grund.

Das interessiert mich einfach - und zwar völlig wertungsfrei.

Ich trenne einfach ablauf und funktionen so...

 

[RogerSchw85]

Auch wenn Du keine Daten hast, die über den aktuellen Zyklus hinaus gespeichert werden müssen?
Z.B. wiederkehrende Berechnungswege?

hab ich mir vorhin au überlegt... Jap ich mache immer eine FB, aber habe diese auch schon ohne IDB aufgerufen

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich verstehe nicht wieso man jetzt eine riesen sache mit Flankenmerker schreiben muss, wenn man es bequem in einem FB lösen könnte...

Ich denke, da war sich das Gro der Threadteilnehmer schon ab Post #7 einig, dass Du da Recht hast.

Der TE ging es einfach mal um das Ausloten der Möglichkeiten und ob das irgendeinen Einfluss auf die Performence hat.

 

[PN/DP]

Ich verstehe nicht wieso man jetzt eine riesen sache mit Flankenmerker schreiben muss, wenn man es bequem in einem FB lösen könnte...

Wenn man nun eine häufiger benötigte Funktion aus einem FC aufrufen will, dann müßte dies nach Deiner Sicht ein FB sein, Multiinstanz würde aber nicht gehen, also müsste man jeder FB-Instanz einen eigenen IDB geben - womöglich nur, um darin einen einzigen Flankenmerker zu speichern....

Harald

 

[RogerSchw85]

Wenn man nun eine häufiger benötigte Funktion aus einem FC aufrufen will, dann müßte dies nach Deiner Sicht ein FB sein, Multiinstanz würde aber nicht gehen, also müsste man jeder FB-Instanz einen eigenen IDB geben - womöglich nur, um darin einen einzigen Flankenmerker zu speichern....

Harald

Bei dir klingt das so negativ...Naja das Thema nimt so kein Ende.

Vielleicht sollte ich meine Variante auch mal überdenken... Bis jetzt hatte ich keine Probleme damit. Bei spezifischen Programmen hab ich auch absolut keine Probleme mit Multiinstanzen... Kommt halt immer auf die Aufgabe an...