# Unterprogramme aufrufen



## Glüh (23 März 2011)

Nabend,

ich habe angefangen mich mit der Wago-Software und Multiprog-Software zu beschäftigen(beide nach IEC61131).

Habe ein "kleines" Problem mit der Umsetzung in Multiprog oder auch Wago.

Ich habe ein Hauptprogramm Main. Im Main möchte ich, über eine Visu, je nach Konfiguation der Anlage "Unterprogramme"/oder FB' de- oder aktivieren. 

Beispiel Anlage 1.
Vakuumpumpe vorhanden --> FB/Unterprogramm 1 aktiv schalten 
Automatikventile vorhanden --> FB/Unterprogramm 2aktiv schalten
Hydraulipumpe  nicht vorhanden --> FB/Unterprogramm 3 inaktiv schalten

Habe die einzelnen Aggregate jeweils einmal als Programm und testweise auch mal als FB angelegt, klappt aber bei mir nicht.
Unterprogramme kann ich nicht in Programm  bitabhängig aufrufen.
Und wenn ich die einzelnen Funktionen in einem FB implemtiere und diesen Fb im Programm Main aufrufen möchte hat dieser FB keine EN/ENO Anschlüsse um diesen Bitabhängig aufzurufen

Gibt es einen Befehl in FUP oder Ladder mit dem ich die Aggregate bitabhängig aufrufen kann ??.
Etwa so was:
U Pumpe_vorhanden
Call FB/Unterprogramm 1

Ich hoffe Ihr könnt mein Problem nachvollziehen....
Bin für jeden Lösungsansatz dankbar. 
So was sollte doch die IEC mit sich bringen oder ich mache einfach was falsch 


Gruß Glüh


----------



## RobiHerb (24 März 2011)

*St !!!!*

Wer mit der IEC neu anfängt und nicht in ST programmieren möchte, macht was falsch!

Ist zwar keine konkrete Antwort, aber wir treiben ja auch nicht mehr unsere Apparate mehr per Pferd, Ochs und Esel an.


----------



## Glüh (24 März 2011)

Hallo Robi Herb,

hat nichts mit nicht wollen zu tun. Unsere Kunden wollen das meistens. Sie möchten sich den Plan einfach ausdrucken und die Logik nachvollziehen können. Das ist in in FUP oder Ladder mit Sicherheit für unseren Kunden einfacher als in ST.

Gruß Glüh


----------



## Simatiker (24 März 2011)

Hallo,
naja, ich muss mal sagen KOP & FUP sind genauso Programmiersprachen der IEC Norm wie ST. Und in allen Sprachen gibt es Möglichkeiten "Unterprogramme" (POUs) bedingt aufzurufen bzw. den Aufruf zu überspringen. Welche Sprache verwendet wird hängt vom Anwender ab, aber in den meisten Fällen, wie von dir schon erwähnt, vom Kunden.
Ich kann dir jetzt nicht sagen wie das mit der Wago-Software und Multiprog-Software zu realisieren ist, aber nach IEC Norm solltest du die Möglichkeit haben entweder mit Sprüngen zu arbeiten oder über den EN Eingang den Aufruf zu steuern. Da musst du mal ein bisschen ausprobieren, was so möglich ist. In CoDeSys kann man in FUP Bausteine mit EN/ENO einfügen.
Beispiel in KOP (CoDeSys V3.4):


Beispiel in FUP (CoDeSys V3.4):


Auch eine Möglichkeit wäre, bastel dir einfach nen Eingang an dein "Unterprogramm", diesen wertest du am anfang aus und wenn dieser FALSE ist programmierst du dir einfach ein 
	
	



```
RETURN;
```
 in dein "Unterprogramm".
Bleibt noch zu erwähnen, das du natürlich beachten musst, das die verarbeiteteten Variablen in deinen "Unterprogrammen" Ihren Zustand bei "nicht Aufruf" behalten. Müsstest du, wenn nötig außerhalb des "Unterprogrammes" bearbeiten.


----------



## Glüh (24 März 2011)

Hallo Simatiker,

Danke für den Denkanstoß.
Das mit Eingang basteln und dann die return-Anweisung ausführen hört sich gut an.

Werde ich morgen mal ausprobieren

Gruß Glüh


----------



## drfunfrock (24 März 2011)

Glüh schrieb:


> Hallo Robi Herb,
> 
> hat nichts mit nicht wollen zu tun. Unsere Kunden wollen das meistens. Sie möchten sich den Plan einfach ausdrucken und die Logik nachvollziehen können. Das ist in in FUP oder Ladder mit Sicherheit für unseren Kunden einfacher als in ST.
> 
> Gruß Glüh



Meinst du das ernst? 

