TIA TIA Portal V18 Wunschliste [Diskussion]

Status
Für weitere Antworten geschlossen.
Zuviel Werbung?
-> Hier kostenlos registrieren
Aber eine "Grenze" zwischen FUP und SCL gäbe es dann dennoch. Was ist denn daran sooo störend, wenn sich diese Grenze "NetzwerkGrenze" nennt? Wie soll denn die optische Gliederung aussehen? Eigenes Fenster klingt für mich eher nach scharfer Trennung vom FUP-Geschehen als nach Eingliederung in die FUP-Welt.
Es ist nicht direkt „störend“, aber man muss manche Sondersachen, welche eigentlich ziemlich einfach wären oft auf 2-3 Netzwerke aufteilen. So könnte man es in 1 Netzwerk machen und wäre meiner Meinung nach übersichtlicher.
Ich könnte mir zwei Varianten vorstellen. Die Eine sieht ähnlich aus wie der FUP-Baustein für erweiterte mathematische Anweisungen, nur dass ich dort keine mathematische Formel reinschreibe, sondern einen SCL-Code. Im Netzwerk wird der Code dann komprimiert dargestellt, dass man das Wesentliche sieht, was dort passiert.
Bei der zweiten Variante wird praktisch ein variables Textfeld eingefügt, wo ich meinen Code reinschreibe und dann an einen Baustein hänge.
 
... nur dass ich dort keine mathematische Formel reinschreibe, sondern einen SCL-Code. Im Netzwerk wird der Code dann komprimiert dargestellt, dass man das Wesentliche sieht, was dort passiert.
Wer macht die Komprimierung der Darstellung? Der Compiler automatisch oder muss man das Komprimieren im SCL-Code (zusätzlich) irgendwie steuern?
Bei der zweiten Variante wird praktisch ein variables Textfeld eingefügt, wo ich meinen Code reinschreibe und dann an einen Baustein hänge.
Die zweite Variante ohne Komprimierung?
Wie soll das "an einen Baustein anhängen" aussehen? Wie in FUP üblich? Der SCL-Code als Kästchen dargestellt mit einer oben angegebenen
"FunktionsKurzbeschreibung", am linken KästchenRand die Eingänge und am rechten die Ausgänge?
Das kann man doch schon, indem man in SCL einen FC oder FB schreibt und im FUP benutzt (aufruft).
Zugegeben, das führt dazu, dass man u.U. viele weitere FCs und FBs kreiert und der Schreiber und der Leser der FUPs viele neue Bausteine kennenlernen/beherrschen muss.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wer macht die Komprimierung der Darstellung? Der Compiler automatisch oder muss man das Komprimieren im SCL-Code (zusätzlich) irgendwie steuern?
Das kann man doch einfach steuern, da wird einfach ein Kästchen von TIA verwendet, wo eine Grafik
Bitmap hinterlegt wird, ich finde die Idee sehr gut!

Klickst du auf das Kästchen drauf klappt es auf, ähnlich wie bei den "Region" und man sieht den SCL Code.

Ich finde die Idee sehr gut!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ja eigentlich, aber den musst du immer aufmachen.
Für einen "Einzeiler" oder "Zweizeiler" zb. eine berechnung, währe
es schon schön wenn man den Baustein nicht verlassen muss.
Genau für solche Sachen hab ich mir das gedacht. Gerade Berechnungen oder Mehrfachvergleiche sind in SCL viel einfacher und übersichtlicher zu programmieren. Auch Mehrfachzuweisungen zB. Also grundsätzlich würden mir da schon einige Sachen einfallen. Natürlich kann man immer alles anders lösen und es ist jetzt auch kein Weltuntergang wenn es die Funktion nicht geben wird, aber für den ein oder anderen könnte es vielleicht praktisch sein. Und der Aufwand dies in Tia zu implementieren sollte auch nicht soooo groß sein.
 
Wer macht die Komprimierung der Darstellung? Der Compiler automatisch oder muss man das Komprimieren im SCL-Code (zusätzlich) irgendwie steuern?

Die zweite Variante ohne Komprimierung?
Wie soll das "an einen Baustein anhängen" aussehen? Wie in FUP üblich? Der SCL-Code als Kästchen dargestellt mit einer oben angegebenen
"FunktionsKurzbeschreibung", am linken KästchenRand die Eingänge und am rechten die Ausgänge?
Das kann man doch schon, indem man in SCL einen FC oder FB schreibt und im FUP benutzt (aufruft).
Zugegeben, das führt dazu, dass man u.U. viele weitere FCs und FBs kreiert und der Schreiber und der Leser der FUPs viele neue Bausteine kennenlernen/beherrschen muss.
In der Programmiersprache Graph gibt es doch auch solche ein- und ausklappbaren Fenster für die Weiterschaltbedingungen etc. So ähnlich stelle ich mir das vor.
In der komprimierten Ansicht sehe ich zB nur ob die Bedingung erfüllt ist oder nicht.
 
