# Was haltet ihr von solchen Funktionen?



## thomasgull (27 Februar 2015)

Was haltet ihr von Programmierschritten die irgendwo bei gewissen Aktionen statische Variablen in Instanzdatenbausteinen verändern?

Nach meiner Meinung ein NO-Go da die Funktion des Bausteins ausser Kontrolle geraten kann.

Thomas


----------



## Verpolt (27 Februar 2015)

Schön  isses nicht.

Siemens schreibt bei den Reglern auch gerne in den IDB.

such mal hier nach Instanzdatenbaustein,  HMi-Zugriff usw...

Da wurde das bis zum Erbrechen durchgekaut


----------



## thomasgull (27 Februar 2015)

Wenn der Bereich definiert ist oder in di inVariablen kann ich noch nach vollziehen.
Aber variablen die dort gelesen und geschrieben werden kann ich nicht befuerworten da sie instabilitaet bergen.
Auch wurde der baustein nicht dafuer entworfen.
Die Firma versuchte so nur einen Mangel im Baustein zu kitten, anstelle es korrekt im Baustein zu programmieren


----------



## Larry Laffer (27 Februar 2015)

@Thomas:
Ich sehe das genauso wie du ...*ACK*


----------



## thomasgull (27 Februar 2015)

Ist leider nicht das einzige Flickwerk in der ganzen Software

da werden Und/Oder Verknüpfungen gemacht mit 60 Anweisungen und zig Klammerausdrücken, da kann man unmöglich noch die Funktion erkennen.

Wenn es funktionieren würde da wäre noch das eine aber da bleibt die Anlage ab und zu stehen und nichts geht mehr. Zum "reparieren werden dann noch 3 Zeilen zugefügt.



Da hat es Funktionen drin wie

O Eingang1
O Eingang2
O (
U Eingang1
U Eingang2
)
= Ausgang

nur 60 Anweisungen lang


----------



## Larry Laffer (27 Februar 2015)

Da kannst du dir dann mit Vollmi die Hände reichen. Der hat auch solche Maschinchen in denen er "schicke lustige" Programm-Snippets drin hat ...

Da hilft nur eins : :sw14:


----------



## thomasgull (27 Februar 2015)

Eine solche Programmierung wäre vielleicht gut für den Zahlengenerator beim Lotto


----------



## Ralle (27 Februar 2015)

IDB-Zugriffe habe ich früher komplett abgelehnt. Inzwischen (1200+1500) mache sich das schon auch mal, wenn der FB alle seine (eingesammelten) Daten in den IDB schreibt und in sich abgeschlossen ist. (Wie z.Bsp. der FB125/126 Profibus von Siemens das schon immer macht). Ansonsten muß man alle Daten über eine Schnittstelle in einen anderen FB/FC übergeben oder erst nochmals in einen globalen DB auslagern und das geht dann u.U. zu Lasten der Performance und des Arbeitsspeichers, insbesondere, wenn es um große Datensammlungen geht. Auch werden in TIA ja nun immerhin symbolisch adressierte Daten bei evtl. Änderungen automatisch nachgezogen, so dass es zumindest nicht ganz so gefährlich ist, wie bei den 300/400 und Klassik. Aber insgesamt versuche ich Querzugriffe in den statischen Speicher der FB hinein zu vermeiden, ist m.E. kein wirklich guter Programmierstil. Aber wie immer, Ausnahmen bestätigen die Regel.


----------



## thomasgull (28 Februar 2015)

@Ralle
Du meinst auch dass du direkt iVariablen, anstelle von Temporären die die du wiederum am Baustein als In benötigst, oder Lesend sehe ich weniger ein Problem. So wie es du beschreibst ist es ist es aber auch so Designt dass die Daten Direkt verwaltet werden.
Hier wurde es gemacht um Funktionen im Baustein zu ändern die sie selber falsch erstellt haben und dies nicht an einer Stelle sondern zu Duzenden. Die Mängel der Funktionen werden so "Behoben" oder besser gesagt verschoben, denn es treten so ganz andere Fehler auf.
Gefordert waren sauber der Funktion entsprechende Bausteine und übersichtliche Strukturen, so  haben wir alles andere als das.