Was ist an einem 


```
Status := VakuumPumpe.Ausgang
```

schwierig zu verstehen?


----------



## StructuredTrash (24 März 2011)

Äh, wozu ist denn dieses ":=" da? :-D

Ich kenne zum Glück solche Probleme nicht, weil ich Entwickler und Servicemann in Personalunion bin, weiss aber von Kollegen, dass die Forderung nach KOP/FUP tatsächlich noch von vielen Kunden gestellt wird.


----------



## drfunfrock (24 März 2011)

StructuredTrash schrieb:


> Äh, wozu ist denn dieses ":=" da? :-D
> 
> Ich kenne zum Glück solche Probleme nicht, weil ich Entwickler und Servicemann in Personalunion bin, weiss aber von Kollegen, dass die Forderung nach KOP/FUP tatsächlich noch von vielen Kunden gestellt wird.




Das ist eine Zuweisung. Du legst einen Wert in eine Variable, die auch mit einem Ausgang gekoppelt sein kann. Z.B.


```
IF Schalter1 AND Schalter2 THEN 
  lampe := True; /* Lampe an */
ELSE 
 lampe := False;  /* Lampe aus */
END_IF;
```

Ich finde das einfach leichter zu verstehen, als das grafische geklüngel  Aber da gibt es ja verschiedene Ansichten.


----------



## winnman (24 März 2011)

FUP kann jeder halbwegs intelligente Elektriker verstehen.

ST fast keiner.

Bin auch dafür, Programme in FUP zu machen. (Teile in AWL mit entsprechenden Kommentaren sind OK).

Wer kann ST, . . . wenn er aus der Elekrtiker Ausbildung kommt?


----------



## IBFS (24 März 2011)

winnman schrieb:


> FUP kann jeder halbwegs intelligente Elektriker verstehen.



Wieso soll denn jeder Hinz und Kunz jede beliebige Maschine reparieren oder deren Programm verstehen können.
Manche Abläufe sind so komplex, das das in KOP/FUP/AWL einfach nicht vernünftig darstellbar ist.

Frank


----------



## StructuredTrash (24 März 2011)

drfunfrock schrieb:


> Das ist eine Zuweisung.



Ich weiss.:-D



drfunfrock schrieb:


> Ich finde das einfach leichter zu verstehen



Ich auch, deshalb heisse ich auch nicht "LadderTrash".


----------



## zotos (25 März 2011)

winnman schrieb:


> FUP kann jeder halbwegs intelligente Elektriker verstehen.
> 
> ST fast keiner.
> 
> ...



Jetzt tust Du den Elektrikern aber unrecht. Selbst zu meiner Schulzeit hatte man schon vor der Ausbildung Kontakt mit Basic und Pascal, heute ist es eben VB, C# oder was auch immer da ist ST doch ein Klacks. 

Dazu kommt das ST und AWL im Vergleich fast wie Pascal und Assembler zu betrachten sind.

Hochsprachen nennt man ja nicht Hochsprachen weil diese besonders hohen Anspruch an den Programmierer stellen. Es geht darum das diese weiter entwickelten Sprachen leichter zu verstehen sind. Kein Adressregister Verbiegerei usw. der Code ist visuell leichter zu begreifen da er auch die horizontale Ebene und Strukturelemente nutzt und nicht alles stoisch untereinander geschrieben wird.

Grafische Darstellungsformen KOP/FUP/CFC und vor allem Abläufe AS/Graph sind mir sehr willkommen. Aber wenn man eine Textorientniete Sprache benutzen will ist ST keine schlechte Wahl.

Ich behaupte das ja nun schon seit Jahren und stelle mit Genugtuung fest, dass sich zumindest hier im Forum eine immer breitere Akzeptanz für   ST/SCL entwickelt.


----------



## drfunfrock (25 März 2011)

Ich habe vor Jahren einmal eine Anlage komplett neu programmiert, weil der Vorgänger alles mit Ladder-Diagrammen gemacht hatte. Da kam eine schöne Tapete bei heraus. Nur um die Dimensionen zu verdeutlichen: 

30 Prozesse mit durchschnittlich 20 Sensoren pro Prozess und alles wurde von einer SPS gesteuert. Die Tapete war beeindruckend. Dazu kam dann noch, dass die Variablen eine chaotische Bennung hatten. Dazu kam dann noch ein Sprachenmix. Ein Teil der Variablen hatte englisch klingende Namen! Der andere Teil landesübliche Bezeichnungen. Am schönsten war aber, dass Zustandsautomaten (Schrittketten) immer mit mehreren Variablen designt wurden, so dass die Kombination Schrittkettendesign, Namensgebung und Ladder jeden verzweifeln lies.


----------