Das kann ich so nicht bestätigen. Dahingehend funktioniert Program_Alarm einwandfrei.

Was aber wirklich ätzend ist ist, dass der Program_Alarm mehr Zykluszeit/SPS-Performance frisst, als jede andere, mir bekannte Funktion.
Unser Standardprogramm hat eine Zykluszeit von ~20ms. Wenn ich 30 Fehler habe (also den Program_Alarm 30x aufrufe), schnellt die Zykluszeit gerne mal auf ~40ms hoch.
Das ist aber nun einmal so bei Bausteinen, die sehr flexibel und einfach in der Handhabung sind.
Man tauscht Komfort gegen Schnelligkeit.

Wenn ihr das nicht möchtet, dann müsst ihr euch da selbst eine schlanke Lösung bauen, das kann nicht Aufgabe einer Standardfunktion sein.

Um 30 Fehler gleichzeitig anzuzeigen... das ist glaube ich nicht die Philosophie hinter dem Program_Alarm. Ich zeige dek ersten Fehler an, Folgefehler nicht. Wenn eine Sicherung fällt, wollen meine Kunden den Sicherungsfall angezeigt kriegen... und nicht auch noch den Ausfall der 101 Temperatursensoren, die an der Sicherung dranhängen...

Dafür eignet sich der Programmalarm gut.
Ein Aufruf ersetzt bis zu 150 Bitmeldungen im Panel. Also bei uns. Er kann natürlich auch 10.000 Bitmeldungen ersetzen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
ja eigentlich, aber den musst du immer aufmachen.
Für einen "Einzeiler" oder "Zweizeiler" zb. eine berechnung, währe
es schon schön wenn man den Baustein nicht verlassen muss.
Klingt erstmal simpel. Aber was ist das dann? Ein FC? Irgendwie muss man das ja kapseln, um es in einem FUP-Netzwerk zu verwenden.
Wie definiere ich IN, OUT, TEMP für diese Kapsel?
Ich verwende SCL für Funktionen, die ich mehrfach aufrufe. Wie rufe ich die Kapsel mehrfach auf?

Achso... und nen SCL-Einzeiler kannst du auch in FUP programmieren... Unser FUP-Spezi dampft regelmäßig unsere tollen SCL-Lösungen auf FUP ein... bin immer wieder fasziniert, wenn er sowas zaubert...
 
Das ist aber nun einmal so bei Bausteinen, die sehr flexibel und einfach in der Handhabung sind.
Man tauscht Komfort gegen Schnelligkeit.
Prinzipiell ist das schon klar. Deswegen sind TIA von SIEMENS und MovieSuite von SEW ja auch solche Monster, die flexibel sind (bzw. sein wollen) und alle Funktionen in sich vereinen. Darunter leidet natürlich die Performance.
Aber aus meiner Sicht ist der Program_Alarm schon ausßergewöhnlich ressourcenfressend.

Wenn ihr das nicht möchtet, dann müsst ihr euch da selbst eine schlanke Lösung bauen, das kann nicht Aufgabe einer Standardfunktion sein.
Da schlage mir doch einmal eine schlanke Lösung vor, mit der ich Alarme für OPC UA erzeugen kann, ohne Program_Alarm zu nutzen?!

Um 30 Fehler gleichzeitig anzuzeigen... das ist glaube ich nicht die Philosophie hinter dem Program_Alarm.
Diese Einschränkung kann ich nicht gelten lassen. Von einem System, das Meldungen anzeigen soll, erwarte ich, dass es auch viele Meldungen anzeigen kann. Implizit zu unterstellen, dass >30 Fehler nicht die Philosophie des Program_Alarm sind, kann ich mir nicht leisten. Einschränkungen müssen dokumentiert sein, damit ich entscheiden kann, ob ich diese Standardfunktion nutzen kann (will).

