Ich muss gestehen das ich das "skripten" noch nie genutzt habe und
habe deswegen mal so eine typische Anfängerfrage:
Kann man die Skript's auch im eigentlichen Programm z.b.: FB aufrufen
um Funktionen die Python besser kann nach draußen zu verlagern?
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-04-06
Originally created by: M.Schaber
Hallo, Thomas!
Zitat:
Ich muss gestehen das ich das "skripten" noch nie genutzt habe und habe deswegen mal so eine typische Anfängerfrage:
Kein Problem - da das Python-Skripting in CoDeSys neu ist, sind alle Anfänger darin (inklusive uns bei 3S ).
Zitat:
Kann man die Skript's auch im eigentlichen Programm z.b.: FB aufrufen um Funktionen die Python besser kann nach draußen zu verlagern?
Nein, leider nicht. Die Skripte dienen - ähnlich wie der alte "Batch Mode" in CoDeSys V2 - lediglich dazu, Abläufe in der Entwicklungsumgebung CoDeSys selbst zu automatisieren. Sie laufen im CoDeSys auf dem Entwicklungsrechner, nicht in der Runtime auf dem Gerät.
Ein Beispiel bei einem Kunden ist, dass Sie CoDeSys aus einem anderen Programm heraus fernsteuern wollen: Eines Ihrer internen Werkzeuge generiert verschiedene PLCOpenXML-Dateien. Dann startet dieses Tool CoDeSys mit einem Skript, das ein Template-Projekt öffnet, die PLCOpenXML-Objekte an die passenden Stellen importiert, und das ganze dann als Projekt abspeichert. Auf diese Weise wollen Sie einen "CoDeSys-Projektgenerator" basteln, um z. B. zu einer bestimmten Anlagenkonfiguration gleich automatisch ein passendes CoDeSys-Projekt auszuspucken.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-04-06
Originally created by: thomas_nienstaedt
... aber wär doch cool wenn das ginge!
Wenn ich mir z.B. ansehe was die Jungs aus Verl gerade zusammenbauen
dann glaube ich Ihr solltet so etwas ähnliches auf die Beine stellen!
Zur Zeit ist es für den End User ja nicht möglich Funktionen in andere
Umgebungen auszulagern weil man die dort einfacher umsetzen könnte.
Wenn ihr also mal gar nichts mehr zu tun habt !
dann könnt ihr ja mal drüber nachdenken!
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-04-06
Originally created by: M.Schaber
Hallo, Thomas,
haben die "Jungs aus Verl" tatsächlich einen Skript-Interpreter in die Laufzeitumgebung eingebaut?
Die in C implementierte Variante von Python könnte sich sicher theoretisch auf den etwas "fetteren" Steuerungen (die z. B. mit Linux laufen) irgendwie einbinden lassen - ich sehe da allerdings schon das Problem, dass Skriptsprachen üblicherweise nicht echtzeitfähig sind, die Garbage Collection kann mal leicht eine Zykluszeit sprengen. Und auch der RAM-Verbrauch ist ziemlich unberechenbar. Gerade auf kleineren Steuerungen sehe ich da keine Chance. Und dadurch, dass Python dynamisch typisiert ist, sind statische Codeüberprüfung und Sicherheitsgarantien bis hin zu CoDeSys Safety für Sprachen wie Python nicht leicht zu machen.
Vielleicht wäre da eine schlankere, statisch typisierte Sprache wie Pawn sinnvoller, aber dann kann ich auch gleich bei ST bleiben.
Originally created by: thomas_nienstaedt
Ich muss gestehen das ich das "skripten" noch nie genutzt habe und
habe deswegen mal so eine typische Anfängerfrage:
Kann man die Skript's auch im eigentlichen Programm z.b.: FB aufrufen
um Funktionen die Python besser kann nach draußen zu verlagern?
Thomas
Originally created by: M.Schaber
Hallo, Thomas!
Kein Problem - da das Python-Skripting in CoDeSys neu ist, sind alle Anfänger darin (inklusive uns bei 3S ).
Nein, leider nicht. Die Skripte dienen - ähnlich wie der alte "Batch Mode" in CoDeSys V2 - lediglich dazu, Abläufe in der Entwicklungsumgebung CoDeSys selbst zu automatisieren. Sie laufen im CoDeSys auf dem Entwicklungsrechner, nicht in der Runtime auf dem Gerät.
Ein Beispiel bei einem Kunden ist, dass Sie CoDeSys aus einem anderen Programm heraus fernsteuern wollen: Eines Ihrer internen Werkzeuge generiert verschiedene PLCOpenXML-Dateien. Dann startet dieses Tool CoDeSys mit einem Skript, das ein Template-Projekt öffnet, die PLCOpenXML-Objekte an die passenden Stellen importiert, und das ganze dann als Projekt abspeichert. Auf diese Weise wollen Sie einen "CoDeSys-Projektgenerator" basteln, um z. B. zu einer bestimmten Anlagenkonfiguration gleich automatisch ein passendes CoDeSys-Projekt auszuspucken.
Originally created by: thomas_nienstaedt
... aber wär doch cool wenn das ginge!
Wenn ich mir z.B. ansehe was die Jungs aus Verl gerade zusammenbauen
dann glaube ich Ihr solltet so etwas ähnliches auf die Beine stellen!
Zur Zeit ist es für den End User ja nicht möglich Funktionen in andere
Umgebungen auszulagern weil man die dort einfacher umsetzen könnte.
Wenn ihr also mal gar nichts mehr zu tun habt !
dann könnt ihr ja mal drüber nachdenken!
Thomas
Originally created by: M.Schaber
Hallo, Thomas,
haben die "Jungs aus Verl" tatsächlich einen Skript-Interpreter in die Laufzeitumgebung eingebaut?
Die in C implementierte Variante von Python könnte sich sicher theoretisch auf den etwas "fetteren" Steuerungen (die z. B. mit Linux laufen) irgendwie einbinden lassen - ich sehe da allerdings schon das Problem, dass Skriptsprachen üblicherweise nicht echtzeitfähig sind, die Garbage Collection kann mal leicht eine Zykluszeit sprengen. Und auch der RAM-Verbrauch ist ziemlich unberechenbar. Gerade auf kleineren Steuerungen sehe ich da keine Chance. Und dadurch, dass Python dynamisch typisiert ist, sind statische Codeüberprüfung und Sicherheitsgarantien bis hin zu CoDeSys Safety für Sprachen wie Python nicht leicht zu machen.
Vielleicht wäre da eine schlankere, statisch typisierte Sprache wie Pawn sinnvoller, aber dann kann ich auch gleich bei ST bleiben.
Beispiel mit dem Aufruf von Subversion.
Gruß,
Markus