Unterprogramme aufrufen

[Glüh]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

Ä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]

Ä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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Das ist eine Zuweisung.

Ich weiss.:-D

Ich finde das einfach leichter zu verstehen

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

 

[zotos]

Zuviel Werbung?
-> Hier kostenlos registrieren

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?

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]

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.