Ich zeige dek ersten Fehler an, Folgefehler nicht. Wenn eine Sicherung fällt, wollen meine Kunden den Sicherungsfall angezeigt kriegen... und nicht auch noch den Ausfall der 101 Temperatursensoren, die an der Sicherung dranhängen...
Manchmal trägt die Anzeige der Folgefehler aber dazu bei, zu analysieren, welche Probleme nach einem Ursprungsfehler noch entstehen können. Wir handhaben das so, dass wir Folgefehler als Folgefehler markieren (zusätzliche Info im Meldetext), aber trotzdem mit aufführen. So oft kommt es (bei uns) nicht vor, dass noch zig Folgefehler erzeugt werden. Das ist für uns soweit passend.

Dafür eignet sich der Programmalarm gut.
Ein Aufruf ersetzt bis zu 150 Bitmeldungen im Panel. Also bei uns. Er kann natürlich auch 10.000 Bitmeldungen ersetzen.
Das verstehe ich nicht. In wieweit hilft da der Program_Alarm?

VG

MFreiberger
 
Ein Aufruf ersetzt bis zu 150 Bitmeldungen im Panel. Also bei uns. Er kann natürlich auch 10.000 Bitmeldungen ersetzen.
Das ist doch irre ;)

Wer entscheidet denn, welche Meldungen gleichzeitig anstehen dürfen? Bei einem Motor kann theoretisch Sicherungsfehler und Kaltleiterfehler gleichzeitig anstehen und auch angezeigt werden.
Bei unseren Anlagen mit 10000 Meldungen können theoretisch alle gleichzeitig anstehen. Und dann auch im HMI zu sehen sein...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zwei Fehler zur exakt gleichen Zeit, die einander nicht bedingen, d.h. einer ist nicht Folgefehler des anderen?

Der Program_Alarm ist definitiv nicht dafür gedacht für jeden Fehler einzeln aufgerufen zu werden, also bei Folgefehlern hunderte Male. Dann wirds halt langsam...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wo steht, dass er dafür gedacht ist?
Ich gehe davon einfach aus, dass wenn ich die in den technischen Daten angegebene maximale an Program_Alarm verwende, das System es auch verkraftet wenn alle gemeinsam in einem Zyklus auftreten. Wenn das nicht der Fall ist, dann müsste das ja irgendwo dokumentiert sein.
 
Konkreter:
Dem Program_Alarm können Textlisten (für beliebige Sprachen) und Variablen übergeben werden. Man kann also mit einem einzigen Program_alarm hunderte Meldungen erzeugen...

Wie kann man da auf die Idee kommen der Sinn des Program_alarm bestünde darin, jedem einen fixen Text zuzordnen und hunderte, ja tausende davon im Programm zu haben?
Wozu kann ich 10 Variablen reingeben, wenn der Baustein einen fixen Text anzeigen soll, wie eine Bitmeldung?

Das Panel muss ich nach einer Erweiterung ohnehin neu laden, dann kann ich gleich bei den Bitmeldungen bleiben, wie früher.

Sicher, das geht auch mit Program_alarm. Aber dann darf man sich nicht beschweren und muss ne größere CPU nehmen. Wir haben das mal getestet, ne 1518 schafft spielend hunderte Program-alarm-Aufrufe.
 
Ich gehe davon einfach aus, dass wenn ich die in den technischen Daten angegebene maximale an Program_Alarm verwende, das System es auch verkraftet wenn alle gemeinsam in einem Zyklus auftreten. Wenn das nicht der Fall ist, dann müsste das ja irgendwo dokumentiert sein.
Hab ich nie gelesen. Steht da auf welcher CPU das laufen soll? Wie gesagt ne 1518 schafft problemlos hunderte Program-alarm-Aufrufe...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Und wie rufst du Program_Alarm auf, wenn du beispielsweise einen Motor-FB hast mit mehreren Störmeldungen, und es kommt beispielsweise Thermistor und Motorschutzschalter in einem Zyklus?
 
Also, wir benötigen nicht 100e Meldungen zur gleichen Zeit und ich bin auch damit einverstanden, dass, wenn man Meldungen auf einem bestimmten System (Panel, CPU,…) verwendet, man dieses System auch groß genug auswählen muss.

Aber ein Meldesystem muss vernünftig Meldungen erzeugen können und auch mit Meldeschwällen umgehen können.
Wenn es das nicht kann, erwarte ich eine entsprechende Information/Beschreibung dazu.

Wie schon geschrieben kann ich doch nicht implizit unterstellen, dass der Program_Alarm nicht für Meldeschwälle gedacht ist?! Wo kommt diese Information her?

Und meine Hauptbeschwerde ist, dass der Program_Alarm ungewöhnlich viel Zykluszeit benötigt. Und das ist nirgendwo dokumentiert. Das ist einfach schwach.

VG

Mario
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben