Step 7 SFC14 / 15 Vor- und Nachteile

[plc_typ]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,
ich habe momentan mit einem sehr Hartnäckigen Kunden zu tun der sich stark in die Programmierung einmischt.

Neuester Punkt auf der Mängelliste sind die Systemfunktionen SFC14 und 15 die ich benutze um Daten konsistent von
Schnittstellen zu Lesen und zu Schreiben (größtenteils I-Device).
Ich soll diese Bausteine nun entfernen und direkt auf die E/A´s zugreifen, wogegen ich mich allerdings Sträube, da ich keinerlei
Vorteile darin sehe.
Ich finde, dass das Konsistente Lesen über die Standardbausteine der Beste weg ist, auch weil man noch eine Auswertung hat
ob das Lesen/ Schreiben erfolgreich war.

Was haltet Ihr davon? Benutzt Ihr immer Die SFC´s oder auch Direktzugriffe auf die E/A ebene?


Gruß Florian

 

[Wincctia]

Hallo plc-typ

bei uns heist es auch immer das man sich mit solchen Sachen zurückhalten soll weil halt nicht so fitte Kollegen von mir die EA Zugriffe (weil ja als Hex übergeben nicht finden) ich Persönlich finde diese Bausteine eigentlich schon Praktisch weil ein Großer unsortierter E/A Bereich einfach einer Struktur übergeben werden kann.
Ich verwend dafür jetzt immer Blockmove wenn der Bereich noch im Prozessabild liegt das findet man ja recht schon über Referenz Daten


Gruß TIA

 

