Input Parameter überschreiben

sablitos

Level-1
Beiträge
30
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
hallo zusammen,

Ich habe immer gedacht ein INPUT Parameter kann von außen beschrieben werden. Der ST-Compiler sagt mir dass das nicht möglich ist, kann das sein ????

Beispiel :
FB_1(IN_1 := ..) ; // FB mit Input Parameter
FC_1() ;

ich will jetzt innerhalb FC_1 den Input Parameter von FB_1 'IN_1' zuweisen :
(* innerhalb FC_1 *)
main.FB_1.IN_1 := xx ; // geht nicht -> Fehlermeldung : '
Operanden von ST, STN, S, R müssen Variable mit Schreibzugriff sein
'

main.FB_1(IN_1 := xx); // geht, ich will aber den FB_1 nicht aufrufen
 
hallo zusammen,

Ich habe immer gedacht ein INPUT Parameter kann von außen beschrieben werden. Der ST-Compiler sagt mir dass das nicht möglich ist, kann das sein ????

Beispiel :
FB_1(IN_1 := ..) ; // FB mit Input Parameter
FC_1() ;

ich will jetzt innerhalb FC_1 den Input Parameter von FB_1 'IN_1' zuweisen :
(* innerhalb FC_1 *)
main.FB_1.IN_1 := xx ; // geht nicht -> Fehlermeldung : '
Operanden von ST, STN, S, R müssen Variable mit Schreibzugriff sein
'

main.FB_1(IN_1 := xx); // geht, ich will aber den FB_1 nicht aufrufen
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich empfehle Sabitos ein Basis Buch über Programmiertechnik zu lesen oder einen Kurs zu buchen.

Das ist nicht böse oder abfällig gemeint aber wahrscheinlich ist das nicht die einzige Frage, die prinzipiell unklar ist.
 
