TIA TIAdreck und Safety

derwestermann

Level-2
Beiträge
628
Reaktionspunkte
65
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin!

Und was kann man falsch machen, damit nicht für alle Safety-Teilnehmer im Profinet ein F-Peripherie-DB erstellt wird?



Übrigens:
Die TIA-SYSUP-Schulung bei Siemens ist komplett für den Arsch!
Da lernt man wirklich überhaupt nichts von dem, was man als Systemumsteiger von S7-Classic braucht!!!
 
Das lässt sich wohl nicht vermeiden, dort stehen ja schließlich wichtige Infos zu jedem deiner Teilnehmer drin, die du verwenden kannst und sollst. Stichwort Passivierung usw.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... das ist nicht seit TIA so sondern schon vorher bei Classic und halt eine Spielregel von Siemens.
Du kannst aber, wenn dich diese DB's stören, sie in einen eigenen Unterordner schieben - dann sieht es ggf. nicht mehr so "schlimm" aus ...

Aber ... by the way ... bei TIA ist ganz sicher nicht alles Gold was glänzt ... aber TIA-Dreck ...? Bleib mal "ein bißchen" sachlich ...

Gruß
Larry
 
OK falsch ausgedrückt: Die Bausteine werden nicht erzeugt, aber logischerweise brauche ich die F-Peripherie-DBs, wie bekomme ich die nun?
Ja, latürnich ist die zugehörige Hardware angelegt und entsprechend parametriert, ich habe sie ja aus dem alten Projekt, das mit dem Bibliotheksgewusel, siehe anderer Thread, herauskopiert.

@DOD666: Und wenn eine Software nach gutdünken seine F-DBs erzeugt, dann ist das Dreck!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
1. CPU enthält F-Programm
2. F-Ablaufgruppe erstellen und dort auch definieren, in welchem Nummernbereich diese DB's erzeugt werden sollen ...
3. Die Bausteine werden nur nach den von dir gemachten Vorgaben erzeugt

und

4. mit Handfeger und Kehrblech den schon erzeugten Dreck wegfegen ... 8)

Gruß
Larry
 
Also gerade bei Safety gibt es bei TIA viele Detailverbesserungen im Vergleich zu Classic.
Die DBs stören doch kaum
 
Nummernbereiche der generierten F-Systembausteine ind Safety-Administration steht auf "Vom System verwaltet".

Eine F-DB-Nummer wird in den F-Parametern der Baugruppe auch angezeigt, aber kein F-DB-Name, wie dies bei den Baugruppen der Fall ist, für die F-DBs erzeugt werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eigentlich ist das ja nun wirklich ganz ok gelöst wenn man es einmal verstanden hat.
Bei V14 landen die Peripherie-DBs eh schon in einem eigenen Ordner (siehe Bild).
Und jeder DB erhält als Prefix seine E/A-Startadresse damit man ihn auch easy wiederfindet (siehe Bild).
Und wie Larry schon sagt landen alle F-DBs in einem von dir persönlich definierten Nummern-Bereich.
F-Peripherie.jpg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nehmen wir die Fakten:
Seit letzter Woche bin ich dabei, aus einem, vom Kunden gestellten, Musterprogramm, mein Projekt aufzubauen. Ich mache seit 20 Jahren S7 und habe mir gedacht, dass ich mal nicht so wie die alten Säcke, die bei der Umstellung von S5 auf S7 im S5 hängengeblieben sind vorgehe, sondern den Umsteigerkurs besuche. Dort lernte ich alles, was man im Berger-Schmöker in einer halben Stunde finden kann. Was ich nicht gelernt habe, ist damit umzugehen, wenn Bibliotheken zu erneuern sind und wie man den Teufelskreis von selbstherrlicher Erstellung neuer Datentypen und der Inkonsistenz zwischen globaler und Projektbibliothek, sowie dem Projekt selbst auflöst.

Nun denn, bauen wir das Projekt halt noch mal neu, mit dem frisch aktualisierten Musterprojekt auf. In selbiges kopiere ich die fehlenden Hardwarekomponenten, beziehungsweise erstelle neue, wegen neuerer GSDML-Dateien. Aber für nicht alle F-Baugruppen werden F-DB erstellt, warum? Also kümmere ich mich erst mal um die restlichen EA, welche als fehlerhaft im Programm, oder in der Variablentabelle ausgewiesen werden und erhalte: Den zweiten Absturz vom TIA-Portal an diesem Tag.
Soviel zum Thema Dreck. Eine Software in der Version V14 hat nicht mehr völlig unkontrolliert abzustürzen!
Nachdem ich das Projekt wieder öffne und erneut übersetze, werden die von mir als fehend mokierten F-DB generiert. Soso, muss man das Projekt also gelegentlich schliessen, damit die Hardware verstanden wird, bei 13 PNIO-Teilnehmern? Dann ist das Dreck!

Was mache ich denn, wenn mal ein ernsthaftes Projekt zu machen ist?
Dürfte ich entscheiden, würde ich sagen: Kein TIA nehmen, ganz einfach.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ggf. können die DBs auch Leichen deiner Zusammenkopiererei sein. In der Safety Administration gibt es unter dem Punkt "Einstellungen" die Möglichkeit "vom System erzeugte Objekte" zu bereinigen. Das kannst du ja nochmal Probieren. Dann Hardware übersetzen und dann Software mal komplett übersetzen.
 
Noch mal ein Entwirrversuch:

Die F-Peripherie-DBs wurden NICHT generiert, ich hatte nicht zu viele davon, sondern zu wenige. Leichen habe ich keine.
Und latürnich habe ich eine F-Ablaufgruppe und so, das ist schon im Musterprojekt alles passend voreingestellt.

Ich habe nach dem TIA-Absturz das Projekt erneut geöffnet und bei der dann vorgenommen Übersetzung, wurden auch die fehlenden F-DBs erzeugt.
Daher meine Anmerkung, ob man denn das Projekt gelegentlich schliessen muss, um konsistent weiterarbeiten zu können.

Danke für die reichliche Anteilnahme

Euer Kai
 
Das mit den F-DBs hatte ich so noch nicht. Ich hatte es bei der IBN nur mal (leider mehrmals an einem Tag), dass nicht alle F-Bausteine übertragen wurden. Ursache unbekannt. Lösung war neu generieren und CPU vor dem übertragen manuell stoppen.
 
Ich habe schon so einige F-CPUs in V13/14 und nun auch in 15.1 projektiert und in Betrieb genommen. Das von dir geschilderte Problem trat bei mir allerdings noch nie auf - weder stand-alone noch im Multiuser.
 
Zurück
Oben