[MSB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Naja, Konsistenz ist in Zeiten von großen Prozessabbildern eigentlich nicht mehr das Hauptargument für SFC14/15.
Also technisch betrachet einen wirklichen Vorteil sehe ich in SFC14/15 (nicht) mehr.
Stören würde es mich allerdings auch nicht, da man EAs in einem DB definitiv besser struckturieren und standardisieren kann als in der Symboltabelle.

Was aber definitiv ein Nachteil ist, das man aus der Sicht eines Fremden, nur mit hohem Aufwand rausfindet wo denn jetzt gerade auf jene konkrete Hardware gelesen / geschrieben wird.
Am SFC14/15 wird ja nur nummerisch die Basisadresse angegeben, was zur Folge hat, das man aus Sicht der HW-EA-Adressen null Querverweise hat.

Mfg
Manuel

 

[PN/DP]

Das ist nicht eine Frage von Vorteil/Nachteil oder Programmierstil, sondern von Erfordernis.

Wenn für die E/A Konsistenz von 3 Byte oder >= 5 Byte festgelegt ist, dann MUSS SFC14/SFC15 benutzt werden.
Wenn Konsistenz von 1, 2 oder 4 Byte festgelegt ist, dann MUSS L/T benutzt werden, SFC14/SFC15 verweigern in dem Fall den Dienst.

Wenn die E/A jedoch im Prozessabbild liegen, dann kümmert sich das Betriebssystem der CPU um die richtige Ansprache der Peripherie und SFC14/SFC15 sind ebenfalls nicht zu benutzen, weil dadurch die E/A ein zweites mal eingelesen/geschrieben würden. Auf die E/A im Prozessabbild wird mit L/T zugegriffen.

Harald

 

[borromeus]

Also ich greife auf die EA's zu wo immer es geht.
Ich sehe umgekehrt nicht den Vorteil des Herumgeschiebe.
Dass man einen DB besser strukturieren kann mag vordergründig ein Vorteil sein, man muss aber alles doppelt dokumentieren.
Also ich verstehe den Kunden.
Den SFC14/15 verwende ich wenn es technisch notwendig ist.

 

[plc_typ]

Zuviel Werbung?
-> Hier kostenlos registrieren

Alles gute Punkte!

Was aber definitiv ein Nachteil ist, das man aus der Sicht eines Fremden, nur mit hohem Aufwand rausfindet wo denn jetzt gerade auf jene konkrete Hardware gelesen / geschrieben wird.
Am SFC14/15 wird ja nur nummerisch die Basisadresse angegeben, was zur Folge hat, das man aus Sicht der HW-EA-Adressen null Querverweise hat.

Ich Finde eigentlich, dass das recht Fix gefunden ist. Schnittstellen DB in den Referenzdaten angeben und nach einer Bitvariable ( xx.0) mit CALL Verwendung schauen. Wenn der Ausführende Programmierer
einigermaßen Strukturiert vorgegangen ist sollte das schnell zu finden sein.


Bleibt noch die Frage von der Notwendigkeit bzw des Nutzen der Ret_Val zur Diagnose.

 

[Thomas_v2.1]

Bleibt noch die Frage von der Notwendigkeit bzw des Nutzen der Ret_Val zur Diagnose.

Ich nutze das z.B. wenn ich von einem FU oder Messgerät Zählerstände einlese. Schlägt der SFC fehl, dann kopiere ich die Zählerstände aus dem SFC-Datensatz nicht. Bei manchen Protokollierungsprogrammen führen solche Sprünge zu Fehlern in der späteren Auswertung. Bzw. bei FUs ist bei mir dann der Antrieb gleich gestört, mit entsprechender Fehlermeldung.

 

[Knaller]

Moin
In der ganzen PLC Welt übertragen die Steuerungen die Daten konsistent, nur nicht in der Siemens Welt. Nur bei BIG S muss die Steuerung mit SFC 14 & SFC15 dazu gezwungen werden. Ist schon doof wenn eine Zielposition für eine Positionierachse zerstückelt wird oder wenn Zählerstände so stückweise ankommen.

Mit RWE hatte ich das Thema.
Gruß Herbert


Sent from my iPhone using Tapatalk

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn die neuen Steuerungen 1200 bzw. 1500 verwendet werden, kann man getrost
auf die SFC 14/15 verzichten.

Was da wirklich mal gelungen ist, das man einen Datentyp für die Ein.-bzw Ausgänge
Deklarieren kann.

 

[Thomas_v2.1]

Moin
In der ganzen PLC Welt übertragen die Steuerungen die Daten konsistent, nur nicht in der Siemens Welt. Nur bei BIG S muss die Steuerung mit SFC 14 & SFC15 dazu gezwungen werden. Ist schon doof wenn eine Zielposition für eine Positionierachse zerstückelt wird oder wenn Zählerstände so stückweise ankommen.

Bei Siemens muss man nur wissen was man tut. 4 Bytes können immer konsistent gelesen werden, d.h. ein Zählerstand als DINT ist damit immer konsistent, auch ohne SFC. Es lässt sich auch das Prozessabbild entsprechend umstellen, das aber nicht mit S7 der unteren Kategorie.

 

[borromeus]

Wir sollten mal definieren um was wir hier diskutieren!
EA's die zB an einer ET200M dranhängen oder PB- Teilnehmer.
Für erstere: kein SFC-Zugriff, für zweitere: kann sinnvoll sein, kann aber auch sehr- sehr sinnvoll sein, siehe:

http://www.sps-forum.de/simatic/83407-sfc14-15-vor-und-nachteile.html#post627838

 

[MSB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schnittstellen DB in den Referenzdaten angeben und nach einer Bitvariable ( xx.0) mit CALL Verwendung schauen. /QUOTE]
Gegenfrage:
Wie finde ich, abgesehen von deiner manuell eingetragenen Symbolik/Kommentar den Schnittstellen-DB (schnell)?

 

[plc_typ]

schnittstellen db in den referenzdaten angeben und nach einer bitvariable ( xx.0) mit call verwendung schauen.

gegenfrage:
Wie finde ich, abgesehen von deiner manuell eingetragenen symbolik/kommentar den schnittstellen-db (schnell)?

Das Stimmt, da hat man dann eher schlechte Karten.

Ich finde aber, dass dann schon von Vornherein ein Strukturproblem vorliegt, wenn es nicht möglich ist anhand der Symbolik einen solchen DB zu finden.
Besonders bei größeren CPU´s mit jede menge Schnittstellen halte ich es da für wichtig diese klar erkenntlich zu machen z.B.

DB400 COM_SEND_Ofen1
DB401 COM_RECV_Ofen1
DB402 COM_SEND_Ofen2
DB403 COM_RECV_Ofen2
DB410 COM_SEND_Beschickung
DB411 COM_RECV_Beschickung