WinCC Meldungarchiv RT Advanced

wiswis

Level-2
Beiträge
23
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,
ich habe ein Problem mit zwei WinCC RT Advanced Panels, die eigentlich komplett identisch sein sollten (gleiches Projekt, gleiche Hardware, gleiche Konfiguration).
Trotzdem zeigt jedes Panel ein unterschiedliches Meldungsarchiv (Meldarchiv) an.
Problembeschreibung:
  • Beide Panels verwenden das gleiche TIA-Portal-Projekt.​
  • Die Meldungen / Alarmmeldungen sind identisch konfiguriert.​
  • Trotzdem werden im Meldarchiv nicht die gleichen Einträge angezeigt.​
  • Auf einem Panel erscheinen alle Meldungen, auf dem anderen jedoch nur ein Teil davon.​
  • Die Panels sollten absolut synchron sein, aber das Meldarchiv ist verschieden.
    Was ich bereits überprüft habe:
  • Projekt wurde auf beide Panels übertragen.​
  • Beide Panels laufen im Runtime-Modus ohne sichtbare Fehler.
    Frage:
  • Woran kann es liegen, dass zwei identische WinCC RT Advanced Panels unterschiedliche Alarm-Meldungsarchive haben?

ich habe noch ein weiteres Problem mit meinem WinCC RT Advanced Projekt.
Problembeschreibung:
In meinem Meldungsarchiv fehlen einige Meldungen – sie werden im Archiv einfach nicht gespeichert.
Ich habe die Meldungen online im Panel gesehen, aber sie erscheinen nicht im Meldarchiv und sind somit in der CSV-Datei nicht vorhanden.
Es sieht so aus, als würden bestimmte Meldungen „verloren gehen“.
Zusätzlich möchte ich das Meldungsarchiv täglich als separate CSV-Datei speichern (z. B. ein CSV-File pro Tag)
  1. Warum werden manche Meldungen im Meldarchiv nicht gespeichert?
    – Liegt es an der Konfiguration, der Archivgröße, der Runtime-Übertragung oder daran, dass alte Archivdateien nicht gelöscht wurden?
  2. Wie kann man das Meldungsarchiv so konfigurieren, dass automatisch jeden Tag eine neue CSV-Datei erzeugt wird?
    Gibt es in WinCC RT Advanced eine Funktion zum täglichen herunterladen, oder muss man das über ein Script realisieren? Über Hinweise oder Best Practices wäre ich sehr dankbar!




 
Hallo.

Zuerst die üblichen Standardfragen:
+ Welche TIA-Portal-Version genau?
+ Welche RT-Version genau?
+ Welche Ziel-Hardware (besser: Betriebssystem) genau?

Dann die weitere (HMI-spezifische) Standardfrage:
+ Wurde der HMI-Teil des Projektes vor dem jeweiligen Transfer komplett übersetzt?
(<HMI-Name> [WinCC RT Advanced] -> Übersetzen -> Software (komplett übersetzen))

TIA-Portal schafft es bis heute nicht, ein fehlerfreies Delta-Übersetzen durchzuführen, da kommen die witzigsten Effekte zutage.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Jedes HMI erstellt sein eigenes Archiv mit eigenen Zeitstempeln und eigener Abfrage/Aktualisierung der Trigger-Variablen. Da können kurze Ereignisse durchaus verloren gehen oder andere Zeitstempel haben.

Das HMI-Projekt wurde vor dem Laden "komplett" übersetzt?
 
Weitere Fragen, speziell deine Probleme betreffend:
+ Du hast ZWEI HMIs in EINEM Projekt, richtig? Wie hast du sichergestellt, dass die softwareseitigen Bestandteile (also Bilder, Meldungen, Variablen etc.) identisch(!) sind?
+ Sind bei ALLEN Meldungen die korrekten (gewünschten) Meldeklassen projektiert?
 
Hallo.

Zuerst die üblichen Standardfragen:
+ Welche TIA-Portal-Version genau?
+ Welche RT-Version genau?
+ Welche Ziel-Hardware (besser: Betriebssystem) genau?

Dann die weitere (HMI-spezifische) Standardfrage:
+ Wurde der HMI-Teil des Projektes vor dem jeweiligen Transfer komplett übersetzt?
(<HMI-Name> [WinCC RT Advanced] -> Übersetzen -> Software (komplett übersetzen))