Der Programmierer ist der Ansicht "das ist schon gut so".

Ich habe die Antwort nicht akzeptiert, da das ganze nochmals ähnlich aufgebaut werden soll und er meint ist ja nur Copy Paste. Das ganze überzieht etwa 50 Bausteine an 20-40 Netzwerke. Also alles ander als nur klein und fein.


----------



## Ralle (28 Februar 2015)

thomasgull schrieb:


> @Ralle
> Du meinst auch dass du direkt iVariablen, anstelle von Temporären die die du wiederum am Baustein als In benötigst, oder Lesend sehe ich weniger ein Problem. So wie es du beschreibst ist es ist es aber auch so Designt dass die Daten Direkt verwaltet werden.
> Hier wurde es gemacht um Funktionen im Baustein zu ändern die sie selber falsch erstellt haben und dies nicht an einer Stelle sondern zu Duzenden. Die Mängel der Funktionen werden so "Behoben" oder besser gesagt verschoben, denn es treten so ganz andere Fehler auf.
> Gefordert waren sauber der Funktion entsprechende Bausteine und übersichtliche Strukturen, so  haben wir alles andere als das.
> ...



Da gebe ich dir absolut Recht, wenn Funkionen, die eigentlich in den FB gehören (bei Reset z.Bsp.) nach außen verlagert werden und dann dort IDB-Daten manipuliert wären, dann ist das auf jeden Fall kein guter Stil!
Hast du mich vielleicht nicht ganz richtig verstanden oder ich hab mich schlecht ausgedrückt , ich vermeide solche Dinge auch auf jeden Fall.


----------



## thomasgull (28 Februar 2015)

Da sind wir uns einig
Ja sind solche befehle


----------



## Blockmove (28 Februar 2015)

Vor einiger Zeit die selbe Diskussion mit Siemens zu diesem Thema gehabt.
Ich hatte mir erhofft, dass bei TIA die Instanzen objektorientierter werden und dort z.B. Deklarationen ala "public" und "private" möglich werden.

Gruß
Dieter


----------



## Pico1184 (4 März 2015)

> Ich hatte mir erhofft, dass bei TIA die Instanzen objektorientierter  werden und dort z.B. Deklarationen ala "public" und "private" möglich  werden.



Lässt du uns dazu auch an der Antwort von Siemens teilhaben? Würd mich mal intressieren...


----------



## Blockmove (4 März 2015)

Die Aussage war, dass sich am Befehlssatz und den Funktionen der 1500er noch einiges ändern wird.
Es wurden einige Dinge "angedeutet", jedoch darf ich hierzu nichts weitergeben.

Gruß
Dieter


----------



## Thomas_v2.1 (4 März 2015)

Blockmove schrieb:


> Die Aussage war, dass sich am Befehlssatz und den Funktionen der 1500er noch einiges ändern wird.
> Es wurden einige Dinge "angedeutet", jedoch darf ich hierzu nichts weitergeben.



Hoffentlich ist das nicht die gleiche Quelle die euch mitgeteilt hat, das TIA würde alles in einer SQL-Datenbank ablegen...

Für Zugriffsmodifizierer wie public oder private muss auch nichts im Befehlssatz erweitert werden, da es rein auf Übersetzungsebene funktioniert. Zumindest in allen nicht-Siemens-TIA-Schnappsideen ist das so.
Wenn der Compiler direkt Maschinencode und nicht diesen Zwischencode erzeugen würde, wäre jede Funktionserweiterung auf jeder noch so alten CPU lauffähig. Zumindest wenn man sich bei der Erstversion ein vernünftiges Konzept ausgedacht hätte. Durch das jetzige Konzept hat man die Probleme, dass nichts mehr Ab- oder Aufwärtskompatibel ist.


----------



## bike (4 März 2015)

Blockmove schrieb:


> Die Aussage war, dass sich am Befehlssatz und den Funktionen der 1500er noch einiges ändern wird.
> Es wurden einige Dinge "angedeutet", jedoch darf ich hierzu nichts weitergeben.
> 
> Gruß
> Dieter



