TIA Program Alarm - Text zu lang und keine Störmeldeausgabe

[ADS_0x1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich bin beim Kunden und soll eine weitere Anlage in einen Anlagenverbund integrieren. Die bisherigen Anlagen sind in TIA v13 projektiert worden, Lizenz ist beim Kunden vorhanden und so wird die neue Anlage ebenfalls in TIA v13 projektiert. Läuft auch alles wunderbar, bis auf eine Sache mit dem Baustein "Program_Alarm".

Der Maschinenbauer hat mit TIA v13 SP1 Update 9 programmiert und baut über einen Baustein einen sog. Log-String auf, in dem verschiedene Prozesswerte aneinanderhängt und über die Textlistenfunktion den aktuellen Schritt der Schrittketten als Text mit ausgibt, sprich als Begleitwert am Program_Alarm-Baustein.

Jetzt haben wir (Dienstleister) brav unsere alten TIA v13 Versionen geupdated und sind auf TIA Portal v13 SP2 unterwegs, haben alles projektiert und nun werfen die Program_Alarm-Bausteine den Fehler 8004 - Maximale Größe von 512 Bytes für die Begleitwerte der Meldung erreicht.

An den Bausteinen sind 3 Begleitwerte angelegt, SD1 bis SD 3, an SD1 liegt ein String an, SD2 eine UInt, an SD3 ein weiterer String. Faktisch sind die Texte auch zu lang, denn:

String 1 [254]
Uint -> Wird zu Text über <Textliste ...> - Skriptcode
String 2 [254]

Mit String 1 und String 2 überschreite ich schon die Länge, ohne den Text der Textliste zu berücksichtigen. Der Baustein gibt ja auch brav den Fehlercode aus.

Aber:

Beim Endkunden laufen die Anlagen schon, das PG vor Ort hat noch TIA v13 Sp1 Update 9 drauf. Dort wird ebenfalls der Fehelrcode ausgegeben, aber die Meldung wird generiert und ausgegeben.

Bei unserer Version wird die Meldung nicht ausgegeben...

Ich habe jetzt schon einmal in den Release Notes zum SP2 geschaut, dort wird allerdings nichts über den Program_Alarm Baustein geschrieben. Wir haben das Problem gelöst, da wir die Strings beschnitten haben und die maximale Länge nicht mehr überschritten wird - dennoch finden wir das Verhalten merkwürdig.

Hat jemand von euch ähnliche Erfahrungen gemacht? Falls nein, kann dieser Beitrag eventuell anderen helfen...

 

[Ralle]

Das kann gut möglich sein, es finden immer mal wieder Feature ;-) ihren Weg in ein SP, die dazu führen, dass etwas nicht mehr ganz so geht wie früher.
Ich kenne das aus der HMI, dort konnte man früher Variablen an Objekten (Button, Ausgabefeld) stehen haben, die rot markiert waren, weil die Anbindung an die SPS fehlerhaft, oder schlichtweg nicht mehr vorhanden waren. War ok, denn manchmal hat man Bider im HMI, die nicht gebaucht werden, die man aber nicht löschen will. Das konnte man übersetzen, ins Panel spielen und (bis auf die fehlenden Variablen) lief das korrekt. Heute geht das nicht mehr, man muß alle diese Variablenfehler beseitigen. Manchmal gibt es dann einen neuen Schalter in den Einstellungen, wo man das aktivieren/deaktivieren kann, aber das muß man dann erst einmal finden.

 

[Hans]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ein Verhalten welches bestimmt damit zusammenhängt wirst du feststellen, wenn du das Projekt auf V14 hochrüstest. Dort wirst du den Fehler bezüglich zu langer Strings direkt beim übersetzen bekommen. Dies war in V13SP1 Upd x noch eine Warnung. Nicht direkt dein Problem, aber evtl. für andere interessant.
Lösung ist, die Strings zu begrenzen, da der compiler natürlich vom maximalen String ausgehen muss, da er nicht weiß wie groß dieser zur Laufzeit tatsächlich wird.

Zu deinem Fall:
Hast du evtl. die Firmware der CPU oder die Bausteinversion geändert?

 

[ADS_0x1]

Danke euch beiden für die Antworten.

Wir haben bei neuen Anlagen des Kunden bereits auf TIA v14 und bei den ganz neuen auf TIA v15 hochgerüstet, da haben wir das Problem durch die beschriebenen Maßnahmen (kürzen der Strings) behoben.

Firmware der CPU ist auf neuerem Stand, als bei den Bestandsanlagen, da wir diese ja erst vor einigen Wochen bestellt hatten. Bausteinversion kann ich dir jetzt adhoc nicht sagen.

Da wir aber noch andere Probleme mit dem Meldungsmanagement hatten, haben wir nun vom Program_Alarm auf Bitmeldungen umgestellt und das Logging komplett auf PM-Quality verlagert - dieses war zuvor schon vorhanden, wurde aber nicht für die Log-Ausgabe verwendet.

Ein Grund, warum wir umgestiegen sind, war die automatische Zuweisung der Störmelde-IDs. Ein Kunde wollte ein-eindeutige MeldungsIDs haben und da wir nicht garantieren konnten, dass bei Inbetriebnahme einer neuen Anlage und Kopie der Software die IDs bestehen bleiben, haben wir hier auf diskrete Bits mit dazugehöriger ID gewechselt.

Viele Grüße!