TIA Die erste große Anlage - Sinnvoll anfangen

DerTechpriester

Level-2
Beiträge
318
Reaktionspunkte
129
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Abend, liebe Forengemeinde.

Ich bin derzeit dabei, die erste größere Anlage (23 Baugruppen) zu programmieren. Bisher war ich in einem anderen Unternehmen eher der Kontrolleuer der Programme, nicht der Programmierer. Der Fluch und Segen gleichermaßen ist, dass ich hier komplett frei bin, solange es hinterher funktioniert.

Das Problem hierbei: Die Bestandsprogramme sind keine Hilfe, da hier nur mit direkter E/A Zuweisung und namenlosen Merkern plus ausschließlich UND/ODER gearbeitet wurde. Also weg damit. Das einzige, was mir bleibt, ist ein SPS Plan, welcher Ein/Ausgang für was ist. So weit, so gut.

Ich möchte die ganze Sache jetzt so Smart wie möglich anfassen. Ich hatte mir gedacht, die ganzen Förderbänder etc. wo es geht in bibliotheksfähigen Bausteinen einzurichten. Aber ich weiß nicht, wie ich meine knapp 300 I/Os händeln soll. Ich habe erst ein wenig mit benutzerdefinierten Datentypen experimentiert, aber dank der fest vorgegebenen Adressen war es ein Reinfall.

Wie verwaltet ihr eure I/Os? Ich könnte einfach bibliotheksfähige Bausteine direkt mit I/Os beschalten. Aber irgendwie wirkt mit dieser Schritt unelegant. (SCL fällt raus).
Ich würde alles gerne organisieren, aber habe außerhalb von Internet Tutorials bisher nur schlechte Stile gesehen.

Danke schonmal

Mit freundlichen Grüßen
Der Techpriester
 
Man könnte zum Beispiel ein UDT für ein Förderband erstellen, wo man Bereiche für Inputs, Outputs und was man sonst noch braucht, hat. In einem globalen DB könnte man zB. ein Array[..] of UDT erstellen, entsprechend der Anzahl der benötigten Förderbänder.
Das UDT kann man per InOut an dem Baustein übergeben.
Die Eingänge muss man natürlich an einer Zentralen Stelle einsammeln und dem entsprechendem UDT-Förderband zuweisen.
Das gleiche auch mit den Ausgängen. Die Zuweisung der Ein-/Ausgänge würde ich allerdings in SCL netzwerk machen.
 
Man könnte zum Beispiel ein UDT für ein Förderband erstellen, wo man Bereiche für Inputs, Outputs und was man sonst noch braucht, hat. In einem globalen DB könnte man zB. ein Array[..] of UDT erstellen, entsprechend der Anzahl der benötigten Förderbänder.
Das UDT kann man per InOut an dem Baustein übergeben.
Die Eingänge muss man natürlich an einer Zentralen Stelle einsammeln und dem entsprechendem UDT-Förderband zuweisen.
Das gleiche auch mit den Ausgängen. Die Zuweisung der Ein-/Ausgänge würde ich allerdings in SCL netzwerk machen.
So ähnlich hatte ich mir das auch gedacht. UDT für Förderbänder etc. Es haperte dann aber bei der InOut Übergabe und der Zuweisung der Hardwareeingänge. Ich würde jetzt ja sagen "Es geht nicht", aber wahrscheinlicher ist, dass mir (noch?) die Erfahrung mit UDTs, Arrays und SCL fehlt.
 
Wie ist überhaupt die Antriebstechnik gestaltet?
Wenn du jetzt FUs mit Bus-Anbindung könntest du schon einiges
damit erschlagen.
 
