# "Power Programming"



## Oberchefe (30 August 2005)

Hallo Kollegen der Rockwellkunst,
hatte von Euch schon mal jemand etwas mit o.a. zu tun? Ich kenne es leider nur von einer kurzen Präsentation, befürchte aber daß es nur bei einfach gestrickten Maschinen oder für Neulinge ohne entsprechende Anzahl von Referenzprojekten (mit Möglichkeit für "Copy-Paste") viel bringt. Was meint Ihr dazu?


----------



## kpeter (31 August 2005)

was ist o.a.


----------



## MatMer (31 August 2005)

Ich nehme mal an *Power Programming*

was das jedoch ist weiß ich nicht


----------



## Oberchefe (1 September 2005)

> Ich nehme mal an Power Programming



richtig erkannt.

http://www.ab.com/powerprogramming/


----------



## BMLLER6758 (20 Dezember 2005)

*POWER-PROGRAMMING*

Hallo Oberchefe !!!

Stelle Dir vor, Du kommst zu einer Maschine die Du nicht selbst prgrammiert hast und sollst  mit Hilfe Deines Laptops und Deiner RS5000 in der Control Logix eine Störung beheben.

Wenn Du es in 10 Minuten nicht schaftst, dann ist die Maschine mit Power Programming programmiert worden.

Ich glaube Du verstehst was ich meine !


----------



## Oberchefe (20 Dezember 2005)

> Wenn Du es in 10 Minuten nicht schaftst, dann ist die Maschine mit Power Programming programmiert worden.



Ich habe mittlerweile eine Maschine gesehen, die von Rockwell Belgien programmiert wurde. Code der allerübelsten Sorte. Sieht nach Umsatzsteigerung (Hardware) durch Verschwendung von Rechenleistung (Software) aus. Ich habe umgehend Rockwell Deutschland damit konfrontiert. Rockwell Deutschland versprach, sich bei ihren Kollegen in Belgien schlau zu machen und anschließend mit mir Kontakt aufzunehmen. Das ist allerdings noch nicht so lange her, daher kann ich noch nichts genaueres sagen. Meine Befürchtung ist aber, daß dies Power Programming sein soll. Falls dem so wäre: jeder durchschnittliche Programmierer dürfte es schaffen, die benötigten Funktionen für seine jeweilige Maschine mit der Hälfte an Code zu programmieren.


----------



## BMLLER6758 (21 Dezember 2005)

Ja, das ist wirklich so, aber die Deutschen sind auch nicht besser.

Ich kenne auch ein aktuelles Großprojekt, welche von einem Solution Provider aus Süd Deutschland programmiert wurde. Und meine sehr guten Quellen bei Rockwell sagen es sei eine absolute Katastrophe !

Ich bin auch Solution Provider und Rockwell wollte mich auch letztes Jahr mal überzeugen PP anzufangen. Aber ich bleibe lieber bei meiner üblichen Art und Weise. Ich habe selbst jahrelang Instandhaltung und Service gemacht, und weiss was es heist sich durch fremden Code zu quälen !

Gruss

Bernd


----------



## arcis (24 Dezember 2005)

*+*



> Code der allerübelsten Sorte.



Was sind die Bewertungskriterien für guten, weniger guten, schlechten und Code von der allerübelsten Sorte?


----------



## BMLLER6758 (24 Dezember 2005)

Also ich denke, wenn 4 sehr gute Rockwell Ingineure und 2 SPS Techniker probleme haben den Code zu lesen, dann kann man von einer schlechten oder undurchsichtigen Programmierung sprechen.

Ich habe es mir jedenfalls angewöhnt das Programm so zu schreiben, das es kein Informatik Studium bedarf um Maschinenstörungen relativ schnell zu finden. Und das funktioniert bei Rockwell wirklich sehr gut.

Natürlich kann ich alles Indirekt Adressieren, von Pontius zu Pilatus springen und 500 Variablen in den JSR´s übergeben. Das sichert mir den Arbeitsplatz, weil jedesmal das Telefon klingelt wenn irgendetwas nicht funzt.

Es gibt natürlich Situationen wo man nicht immer den einfachsten Weg wählen kann und es gibt auch Befehle (MAPC, MCCP, FBC..) wo man das Handbuch mal zu rate ziehen muss.

Aber einfache Sachen darf man ruhig einfach programmieren.

In diesem Sinne !

Frohe Weihnachten !


----------



## arcis (25 Dezember 2005)

*+*



> Ich habe es mir jedenfalls angewöhnt das Programm so zu schreiben, das es kein Informatik Studium bedarf um Maschinenstörungen relativ schnell zu finden.




Wie macht man sowas, übersichtliche und leicht verständliche SPS Programme zu schreiben? Wie struikturiert man Programme, die aus mehr als 50 AWL Zeilen bestehen?


----------



## BMLLER6758 (25 Dezember 2005)

Bei Allen Bradley macht man das in Kontaktplan !


----------



## arcis (25 Dezember 2005)

*+*



> Bei Allen Bradley macht man das in Kontaktplan !