Ich bin jetzt mal nicht so drauf wie RobiHerb :[

main.FB_1(IN_1 := xx); // geht, ich will aber den FB_1 nicht aufrufen

Man übergibt nur Werte an die Schnittstelle eines Aufrufs (!!!) wenn ich auch aufrufe (!!!). Was sollte der FB mit den Eingangs-Parametern (oder ein FC oder in irgendeiner anderen Programmiersprache eine Procedure oder Function), wenn dieser sie nicht auch verabeiten soll - das ist nämlich sein ureigenster Sinn ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Lupo,

wenn die Funktion FC_1() in MAIN aufgerufen wird sollen paar Input-Parameter von FB_1 aktualisiert werden. Das Problem ist das ich den 'FB_1' innerhalb der Funktion 'FC_1' nicht aufrufen kann (da bei TwinCat
Rekursionen nicht erlaubt sind )
deswegen war die Frage wie kann ich die Inputs von 'FB_1' aktualisieren ohne den gesamten FB aufzurufen, und die Lösung war :

MEMCPY(adr(main.FB_1.Input), adr(xx),4);

und so kann ich die Input Parameter von
[FONT=Arial, Helvetica, sans-serif]FB_1 innerhalb FC_1 aktualisieren ohne FB_1 aufzurufen.[/FONT]​
 
Hi,

gute Frage! Ich bin auch immer darüber gestolpert und habe das denn mit globalen Variablen gelöst. Ich habe mir das so erklärt, das der CoDeSys das nicht erlaubt, Du ja praktisch zwei Variablen ohne Verküpfung (z.B. &) auf ein und denselben Eingang legst (Was ja in CFC nicht erlaubt und in FUB erstgarnicht möglich ist). Wie weit ich allerdings mit meiner Erkärung der Dinge an der Wahrheit liege, kann ich Dir nicht sagen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Evangelium des Lukas, Kapitel 23, Vers 34. 'Tschuldigung, musste einfach sein.
Mit MEMCPY kann man natürlich überall hin schreiben, aber ist das sinnvoll? Der FB_1 ist im MAIN instanziiert, also dazu gedacht, vom MAIN aus aufgerufen zu werden. Dementsprechend kann er auch nur mit Variablen gefüttert werden, die dem MAIN zugänglich sind. Das Verwursten dieser Variablen ist doch ebenfalls Aufgabe von MAIN. Warum steht dann der Code in einer Funktion und nicht direkt im MAIN? Sollte es nur darum gehen, den Code von MAIN in übersichtliche Häppchen aufzuteilen, vielleicht auch, weil so ein Häppchen im MAIN mehrfach benötigt wird, wäre es sinnvoller, im MAIN Aktionen anzulegen. Die kann man nicht nur von aussen aufrufen, sondern auch aus dem MAIN heraus.
 
Var_in_out

Hallo Lupo,

wenn die Funktion FC_1() in MAIN aufgerufen wird sollen paar Input-Parameter von FB_1 aktualisiert werden. Das Problem ist das ich den 'FB_1' innerhalb der Funktion 'FC_1' nicht aufrufen kann (da bei TwinCat
Rekursionen nicht erlaubt sind )
deswegen war die Frage wie kann ich die Inputs von 'FB_1' aktualisieren ohne den gesamten FB aufzurufen, und die Lösung war :

MEMCPY(adr(main.FB_1.Input), adr(xx),4);

und so kann ich die Input Parameter von
FB_1 innerhalb FC_1 aktualisieren ohne FB_1 aufzurufen.

Mein erster Kommentar war wohl etwas zu spontan, aber ich bin gelegentlich schon erschrocken, wie hier gehandwerkelt werden soll, wenn dahinter ggf reale Anlagen mit Kraft und Energie zu Werke gehen.

Also zurück zum speziellen Fall etwas ausführlicher:

Einem FB gibt man Parameter als Input mit, DAMIT sie lokal im FB nur gelesen oder ggf. auch geändert werden können. Die Parameter sind WERTE, also Kopien von Daten, die aus Quellen ausserhalb des FB stammen, die Ursprungsdaten bleiben unberührt von allem, was im FB gemacht wird.

Will man die Daten (sozusagen synchron) von aussen und von innen manipulieren können, gibt es eigentlich nur einen sicheren Weg: beide "Partner" manipulieren das gleiche Daten Objekt.

Das machen viele SPS Leute mit Globalen Daten aus der Tradition der AWL, wo man sogar oft wusste, an welcher Stelle im Memory dieses oder jenes Merkerchen sich befindet.

Unter Software Leuten ist dies aus vielen Gründen eine Sünde und führt in der Praxis immer wieder zu ewigen Suchen nach Fehlern, da an Globalen Daten JEDER drehen kann.

Die IEC bietet für den Fall, den Sablitos hat, die Möglichkeit, dem FB die Parameter als VAR_IN_OUT zu übergeben, der Softwerker nennt so etwas "per Referenz". Hier bekommt der FB nicht eine Kopie des Wertes übergeben, sondern die ADRESSE genannt, an der die gewünschten Daten stehen. Für den Entwickler des Programms sieht es aus, als ob er mit dem Wert des übergebenen Parameters arbeitet, real arbeitet er aber mit dem Wert, der an der Adresse steht, die er übergeben bekommt. Den Unterschied sieht nur der IEC Compiler, die Syntax für den Programmschreiber ist die Gleiche.

Da Sablitos hier das Wort Main statt PLC_PRG benutzt, vermute ich, dass er die Sprache C kennt, ein const Pointer kommt der VAR_IN_OUT recht nahe, eine Referenz aus C++ entspricht dem besser und unter .NET und C# wird sowieso jedes übergebene Objekt eine Referenz. Zwischen IEC ST und .NET C# von heute liegen 30 Jahre Erfahrung in der Industrie, die leider an der SPS vorbei gegangen sind. (Wer AWL schreibt, ist 50 Jahre hinter dem Mond!)

Jetzt habe ich wohl ein paar Feinde hier im Forum, aber nochmals der Hinweis, Programmieren ist etwas mehr als Try and Error und Hurrah, es läuft.

Ein Buch und Kurse sind notwendig, wenn es über das Hobby Programmieren hinausgeht.
 
Da Sablitos hier das Wort Main statt PLC_PRG benutzt, vermute ich, dass er die Sprache C kennt, ein const Pointer kommt der VAR_IN_OUT recht nahe, eine Referenz aus C++ entspricht dem besser und unter .NET und C# wird sowieso jedes übergebene Objekt eine Referenz. Zwischen IEC ST und .NET C# von heute liegen 30 Jahre Erfahrung in der Industrie, die leider an der SPS vorbei gegangen sind. (Wer AWL schreibt, ist 50 Jahre hinter dem Mond!)

Jetzt habe ich wohl ein paar Feinde hier im Forum, aber nochmals der Hinweis, Programmieren ist etwas mehr als Try and Error und Hurrah, es läuft.

Ein Buch und Kurse sind notwendig, wenn es über das Hobby Programmieren hinausgeht.

Na gut, mich hast du nicht zum Feind, aber nun hab ich schriftlich, dass ich 50 Jahre hinter dem Mond und Hobbyprogrammierer bin! :ROFLMAO: Ich hab das schon immer geahnt, wenn ich so meinen Code nach 2 Jahren wieder mal bearbeiten mußte ...

Aber eines ist eigenartig, warum laufen meine Anlagen und ich behaupte mal, gar nicht so schlecht, während ich einige "Informatikermaschinen" kenne, die toll programmiert sind, aber sch... laufen? Es gehört evtl. noch ein wenig mehr dazu, als nur Informatik zu studieren, aber zugegeben, ein wenig Grundwissen in Informatik, Mathematik und Logik sollte man mitbringen.
 
Zuletzt bearbeitet:
Aber eines ist eigenartig, warum laufen meine Anlagen und ich behaupte mal, gar nicht so schlecht, während ich einige "Informatikermaschinen" kenne, die toll programmiert sind, aber sch... laufen? Es gehört evtl. noch ein wenig mehr dazu, als nur Informatik zu studieren, aber zugegeben, ein wenig Grundwissen in Informatik, Mathematik und Logik sollte man mitbringen.

Versuchst du wirklich einem Informatiker zu erklären, was ein PLC Programm ist?
Die frühstücken doch schon Pointer, da ist doch eine normale UND / ODER Verknüpfung doch nur Beiwerk.

Ralle, der Kollege macht doch nichts banales, sondern nur Atomkraftwerke, das ist nicht deine oder meine Gewichtsklasse ;-)
Meine Maschinen funktionieren weltweit und das meist fehlerfrei,doch ich habe nicht Informatik studiert.
Bin ich jetzt draußen? :confused:


bike
 
Man kann nicht alles aus der Hochsprachen-Programmierung problemlos und sinnvoll auf die SPS übertragen. Aber der Ansatz, Daten so lokal wie möglich anzulegen, um den Zugriff darauf örtlich zu beschränken, steht auch einem SPS-Programm gut zu Gesicht. Bei globalen Variablen ist einfach die Versuchung zu gross, sie an Stellen zu manipulieren, an die man sich selbst später nicht mehr erinnert.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Man kann nicht alles aus der Hochsprachen-Programmierung problemlos und sinnvoll auf die SPS übertragen. Aber der Ansatz, Daten so lokal wie möglich anzulegen, um den Zugriff darauf örtlich zu beschränken, steht auch einem SPS-Programm gut zu Gesicht. Bei globalen Variablen ist einfach die Versuchung zu gross, sie an Stellen zu manipulieren, an die man sich selbst später nicht mehr erinnert.

Recht hast du, aber sag das den Leuten die IDB nutzen, um dann von überall her (WinCCFlex, andere FB, FC) darauf rumzupoken. Wenn die Werkzeuge bestimmte Dinge nicht zulassen (wie hier in diesem Falle bei Codesys), dann mag das noch angehen, aber sonst? Und selbst da kommt dann ein Kluger auf Memcopy :ROFLMAO:
 
Man kann nicht alles aus der Hochsprachen-Programmierung problemlos und sinnvoll auf die SPS übertragen. Aber der Ansatz, Daten so lokal wie möglich anzulegen, um den Zugriff darauf örtlich zu beschränken, steht auch einem SPS-Programm gut zu Gesicht. Bei globalen Variablen ist einfach die Versuchung zu gross, sie an Stellen zu manipulieren, an die man sich selbst später nicht mehr erinnert.

Da bin ich absolut bei dir.
Das sollte bzw muss die Zukunft sein, sonst kann man ein Programm nicht mehr warten.
Nur kann und darf man auch nicht alle Ideen der Hochsprachenprogrammierung als Lösung aller Aufgaben der PLC Programmierung bezeichnen.

Denn auch die die Informatik ist im Wandel und ob die immer gut ist?


bike
 
... aber nochmals der Hinweis, Programmieren ist etwas mehr als Try and Error und Hurrah, es läuft.
Nein ... da muss ich widersprechen (auch vielleicht, weil ich auch nur Hobbi-Programmierer bin und von hinterm Mond herkomme) - Programmieren ist genau DAS. Mir ist jedenfalls nicht bekannt, dass es irgndwo auf der Welt irgend einen Programmierer gibt, der auf Anhieb ein Programm (und sei es auch noch so klein) hinbekommen hat. Im Gegenteil : die gängige Praxis ist, dass man etwas erstellt und es verteilt und dann mal schaut, was passiert. Im simpelsten Fall nennt man das Beta-Test.

Sorry, dass mußte dazu mal raus.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Recht hast du, aber sag das den Leuten die IDB nutzen, um dann von überall her (WinCCFlex ...) darauf rumzupoken.

Auch hierzu ein Widerspruch. In der Hochsprachen-Programmierei ist es sehr üblich, von einem Objekt eine Instanz (? = I-DB) zu erzeugen und auf die Elemente dieser Instanz (also Daten, Functionen, Proceduren) zuzugreifen. Das nennt man dann OOP ... ;).

Sofern es sich hierbei allerdins nicht um eine Multi-Instanz handelt gebe ich dir bezüglich der Weiterwendung der I-DB-Inhalte in anderen Bausteinen allerdings Recht - das wäre dann ein Faux-pas.
 
Zu LL möchte ich mal ein Beispiel von Siemens anführen, ich unterstelle mal das die bei der Endwicklung
von TIA sich die Endwickler sehr wohl mal Gedanken Gemacht haben und auf ein Stück Papier aufgeschrieben
was das spätere Produkt so können muß und wie es aussehen soll. Ich unterstelle auch das da mehr als 100
Vollprofis mit Erfahrung aus Step 7 und anderen Siemens Produkten mitgearbeitet haben. Was ist daraus ge-
worden, ein Produkt was ich zur Zeit ablehne und vor allen Dingen nicht fehlerfrei ist [/Punkt]
 
... das gilt aber nicht nur für Siemens sondern auch z.B. für Microsoft und wie sie alle heissen. Es gibt überhaupt gar keine Software, die auf dem Stand 1.0 geblieben ist und zu der nicht ganz kurz nach dem Release ein Servicepack herausgekommen wäre.
Ich muss dazu allerdings auch sagen, dass diese Umtriebe vor 20 Jahren (oder 50 Jahren, wo AWL noch Stand der Technik war) nach meiner Meinung lange nicht so schlimm wie heute waren ...

Gruß
Larry
 
Zurück
Oben