Ich weiß es ist OT, aber sehr seltsam ist es, dass ein System ausgeliefert wird, das nicht fertig ist.
So darf ich doch deine Aussage verstehen.
Wenn dem so ist, kann man ja gut und erfolgreich gegen Big$ klagen. 
Denn vor Gericht werden die Knaben aussagen müssen. 

Könnt ihr euch erinnern, wie vor so ungenau 4 Jahren über TIA und die neuen CPU euphorisch nach der Hirnwäsche von Big$ hier geschrieben wurde.


bike


----------



## Blockmove (5 März 2015)

Bike, wieviele Funktionen wurden bei der 300 oder 400er eingebaut?
Vergleich mal die Systembausteine einer CPU 412 von 95 mit einer aktuellen


----------



## mariob (9 März 2015)

Hi,
wo ist eigentlich der Perfekte? Der hatte es doch immer so mit TIA.....

Gruß
Mario


----------



## vollmi (9 März 2015)

bike schrieb:


> Ich weiß es ist OT, aber sehr seltsam ist es, dass ein System ausgeliefert wird, das nicht fertig ist.
> So darf ich doch deine Aussage verstehen.



Willst du damit etwa andeuten das Step7 fertig ist?
Versuch da mal eine SCL Multiinstanz online zu betrachten.
Oder ein Projekt über alles zu übersetzen und zu laden das mehr als 5 CPUs hat.

mfG René


----------



## bike (9 März 2015)

Blockmove schrieb:


> Bike, wieviele Funktionen wurden bei der 300 oder 400er eingebaut?
> Vergleich mal die Systembausteine einer CPU 412 von 95 mit einer aktuellen



Stimmt, es wurde nachgerüstet.
Doch der Vergleich von dir hinkt etwas.
Big$ will alles in das OS der CPU reinbuttern, damit die Nachbauer scheitern.
So kann man seine eigene Unfähigkeit verstecken und es als Innovation verkaufen.

@René: kann man bei einem anderen Hersteller über 100 CPU alles ohne Probleme fehlerfrei übersetzen?
Ich habe bisher wenig Probleme mit unseren Projekten und deren Übersetzung.
Liegt es, wenn es bei dir nicht klappt an Big$ oder an dir?
Wenn bekannt ist, dass etwas nicht bzw nicht fehlerfrei funktioniert, dann muss es eben anders machen.
Nimm einen Compiler und schicke zu einem div durch Null.
Solch ein Vergleich wie du ihn anstellst  hinkt nach meiner Meinung wie Stördebecker auf seinem letzten Weg.

 Mist, jetzt verteidige ich Big$ schon, so weit ist es gekommen.


bike


----------



## Blockmove (9 März 2015)

bike schrieb:


> Mist, jetzt verteidige ich Big$ schon, so weit ist es gekommen.



Wenn ich Doku schreibe, dann ärgere ich mich über Microsoft mehr als über Siemens.
EPlan P8 ist auch ein Quell stetiger Freude.
Kuka ist auch nicht besser.

Also sogesehen gehört eine Portion Leidensfähigkeit eben zum Job.

Was mich am meisten in der Zwischenzeit ärgert sind diese saublöden Marketing-Versprechen ala:


> "Durch den Einsatz unserer neuen Software Drecksgelumpe 5.8 arbeiten Sie 40% effizienter"



Oder kürzlich die Unverfrorenheit schlechthin:


> "Wir haben die gleiche Aufgabe mit Drecksgelumpe 5.8 von einem Einsteiger und einem langjährigen Anwender der alten Software lösen lassen.
> Das Resultat war, dass der Einsteiger 20% schneller war. Sie sehen also; Sie müssen offen für das neue sein und nicht an alten Zöpfen festhalten"


----------



## vollmi (9 März 2015)

Blockmove schrieb:


> Oder kürzlich die Unverfrorenheit schlechthin:



Der Einsteiger wird sich das dann einfach schnell zusammengeklickt haben. Vermutlich funktionell aber nicht mehr Wartbar.
So vonwegen nachhaltig programmieren kostet halt Zeit egal mit welcher Software.

mfG René


----------



## vollmi (9 März 2015)