Fördertechnik ist ein richtig tolles Beispiel.
Wir haben mehrere Lieferanten für Fördertechnik.
Einige verwenden Bibliotheken, einige parametrisierte FBs, und einer programmiert Old-School.
Interessant ist, dass die Firmen mit Bibliotheken am längsten für die Inbetriebnahme brauchen und der Old-School-Kollege am schnellsten ist.
In den Bibliotheken sind jede Menge Varianten für Rollenbahnen. Teilweise gibt es Konfigurationen über Bits oder Modi ... Bei der Fehlersuche flucht die Instandhaltung jedesmal. Ist ja auch verständlich wenn 80% des Codes bei der betroffenen Rollenbahn oder Drehtisch für andere Modi sind. Visio ist das selbe. Für je Variante gibt es einen Bildbaustein in der Bibliothek.
Wenn eine Fördertechnik dein erstes großes Projekt ist, dann würde ich dir raten die Finger von Bibliotheken weg zu lassen. Mach es konventionell und sammle erstmal Erfahrung welche Funktionen und welche Sonderwünsche während der Inbetriebnahme noch auftauchen.
300 E/As sind überschaubar und nicht sonderlich viel bei Fördertechnik.
Und noch ein Ratschlag: Fördertechnik mit Und, Oder und ein paar Timern in KOP / FUP läuft meist deutlich besser als alles in SCL.
Fördertechnik gehört zu den meist unterschätzten Aufgaben in der Automatisierungstechnik. Ganz besonders wenn es Arbeitsplätze sind und Mitarbeiter an der Fördertechnik arbeiten. Also Montagebänder und Fertigungslinien.
 
Zuletzt bearbeitet:
Konventionell ohne viel Schnick & Schnack anfangen, im Laufe deiner Entwicklung wirst du immer mehr Erfahrungen sammeln und für dich entdecken, was man vereinfachen und verbessern könnte. Gerade die ersten Programme oder Anlagen haben zu Anfang noch deutlich Optimierungen seitens des Kunden, an Wünschen des Ablaufs etc., pp. Das kommt dann nach und nach.

Wenn du schon schreibst, dass die Instandhaltung danach daran Troubleshooten darf, die mögen es so simpel wie möglich. Die Kunst ist es nicht, ein Programm ans Laufen zu bekommen, sondern einfach und verständlich zu programmieren - dabei auch immer wichtig und nicht zu unterschätzen sind Kommentare, Netzwerkbeschriftungen sowie Variablenbeschriftungen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zuerst muss man ein wirklich gutes Konzept machen. Das heißt alles so weit wie möglich in kleine Probleme zerlegen bis man meint die großen schaffen zu können. Sind Prozesse dabei die du nicht kennst?

Gibt es irgendeine Art Standard? Erfahrungsgemäß ist einen Standard zu entwickeln sehr schwierig und zeitaufwendig. Außerdem geht das erste Projekt mit neuem Standard meistens in die Hose…
 
Konventionell ohne viel Schnick & Schnack anfangen, im Laufe deiner Entwicklung wirst du immer mehr Erfahrungen sammeln und für dich entdecken, was man vereinfachen und verbessern könnte. Gerade die ersten Programme oder Anlagen haben zu Anfang noch deutlich Optimierungen seitens des Kunden, an Wünschen des Ablaufs etc., pp. Das kommt dann nach und nach.
Eben, erst sollten ein paar Anlagen funktionieren bevor man sich an einen Standard macht.
Fängt man mit Bibliotheksbausteinen an, die nicht passen, kann eine Inbetriebnahme zum Chaos werden.
Gerade bei einer Fördertechnik.
 
Hallo,
aus 10-Jähriger Erfahrung im Bereich Neuerstellung und Warten fremder Programme kann ich dir sagen, dass für mich 2 Grundsätze zählen(und immer wieder auszahlen):
1. "Keep It Simpel and stupid."
2. "Programmieren ist binär."

1. Soll bedeuten die Kunst beim Programmieren besteht darin alles sehr verständlich zu schreiben. Komplexe Programme die wenig Code aber viel Schmalz benötigen sind eher schlechter zu debuggen, warten oder zu erweitern.

2. Programmiere die gleich Funktion nie mehr als 2x. Hast du 4 systemisch gleiche "Module" mach einen kleinen FC draus. das spart unheimlich Zeit.

VG und viel Spaß bei de Projekt.
 
Oft stellt sich auch heraus, daß die meisten "gleichen/Standard"-Förderstücke dann jedes eine andere Spezialfunktion hat
Genau … Und oft auch noch mehr als eine.
Selbst nach so vielen Jahren im Job, bin ich mir sicher, dass ich nicht alle Varianten kenne, die man sich zu einem Stück Fördertechnik ausdenken kann. Deshalb bevorzuge ich da auch ganz klassische Programmierung ohne viele FBs und FCs. Das ist nur einmal mehr Arbeit, gibt mir aber maximale Flexibilität. Und die ist bei uns wichtiger als 2 Tage bei der Programmerstellung gespart.
 
Genau … Und oft auch noch mehr als eine.
Selbst nach so vielen Jahren im Job, bin ich mir sicher, dass ich nicht alle Varianten kenne, die man sich zu einem Stück Fördertechnik ausdenken kann. Deshalb bevorzuge ich da auch ganz klassische Programmierung ohne viele FBs und FCs. Das ist nur einmal mehr Arbeit, gibt mir aber maximale Flexibilität. Und die ist bei uns wichtiger als 2 Tage bei der Programmerstellung gespart.

Der TE hat ja nur Förderbänder erwähnt… Wer weiss um was es sich tatsächlich im ganzen handelt.
Ich komme aus der Sparte Powertrain/E-Mobilitäts Montage. Viel montieren, fügen, schrauben, messen usw. Ich versuche alles was öfter als 1x mal an der Anlage vorkommt und auch nur ähnlich ist in FBs zu verpacken. Am besten in mehrere kleine Teilfunktionen die dann parametriert und zusammengestöpselt werden. Das macht das ausrollen von Änderungen deutlich einfacher. Eine Schraubstation ist eine Schraubstation, egal ob 10x Torx händisch angewunden oder 3x Innensechskant mit Zuführung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich würde die IOs nicht mit UDTs zusammenfassen. zu oft muss dann doch die Reihenfolge der IOs geändert werden und dann passt der UDT nicht mehr. Insbesondere, wenn er mehrfach verwendet wird.

Erst einmal nur Funktionen implementieren, die du brauchst. Also nicht unnötig was programmieren, was du vielleicht in ferner Zukunft brauchen könntest. Es sei denn, es kann bei einer wahrscheinlichen Diagnose helfen. Z.B. Status anzeige oder Fehlerbehandlung.

Globale Zugriffe auf DBs aus FCs und FBs meiden. Birgt oft die Gefahr, dass Werte unbeabsichtigt aus verschiedenen Quellen überschrieben werden. Ideal ist, wenn nach dem Kompilieren die Bausteine Bibliothek konform sind. Dies kann man unter den Eigenschaften des jeweiligen Bausteins auslesen. Wird bei jedem kompilieren geprüft.

Für simple häufig vorkommende Funktionen, macht es durchaus Sinn, einen FC oder FB anzulegen und die Sensoren an die Inputs zu legen und die Outputs auf die Aktuatoren zu legen. Habe das mal für Stoppereinheiten gemacht, weil die Anlage zig identische Stopper hatte.

Bei dem Aufbau der Bausteinen kann man sich auch an die PLCopen Beispielbausteine halten.

Bei komplexeren Funktionen würde ich den FB noch einen InOut Variable (UDTs definiert) mit Parametern mitgeben. Diese sind dann in einem Parameter_DB angelegt, damit nur dort Parameter eingetragen werden. So kann man auch mit Variablen zur Visualisierung im HMI umgehen.

Bei Bausteinen mit vielen Inputs und Outputs, die nicht immer alle beschaltet werden, kann man die IOs bei nicht verwenden ausblenden. Das bringt mehr Übersicht und lässt sich wenn man z.B. ein Input in der Schnittstelle selektiert hat unter Eigenschaften einstellen.

Bei IOs und anderen Variablen sinnvolle prägnante Bezeichnungen nutzen und mit Informationen anreichen (z.B. im Kommentar Einheiten, Funktion oder Betriebsmittkennzeichnung eintragen). Damit kann man die IOs im Schaltplan/-schrank schneller finden und sich besser in die Funktion einarbeiten. Du wirst dir später dafür danke, wenn du nach langer Zeit an der Anlage wieder Hand anlegst.

Sinnvoll sind bei Bausteinen auch die Kommentare an den IOs, wenn diese später als Bibliotheksbaustein (ins besondere Know How Protected) verwendet werden sollen. Da sie beim Schweben mit der Maus über dem Interface im Tooltip angezeigt werden.

Versuche dir einen einheitliche Stil beim Programmieren anzugewöhnen. Hier kann dir der Styleguide von Siemens ein ersten Ansatz/Inspiration sein. Test Suite bietet dir die Möglichkeit diesen auch zu prüfen, um so die Code Qualität zu erhöhen. Mann kann den von Siemens bereitgestellten Styleguide an die eigenen Vorlieben anpassen. Zudem bietet die Test Suite mittlerweile auch Möglichkeit um Unittests durch zu führen. Muss man aber abwägen, ob es sich lohnt.

Generell würde ich keine Programmiersprache ausschließen. Es gibt gute Gründe für KOP/FUP aber auch SCL. Genutzt wird das, was für den jeweiligen Fall die beste Implementierung und Analyse Fähigkeit bietet. KOP/FUP meist für reine Signal/Logikverschaltung, SCL für Rechnung und kleine State Maschines und Graph für Umfangreiche Schrittketten. Wobei Graph oft bei uns nicht gewünscht ist.
 
Erstmal Danke an alle für eure bisherigen Antworten. (y)
was ist daran "unelegant"? 🍿
Es schien mir einfach eleganter das Programm von der Hardware ein wenig zu trennen. Unsere Firma hat die Krankheit, alles irgendwie wiederverwenden zu wollen und immer wieder sehr ähnliche, modulare Maschinen aufzustellen. Die Programme sind jedes mal wieder gänzlich unterschiedlich.
wieviele sind denn die "ganzen"? Und sind die wirklich alle gleich?
Also derzeit sind es 20 Förderbahnen, die wirklich alle nichts besonderes sind. Mehr dazu beim 👉
Fördertechnik ist ein richtig tolles Beispiel.
Wir haben mehrere Lieferanten für Fördertechnik.
Einige verwenden Bibliotheken, einige parametrisierte FBs, und einer programmiert Old-School.
Interessant ist, dass die Firmen mit Bibliotheken am längsten für die Inbetriebnahme brauchen und der Old-School-Kollege am schnellsten ist.
In den Bibliotheken sind jede Menge Varianten für Rollenbahnen. Teilweise gibt es Konfigurationen über Bits oder Modi ... Bei der Fehlersuche flucht die Instandhaltung jedesmal. Ist ja auch verständlich wenn 80% des Codes bei der betroffenen Rollenbahn oder Drehtisch für andere Modi sind. Visio ist das selbe. Für je Variante gibt es einen Bildbaustein in der Bibliothek.
Wenn eine Fördertechnik dein erstes großes Projekt ist, dann würde ich dir raten die Finger von Bibliotheken weg zu lassen. Mach es konventionell und sammle erstmal Erfahrung welche Funktionen und welche Sonderwünsche während der Inbetriebnahme noch auftauchen.
300 E/As sind überschaubar und nicht sonderlich viel bei Fördertechnik.
Und noch ein Ratschlag: Fördertechnik mit Und, Oder und ein paar Timern in KOP / FUP läuft meist deutlich besser als alles in SCL.
Fördertechnik gehört zu den meist unterschätzten Aufgaben in der Automatisierungstechnik. Ganz besonders wenn es Arbeitsplätze sind und Mitarbeiter an der Fördertechnik arbeiten. Also Montagebänder und Fertigungslinien.
Ich verstehe. Ich habe hierbei den Vorteil, dass ich die alleinige Hoheit habe und "nur" meine Anlagen programmiere. Keine 200 Varianten. Wir sind der "Kunde", nicht der Maschinenbauer. Ich habe X wiederverwendete Bahnen die alle komplett eigene Programme besitzen obwohl sie nur in der Länge variieren. Daher sind auch Funktionen und Sonderwünsche klar ... rechts und links von der neuen Anlage stehen schon welche aus den 1970ern die exakt die gleichen Anlagenteile in anderer Anordnung verwenden.

Konventionell ohne viel Schnick & Schnack anfangen, im Laufe deiner Entwicklung wirst du immer mehr Erfahrungen sammeln und für dich entdecken, was man vereinfachen und verbessern könnte. Gerade die ersten Programme oder Anlagen haben zu Anfang noch deutlich Optimierungen seitens des Kunden, an Wünschen des Ablaufs etc., pp. Das kommt dann nach und nach.

Wenn du schon schreibst, dass die Instandhaltung danach daran Troubleshooten darf, die mögen es so simpel wie möglich. Die Kunst ist es nicht, ein Programm ans Laufen zu bekommen, sondern einfach und verständlich zu programmieren - dabei auch immer wichtig und nicht zu unterschätzen sind Kommentare, Netzwerkbeschriftungen sowie Variablenbeschriftungen.
Ja. Ich werde hier auch mein Bestes tun. Ich habe schon zu oft selbst vor schlecht oder gänzlich unkommentierten Programmen gesessen. Hier soll eine neue Funktion rein. Habe nach zwei Tagen basteln alles neu geschrieben. Aber genau darum geht es mir. Ich möchte mit Bausteinen das "einhausen" was eh niemand mehr anfassen wird. Fördertechnik Vor/Zurück/Stop. Sollte für die Instandhaltung ja gut sein, wenn Förderband XY ein Block ist der nur angesteuert werden muss. Die Instandhalter sind wie gesagt keine TIA Leute. Die können nur gucken ... wenn überhaupt.

Zuerst muss man ein wirklich gutes Konzept machen. Das heißt alles so weit wie möglich in kleine Probleme zerlegen bis man meint die großen schaffen zu können. Sind Prozesse dabei die du nicht kennst?

Gibt es irgendeine Art Standard? Erfahrungsgemäß ist einen Standard zu entwickeln sehr schwierig und zeitaufwendig. Außerdem geht das erste Projekt mit neuem Standard meistens in die Hose…
Es gibt einen Standard ... absolutes, unkommentiertes Chaos den teilweise nicht mal der Ersteller selbst noch lesen kann. Im Zweifel Reset-Taster.

Hallo,
aus 10-Jähriger Erfahrung im Bereich Neuerstellung und Warten fremder Programme kann ich dir sagen, dass für mich 2 Grundsätze zählen(und immer wieder auszahlen):
1. "Keep It Simpel and stupid."
2. "Programmieren ist binär."

1. Soll bedeuten die Kunst beim Programmieren besteht darin alles sehr verständlich zu schreiben. Komplexe Programme die wenig Code aber viel Schmalz benötigen sind eher schlechter zu debuggen, warten oder zu erweitern.

2. Programmiere die gleich Funktion nie mehr als 2x. Hast du 4 systemisch gleiche "Module" mach einen kleinen FC draus. das spart unheimlich Zeit.

VG und viel Spaß bei de Projekt.
Danke. So ist es auch geplant.
Zu den anderen Kommentaren: Sonderfunktionen bin ich zum Glück raus. Wie oben gesagt sind wir der Kundenbetrieb ... ich weiß genau, wie die Maschine aussieht und was sie tun soll. Ich werde auch nicht die gesamten Baugruppen zusammenfassen, nur so Geschichten wie "Band/Kette Vor/Zurück.
Der TE hat ja nur Förderbänder erwähnt… Wer weiss um was es sich tatsächlich im ganzen handelt.
Ich komme aus der Sparte Powertrain/E-Mobilitäts Montage. Viel montieren, fügen, schrauben, messen usw. Ich versuche alles was öfter als 1x mal an der Anlage vorkommt und auch nur ähnlich ist in FBs zu verpacken. Am besten in mehrere kleine Teilfunktionen die dann parametriert und zusammengestöpselt werden. Das macht das ausrollen von Änderungen deutlich einfacher. Eine Schraubstation ist eine Schraubstation, egal ob 10x Torx händisch angewunden oder 3x Innensechskant mit Zuführung.
👉Eine Verpackungsanlage. Die gekaufte Anlage wirft gerollte Stahlprofile auf ein Band, welche dann in kleine Bünde zusammengestapelt und umreift werden. Die Kleinbünde werden dann von einem Portalroboter (nix mit zu tun) gestapelt, umreift und als Großbund auf den Hof geschoben. Hat den Vorteil, dass keine filigrane Technik zum Einsatz kommt und alles viel einfacher ausgeführt ist, als es sich anhört. Der Großteil der Fördertechnik macht stumpf Dauerlauf, den Rest machen Stopper, Ausheber, Querschieber. Nur eine Baugruppe fährt auch mal rückwärts, eine fährt Start/Stopp. Können müssen es aber eh alle (Handbetrieb). Ich kann mit der SPS noch nicht mal die Band/Kettengeschwindigkeit regeln. Start. Stop. Rückwärts. Der Rest ist fest im Umrichter eingestellt ... in unserem Schrank fährt kein Bus ... aber das ist nicht mein Bier.
 
Zuletzt bearbeitet:
Ich würde die IOs nicht mit UDTs zusammenfassen. zu oft muss dann doch die Reihenfolge der IOs geändert werden und dann passt der UDT nicht mehr. Insbesondere, wenn er mehrfach verwendet wird.

Erst einmal nur Funktionen implementieren, die du brauchst. Also nicht unnötig was programmieren, was du vielleicht in ferner Zukunft brauchen könntest. Es sei denn, es kann bei einer wahrscheinlichen Diagnose helfen. Z.B. Status anzeige oder Fehlerbehandlung.
Davon bin ich dank dieses Threads hier auch schon abgerückt. Danke.
Globale Zugriffe auf DBs aus FCs und FBs meiden. Birgt oft die Gefahr, dass Werte unbeabsichtigt aus verschiedenen Quellen überschrieben werden. Ideal ist, wenn nach dem Kompilieren die Bausteine Bibliothek konform sind. Dies kann man unter den Eigenschaften des jeweiligen Bausteins auslesen. Wird bei jedem kompilieren geprüft.

Für simple häufig vorkommende Funktionen, macht es durchaus Sinn, einen FC oder FB anzulegen und die Sensoren an die Inputs zu legen und die Outputs auf die Aktuatoren zu legen. Habe das mal für Stoppereinheiten gemacht, weil die Anlage zig identische Stopper hatte.

Bei dem Aufbau der Bausteinen kann man sich auch an die PLCopen Beispielbausteine halten.

Bei komplexeren Funktionen würde ich den FB noch einen InOut Variable (UDTs definiert) mit Parametern mitgeben. Diese sind dann in einem Parameter_DB angelegt, damit nur dort Parameter eingetragen werden. So kann man auch mit Variablen zur Visualisierung im HMI umgehen.

Bei Bausteinen mit vielen Inputs und Outputs, die nicht immer alle beschaltet werden, kann man die IOs bei nicht verwenden ausblenden. Das bringt mehr Übersicht und lässt sich wenn man z.B. ein Input in der Schnittstelle selektiert hat unter Eigenschaften einstellen.
Danke für die Hinweise. Keine globalen Zugriffe ist klar. Dann hätte ich die selben Probleme, die mir die alten Programme auch bereiten.
Das mit dem Ausblenden wusste ich noch gar nicht. Thanks.
Bei IOs und anderen Variablen sinnvolle prägnante Bezeichnungen nutzen und mit Informationen anreichen (z.B. im Kommentar Einheiten, Funktion oder Betriebsmittkennzeichnung eintragen). Damit kann man die IOs im Schaltplan/-schrank schneller finden und sich besser in die Funktion einarbeiten. Du wirst dir später dafür danke, wenn du nach langer Zeit an der Anlage wieder Hand anlegst.

Sinnvoll sind bei Bausteinen auch die Kommentare an den IOs, wenn diese später als Bibliotheksbaustein (ins besondere Know How Protected) verwendet werden sollen. Da sie beim Schweben mit der Maus über dem Interface im Tooltip angezeigt werden.

Versuche dir einen einheitliche Stil beim Programmieren anzugewöhnen. Hier kann dir der Styleguide von Siemens ein ersten Ansatz/Inspiration sein. Test Suite bietet dir die Möglichkeit diesen auch zu prüfen, um so die Code Qualität zu erhöhen. Mann kann den von Siemens bereitgestellten Styleguide an die eigenen Vorlieben anpassen. Zudem bietet die Test Suite mittlerweile auch Möglichkeit um Unittests durch zu führen. Muss man aber abwägen, ob es sich lohnt.

Generell würde ich keine Programmiersprache ausschließen. Es gibt gute Gründe für KOP/FUP aber auch SCL. Genutzt wird das, was für den jeweiligen Fall die beste Implementierung und Analyse Fähigkeit bietet. KOP/FUP meist für reine Signal/Logikverschaltung, SCL für Rechnung und kleine State Maschines und Graph für Umfangreiche Schrittketten. Wobei Graph oft bei uns nicht gewünscht ist.
Namen und Kommentare braucht doch keiner. :D Spaß. Ich versuche immer alles wenn möglich in Diagrammen und Grafcets festzuhalten. Den Styleguide muss ich mir unbedingt mal ansehen.
Ich muss SCL und Graph ausschließen. SCL habe ich noch nie verwendet oder im Einsatz gesehen (ich beherrsche aber C und Python, also reine Fleißaufgabe), aber außer mir wird das niemals irgendjemand verstehen im Unternehmen. Graph muss ich ausschließen, da meine 1200 das nicht beherrscht. ;)

Danke für eure Ratschläge und Anregungen.
 
Zurück
Oben