TIA Verwendung AT-Sicht

Zuviel Werbung?
-> Hier kostenlos registrieren
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 der vollsymbolische Zugriff :p
Ob nun optimiert oder nicht, das ganze Bitmeldeverfahren ist schon immer eine Crux.
Die Adressierung war schon immer irgendwie krank.

Ich hab ein paar Anlagen mit ProgramAlarm gemacht. Ist schon ein Fortschritt, aber bei großen Anlagen sehr mit Vorsicht zu geniesen.
Stichwort (Meldeschwall)

Mittlerweile nutzen wir ProDiag. Das geht schon mehr in Richtung zeitgemässes Alarmverfahren.
Allerdings kommst du damit noch tiefer in die Versionshölle. Bei jeder Version gibt es Änderungen.
Die Funktionalität mit Code-Viewer und Graph-Viewer ist schon "geil".

Gruß
Blockmove
 
Das ist der vollsymbolische Zugriff
Nicht der vollsymbolische Zugriff sondern eine Möglichkeit des vollsymbolischen Zugriffs.

Wie weiter oben ja schon gepostet, nutze (zumindest) ich einen anderen Weg, wodurch sich der Zugriff auf die Einzelbits wie bei Ralles nichtoptimiertem DB gestaltet.
Muss halt jeder für sich entscheiden, welchen Kompromiss er eingeht, weil das Bitmeldeverfahren blöderweise keine boolschen Variablen zur Meldung zulässt, man es aber nutzen möchte/muss.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.

Wenn du ein Word/Int-Array als Trigger verwendest, dann stimmt die bei der Meldung angezeigte SPS-Adresse aber auch nur, wenn dein Array mit Index Null beginnt. Bei allen anderen Werten ist die SPS-Adresse falsch. Man darf beim TIA-Portal nicht so genau hinschauen ;-)
 
Ich hab ein paar Anlagen mit ProgramAlarm gemacht. Ist schon ein Fortschritt, aber bei großen Anlagen sehr mit Vorsicht zu geniesen.
Stichwort (Meldeschwall)

Mittlerweile nutzen wir ProDiag.

Bei der S7-300 wurden die Bausteinmeldeverfahren kaum eingesetzt. Jetzt mit der 1500er ist ProgramAlarm das "Praktischste" was es gibt, wobei es annähernd gleich funktioniert mit ein paar mehr Tücken wie bisher. Wenn die Zeitstempelung nicht funktioniert, dann wird eben der Zeitstempel in der SPS selber erzeugt und als Begleitwert der Meldung mitgeschickt. Weil ProgramAlarm mit Meldeschwällen nicht umgehen kannt, muss außen um den Baustein drumherum eine entsprechende Auswertung programmiert werden damit die SPS in so einem Fall nicht in Stopp geht.
Und anstatt das Siemens das System korrekt implementiert, bieten sie dir eine weitere kostenpflichtige Option an mit Funktionen welche die Bugs umgehen. Das nenne ich mal zeitgemäß.

Bei dem einen Thread kürzlich, in dem jemand nach Fehlerhandling in der SPS gefragt hatte, und daraufhin auseinandergenommen wurde mit "macht man nicht", "kann man nicht" usw. habe ich mir auch nur meinen Teil gedacht. So bescheiden wie Siemens das mit ProgramAlarm umgesetzt hat, bekommt man das nämlich auch selber implementiert.
 
Und anstatt das Siemens das System korrekt implementiert, bieten sie dir eine weitere kostenpflichtige Option an mit Funktionen welche die Bugs umgehen. Das nenne ich mal zeitgemäß.

Naja, klar kann man sich über die miserable Implemtierung von ProgramAlarm ärgern. Durch eine Störmeldung eine SPS möglicherweise in Stop zu schicken ist schon stümperhaft.
Noch schlimmer dies im Nachhinein als definiertes Systemverhalten zu deklarieren.
Unabhängig davon finde ich den Preis für ProDiag trotzdem nicht überzogen. Ist halt die alte Frage: Was bringt es und was kostet es?
 
Zurück
Oben