bike schrieb:


> @René: kann man bei einem anderen Hersteller über 100 CPU alles ohne Probleme fehlerfrei übersetzen?
> Ich habe bisher wenig Probleme mit unseren Projekten und deren Übersetzung.
> Liegt es, wenn es bei dir nicht klappt an Big$ oder an dir?



Bei oben genannten Beispielen, liegt es an Siemens. Du nutzt da einfach die Möglichkeiten die Step7 anbietet nicht aus. Ich wollte die Möglichkeiten die Step7 bietet halt nutzen, kann aber nicht weil es halt nicht funktioniert.

Du hast hast doch gesagt die Software ist nicht fertig warum sie ausgeliefert wird. Und ich sag weder TIA noch Step7 sind fertig. Ich hab nur das Gefühl das du da mit zweierlei Mass misst.
Bei Step7 sagst du, wenn was nicht funktioniert "muss man es halt anders machen". Bei TIA sagst du wenn was nicht funktioniert "Mistsoftware kann man nicht gebrauchen"

Wo also hinken meine Vergleiche bitteschön?

mfG René


----------



## bike (9 März 2015)

vollmi schrieb:


> Wo also hinken meine Vergleiche bitteschön?
> 
> mfG René



Stimmt ich nutze Siemens nicht.
Oder doch? Sei versichert ich kann und programmiere mit Siemens.

Bei TIA fehlen die Grundlagen, da diese nicht funktionieren.
Und  die Funktionen die du möchtest, sind nicht bei Big$ dokumentiert und  auch mit diesen Unzulänglichkeiten? kann man gute Programme schreiben. 
ich möchte durch Null divideren und warum geht die CPU auf Stop?
Ist da Big$ oder der Hardwarehersteller schuld? Oder doch vielleicht ich? 

Du kennst Step7 Version 1 nicht, das war so wie jetzt bei TIA, alles versprochen und nichts, absolut nichts hat funktioniert.
Awl war nicht brauchbar, KOP war eine Katastrophe und FUP war nicht da, da Teufelszeug.
Es  war eben TI, die als Leidfaden (Leidensfaden?) angenommen wurde. S7 200  ist ja der direkte nachbau von TI und daher auch vermutlich nicht der  Renner geworden.
Nur hatte ich die Illusion, dass die dazulernen und nicht wieder solch einen Mist ausliefern.



bike


----------



## vollmi (9 März 2015)

bike schrieb:


> Stimmt ich nutze Siemens nicht.




Des lesens bist du aber auch nicht wirklich mächtig oder? Zwischen nicht alle Funktionen nutzen und gar nicht nutzen liegen schon minimale Unterschiede. Und ich hab nicht angedeutet das du Siemens nicht nutzt.




> Bei TIA fehlen die Grundlagen, da diese nicht funktionieren.
> Und die Funktionen die du möchtest, sind nicht bei Big$ dokumentiert und auch mit diesen Unzulänglichkeiten? kann man gute Programme schreiben.




Natürlich sind die Funktionen Dokumentiert und im Step7 vorhanden, sie funktionieren nur nicht.




> ich möchte durch Null divideren und warum geht die CPU auf Stop?
> Ist da Big$ oder der Hardwarehersteller schuld? Oder doch vielleicht ich?




Was hat eine ungültige Anweisung mit fehlerhaften Funktionen zu tun?




> Du kennst Step7 Version 1 nicht, das war so wie jetzt bei TIA, alles versprochen und nichts, absolut nichts hat funktioniert.




Ich hab tatsächlich erst mit 3.2 angefangen da vorher noch Step5 angesagt war. Nichts destotrotz waren da noch n Haufen Unzulänglichkeiten drin. Wirklich n Haufen.[/QUOTE]


mfg René


----------



## Draco Malfoy (12 März 2015)

Blockmove schrieb:


> Vor einiger Zeit die selbe Diskussion mit Siemens zu diesem Thema gehabt.
> Ich hatte mir erhofft, dass bei TIA die Instanzen objektorientierter werden und dort z.B. Deklarationen ala "public" und "private" möglich werden.
> 
> Gruß
> Dieter


Sorry für OT aber - kannst Du mir als einem nicht-Informatiker sondern Elektrotechniker mal erklären, was 

- 1. "objektorientiert" und
- 2. "private" und "publik" bedeutet ???

Ich lese dies mit "objektorientiert" ständig in irgendwelchen Zusammenhängen und mich befällt jedesmal das Kotzen, weil ich a) mit diesen Begriffen nichts anfangen kann, b) es in den zahlreichen Steuerungen, die ich bisher programmiert habe, allenthalben verschiedene Objekte gegeben hat, aber ich verstehe nicht, wie etwas davon objektorientiert oder objekt-desorientiert sein kann, und was diese ganze Informatiker-Freaksprache überhaupt in meiner Steurerungswelt zu suchen hat ??

Ganz ernstlich ich verstehe es nicht. Ich habe Datenbausteine, Funktionen, Funktionsbausteine, von mir aus Multiinstanzen und Technologieobjekte. Ich verstehe sogar mittlerweile, was technische Hierarchie in PCS7 ist, und wie mit ihr umzugehen ist. Aber was zum Satan ist bitte schön "objektorientiert" ?? Und was soll ich in einer Bausteininstanz "private" und "publik" deklarieren können ?? 

Dank im Voraus


----------



## vollmi (12 März 2015)

Ich denke grundsätzlich programmierst du schon Objektorientiert. 
Das bedeutet so salopp gesagt ja nur das du das Physikalische Feld in der SPS nachbildest nach Objekten gegliedert.
z.B. Ein Axialventilator mit Schaufelverstellung besteht ja aus diversen Einzelteilen.
- Schaufelhydraulik -> FB "Schaufelhydraulik"
- Motor -> FB "Motor"
- Fremdlüftung -> FB "Fremdlüftung"
etc.
Das sind alles kleine Objektabildungen der Anlagenteile.
Diese haben intern keinerlei direkte Zugriffe auf die Peripherie sondern reichen die Daten die sie verarbeiten nur durch bzw nehmen sie entgegen und geben zurück.
Das übergeordnete Objekt wäre dann der Axialventilator -> FB "Axialventilator" 
der ruft dann die teilobjekte auf. Auch im Axialventilator gibts keinen Zugriff auf die peripherie. 

Der FB Axialventilator bekommt dann von "draussen" alle Daten. GlobalDBs etc und gibt das weiter an die Untergeordneten Bausteine

mfG René


----------



## MasterOhh (12 März 2015)

Draco Malfoy schrieb:


> Sorry für OT aber - kannst Du mir als einem nicht-Informatiker sondern Elektrotechniker mal erklären, was
> 
> - 1. "objektorientiert" und
> - 2. "private" und "publik" bedeutet ???
> ...



Da brauchst du nur mal eine Suchmaschine deines Vertrauens bemühen oder bei Wikipedia nachschaun. Dir hier Vererbung, Datenkapselung, Attribute und Methoden zu erläutern würde den Rahmen dieses Threads doch schon sehr sprengen. 
Wozu Objektorientierung? OOP ermöglicht es einen Programmcode zu strukturieren, ihn wiederverwendbar zu machen und komplexe Strukturen zu vereinfachen. 
Datenkapselung (public, private etc.) verhindert genau das was der Threadersteller hier moniert hat, den wahllosen und ungehinderten Zugriff auf irgendwelche Variablen kreuz und quer im Programmcode. 

Einen "nur" Anlagenprogrammierer wird der Sinn und Nutzen dieser "Informatiker-Freaksprache" kaum deutlich werden, da der Steuerungscode, selbst für komplexere Maschinen, selten auch nur ansatzweise an die Komplexität einer "Mittelgewichtigen" PC-Anwendung heran kommt. Viele Programmierer die auch abseits von SPS Programme erstellen, werden aber schnell erkennen das OOP seine Daseinsberechtigung hat und sich über Möglichkeiten freuen dieses auch in Anlagenprogrammierung einzusetzen.


----------



## Blockmove (12 März 2015)

Draco Malfoy schrieb:


> Sorry für OT aber - kannst Du mir als einem nicht-Informatiker sondern Elektrotechniker mal erklären, was
> 
> - 1. "objektorientiert" und
> - 2. "private" und "publik" bedeutet ???
> ...



Wie schon Rene schreibt, ist Objektorientierung für SPSler eigentlich was einfaches.
Wir haben schliesslich mit realen Objekten zu tun.
Nimm mal ein einfaches Handling mit Greifer, Vertikalhub und Horizontalachse.
Jedes dieser Elemente ist nun ein Objekt.
Und jedes Objekt hat sogenannte Zustände und Methoden.
Der Greifer hat die Zustände "Offen, Geschlossen, Leer, Belegt" und die Methoden "Spannen, Lösen"
Die Achse hat die Zustände "Bereit, Referenziert, Ist-Position, Ist-Drehzahl, ..." und die Methoden "Fahre zur Position, Tippen+, Tippen-, Referenzieren,..."

Bisher hast du für als dies FCs, FBs, Merker, Instanz-DBs und Global-DBs. Im Prinzip musst du dir also erstmal alles zusammensuchen was z.B. zur Horizontalachse gehört.
Bei der Objektorientierung gibt es diese Trennung zwischen Funktionen und Daten nicht mehr. 
Nach aussen hin wird nicht mehr die Achs-Position in einen Achs-DB geschrieben und dann der Start-Merker gesetzt, sondern du rufst die Methode "Horizontalachse::Fahre zur Position (1234.0)" auf.

Jetzt brauchst du aber zur Ansteuerung einer Achse viele Befehle und musst auch viele Meldungen verschalten.
Viel davon ist für die anderen Programmteile / Objekte völlig uninteressant.
Deshalb gibt es einfach die Begriffe "public" und "private".
Mit "public" deklariert man Eigenschaften und Methoden, die für andere notwendig sind. Und mit "private" kapselt man eben die internen Dinge.

Dies ist wirklich nur eine extrem stark vereinfachte Beschreibung.

Eigentlich kannst du auch mit S7 objektorientiert programmieren.
Du packst alles in entsprechende FBs und greifst dann auf die Multiinstanzen zu.
Nur leider fehlen dann eben Dinge wie die Möglichkeit der Definition von Eigenschaften, Methoden, public, private und ein entsprechender Querverweis.

GrußDieter


----------



## Draco Malfoy (12 März 2015)

Ok. Vielen Dank für die freundlichen Erklärungen, ich glaube, so langsam beginne ich den Sinn dahinter zu begreifen, und muss nicht jedesmal stutzen wenn von diesem schwarzmagischen OOP geredet wird. D.h. also auf Deutsch gesagt, wenn ich ein "Objekt" wie z.B. ein Stelltisch, einem bestimmten FB zuordne (um konkretes Beispiel zu wählen - FB 450_OBERTISCH_STANZE) und dann seine "Methoden" (sprich - Funktionsumfang) nur innerhalb dieses FB realisiere, und nicht etwa noch Bausteine wie FC 30_OT_STANZE_POSITIONSFAHRT habe, die komplett woanders aufgerufen werden, dann programmiere ich objektorientiert ?

D.h. also ein nach OOP idealer Programmierstil würde demnach so aussehen:

 .... Im ORG. BAUSTEIN_STANZSTATION wird FB 450_OBERTISCH_STANZE aufgerufen.
FB 450 bindet seinerseits Multiinstanten ein, und zwar:
- FB 400_SERVOACHSE_POSITIONIEREN;
- FB 401_SERVOACHSE_REFERENZIEREN;
- FB 402_SERVOACHSE_PARAMETERZUGRIFF;
- FB XXX_ALLGEMEINE_FUNKTION XXX

Wobei alle diese dargestellte Bausteine "neutrale" Funktionseinheiten sind, die nicht wissen, ob sie für den Obertisch oder Untertisch, oder noch was anderes gebraucht werden.
Um jetzt "Private" und "Public" nachzubilden müsste ich dann verhindern, daß noch irgendwoanders auf den Bereich "static" meines FB 450 gelesen oder geschrieben wird, und jegliche Kommunikation mit anderen Programmteilen über IN/OUT/INOUT erfolgt. Richtig ?


----------



## Blockmove (12 März 2015)

Draco Malfoy schrieb:


> D.h. also ein nach OOP idealer Programmierstil würde demnach so aussehen:
> 
> .... Im ORG. BAUSTEIN_STANZSTATION wird FB 450_OBERTISCH_STANZE aufgerufen.
> FB 450 bindet seinerseits Multiinstanten ein, und zwar:
> ...



Naja es geht so in diese Richtung bzw. mehr kannst du in S7 z.Z auch nicht machen.
Die Kommunikation findet aber nicht mehr über die Beschaltung der Schnittstelle statt sondern direkt über die Instanz.

```
U #insX_AchseReferenzieren.Refpkt_IO
U #insX_ServoAchseParameterzugriff.Gueltig
U #insSchrittkette.S3
= #insX_ServoAchsePositionieren.Pos1.Start
```

Du kannst jetzt zwar versuchen mit IN/OUT/INOUT etwas Übersicht und Ordung in die Sache zu bringen.
Aber letztlich ist es aus Aufrufsicht (fast) egal ob du nun alles im Stat-Bereich deklarierst oder in die Schnittstelle packst.

Wäre es jetzt wirklich Objektorientiert, dann würde es Klassen geben. Darin wären dann Daten, Schnittstellen und Funktionen zusammengefasst.

Gruß
Dieter


----------



## vollmi (12 März 2015)

Blockmove schrieb:


> Du kannst jetzt zwar versuchen mit IN/OUT/INOUT etwas Übersicht und Ordung in die Sache zu bringen.
> Aber letztlich ist es aus Aufrufsicht (fast) egal ob du nun alles im Stat-Bereich deklarierst oder in die Schnittstelle packst.
> 
> Wäre es jetzt wirklich Objektorientiert, dann würde es Klassen geben. Darin wären dann Daten, Schnittstellen und Funktionen zusammengefasst.



Als Klasse könnte man ja einen UDT ansehen oder? Ich meine IM FB oder FC definiert man dann eine Variable vom Typ des UDT.
Also UDT1 = Regelventil = Klasse

```
Atribute: Maximaloeffnung
              Minimalöffnung
Methode: bfAuf
               bfZu
```


```
FB_Ventil.Reg.bfAuf := #BefehlAuf;
#Max := FB_Ventil.Reg.Maximaloeffnung;
#RmAufbefehl := FB_Ventil.Reg.bfAuf; // Ja man kann auch an in deklarierte Typen zurücklesen

FB_Ventil()
```

Ob das Reg im FB_Ventil nun an In/Out oder Stat deklariert ist spielt in Step7 keine Rolle. Darf nur nicht an INOUT oder Temp deklariert sein da diese nicht in der Instanz landen.

Mit einer vernünftigen Struktur steht und fällt das ganze da man Referenzdaten nahezu vergessen kann. Aber ich steh da auch noch ganz am Anfang.

mfG René


----------



## Blockmove (12 März 2015)

@Rene
Naja eine UDT unterscheidet sich schon von einer Klasse.
Aber letztlich hilft das alles nix, da Siemens auf diesem Gebiet einfach zu rückständig ist.

Persönlich arbeite ich viel mit UDTs und Strukturen.
Den Zugriff auf Instanzen vermeide ich.
Ich gehe dann lieber den "Zwischenschritt" über Global-DBs die alle notwendigen Daten und Zustände enthalten.
Merker gibts eigentlich ausser den Taktmerkern keine mehr.
Ich lege Wert darauf, dass ein Instandhalter mit Querverweis und "Gehe zu" die für ihn wichtigen Dinge im Programm finden kann.
Das schränkt zwar bei der Programmierung ein und man hat mehr Tipparbeit, aber dafür hab ich am Abend meine Ruhe 
Aber bekanntlich führen viele Wege nach Rom 

Gruß
Dieter


----------



## vollmi (12 März 2015)

Ich gehe eben auch eher den Weg über GlobalDBs mit UDTs abgefüllt. Das ist etwas übersichtlicher und lässt sich auch besser in den VAT eintragen und verwalten.

mfG René


----------

