TIA Program_alarm overflow? Was jetzt wieder los?

Zuviel Werbung?
-> Hier kostenlos registrieren
Antwort war, dass es erledigt ist, da ProDiag Programmalarm "richtig" verwendet.
Lizenzpreise halten sich in Grenzen, daher eben ProDiag gekauft.

Als in grenzen halten würd ich das nicht bezeichnen. Eine lizenz für alle meldungen auf der cpu. Kostet ja soviel wie die cpu selber. Und die kleine für 250 meldungen brauchts ja nicht da die kleinste cpu ja schon soviele gleichzeitig kann.

Oder wie funktioniert die lizenzierung?
 
Als in grenzen halten würd ich das nicht bezeichnen. Eine lizenz für alle meldungen auf der cpu. Kostet ja soviel wie die cpu selber. Und die kleine für 250 meldungen brauchts ja nicht da die kleinste cpu ja schon soviele gleichzeitig kann.

Oder wie funktioniert die lizenzierung?

Ab 25 Meldungen brauchst du eine Lizenz.
Preis ... Naja wenn ich den Zeitaufwand für das erstellen gegenrechne, dann relativieren sich die Kosten.
In den CPU-Einstellungen musst du nur anklicken, welche Lizenz du hast.
Du brauxhst keinen ALM oder ähnliches.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ab 25 Meldungen brauchst du eine Lizenz.
Preis ... Naja wenn ich den Zeitaufwand für das erstellen gegenrechne, dann relativieren sich die Kosten.
In den CPU-Einstellungen musst du nur anklicken, welche Lizenz du hast.
Du brauxhst keinen ALM oder ähnliches.

nunja mir reicht eben die Funktion von program_alarm grundsätzlich. Nur die 300 meldungseinschränkung nervt. Ich würde also kaum zeit sparen. Und da ich eher viele kleine cpus einsetze als eine grosse bräuchte ich natürlich dementsprechend viele lizenzen.
Nichtsdestotrotz werde ich mir die Sache mal anschauen.
Gibts da schon erfahrung mit wincc oa? Kann das direkt von prodiag profitieren?
 
Hi,
Wenn den Program_Alarm benutzt , muss man umbedingt auf die Fehler die der FB melden kann reagieren. ( siehe Help infos vom Program_Alarm )
Es gibt 2 Arten von Fehler die er Melden kann:
1) Fehler die verursacht warden durch faslche parametrierung ,.. d.h. fehler im Programm beheben
2) Fehlersituation die in CPU erkannt warden,.. d.h. der Alarm konnte nicht ausgeführt werde ( da glaube ich gibt es 4 mögliche Gründe ,.. siehe help )
In der Help steht im nächsten Zyklus den Vorgang wiederholen ( da braucht man im Anwenderprogramm eine Verwaltung, was nicht trivial ist)
( einer der Fehler ist das Überschreiten der max. mögliche Alarme ,.. das ist hier das Problem )
d.h. mit dem Program_Alarm kann man alles lösen ,.. kostet aber Zeit und Anfwand.
Mit prodiag , sind alle diese problem gelöst:
- prodiag frägt intern diese Fehler ab, merkt sich das der Call ( Alarm kommen oder gehen ) nicht geklappt hat und versucht es im nächsten Zyklus,.. bis es geklappt hat
- d.h ,.. es geht kein Alarm verloren und es bleiben auch keine hängen ( z.B. wenn es beim gehen nicht geklappt hat )
- und noch wichtig , grössere Zykluszeitverlängerungen und schwankungen gibt es mit prodiag nicht. Jeder prodiag Fb verschickt nur ein Alarm pro Zyklus
( z.b. wenn in einem Zyklus 3 Alarme anstehen , warden diese in 3 zyklen verschickt ,.. aber mit dem Zeitstempel von dem ursprünglischer Zyklus , prodiag merkt sich die zeiten )
Hoffe dass ich helfen konnte
 
Hi,
Wenn den Program_Alarm benutzt , muss man umbedingt auf die Fehler die der FB melden kann reagieren. ( siehe Help infos vom Program_Alarm )
Es gibt 2 Arten von Fehler die er Melden kann:
1) Fehler die verursacht warden durch faslche parametrierung ,.. d.h. fehler im Programm beheben
2) Fehlersituation die in CPU erkannt warden,.. d.h. der Alarm konnte nicht ausgeführt werde ( da glaube ich gibt es 4 mögliche Gründe ,.. siehe help )
In der Help steht im nächsten Zyklus den Vorgang wiederholen ( da braucht man im Anwenderprogramm eine Verwaltung, was nicht trivial ist)
( einer der Fehler ist das Überschreiten der max. mögliche Alarme ,.. das ist hier das Problem )
d.h. mit dem Program_Alarm kann man alles lösen ,.. kostet aber Zeit und Anfwand.
Mit prodiag , sind alle diese problem gelöst:
- prodiag frägt intern diese Fehler ab, merkt sich das der Call ( Alarm kommen oder gehen ) nicht geklappt hat und versucht es im nächsten Zyklus,.. bis es geklappt hat
- d.h ,.. es geht kein Alarm verloren und es bleiben auch keine hängen ( z.B. wenn es beim gehen nicht geklappt hat )
- und noch wichtig , grössere Zykluszeitverlängerungen und schwankungen gibt es mit prodiag nicht. Jeder prodiag Fb verschickt nur ein Alarm pro Zyklus
( z.b. wenn in einem Zyklus 3 Alarme anstehen , warden diese in 3 zyklen verschickt ,.. aber mit dem Zeitstempel von dem ursprünglischer Zyklus , prodiag merkt sich die zeiten )
Hoffe dass ich helfen konnte
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wo hast du diese Beschreibung denn her, hat Siemens dir das so gesagt?

