TIA In welche Programmiersprache programmiert Ihr / optimimierte Bausteine

Erik1969

Level-2
Beiträge
28
Reaktionspunkte
4
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
mal ne Frage in die Runde:
In welcher Programmiersprache programmiert Ihr in TIA V15 und folgende Versionen
Benutzt Ihr optimierte Datenbaustein?
Benutzt Ihr noch irgenweleche "Leichen" aus Step5 oder Step7 ( Merker / S5 Timer / nicht optimierte DB`s)
benutzt Ihr Graph
auch mal bitte schreiben, warum Ihr z.B. in FUP programmiert und nicht in KOP (oder umgekehrt)
bitte keine Grundsatzdikussion.
danke für Eure Antworten
 
KOP, SCL und mittlerweile vor allem KOP mit SCL-NWs.
KOP weil wir überwiegend im Automotive unterwegs sind und es mir eh' leichter fällt.

Wir verwenden überwiegend die S7-1200, daher kein Graph.

Alles optimiert.
Insbesondere weil es mich zwingt, vollsymbolisch zu arbeiten.

Einzig noch Takt-/Systemmerker, die einmalig am Beginn des Zyklus in einen DB übertragen werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
SCL, KOP für erleichterte Wartung durch andere.
Anmerkung: Habe Siemens-AWL nie erlernt und komme damit auch nur bedingt zurecht.
Programmierung nur symbolisch, nicht optimierte Bausteine nur für Kommunikation mit Geräten, die dies zwingend erfordern wie externe PUT/GET-Zugriffe.
 
In welcher Programmiersprache programmiert Ihr in TIA V15 und folgende Versionen
Benutzt Ihr optimierte Datenbaustein?
... u.s.w. ...
bitte keine Grundsatzdikussion.
:unsure: Hmmm, das wird aber schwierig. Eigentlich fragst Du doch ziemlich gezielt nach GrundsatzEntscheidungen und sagst dann "bitte keine Grundsatzdikussion". Ich bin mal gespannt auf die Antworten ... ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zu einer Modernen Programmierung gehört es sicherlich,
soweit als möglich mit optimierten DB's zu arbeiten.
Die Verwendung von Symbolischen Variablen sollte Obligatorisch sein.
Den Kern meiner neu erstellten Programme schreibe ich in SCL (Funktionsmodule & Schrittketten).
Die Aufrufumgehung, sowie die Grundfunktionen normalerweise in KOP, auf Kundenwusch auch FUP
und in seltenen Fällen auch in SCL. GRAPH wird nur auf expliziten Kundenwunsch verwendet.
Anders ist dies allerdings bei (Teil-)Retrofit Projekten. Dort gilt zwar im Grundsatz prinzipiell
das Gleiche, jedoch werden teilweise aus Zeit und Kostengründen Programmteile migriert
und weiterverwendet (auch AWL).
Ich muß auch zugeben, dass ich nicht immer mit optimierten DB's arbeite.
Der Grund dafür ist zum einen die leichtere Bit <-> Byte Umsetzbarkeit und
zum Anderen die manchmal schnellere Umsetzbarkeit von Pointer-Aufgaben
mittels Hardware-Pointern.


Gruß


A.
 
Bei Bestandscode so weiter wie gehabt.

Neue Konzepte KOP+SCL, also KOP-Bausteine mit SCL-Netzwerken. Standardbausteine und Bibliotheken fast ausschließlich SCL.

Graph nur bei Kundenvorschrift oder gegen Aufpreis.

Bei Einzelanwendungen alles optimiert. Bei Serien werden DBs teilweise nicht optimiert angelegt, um per libnodave extern zugreifen zu können. Letzteres wird 2023 durch V17 und Web-Api abgelöst werden.

Schnittstellen zu Peripherie immer optimiert per UDT auf EA-Variablen oder per Getio/Setio in Byte-Arrays die dann umkopiert werden.
 
Schnittstellen zu Peripherie immer optimiert per UDT auf EA-Variablen oder per Getio/Setio in Byte-Arrays die dann umkopiert werden.
Grundsätzlich zu begrüßen, klappt aber nicht immer, da manche Geräte (an PROFINET/BUS) ein sehr merkwürdiges
Blockmapping haben. Ist zwar Gott seis gedankt nur eine minderheit, ist aber leider manchmal so.

Gruß

A.
 
Grundsätzlich zu begrüßen, klappt aber nicht immer, da manche Geräte (an PROFINET/BUS) ein sehr merkwürdiges
Blockmapping haben. Ist zwar Gott seis gedankt nur eine minderheit, ist aber leider manchmal so.

Gruß

A.
Ich verwende ohnehin immer Treiberbausteine, da kann man sich dann schon behelfen. Schräg waren immer die Lithium-Batterien mit 20 Bit Integerzahlen, 12 Bit gibt's da auch immer wieder.
 
"optimierte" EA-Adressen gibt es doch gar nicht?
Das stimmt schon, aber wir haben mal Versuche gemacht in Bezug auf Performance die suggerieren, dass boolsche EAs im Speicher in einer optimierten Form abgebildet werden.

Hintergrund war:
UDT für Ein- und Ausgänge angelegt, wobei innerhalb der UDTs ausschließlich Arrays zum Einsatz kamen (also Array [0..511] of Bool usw.) auch in PLC Variablentabellen mittels UDTs ddeklariert.
Dann Eingänge blockweise auf DB kopiert, Ausgänge blockweise von DB aus Ausgänge kopiert.
Legt man die DBs optimiert an, dann waren diese Schaufelvorgänge schneller als wenn die DBs nicht optimiert sind.
TIA V15.1, Firmware 2.6
 
Zuletzt bearbeitet:
Graph gegen Auspreis? das muss ich mei chef mal erzähler. Warum? ist es für euch soviel extra Aufwand?

Meinerseit ist mit optimiert oder nicht optimierte DB eigentlich scheiß egal.
Alle Standart Bausteinen sind aber nicht optimiert und neue DB lege ich an wie ich sie brauche.
Merker in der Regel nur die Systemmerker. Wenn ich Merker aber brauche verwende ich sie.
 
Das ist ja fast schon gemein bis hinterhältig! Da muss man ja wieder die Bits hin- und her-schieben bzw. maskieren, um sie in ein gängiges IntegerFormat (INT oder DINT) zu wandeln! :eek:
Naja. Das sind halt Batteriecontroller..... CAN-Bus, müllen den Bus zu mit Querverkehr der innerhalb der Batterieelektronik läuft, CANopen ist ein Fremdwort. Immerhin werden keine CAN-IDs von CANopen überladen.

Das mit den 20 Bits ist schon verständlich. 9 Werte wo 16 Bit zu wenig sind lassen sich so in 3 CAN-Frames packen, 32 Bit würden 5 CAN-Frames benötigen.

Und hinten am S7-Treiber kommen sowieso DINT oder UDINT raus
 
Zuletzt bearbeitet:
Graph gegen Auspreis? das muss ich mei chef mal erzähler. Warum? ist es für euch soviel extra Aufwand?
Graph macht aus meiner Sicht nur Sinn mit entsprechenden HMI-Mitteln wie Prodiag, iDesignerPro usw.
Muss ich ohnehin mit dem Programmiergerät und Step 7 ran, dann ist ein klassicher Ablauf mit SR-Gliedern genauso intuitiv zu diagnostizieren wie eine Graph-Kette. Zudem sind jene Dinge, die sich in unserer Branche mittels Schritt-Abläufen darstellen lassen, sehr begrenzt. Darunter fallen so Dinge wie das Bedienen eines Parameterkanals auf Profinet oder CANopen, das Lesen von Barcodes mit Kameras oder Codelesern, das senden eines Bauteildatentelegramms an ein MES-System.

Dass zu Zeiten, wo die meisten Schrittketten mit dutzenden Schritten mittels SPL in AWL gelöst wurden, sich viele Instandhalter Graph gewünscht haben, ist verständlich. Aber für so Dinge wie ich sie oben genannt habe ist CASE in einem SCL-Netzwerk für mich eher das Mittel der Wahl.

Um auf die Frage zurück zu kommen:
Da wir es faktisch nie machen, fehlt meinen Leuten dazu die Erfahrung, und damit leidet auch die Effizienz. Die Antwort lautet somit ja.

Habt Ihr da mal die performance geprüft?
Nein, haben wir nicht. Es geht auch nur darum, während der Inbetriebnahme 4-5 mal am Tag eine Tabelle aus 3 bis 180 Steuerungen zu lesen und zu verifizieren. Danach wird der Mechanismus alle 3-6 Monate mal gebraucht. Ob das jetzt pro Steuerung 1 Sekunde oder 20 Sekunden dauert ist im Grunde egal.
Aber das ist aus meiner Sicht der einzige Weg, um PUT/GET an den Steuerungen deaktivieren zu können. OPC-UA möchten wir nicht aktivieren, da es bei 300-400 Steuerungen pro Jahr doch erhebliche Lizenzkosten verursacht und ab V19 wohl auch das Lizenzenhandling arbeitsintensiv werden wird.

In Bezug auf Performance habe ich meinen obigen Beitrag noch ergänzt.
 
Graph macht aus meiner Sicht nur Sinn mit entsprechenden HMI-Mitteln wie Prodiag, iDesignerPro usw.
Muss ich ohnehin mit dem Programmiergerät und Step 7 ran, dann ist ein klassicher Ablauf mit SR-Gliedern genauso intuitiv zu diagnostizieren wie eine Graph-Kette.
Sorry, aber das ist schlichtweg falsch.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
mal ne Frage in die Runde:
In welcher Programmiersprache programmiert Ihr in TIA V15 und folgende Versionen
Benutzt Ihr optimierte Datenbaustein?
Benutzt Ihr noch irgenweleche "Leichen" aus Step5 oder Step7 ( Merker / S5 Timer / nicht optimierte DB`s)
benutzt Ihr Graph
auch mal bitte schreiben, warum Ihr z.B. in FUP programmiert und nicht in KOP (oder umgekehrt)
bitte keine Grundsatzdikussion.
danke für Eure Antworten
- KOP/SCL/Graph
- immer
- nein
- ja

KOP ist für mich leichter zu lesen.
 
Graph macht aus meiner Sicht nur Sinn mit entsprechenden HMI-Mitteln wie Prodiag, iDesignerPro usw.
Muss ich ohnehin mit dem Programmiergerät und Step 7 ran, dann ist ein klassicher Ablauf mit SR-Gliedern genauso intuitiv zu diagnostizieren wie eine Graph-Kette. Zudem sind jene Dinge, die sich in unserer Branche mittels Schritt-Abläufen darstellen lassen, sehr begrenzt. Darunter fallen so Dinge wie das Bedienen eines Parameterkanals auf Profinet oder CANopen, das Lesen von Barcodes mit Kameras oder Codelesern, das senden eines Bauteildatentelegramms an ein MES-System.
GRAPH gegen Aufpreis? Das ist aber schon lange her! Seit einer Umstellung (S7 2. Generation) von Siemens
(bin mir nicht sicher, meine aber es war so um 2005-2007) auf nur noch Professional Pakete (u.A. abschaffung der Mini Version)
sind sowohl GRAPH als auch SCL im Paket ohne Mehrpreis enthalten. Zugegeben Tools wie Prodiag und ähnliche
sind nach wie vor Kostenpflichtig (Teilweise sogar Runtimelizenzpflicht).

Zwar wird in Teilen der Autoindustrie GRAPH vorgeschrieben (meist mit Prodiag), allerdings sind nicht
alle Kunden bereit dafür (Prodiag o.ä.) zu bezahlen. Zugegeben die Diagnosemüglichkeiten sind
hervorragend, dass aber das eine oder andere mal eine größere CPU fällig wird (Zeit und Speicherbelastung)
ist dann wieder weniger schön.

Ich persönlich vermeide GRAPH wenn möglich. Dies liegt zum einen daran, dass ich in der S5 Version schlechte Erfahrungen
gemacht habe (zugegeben in TIA wesentlich besser) und zum anderen daran, dass ich mir selbst
Schrittketten-Steuermodule (Interpreter) geschrieben habe die sehr schnell sind und vergleichsweise
wenig Code benötigen. Schrittketten in S/R Technik verwende ich seit ca. 20 Jahren so gut wie nicht mehr.
Sicherlich neigt man bei schnellen Tests mit nur wenigen Schritten immmer wieder mal dazu diese zu verwenden
aber meist führt dies auf Grund von Inbetriebnahmehektik zum verbleib dieses Softwremüll's.

Meine Schrittketten sind alle in Vektortechnik (Schrittzahl/Nummer als Integervariable) programmiert.
Dies hat zwar den Nachteil, dass "UND" Verzweigungen nicht direkt möglich sind, sondern
Unterschrittketten zum Einsatz kommen müssen, jedoch den Vorteil einer besseren Übersicht und Diagnose.
GRAPH (Seit S7) und GRAPHSET arbeiten im Kern übrigens ähnlich.

Gruß

A.
 
Sorry, aber das ist schlichtweg falsch.
Begründung?

Wenn man SR-Glied Abläufe so schreibt, wie sie in der Schule bzw. in vielen Kursen gezeigt werden, gebe ich dir recht.
Wenn man sie so baut wie ich sie von meinen damaligen Kollegen und Chefs gelert habe, dann bleibe ich bei meinem Standpunkt.
 
Zuletzt bearbeitet:
Zurück
Oben