# Omac



## RobiHerb (20 Februar 2010)

Hat hier schon jemand mal eine reale Steuerung nach

OMAC (Open Modular Architecture Controls) Standard entwickelt?


----------



## markuscps (3 März 2010)

ich wollte auch in diese Richtung gehen und mal mit der Betriebsartenverwaltung und den Packtags beginnen. Habe bis jetzt nur Informationen gesammelt, diesen kann ich dir gerne zukommen lassen

Gruss


----------



## RobiHerb (3 März 2010)

*Praxis*

Hallo, danke für die Antwort. Ich habe auch bisher nur die Theorie der PackML aus den Internet und von Rockwell einiges gelesen. Es geht mir mehr darum, ob es Erfahrungen gibt, dass es auch Vorteile bringt oder nur einen Formalismus darstellt.

Frage wäre auch, ob man es mit CoDeSys erledigen kann und dann V3.x oder V2.x.


----------



## Flo (3 März 2010)

Hallo, der Steuerungshersteller Schneider/Elau (laufen unter Codesys V2.x bzw. bald unter V3.x) hat ein Template das nach den Richtlinien der OMAC erstellt ist. (Für Serienmaschinen keine schlehcte Sache nicht, meiner Meinung nach)
mfg,
flo


----------



## markuscps (20 Mai 2010)

In dem OMAC-Standard werden alle Ein und Ausgaenge in einem DB abgelegt, arbeiten viele von euch auf diese Art?

ich finde den Standard vor allem Hilfreich um die Daten einem BDE-System zu uebergeben, was haltet ihr davon?


----------



## IBFS (20 Mai 2010)

markuscps schrieb:


> In dem OMAC-Standard werden alle Ein und Ausgaenge in
> einem DB abgelegt, arbeiten viele von euch auf diese Art?       ..., was haltet ihr davon?


 
Ein- Und Ausgänge in einen DB zu rangieren und dann im Programm
nur noch auf den oder die DBs zu schauen, finde ich schon sinnvoll.

Es ist nun nicht generell zu empfehlen aber speziell in Firmen, wo die
Ein- und Ausgänge ganz kryptische Namen tragen, kann man dann intern
mit seinen eigenen logischen Namen Arbeiten und nicht mit dem 
unlesbaren externen Symbol.

Beispiel:

C_532GCTRLP01EE001_DIEY1 = E 40.0
C_532GCTRLP01EE001_DIEY2 = E 40.1
C_532GCTRLP01EE001_DIEY3 = E 40.2
C_532GCTRLP01EE001_DIEY4 = E 40.3
usw.


Für die Programmsimulation und Diagnose hat es auch Vorteile, denn
man kann ja mal schnell im OB1 die Rangier-FCs auskommentieren und
einen Prozesssimulations-FC scharfschalten


Gruß

Frank


----------



## markuscps (20 Mai 2010)

und man muss bei der Projektierung nicht auf den Schaltplan schauen, kann mir egal sein welche Ein\Ausgaenge benutzt werden.


----------



## IBFS (20 Mai 2010)

markuscps schrieb:


> und man muss bei der Projektierung nicht auf den Schaltplan schauen, kann mir egal sein welche Ein\Ausgaenge benutzt werden.


 
...aber die Anzahl der EA und der Wirksinn (NO/NC) ändern sich doch öfter
als einem lieb ist. Und dann ist man dann doch gezungen in die fünfzigse
Überarbeitung des Planes zu schauen.  

Frank


----------



## markuscps (23 Mai 2010)

Ja aber das lässt sich leicht ändern, egal ob man jetzt eine Datenbank verwendet oder Symbolen den vorrang gibt.
Mich würde aber interessieren was ihr von dieser Gruppe (OMAC) hier haltet, ist das nur wieder Arbeit und am Ende kommt nichts dabei raus oder haltet ihr es für Sinnvoll?
Ich könnte mir vorstellen es erleichtert einem die Anbindung an das BDE-System des Kunden und liefert auch noch eine Dokumentation frei Haus mit.

http://www.omac.org/Content/Navigat...ng_Groups/Packaging/Documents68/Documents.htm

unter "Guidelines  for Packaging Machinery Automation V3.1" findet ihr eine Beschreibung. 

Hier findet ihr ein Demo in Excel 
http://www.omac.org/Content/Microsi...PackML_Sub_Team/Home1058/PackML_Demo_Rev8.xls

Was haltet ihr davon?

In die gleiche Richtung geht auch die PLCopen.org


----------



## markuscps (25 Mai 2010)

Hier habe ich noch ein paar Infos zu Omac unter Wago-CoDeSys gefunden

http://www.omac.org/filestore/OMAC/PAF2008/WAGO PAF2008 Scripted Demo.pdf


----------

