TIA Verwendung AT-Sicht

[Tigerente1974]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Forum,

ich habe zum ersten Mal mit der AT-Sicht herumprobiert.

Hintergrund: Ich habe die Bits für Störmeldungen in einem DB. Für den symbolischen Zugriff mit aussagekräftigem Kommentar wollte ich das auf jeden Fall mit BOOL-Variablen haben.
Zur besseren Übersicht habe ich die Bits zu einem "Wort" zusammengefasst. Dazu habe ich ein Struct angelegt, in dem 16 BOOL-Variablen deklariert sind.

Z.B.:
DBX0.0: "DB_Störungen".Foerderer12_W1.Sicherung
DBX0.1: "DB_Störungen".Foerderer12_W1.Laufzeitfehler
etc.

Für mein Sammelfehlerbit möchte ich natürlich das Wort abfragen. Das geht mit einem absoluten Zugriff.
Ich möchte aber symbolisch zugreifen. Das geht aber nicht wegen des STRUCT.

Also habe ich mir einen Baustein geschrieben, der als Eingang ein STRUCT mit 16 BOOL-Variablen hat und eine AT-Sicht als WORD darauf gelegt.
So kann ich das als WORD vergleichen und über einen Ausgang an der Schnittstelle ausgeben. ob ein Bit aus der Struktur an ist.
Das habe ich in der Simulation getestet und es scheint zu funktionieren.

Nun zu meiner Frage:
Für eine AT-Sicht wird ja ein FB benötigt. Bei dessen Aufruf muss also auch ein Instanz-DB deklariert werden.
Bei entsprechend vielen Störmeldewörtern käme eine ganz Reihe von IDB zusammen.
Deswegen habe ich getestet was passiert, wenn ich den FB mit der AT-Sicht immer mit der gleichen Instanz aufrufe.

In der Simulation hat die Auswertung mehrerer, verschiedener Störmeldewörter so funktioniert.
Andererseits sollte man das ja eben nicht machen, dass man einen FB mehrfach mit der gleichen Instanz aufruft.
Allerdings habe ich ja keine Variablen im "Static"-Bereich angelegt, sondern nur am Eingang und am Ausgang.

Ist der Code so unsauber?
Wenn ja, wie kann ich das sauber lösen ohne für jedes Störmeldewort einen IDB zu deklarieren?

Gruß

Chris

 

[TP-Inc]

Hallo, ich denke der Code funktioniert da sich der FB nix merken muss, die Eingänge werden bei jedem Aufruf neu übergeben. Ob das saubere Programmierung ist, ist eine Streitfrage. Mir wärs einfach zu blöd so viele Meldungen anzuschalten. Da der DB fürs Bitmeldeverfahren sowieso nicht optimiert sein darf, würde ich hier eine Funktion schreiben die den DB als ANY bekommt, die Länge bestimmt und mit einer Schleife den DB wortweise auf <>0 abfragt.

 

[Tigerente1974]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

danke für die Antwort.
so wie Du das mit der Schleife vorgeschlagen hast, mache ich das für die Bearbeitungsstationen. Pro Station ein DB und dann mit Schleife abfragen und auch nullen, wenn quittiert wird.
Da sind in der Regel auch mehr als 1 oder 2 Störmeldewörter drin. Und ich habe nicht so viele Stationen.
Aber Förderer kommen auch gern mal 30 oder mehr. Da würde ich dann pro Förderer einen DB mit einem Störmeldewort deklarieren.
Und ich fand das bisher recht übersichtlich alle Förderer in einem Störmelde-DB zusammenzulegen.

Ich möchte aber unbedingt von den absoluten Zugriffen weg. Vielleicht ist das am Ende doch der sauberste Weg für mein Konstrukt.

 

[hucki]

Da der DB fürs Bitmeldeverfahren sowieso nicht optimiert sein darf.

Bei mir ist er optimiert und arbeitet zuverlässig?!



Die WORD-Ausgabe der Störmeldebits nehme ich direkt in dem FB vor, der auch die Fehler erfasst.
Dies ist eh' ein FB, da ich dort auch Timer und Zustandsmerker zur Flankendetektion im Static-Bereich benötige. Für die WORD-Ausgabe hab' ich dann eine AT-Sicht auf eine TEMP-Variable erstellt und übertrage über diese mit zwei MOVEs von STRUCT zu WORD.

