Stationen im Programm sinnvoll gruppieren

[TP-Inc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi, ich wollte mal fragen wie ihr Stationen/Baugruppen im Programm gruppiert. Bezieht sich jetzt rein auf TIA Portal, also 1500er und Mobile/Comfort Panel. Aktuell bekommt jede Station einen Ordner mit eigenem Nummerkreis. Alles in diesem Ordner beginnt mit zB.: Station1_xy.

Das ist zwar meiner Meinung sehr übersichtlich, beim kopieren von gesamten Stationen heißt natürlich aber alles Station1_xy_1. Da ist dann einer einen ganzen Tag mit Suchen&Ersetzen beschäftigt… vor allem auf der HMI ist es viel Aufwand.

Gibts da andere/bessere Konzepte?

 

[de vliegende hollander]

Hi, ich wollte mal fragen wie ihr Stationen/Baugruppen im Programm gruppiert. Bezieht sich jetzt rein auf TIA Portal, also 1500er und Mobile/Comfort Panel. Aktuell bekommt jede Station einen Ordner mit eigenem Nummerkreis. Alles in diesem Ordner beginnt mit zB.: Station1_xy.

Das ist zwar meiner Meinung sehr übersichtlich, beim kopieren von gesamten Stationen heißt natürlich aber alles Station1_xy_1. Da ist dann einer einen ganzen Tag mit Suchen&Ersetzen beschäftigt… vor allem auf der HMI ist es viel Aufwand.

Gibts da andere/bessere Konzepte?

Ich mach es ähnlich. Benutze aber das KKS System. Sprich auf Basis von TAG Nummern

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

kopieren von gesamten Stationen heißt natürlich aber alles Station1_xy_1. Da ist dann einer einen ganzen Tag mit Suchen&Ersetzen beschäftigt… vor allem auf der HMI ist es viel Aufwand.

Gibts da andere/bessere Konzepte?

Naja, man KÖNNTE:
Station01 Station99 überall da stehen lassen, wos nicht interessiert. Und ne Liste führen, was 01 oder 99 ist.
Nur Meldetexte etc. kriegen nen Klartext...

 

[Blockmove]

Ich handhabe es mit den Stationen genauso und nutz dann auch ganz einfach Suche-und-Ersetze.
Klar ist das unter Umständen mehr Aufwand als wenn man z.B. nur mit komplett parametrisierten Bausteinen arbeitet.
Aber ich seh hier nicht nur die Zeit beim Erstellen des Programmes sondern auch Inbetriebnahme und evtl. spätere Fehlersuche oder Änderung.
Und dabei spart man mit dieser Programmstruktur wieder Zeit.

 

[A3Q]

Naja, man KÖNNTE:
Station01 Station99 überall da stehen lassen, wos nicht interessiert. Und ne Liste führen, was 01 oder 99 ist.
Nur Meldetexte etc. kriegen nen Klartext...

Wenn man ProDiag nutzt und auch nur irgendwie den Pfad oder den Bausteinnamen im Meldetext und/oder Infotext hat, wird das aber auch problematisch.


Ich denke auch es bleibt übersichtlicher wenn alle Bausteine dann umbenannt werden. Ob es bei euren Programmstandard möglich ist, so viel wie möglich zu instanzieren an "Standardbausteinen" und somit die Anzahl der Bausteine zu reduzieren, welche immer umbenannt werden müssen (Call-Bausteine, ein paar Schrittketten je Station, hier und da Globale DBs) kannst leider nur du wissen .

-chris

 

[codemonkey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es kommt halt immer auf die Rahmenbedingungen an. 1. gibt es keine Universallösung und 2. hat alles Vor- und Nachteile.
Ich selbst bin einen ganz anderen Weg gegangen, es gibt nicht für jede Station einen eigenen Ordner, sondern eine funktionale Zuordnung: Betriebsarten, Bewegungen, Meldungen, Schrittketten, usw. in den Bereichen gibt es dann DBs mit Arrays, in denen die Stationen abgebildet sind. Die Visu ist auch dementsprechend aufgebaut und ich kann recht leicht eine Station hinzufügen oder auch dazwischen setzen.

 

[Holzmichl]

Ich nutze typischerweise eine Kombination aus FCs, Global-DBs und Structs bzw UDTs.
Das heißt an einen FC wird als INOUT oder OUT eine Struktur übergeben, was für mich praktisch alle FBs für Standard-Funktionen erspart. Bleibt dann aus meiner Sicht sehr übersichtlich, leicht erweiterbar und ich habe innerhalb eines gesamten Projektes maximal 1-3 mal die Notwendigkeit eines Programmübertrags mit Stop-Anforderung, wenn kein Safety übertragen wird.
Dabei gibt es je Anlagenbereich - meistens analog zu den Sicherheits-Bereichen = Automatik-Bereichen - einen Global-DB für den Ablauf, einen DB für Antriebe und einen DB für Einstellwerte, bei dem ich die Startwerte bei jedem Erweitern problemlos mit den Aktualwerten übertragen kann.
Alle wiederkehrende Einheiten, z.B. Pneumatikzylinder haben die selbe Struktur, welche auch so im HMI genutzt wird. Bei einem Kopieren einer Einheit bleiben die vielen Einzelvariablen gleich, da ich nur den Namen des Structs oder UDTs ändern muss.