TIA-Portal schafft es bis heute nicht, ein fehlerfreies Delta-Übersetzen durchzuführen, da kommen die witzigsten Effekte zutage.
+ V17
+TP1900 Comfort HMI Panel V17.00.00.00_42.01
+Nein , ich habe nur einmal komplett übersetzt und geladen, sonst machen wir nicht komplett laden
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Weitere Fragen, speziell deine Probleme betreffend:
+ Du hast ZWEI HMIs in EINEM Projekt, richtig? Wie hast du sichergestellt, dass die softwareseitigen Bestandteile (also Bilder, Meldungen, Variablen etc.) identisch(!) sind?
+ Sind bei ALLEN Meldungen die korrekten (gewünschten) Meldeklassen projektiert?
alles ist identisch, hardware : ich habe zwei identische Panel und in Software ich andere nur ip adresse damit ich kann die andere Panel laden, wenn ich was laden will, sonst sind sie identisch
 
alles ist identisch, hardware : ich habe zwei identische Panel und in Software ich andere nur ip adresse damit ich kann die andere Panel laden, wenn ich was laden will, sonst sind sie identisch
Das heißt, du hast nur EIN HMI im Projekt? Und diesen Projektteil transferierst du auf ZWEI Comfort-Panels, wobei du vorher die IP-Adresse in der HardwareConfig änderst?

Hm, schwer zu sagen, wie sich da die Steuerung und die Panels bezüglich der Kommunikation wirklich verhalten ... :oops:

Zwar offtopic, aber dennoch:
Wie stellst du Bedienungssicherheit her, wenn an beiden Panels die gleiche Funktion quasi simultan unterschiedlich bedient wird?
 
Ich bleibe bei meiner Aussage:

Hm, schwer zu sagen, wie sich da die Steuerung und die Panels bezüglich der Kommunikation wirklich verhalten ... :oops:

Welches Panel funktioniert denn (deiner Meinung nach) korrekt?
Das ursprünglich projektierte oder das, bei dem du vor dem Laden im Projekt die HMI-IP-Adresse änderst?
Wie verhält es sich, wenn du nur das (vermeintlich) fehlerhafte Panel mit der Steuerung verbindest?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielleicht, du hast du die HMI Quittierbits konfiguriert ? Und/oder die PLC Quittierbits ?

Ohne zu wissen wie du es programiert hast, aber kann es sein dass die PLC die HMI Quittierbits überwacht, und programmatisch die PLC Quittierbits davon steuert ?
In den Fall kann das Quittieren auf einen HMI das Quittieren auf den anderen HMI beeinflussen.
Es kann auch sein dass die eine HMI die Flanken von Triggerbits nicht sieht, wenn die PLC Triggerbits sofort durch die andere HMI Quittierbit zurückgesetzt wird, und dann sofort von das PLC Programm wieder gesetzt wird (weil die Bedingungen) für die Alarm noch anstehen, oder sofort wieder gesetzt werden.

Überprüfe dass getrennte Speicheraddressen von die HMI Quittierbits konfiguriert sind.

Pro Alarm braucht man diese Variabeln:
  • Rohen Alarmbit (ohne Speicherung). Direkt von die Alarmbedingung(en) gesteuert.
  • Gespeicherte Alarmbit (= Trigger bit). Dies muss von das rohen Alarmbit gesetzt werden. Wenn das rohen Alarmbit nicht mehr aktiv ist und das gespeicherte Quittierbit aktiv ist, dann das Trigger bit zurücksetzen.
  • HMI 1 Quittierbit.
  • Flankenspeicher HMI 1 Quittierbit.
  • HMI 2 Quittierbit.
  • Flankenspeicher HMI 2 Quittierbit.
  • Gespeicherte HMI Quittierbit. Muss gesetzt werden auf steigende Flanke von die HMI Quittierbit, von beide HMIs. Muss zurückgesetzt werden auf weckfall von das rohen Alarmbit.
  • SPS Quittierbit (optional).
Um zu erkennen wo die Fehler liegt, schlage ich vor diese Variabeln zu tracen.
 
Das heißt, du hast nur EIN HMI im Projekt? Und diesen Projektteil transferierst du auf ZWEI Comfort-Panels, wobei du vorher die IP-Adresse in der HardwareConfig änderst?

Hm, schwer zu sagen, wie sich da die Steuerung und die Panels bezüglich der Kommunikation wirklich verhalten ... :oops:

Zwar offtopic, aber dennoch:
Wie stellst du Bedienungssicherheit her, wenn an beiden Panels die gleiche Funktion quasi simultan unterschiedlich bedient wi

Ich bleibe bei meiner Aussage:



Welches Panel funktioniert denn (deiner Meinung nach) korrekt?
Das ursprünglich projektierte oder das, bei dem du vor dem Laden im Projekt die HMI-IP-Adresse änderst?
Wie verhält es sich, wenn du nur das (vermeintlich) fehlerhafte Panel mit der Steuerung verbindest?
die ursprünglich Panel hat alle Infos, ausser Meldarchin ist nicht ganz, fehlen viele Meldungen
 
Zurück
Oben