TIA AWL Unterschiede S7-1500 zu S7-300

Zuviel Werbung?
-> Hier kostenlos registrieren
Hi

dieser Thread liefert 20 Gründe sofort mit AWL aufzuhören und das Programm in SCL zu schreiben.

'n schön' Tach auch
HB

Wäre schön, wenn du wenigstens einen der angeblich 20 Gründe mal ausführlicher begründen würdest.

Es ging hier im Wesentlichen um das Verständnis der Grundlagen von Pointern, nicht um Sprachen.
 
Es ging hier im Wesentlichen um das Verständnis der Grundlagen von Pointern, nicht um Sprachen.
Der Ursprungs-Thread ging aber um die Schreibweise bei einer S7-1500 und dort gibt es bei korrekter Programmierweise (optimierte Bausteine) sowieso keine Pointer mehr.
Und bei einer S7-1500 kann man in der Tat, in SCL so einiges sehr viel besser, schneller und übersichtlicher lösen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Ursprungs-Thread ging aber um die Schreibweise bei einer S7-1500 und dort gibt es bei korrekter Programmierweise (optimierte Bausteine) sowieso keine Pointer mehr..

Wenn es bei optimierten Bausteinen keine Pointer mehr gibt, ist das ein gravierender Nachteil für Aufgaben, die sich ohne Pointer nur sehr umständlich lösen lassen.

Und bei einer S7-1500 kann man in der Tat, in SCL so einiges sehr viel besser, schneller und übersichtlicher lösen.

Dann zeig doch mal, wie sich die Aufgabe hier ( Funktion, die ein Bitfeld nach gesetzten Bits absucht) in SCL sehr viel besser, schneller und übersichtlicher lösen lässt.
 
Dann zeig doch mal, wie sich die Aufgabe hier ( Funktion, die ein Bitfeld nach gesetzten Bits absucht) in SCL sehr viel besser, schneller und übersichtlicher lösen lässt.

Ich würde mich nicht darauf versteifen, das Verfahren was du bisher hattest genau so umzusetzen.
Was ist dieses "Bitfeld"? SCL versteht sich am besten auf Arrays, d.h. ein Bool- oder Word-Array kannst du damit sehr einfach verarbeiten. Vielleicht kannst du dein "Bitfeld" auch in ein Array umwandeln.

Ich vermute aber, das ist eine Funktion welches in diversen hintereinanderliegenden unstrukturierten Word/Int Variablen prüft ob ein Bit gesetzt ist, um daraus eine Sammelstörung zu generieren. Das kann man auch grundsätzlich anders lösen, z.B. in dem der Antriebsbaustein oder was auch immer einen Ausgang für ein Sammelstörbit gleich mitbringt. Dann füge ich n Antriebe hinzu und alles funktioniert direkt, d.h. das Programm ist modular, ohne dass ich irgendwelche weiteren Funktionen anpassen muss.
 
Ich denke mir bei solchen Dingen immer, wie wurde das bisher in Codesys gelöst. Hierfür musste es auch eine Lösung geben sonst wären hier auch ganz schnell stimmen laut geworden.
Also kann ich der Frage Über die richtige Methode nur beipflichten

Gesendet von meinem SM-G930F mit Tapatalk
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich denke mir bei solchen Dingen immer, wie wurde das bisher in Codesys gelöst. Hierfür musste es auch eine Lösung geben sonst wären hier auch ganz schnell stimmen laut geworden.
Das ist in erster Linie mal ein psychologisches Problem ... Vielleicht geht der typische Codesys Programmierer mit einer etwas offeneren Denkweise an die Sache ran,
als der "nur" Siemens-Programmierer, der auf Biegen und Brechen auch heute noch Sachen verteidigt, die zu S5-Zeiten schon Murks waren.

Unter der Voraussetzung das du der TE sein Bitfeld auf ein Array Ummünzen kann, hier mal ein Beispiel in SCL:

Code:
iBitsum := 0 ;
iBitnum := 0 ;
FOR iSchleife := iAnfang TO iEnde By 1 DO
//Zähler der Ein-Bits
   IF aBitfeld[iSchleife] THEN
       iBitsum := iBitsum + 1 ;
   END_IF;

//Nummer des ersten Bits
   IF iBitnum := 0 AND aBitfeld[iSchleife] THEN
       iBitnum := iSchleife ;
   END_IF;
END_FOR;

Bei beiden Varianten gibt es keine Problem mit optimierten DBs, noch dieses Gehampel mit AR etc.

Mfg
Manuel
 
Also auch wenn's nicht direkt was mit dem Thema zu tun hat, finde ich das "optimiert" nicht per se "richtig" bedeutet!
Da stimme ich dir zu, aber groß S will uns dazu bringen.
Und du wirst sehen, dass sich auf kurz oder lang alle Siemens Lösungen auf diese Einstellung beziehen.
Auf meine letzte Suport Anfrage kam auch die Antwort: "Ja sie müssen halt den Baustein auf optimiert setzen und es dann so uns so machen.
Da wurde mir keine Alternative angeboten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich finde das eigentlich sehr gut. So kann ich meine Programme ohne großen Stress auch auf andere Plattformen umziehen und bin nicht mehr an Siemens gebunden. Will ein Kunde eine Codesys Steuerung, dann bekommt er sie. Programm funktioniert da auch, einmal abtippen muss ich es halt. Aber das ist Fleißarbeit.

Gesendet von meinem SM-G930F mit Tapatalk
 
Also auch wenn's nicht direkt was mit dem Thema zu tun hat, finde ich das "optimiert" nicht per se "richtig" bedeutet!

Obwohl ich voll symbolisch arbeite, lassen sich viele Anwendungen mit optimierten Einstellungen nur schwer lösen.
Nimmt man Kopplungen Leit- und Fertigungssteuerungssytemen oder inteligenten Mess- und Prüfsystemen, dann stößt man sehr schnell an die Grenzen von "optimiert".
Arbeit man dazu noch mit Sichten (AT), dann wirds auch schwierig.

Mein Fazit zu den optimierten DBs:
"Gut gemeint ist das Gegenteil von gut-gemacht"

Gruß
Blockmove
 
Ich würde mich nicht darauf versteifen, das Verfahren was du bisher hattest genau so umzusetzen.
Was ist dieses "Bitfeld"? SCL versteht sich am besten auf Arrays, d.h. ein Bool- oder Word-Array kannst du damit sehr einfach verarbeiten. Vielleicht kannst du dein "Bitfeld" auch in ein Array umwandeln.

Ein Bitfeld kann ein ARRAY of BOOL sein, muss aber nicht. Kann auch irgendeine andere Variable sein. Es ist eine Betrachtungsweise unabhängig von der Deklaration.

Damit es unabhängig ist, brauche ich den ANY-Pointer zur Parameterübergabe. Und warum sollte ich mit Arrays arbeiten, wenn ich schon einen Pointer habe? Technisch gesehen arbeitet sowieso jede Arraybearbeitung mit Pointern, das zu vertuschen bringt nur etwas für Leute, die mit Pointern auf Kriegsfuß stehen.

Ich vermute aber, das ist eine Funktion welches in diversen hintereinanderliegenden unstrukturierten Word/Int Variablen prüft ob ein Bit gesetzt ist, um daraus eine Sammelstörung zu generieren. Das kann man auch grundsätzlich anders lösen, z.B. in dem der Antriebsbaustein oder was auch immer einen Ausgang für ein Sammelstörbit gleich mitbringt. Dann füge ich n Antriebe hinzu und alles funktioniert direkt, d.h. das Programm ist modular, ohne dass ich irgendwelche weiteren Funktionen anpassen muss.

Ich brauch die Funktion zB, um von einem Peripherieblock eines Gebläses aus einzelnen Bits Alarm-, Warnungs- und Wartungsnummern zu generieren. Die werden dann auf einem PC mit einem dazugehörigen Text versehen, angezeigt und in eine Logdatei geschrieben. Es gibt in dem Block zwar auch ein Sammelstörungsbit, aber das ist mir nicht detailliert genugl.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich brauch die Funktion zB, um von einem Peripherieblock eines Gebläses aus einzelnen Bits Alarm-, Warnungs- und Wartungsnummern zu generieren. Die werden dann auf einem PC mit einem dazugehörigen Text versehen, angezeigt und in eine Logdatei geschrieben. Es gibt in dem Block zwar auch ein Sammelstörungsbit, aber das ist mir nicht detailliert genugl.

Tja bei genau diesen Anwendungen ärgere ich mich nicht mehr mit Any-Pointern rum.
Das geht in der Regel wunderbar mit einer Sicht und funktioniert in TIA auch in KOP/FUP.
Hier hat TIA wirklich Vorteile. Man muss halt nur die alten Zöpfe mal abschneiden.

Gruß
Blockmove
 
Das ist in erster Linie mal ein psychologisches Problem ... Vielleicht geht der typische Codesys Programmierer mit einer etwas offeneren Denkweise an die Sache ran,
als der "nur" Siemens-Programmierer, der auf Biegen und Brechen auch heute noch Sachen verteidigt, die zu S5-Zeiten schon Murks waren.

Ich bin kein "nur" Siemens-Programmierer, komme aus der PC-Programmierung (C,C++) . AWL ist bei Siemens-SPSen nun mal die Sprache, mit der man alles machen kann. Murks kann man natürlich auch damit machen, aber ich brauch keinen Kindergarten, der alles gefährliche von mir fernhält.


Unter der Voraussetzung das du der TE sein Bitfeld auf ein Array Ummünzen kann, hier mal ein Beispiel in SCL:

Code:
iBitsum := 0 ;
iBitnum := 0 ;
FOR iSchleife := iAnfang TO iEnde By 1 DO
//Zähler der Ein-Bits
   IF aBitfeld[iSchleife] THEN
       iBitsum := iBitsum + 1 ;
   END_IF;

//Nummer des ersten Bits
   IF iBitnum := 0 AND aBitfeld[iSchleife] THEN
       iBitnum := iSchleife ;
   END_IF;
END_FOR;

Das ist ein Code-Schnipsel, aber noch keine Funktion. Wenn ich das 20 mal in einem Programm brauche, will ich nicht 20 mal das selbe Geraffel nur mit anderen Namen schreiben.

Code:
 CALL FCScanBits( Bitfeld:=#PE.Stoerbit1, von:= 0, bis :=80, Bitnum:=#Stoernum);
ist da bedeutend kürzer und übersichtlicher. Für eine Funktion brauche ich aber einen ANY-Pointer zur Parameterübergabe und den in ein Array umzusetzen ist so umständlich, dass sich die Vorzüge von SCL nicht lohnen.

Bei beiden Varianten gibt es keine Problem mit optimierten DBs, noch dieses Gehampel mit AR etc.

Mfg
Manuel


Da die sogenannten "optimierten" Bausteine nur von Siemens-Software gelesen werden können, sind sie für mich eh uninteressant. Das "Gehampel mit AR" ist kein Problem für mich.
 
AWL ist bei Siemens-SPSen nun mal die Sprache, mit der man alles machen kann.

Stimmt bei der 1500er aber nur noch bedingt, da ihr ja etliche Register fehlen, die vom System bei Verwendung von AWL per Software nachgebildet werden. Das kostet Zeit und erfordert einige Klimmzüge wenn man aus AWL Code auf Bausteine in z.B. FUP zugreifen möchte.

Von irgendwas mit Internetzugang gesendet.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich bin kein "nur" Siemens-Programmierer, komme aus der PC-Programmierung (C,C++) . AWL ist bei Siemens-SPSen nun mal die Sprache, mit der man alles machen kann. Murks kann man natürlich auch damit machen, aber ich brauch keinen Kindergarten, der alles gefährliche von mir fernhält.
Getroffene Hunde sollen ja besonders laut bellen :ROFLMAO:

Zu AWL: Das ist bei der 1500er lediglich noch, eine emulierte Ebene, die mehr oder minder ausschließlich Kompatibilitätsgründen am Leben gehalten wird / bzw. überhaupt erst eingeführt wurde,
und auch in etlichen Details nicht so kompatibel ist wie man es vielleicht hätte erwarten können und müssen.
D.H. Die Statusregister, Akkus, ARs ... alles ist nur noch emuliert, und nicht mehr Prozessornah.
Wobei der weitaus schwerwiegendere Fakt (für micht) ist: AWL gibt es auf der 1200er überhaupt nicht (auch wenn da sicherlich ein wenig Politik mitschwingt).

Für eine volle Funktion in deinem Sinne müsst man halt evtl. noch serialize/deserialize, um variabler zu verwenden, einziger Nachteil, man müsste sich halt auf eine Maximalgröße im Sinne der Datenmenge festlegen.
https://support.industry.siemens.com/cs/de/de/view/42603881

Ist mir ja aber im Prinzip eh egal, wenn du eh nur dein Schema F weitermachen willst, bitte schön, ich werde dich sicherlich nicht aufhalten wollen.
Nur darfst du dich halt dann auch nicht beschweren, wenn du knapp oberhalb der Prozessorebene agierst, das du an Tagen wie diesen, dann auch deine ganzen Funktionen umbasteln musst.
 
Zurück
Oben