Ich glaube nicht, dass Kontaktplanprogrammierung schon einen strukurierten Programmaufbau und eine Strukturierung von Teilaufgaben gewährleistet. Kontaktplan kenne ich eigentlich nur von Mitsubishi, weil der AWL Editor für die CPU`s, mit denen ich es zu tun hatte, nicht zu bedienen war.


----------



## Oberchefe (25 Dezember 2005)

> Was sind die Bewertungskriterien für guten, weniger guten, schlechten und Code von der allerübelsten Sorte?



Letzteres habe ich beispielsweise wenn ich einen Task alle 3 Millisekunden laufen lasse um zu überprüfen, ob ein Eingang während einer Maschinenumdrehung da war. Jeder vernünftige Programmierer würde den Eingang (auf den sowieso vorhandenen) Registration Eingang legen und einen Event-gesteuerten Task auf eine bestimmte Maschinenposition starten und dann den Registration Status abfragen.
Oder wenn ich in Ablaufsteuerung programmiere und so ungünstig lange Tagnamen verwende daß ich nur mit einem 24 Zoll Bildschirm aufwärts halbwegs vernünftig damit arbeiten kann, zudem wenn die Verwendung von Ablaufsteuerung mehr oder weniger mit Kanonen auf Spatzen geschossen  ist weil es ein paar JSR mit EQU in Kontaktplan davor auch getan hätten, die eine oder andere Routine anzuspringen abhängig vom Wert eine Variablen.


----------



## MSB (25 Dezember 2005)

Das leichteste ist die Beobachtung von dir selbst,

wenn du jetzt ein Programm schreibst, ob in Kontaktplan oder AWL oder gar ST, und du 4 Wochen später bei der Inbetriebnahme nicht mehr durchblickst was du da eigentlich warum gemacht hast, solltest du an deiner Strukturierung was ändern.
Frag dich selbst was du ändern könntest, und möglicherweise durchschaubarer machen könntest.

Bei wirklich guten Programmierern kannst du zig tausende Zeilen Code vor dir haben und du weißt ziemlich schnell wo was passiert.

Das schließt sinnvolle durchgängige Symbolik oder bei AB Tag-Namen, wie angepasstes Programmieren, Stichwort des Vorredners Kanonen auf Spatzen.

Wie gesagt Kontaktplan, AWL, ST das sind nur Darstellungsarten.
Die Struktur ist die Reihenfolge und die Symbolik.

Mfg
Manuel


----------



## BMLLER6758 (18 September 2006)

Das Thema ist zwar schon fast 1 Jahr alt, aber ich möchte es doch nochmal wieder aufgreifen.

Da gibt es zum Beispiel die UDT´s "User defined Tags" die man in jedem Power Programming Project findet. Eigentlich eine sehr schöne Sache:

Man kann zum Beispiel seine gesamten Tags Modulbezogen zusammenfügen.

Man nehme zum Beispiel eine Zylinder gesteuerte Pick and Place Station bestehend aus: 

2 Zylindern (Vor und Zurück, Hoch und Runter) = 4 Ventile
1 Sauger
1 Vakuumüberwachung für den Sauger
4 Inis für die Abfrage der Positionen der Zylinder

Das sind also 5 Eingänge und 5 Ausgänge ( dazu kommen sicher noch einpaar Merker und Timer, vielleicht auch noch 1 oder 2 Zähler), aber die sind hier uninteressant.

Also haben wir 10 Adressen die auf direkte Ein-und Ausgänge zugreifen. Und hier geht das Problem mit der ÜBERSICHT los. 

*Mann kann bei der Deklaration der UDT´s keinen Alias vergeben !!!

*Und das ist auch nicht geplant ! 

Bitte um Kommentare !!!


----------



## Oberchefe (25 September 2006)

UDT's sind nicht dafür gedacht, Modultags zusammenzufassen. Sie sind dafür gedacht, selbst geschriebene Funktionen lesbarer zu machen. Z.B. wenn ich mir eine Fehlerhistory schreibe und habe bei allen Datensätzen im 7. Wort die Sekunden stehen, dann erzeuge ich mir ein UDT Typ "Fehlerhistory" mit den Mitgliedern Jahr, Monat, Tag, Stunde, Minute, Sekunde, Fehlergrund. Beschrieben werden die lesbaren Felder. Jetzt brauche ich nur noch jedes mal beim Auftreten eine Fehlers das UDT "Fehlerhistory" zu kopieren und habe die letzten 50 Fehler zur Verfügung. Und jeder versteht die Logik ohne große Erklärungen.
In Deinem Beispiel würde ich vielleicht (wenn überhaupt) ein UDT "Zylinder" erzeugen. Die Mitglieder: Ausgang Ansteuerung, Reedkontakt vorne, Reedkontakt hinten, Laufzeit vor (Typ: Timer), Laufzeit zurück (Typ: Timer)....
Ein- und Ausgänge müssen zugewiesen werden (macht meistens sowieso Sinn über Bitmerker zu gehen, andernfalls kann es passieren daß sich der Zustand eines Eingangs während des kompletten Programmdurchlaufs ändert).


----------



## M_o_t (1 Oktober 2006)

Hallo zusammen,

ich habe das "Vergnügen" mit Power Programming zu arbeiten. Es braucht wirklich viel power. Es soll angeblich so gemacht sein das es jeder versteht, nur diesen jeden habe ich noch nicht gefunden. 
Die ganze Sache basiert auf der OMAC ist eine normierung der Ami's wie eine Maschine eingeschalten und ausgeschaltet wird. Ohne diese Beschreibung scheitert man schon mal von Anfang an. Mit der Beschreibung sucht man sich dann doch ziemlich den Wolf.
Ich fand bisher Template von Elau nicht unbedingt den glücklichen Wurf aber A&B leistet sich die viel schlimmere Vorlage.

Gruß
Silke


----------



## BMLLER6758 (11 November 2006)

Oberchefe schrieb:


> UDT's sind nicht dafür gedacht, Modultags zusammenzufassen. Sie sind dafür gedacht, selbst geschriebene Funktionen lesbarer zu machen.



Das gibts doch erst ab Version 16 ! Oder ???


----------



## Oberchefe (14 November 2006)

Was soll es erst ab Version 16 geben, UDT's oder Modultags?


----------