Das heißt, wenn ich das Bausteinmeldeverfahren bei er 1500 einsetzen will, dann muss ich ein eigenes Zeitstempelsystem drumherumstricken damit das funktioniert?

Ich weiß nicht wie Siemens das bei der S7-300/400 gemacht hat, aber da funktioniert es ganz einfach so wie es jeder normal denkende Mensch erwarten würde.

Nämlich (S7-300 mit AlarmS):
Die CPU Daten sagen es sind 300 gleichzeitig anstehende AlarmS-Meldungen möglich. Wenn ich in der SPS 300 Alarme anstehen habe, kommt zusätzlich am Bediengerät eine Meldung dass keine neuen Meldungen mehr verarbeitet werden. Setze ich die 301. Meldung wird diese nicht am HMI angezeigt. Nehme ich die 1. Meldung weg so kommt die 301., jedoch eben nicht mehr mit dem Zeitstempel des Entstehens sondern mit dem Zeitstempel bei dem die Meldung durch freiwerden des Platzes erzeugt werden konnte.
Ich weiß nicht wie man so etwas triviales versemmeln kann.
 
Moin,
also grundsätzlich bin ich ja vollkommen bei euch - das war in Summe keine Glanzleistung der Siemens-Entwickler.
Aber wie sinnvoll ist es (im normalen mir bekannten Anlagen und Maschinenbau) über 200 Meldungen in einem Zyklus zu generieren und zur Anzeige zu bringen?
Ich persönlich versuche es zumindest immer, nur das zu melden, was auch relevant ist. Also wenn eine 24V Sicherung fällt, dann zeige ich das (mit welchem Verfahren auch immer) an. Dass dadurch bspw. 10 PN-Teilnehmer auch fehlen/gestört sind, ist ja dann ein Folgeproblem und somit meines Erachtens nicht unbedingt anzuzeigen. Somit versuche ich schon im Programm selber, so einen Meldeschwall zu unterbinden, weil es den Bediener ja auch eher verwirrt, als bei der Fehlersuche unterstützt.
Ich wollte nur darauf hinaus, dass wenn man den Program Alarm in seinen gegebenen Grenzen einsetzt, der auch ganz gut funktioniert.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,
also grundsätzlich bin ich ja vollkommen bei euch - das war in Summe keine Glanzleistung der Siemens-Entwickler.
Aber wie sinnvoll ist es (im normalen mir bekannten Anlagen und Maschinenbau) über 200 Meldungen in einem Zyklus zu generieren und zur Anzeige zu bringen?

Es geht hier ja nicht nur um Alarme und Störungen. Ich will ja auch Rückmeldungen "Melden" die landen zwar nicht in einer Alarmliste aber doch zumindest im Meldearchiv.
Also nicht nur Sicherungsautomat ausgelöst, sondern auch. Sicherungsautomat ausgeschaltet. Schütz angezogen. Handschalter auf Tableau betätigt etc. Die gehen alle von den 300 Möglichen Meldungen ab.
Und 30 Eingeschaltete Sicherungsautomaten, sind auch 30 gleichzeitig auftretende Meldungen.
 
Moin Vollmi,
Es geht hier ja nicht nur um Alarme und Störungen. Ich will ja auch Rückmeldungen "Melden" die landen zwar nicht in einer Alarmliste aber doch zumindest im Meldearchiv.
Also nicht nur Sicherungsautomat ausgelöst, sondern auch. Sicherungsautomat ausgeschaltet. Schütz angezogen. Handschalter auf Tableau betätigt etc. Die gehen alle von den 300 Möglichen Meldungen ab.
Wie gesagt, bin absolut bei dir. Das es mit Sicherheit Applikationen wie deine gibt, in denen die Funktion auch solche Dinge bewältigen muss, ist klar. Das du den Program Alarm dann nicht nutzen kannst ist natürlich ärgerlich.
Ich wollte ja nur davon weg, den Baustein grundsätzlich zu verteufeln :D für viele Anwendungen ist der schon ganz cool.
 
Hi Howard,
da hast du recht, man kann und darf den Program_Alarm nicht verteufeln, das war auch nicht meine Intension.
Mann sollte aber ihn richtig benutzen, und auf die Fehler die Rückmelden kann in bedarfsfall reagieren.

Hi Thomas V2.1
vor ca. einem Jahr war mein Chef in einem Meeting mit Siemens ( ich war nicht dabei ) ,.. danach hat mein Chef mich gebeten dies zu analysieren ,.. hab da eine Woche lang mit prodiag und program_alarm rumgespielt . Ich hatte damals eine 1516 ,.. da war die Grenze wenn ich mich noch richtig errinere 600 Alarme.
Für uns war nicht das Thema 300 gleichzeitig anstehende Alarme , sondern das Thema Zykluszeitschwankungen

Hi alle,
wollte euch nur meine Tests die ich vor einem Jahr gemacht hatte ,..euch in kurzform mitteilen.
was wer benuzut , muss jeder selber entscheiden , bzw. die Kunden die unsere maschine bestellt haben ( die wollen auch oft mitreden )

Gruß an alle
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Problem sind ja auch nicht 300 pro Zyklus, sondern das max 300 anstehen können. Und das wäre für uns nicht mal das Problem, das Problem ist das man Logik herum bauen muß, weil man die Meldungen neu triggern muß. Und auch die Anzahl der Meldungen die man auslöst muß man begrenzen, sonst geht die Zykluszeit hoch!
 
Hallo René,

ich habe diese Meldung auch noch anstehen:
Wie bekommt man diese Meldung wieder "weg"? Quittieren usw. hilft leider nicht weiter.

mfg Michael
 
Zurück
Oben