Das solche "Konstrukte" überhaupt notwendig sind liegt aber auch nur an der TIA-Logik:
Warum werden die deoptimierten AT-Sichten hinter Remanenz "Im IDB setzen" versteckt und sind daher nicht im FC möglich? Ein FC hätte dem TE ja ausgereicht.
Warum sind für das Bitmeldeverfahren keine Einzel-BITs zulässig, sondern nur WORDs? Dann könnte man sich das ganze Gebastel eh' sparen.
(Und warum gibt's den Programm-Alarm nicht bei der S7-1200?)

 

[PN/DP]

Für mein Sammelfehlerbit möchte ich natürlich das Wort abfragen. Das geht mit einem absoluten Zugriff.
Ich möchte aber symbolisch zugreifen.

Warum eigentlich so umständlich und ineffizient erst 16 Bit an einen Baustein übergeben (jedes Bit kopieren!) und dann mit Klimmzügen im Baustein die 16 Bit als Word ansprechen und das Word auf <> 0 vergleichen?

Call "MyFB","ImmerSelbeInstanz"
 (In1:="DB1".Bit1,
  In2:="DB1".Bit2,
  In3:="DB1".Bit3,
  ...
  In16:="DB1".Bit16,
  Out => "Sammelfehler")

Folgendes tut das selbe viel effizienter und sieht auch nicht unverständlicher aus:

O "DB1".Bit1
O "DB1".Bit2
O "DB1".Bit3
...
O "DB1".Bit16
= "Sammelfehler"

Bei dieser direkten Variante kann man auch leicht weniger als 16 Bit verknüpfen und muß da nicht wie bei der FB-Lösung eine "Immer0"-Variable (oder FALSE) anschalten.

Harald

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Letztlich gibt es x verschiedene Möglchkeiten und alle haben irgendeinen Nachteil.
Bei mir gibt es auch saubere Störmeldungen im Stations-DB ("StationX".Error.NC3-Fault).
Fürs Panel gibt es dann einen eigenen Stör-FB wo ich die Stationsstörungen der Panel-Störvariable über Slice-Zugriff zuweise.
Ist zwar mehr Tipparbeit, aber unsere Instandhalter kommen gut damit zurecht. Bei einer Störung gibt es eine zentrale Anlaufstelle im Programm und von da geht die Suche weiter.
Bei Neuanlagen verwenden wir eigentlich nur noch ProDiag. Damit entfällt die Bitglauberei.

Gruß
Blockmove

 

[Tigerente1974]

Warum eigentlich so umständlich und ineffizient erst 16 Bit an einen Baustein übergeben (jedes Bit kopieren!) und dann mit Klimmzügen im Baustein die 16 Bit als Word ansprechen und das Word auf <> 0 vergleichen?

In der Ausbildung hat man uns beigebracht, die Störmeldungen als Globalmerker zu projektieren und dann das Meldewort (Z.B. MW200) abzufragen.
Das ging sehr einfach und funktionierte sicher. Das war in den 90ern und die S7 stand noch in den Startlöchern.
Mit der S7 wurde es üblich, die Störmeldungen in einen DB zu schreiben. Was ja auch Vorteile mit sich bringt.

Was ich da jetzt versucht habe, ist das Schema mit den Globalmerkern und dem Meldewort auf Störbits im DB zu übertragen.
Da die Störbits je nach Variante der Maschine variieren, habe ich nach einer Möglichkeit gesucht, die Bits nicht untereinander schreiben zu müssen.
Wenn man da mal ein Bit vergisst oder sich vertippt, kommt das Sammelfehlerbit nicht. Auch deswegen habe ich versucht, eine andere Lösung zu finden.
So ist das dann mit dem Abfragen eines ganzen DB in einer Schleife entstanden. (Siehe mein Post #3)
Das klappt aber eben nicht mehr, wenn man nicht für jeden Teilbereich einen eigenen Stör-DB projektiert.
Auf der Suche nach einer eleganten Lösung habe ich das dann mit der AT-Sicht versucht.

 

[Tigerente1974]

Letztlich gibt es x verschiedene Möglchkeiten und alle haben irgendeinen Nachteil.
Bei mir gibt es auch saubere Störmeldungen im Stations-DB ("StationX".Error.NC3-Fault).
Fürs Panel gibt es dann einen eigenen Stör-FB wo ich die Stationsstörungen der Panel-Störvariable über Slice-Zugriff zuweise.
Ist zwar mehr Tipparbeit, aber unsere Instandhalter kommen gut damit zurecht. Bei einer Störung gibt es eine zentrale Anlaufstelle im Programm und von da geht die Suche weiter.
Bei Neuanlagen verwenden wir eigentlich nur noch ProDiag. Damit entfällt die Bitglauberei.

Gruß
Blockmove

ProDiag geht leider nicht auf BASIC-Panels. Da die Funktionalität der BASIC-Panels für uns ausreicht, setzen wir die auch ein.
Kannst Du das mit dem SLICE-Zugriff in 2-3 Sätzen näher erläutern?
Vielleicht ist das ja der richtige Kniff für mich.

Gruß

Chris

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

ProDiag geht leider nicht auf BASIC-Panels. Da die Funktionalität der BASIC-Panels für uns ausreicht, setzen wir die auch ein.
Kannst Du das mit dem SLICE-Zugriff in 2-3 Sätzen näher erläutern?
Vielleicht ist das ja der richtige Kniff für mich.

Gruß

Chris

Die Triggervariable für's Panel ist definiert als ein Array of Word.
Du kannst nun mit "HMI-DB".Stoer[1].%X5 die Störung adressieren.

Also z.B. so in einem HMI-Stör-FB/FC

U "StationX".Error.NC3-Fault
= "HMI-DB".Stoer[1].%X5

Ist, wie geschrieben, augenscheinlich erstmal mehr Arbeit.
Hat aber den Vorteil, dass die HMI-Störungen zentral an einer Stelle zusammen laufen und das freut die Instandhaltung.

Ausserdem muß ich oft Störungen auch ein MES-System und / oder Alarmierungssystem übergeben und da kann ich die Triggerbits meist nicht 1:1 übernehmen.

U "StationX".Error.NC3-Fault
= "HMI-DB".Stoer[1].%X5
= "SMSALARM".SMS[4]
= "MES_Data".PLC_Error[4].%X12

Und da relativiert sich der Aufwand wieder.

Gruß
Blockmove

 

[Ralle]

Bei mir ist er optimiert und arbeitet zuverlässig?!

Kann ich nicht so ganz verstehen.
Bits werden in optimierten DB als Byte gespeichert, also je Bit ein Byte.
Für Bitmeldungen muß man ja in der HMI Bits aus einem Word oder auch aus einem Array angeben.
Wie gibst du das an?

 

[Blockmove]

Für Bitmeldungen muß man ja in der HMI Bits aus einem Word oder auch aus einem Array angeben.
Wie gibst du das an?

So:

"HMI-DB".Stoer[1].%X5

 

[TP-Inc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ihr habt die Störungen als Bit in einem DB und dann noch extra in einem anderen DB als Wort? Da hat man ja die doppelte Arbeit. Warum nicht die Triggervariable direkt auf den Störmelde-DB zeigen lassen? Erscheint mir sehr umständlich. Jetzt verstehe ich allerdings wie ihr mit optimierten DBs im Bitmeldeverfahren arbeiten könnt. Aber ja, jedem das seine

 

[hucki]

Kann ich nicht so ganz verstehen.
Bits werden in optimierten DB als Byte gespeichert, also je Bit ein Byte.
Für Bitmeldungen muß man ja in der HMI Bits aus einem Word oder auch aus einem Array angeben.
Wie gibst du das an?

Optimiert als mehrere WORDs.

Ich sammle die Fehler in mehreren STRUCT OF BITs (a 16 BIT und thematisch passend), damit ich sie symbolisch und in KOP (wegen der besseren Wartbarkeit) darstellen kann, und übertrage diese STRUCTs mittels AT-Sicht auf eigenständige WORDs für die Bitmeldung des Panels. Alles im gleichen optimierten DB.
(PS: Sammelfehler erzeuge ich gezielt durch herkömmliche Verknüpfungen, wie von PN/DP gepostet.)

Dadurch hab' ich zwar doppelte Datenhaltung, aber da die zum Einen nicht remanent sein muss und zum Anderen bei mir auch keine riesige Menge darstellt, fällt das zumindest bei mir nicht wirklich ins Gewicht.



Ich war allerdings verwirrt, ob der IMHO so rigorosen Aussage: "der DB darf fürs Bitmeldeverfahren nicht optimiert sein".
Ich meine, dem Bitmeldeverfahren selbst ist das doch egal. Es verlangt halt (leider) nur nach WORDs.

Jetzt bin ich allerdings noch verwirrt, das Bitmeldungen auch aus einem ARRAY gehen. Eben mit einem ARRAY[0-15] OF BOOL probiert, welches bei mir das KTP700 mobile nicht zur Bitmeldung akzeptieren will.
Welche Bedingungen gelten für Deine Aussage? Mit den mittlerweile möglichen eigenen Kommentaren für jedes ARRAY-Element wäre das ja vlt. auch eine Alternative.

 

[ducati]

das ist doch irre... was Siemens da mit dem optimierten Scheiss verbrochen hat...
zum Glück nutzen wir nur nichtoptimierte DBs. Da sind halt in dem StörungsDB 1000 Bools drin. Bit 735 ist dann auch coolerweise auch Meldung 735, sogar im Panel wo ich wortweise auf diesen DB zugreife...

"HMI-DB".Stoer[1].%X5 ...

hmm, da werd ich doch blöd, wenn ich mir da ständig ausrechnen muss, was jetzt Meldung 735 ist...

Aber gut, scheinbar ist das TIA Dings eher für Maschinen mit 100 Meldungen, als für Anlagen mit 10000 Meldungen erfunden worden.

Bin mittlerweile echt froh, den alten Classic Programmierstil auch aufs TIA übernommen zu haben. Wir brauchen den neuen Kram (z.B. optimierte DBs) für wirklich nichts...

Frohe Ostern

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

"HMI-DB".Stoer[1].%X5 ...

hmm, da werd ich doch blöd, wenn ich mir da ständig ausrechnen muss, was jetzt Meldung 735 ist...

Das zeigt dir TIA bei der Bitmeldung an. Rechnen brauchst du da also nix.
"Optimiert" ist so ein typisches Beispiel von "gut gemeint ist das Gegenteil von gut gemacht"

Gruß und schöne Ostern
Blockmove

 

[ducati]

hmm, ich will jetzt Meldung 735 im Programm abfragen...

U "DB-Meldungen".Meldung_00735

find ich jetzt einfacher als

U "DB-Meldungen".Stoer[45].%X14

da kann ich gleich schreiben

U DB100.DBX90.6

Stimmt das überhaupt? Fängt das Array bei 0 oder 1 an? Und wo rechnet mir TIA das aus?

Mir erschließt sich die Geschichte grad überhaupt nicht...
Warum nutzt Ihr nicht einfach nichtoptimierte DBs... ?

Gruß.

PS: mit nichtoptimiert meine ich nicht zwangsläufig nichtsymbolisch...

 

[Tigerente1974]

Anhand der Beiträge sieht man, dass mal wieder viele Wege nach Rom führen. Und scheinbar gibt es nicht den Königsweg. Ich werde die ein oder andere Anregung mal nachstellen und schauen ob eine gute Alternative dabei ist.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

hmm, ich will jetzt Meldung 735 im Programm abfragen...

U "DB-Meldungen".Meldung_00735

find ich jetzt einfacher als

U "DB-Meldungen".Stoer[45].%X14

da kann ich gleich schreiben

U DB100.DBX90.6

Stimmt das überhaupt? Fängt das Array bei 0 oder 1 an? Und wo rechnet mir TIA das aus?

Mir erschließt sich die Geschichte grad überhaupt nicht...
Warum nutzt Ihr nicht einfach nichtoptimierte DBs... ?

Gruß.

PS: mit nichtoptimiert meine ich nicht zwangsläufig nichtsymbolisch...

In der HMI-Projektierung kannst du dir bei den Bitmeldungen den Zugriff / die Adresse einblenden.
Daher ist mir es eigentlich egal ob nun optimiert oder nicht.
Die Störungsnummer steht bei mir in der Netzwerküberschrift.
Der Störtext im Netzwerkkommentar.

Gruß
Blockmove

 

[Ralle]

So:

"HMI-DB".Stoer[1].%X5

Ja, wie man an ein Bit in so einem Word kommt ist schon klar. Mit vollsymbolischem Zugriff hat das mal gar nichts zu tun.
Aber das ist mir zu krank. Wie bitte soll ich das meinem Kunden klar machen, dass er wie vor 30 Jahren mit Bytes und Bits und Words rumrechnen soll, um die richtige Störmelde-Adresse zu nutzen.
Dann ist mir meine derzeitige Variante lieber, nicht optimierter Baustein, 16 Bits definiert in einem Struct --> "Stoermelde_DB".Stoermeldung_2347 und in den Bitmeldungen den Text auch tatsächlich bei Nummer 2347 rein. Im übrigen konnte ich noch nicht feststellen, dass dieser eine nicht optimerte DB, die SPS tatsächlich verlangsamt, so wie Siemens das als Möglichkeit beim Einsatz nicht optimierter DB behauptet (Man schreib aber nur "könnte"). Und fragt jetzt bitte nicht, wo genau das steht, ich weiß es nicht mehr ;-)

 

[hucki]

So:

"HMI-DB".Stoer[1].%X5

Ja, wie man an ein Bit in so einem Word kommt ist schon klar. Mit vollsymbolischem Zugriff hat das mal gar nichts zu tun.

Das ist aber nicht die Darstellung, wie man in der PLC das BIT in das WORD bekommt, sondern wie das HMI das BIT durch Triggervariable und -bit wieder aus dem optimierten WORD holt. Und diese beiden Angaben dürften bei optimiertem und nicht optimiertem DB ja gleich sein.