Mrtain
Level-2
- Beiträge
- 845
- Reaktionspunkte
- 390
-> Hier kostenlos registrieren
Willkommen in der TIA-Hoelle
- Ersteller Techpriester
- Erstellt am
-> Hier kostenlos registrieren
Mrtain
Level-2
- Beiträge
- 845
- Reaktionspunkte
- 390
Wahrscheinlich schon....
Mrtain
Level-2
- Beiträge
- 845
- Reaktionspunkte
- 390
-> Hier kostenlos registrieren
Ja, kenn ich. Deswegen versuche ich, die Dinge kurz zu halten.
Aber zig und / oder Verknüpfungen in einem Netzwerk machen es meiner Erfahrung auch nicht überschaubarer.
- Beiträge
- 2.645
- Reaktionspunkte
- 774
Hört sich an nach ein versautes Standart Programm wo alles drin ist und jeder schon jahrenlang reingekotzt hat.
Sind euer Anlagen da so groß das ein neu schreiben mehr Zeit kost?
Sind euer Anlagen da so groß das ein neu schreiben mehr Zeit kost?
Draco Malfoy
Level-1
- Beiträge
- 1.168
- Reaktionspunkte
- 82
Erst mal müssen ja die „erfahrenen Herren“ in Rente gehen, sonst sorgen die schon dafür, daß der Kollege dort nicht mehr arbeitet. Wie groß ist eure E-Konstruktion Abteilung ?
gerribaldi
Level-2
- Beiträge
- 88
- Reaktionspunkte
- 15
-> Hier kostenlos registrieren
Ich probiere es mal zu erklären. Es gab zwei Varianten dieser Funktion. Bei beiden Varianten sind folgende Bedingungen immer gleich:
Wir hatten in unsere Maschinen mehrere SPSen verbaut. Diese haben alle mit einer zentralen SPSen kommuniziert, welche für die u.a. Achsensteuerung zuständig war. Zusätzlich habe alle SPSen auch noch mit einem normalen PC [PC-1] kommuniziert, auf dem noch ein Stück Software lief, wo u.a. die ganze Kommunikation verwaltet hat. Zusätzlich lief auf diesem PC auch ein weiteres Stück Software, welche Einstellungen und Parameter wo der Benutzer an der Visualisierung eingegeben hat, hinterlegt wurden. Fehlermeldesystem inkl. der historischen Datenbank lief auf einem weiteren PC.
V1: Kommunikation via Arcnet. Hier wurde auf dem PC-1 ein Textfile hinterlegt, in dem man mit Hilfe von Dezimalwerten angeben konnte, ob bzw. welche Funktion vorhanden ist. In dem Textfile konnte man in zu Beginn anhand eines Headers festlegen, für welches Steuerung das File gedacht war. Die Software auf PC-1 hat diese Textfiles bei jedem Neustart neu eingelesen. Dieses Textfile musste für jede SPS vorhanden sein.
Werte wo der Benutzer aus an der Visu eingegeben hat, wurden direkt in die SPS geschickt und auch an PC-1 -> auf diesem auch gesichert. Nach einem Neustart der SPS hat die bei PC-1 nachgefragt und alle notwendigen Einstellungen/Parameter wieder geholt.
V2: Kommunikation via Ethernet und UDP. Hier war es im Prinzip genauso, nur dass die Datei anders aufgebaut war. Hier wurde nicht mehr mit Dezimalwerten gearbeitet, sondern mit Variablennamen. Das war dann soweit durchstrukturiert, dass man mit einer zentralen Konfig-Datei die Funktion und Konfiguration von zig verschiedenen SPSen steuern und beeinflussen konnte. Hier wurden die Dateien zur Laufzeit eingelesen bzw. wenn der IBN-Mensch vor Ort dies angestoßen hat.
Hier wurde dann auch alle innerhalb der SPS konsequent mit FBs realisiert, die dann so oft aufgerufen wurden, wie eine Funktion vorhanden war. Dies war bei V1 noch nicht ganz so ausgeprägt
Werte wo der Benutzer aus an der Visu eingegeben hat, wurden auch hier direkt in die SPS geschickt und auch an PC-1 -> auf diesem auch gesichert. Nach einem Neustart der SPS hat die bei PC-1 nachgefragt und alle notwendigen Einstellungen/Parameter wieder geholt. Wurde die SPS einen anderen Rechner zugeordnet, konnte man so auch die Werte von dort holen, Bsp PC-2.
Von Prinzip kannst du dir das wirklich wie ein File- oder DB-Server vorstellen, der die Werte zur VErfügung gestellt hat und auf dem man auch Werte ablegen konnte.
Noch ein Hinweis zum Abschluss
Codeform der SPS war immer ST (vereinzelt FUP), es war KEINE Siemens Steuerung im Einsatz! Bei Neuanlagen hatten wir seit ca. 1998 kein AWL mehr im Einsatz, was jetzt schon über 20 Jahre sind. Von daher habe ich teilweise kein Verständnis dafür, dass sich noch immer so viele Leute an diesem grauenhaften AWL festhalten.... :???::roll::???::roll:
- Beiträge
- 2.645
- Reaktionspunkte
- 774
Draco Malfoy
Level-1
- Beiträge
- 1.168
- Reaktionspunkte
- 82
Ich meinte eher denjenigen, der sich hier über die veralteten Programmierweisen beschwert hat.
OP
Techpriester
Level-1
- Beiträge
- 8
- Reaktionspunkte
- 0
-> Hier kostenlos registrieren
MoinMoin.
Danke, für die Antworten.
Als allererstes: Ich bringe (zumindest derzeit) keinen neuen Stil mit rein. Ich bin Technologe und QS-Mann der sich ein wenig mit SPS auskennt. Mein mein Job ist es, die Maschinen zu kennen, nicht sie zu programmieren. Ich versuche auch nicht die Geschäfts- oder Abteilungsleitung zu nerven. Die Abteilungsleitung ist E-Konstrukteur und findet gut, wie es derzeit läuft. Ich agiere nicht als "verärgerter Nachwuchsprogrammierer" sondern im Auftrag einer neuen Geschäftsleitung, die, anders als die alte, genau weiß, dass in der Programmierung das Chaos herrscht.
Beispiel: Service will eine Lichtschranke nachrüsten. Der "freie Eingang" der gewählt wird, arbeitet aber bereits eine inexistente Schutzeinrichtung ab. Hierdurch kommt es später zu "unerklärlichen Maschinenstillständen". Die Maschine hält einfach ohne Störmeldung an, weil sie denkt, jemand hat manuell Einlass ins Schutzgitter angefordert. Der Fehler tritt aber nur sporadisch auf, da die LS oftmals wieder frei wird, BEVOR die Anlage endgültig herunterfährt. Danach fährt ein weiteres Serviceteam von Norddeutschland fast nach Slowenien runter, weil keiner einen Plan hat, was los ist. Kurz drauf musste dann auch die Technologieabteilung mit, weil die zweite Produktionslinie sich später gleich mit verabschiedet hatte. Es ist leider kein Spaß, wenn in der Großindustrie deine nicht abgenommene Anlage plötzlich spastische Anfälle entwickelt und Service und Fernwartung im Dunkeln tappen...
MfG
Danke, für die Antworten.
Als allererstes: Ich bringe (zumindest derzeit) keinen neuen Stil mit rein. Ich bin Technologe und QS-Mann der sich ein wenig mit SPS auskennt. Mein mein Job ist es, die Maschinen zu kennen, nicht sie zu programmieren. Ich versuche auch nicht die Geschäfts- oder Abteilungsleitung zu nerven. Die Abteilungsleitung ist E-Konstrukteur und findet gut, wie es derzeit läuft. Ich agiere nicht als "verärgerter Nachwuchsprogrammierer" sondern im Auftrag einer neuen Geschäftsleitung, die, anders als die alte, genau weiß, dass in der Programmierung das Chaos herrscht.
Den Nagel auf den Kopf getroffen. Jahrelang wird das selbe Programm benutzt und beliebig erweitert und gestutzt. Problematisch ist hierbei, dass es sich um große Anlagen mit 10+ einzelmaschinen handelt mit jeweils gefühlt 100 Varianten, die alle im Programm eingepflegt sind und wenn sie nicht gebraucht werden, via Testmerker o.ä. totgelegt werden. Besonders schlimm sind dann so Situationen, in denen eine Fräsanlage nach einer Nachrüstung rumspinnt, weil die Eingänge bereits anderweitig abgearbeitet werden.
Beispiel: Service will eine Lichtschranke nachrüsten. Der "freie Eingang" der gewählt wird, arbeitet aber bereits eine inexistente Schutzeinrichtung ab. Hierdurch kommt es später zu "unerklärlichen Maschinenstillständen". Die Maschine hält einfach ohne Störmeldung an, weil sie denkt, jemand hat manuell Einlass ins Schutzgitter angefordert. Der Fehler tritt aber nur sporadisch auf, da die LS oftmals wieder frei wird, BEVOR die Anlage endgültig herunterfährt. Danach fährt ein weiteres Serviceteam von Norddeutschland fast nach Slowenien runter, weil keiner einen Plan hat, was los ist. Kurz drauf musste dann auch die Technologieabteilung mit, weil die zweite Produktionslinie sich später gleich mit verabschiedet hatte. Es ist leider kein Spaß, wenn in der Großindustrie deine nicht abgenommene Anlage plötzlich spastische Anfälle entwickelt und Service und Fernwartung im Dunkeln tappen...
Wir haben in der E-Kontruktion 3,5 Mitarbeiter und 3+(2x0,5) SPS Programmierer (3,5 und 4 weil ein E Planer zum Teil auch als SPS-Aushilfe arbeitet und ein weiterer SPS Mann eigentlich ein zweckentfremdeter Serviceprogrammierer ist. Sie sind heillos überfordert da sie sowohl Neuanlagen und Fernwartung machen. Wir haben auch Einrichter mit SPS Ausrüstung, die können aber höchstens mal einen Eingang ändern. Eine Zeile AWL und sie schmeißen den Laptop weg.
MfG
Mrtain
Level-2
- Beiträge
- 845
- Reaktionspunkte
- 390
Kenn ich nur zu gut... Und dann diskutiert mit dem Vertrieb, was Standard ist und was nicht...
Aber grundsätzlich sollten Komponenten, die nicht vorhandenen sind, nicht im Programm sein. Oder zumindest deaktiviert.
Nur der Interesse halber, in welcher Branche seid ihr tätig?
Zuletzt bearbeitet:
- Beiträge
- 16.497
- Reaktionspunkte
- 6.100
Mann könnte das Pferd auch einmal andersherum aufzäumen.
Ist die E-Konstruktion wirklich so unfähig oder will nicht?
Oder liegt es an der Geschäftsführung die nicht weiß was Sie will
oder wie Ziele aussehen was Entwickelt werden soll.
Wenn die E-Konstruktion schon seit gestern so überlastet ist liegt
das nicht an ihnen selber!
Ist die E-Konstruktion wirklich so unfähig oder will nicht?
Oder liegt es an der Geschäftsführung die nicht weiß was Sie will
oder wie Ziele aussehen was Entwickelt werden soll.
Wenn die E-Konstruktion schon seit gestern so überlastet ist liegt
das nicht an ihnen selber!
-> Hier kostenlos registrieren
Positiv ist, dass die Geschäftsleitung das Problem offensichtlich erkannt hat.
Wie die Software so geworden ist, kann ich nur vermuten. Ich gehe mal davon aus, dass die Programmierer irgendwann keine Lust mehr hatten bei jedem Projekt wieder Dinge in die Software einzubauen, die dann beim nächsten mal wieder raus müssen, dann wieder rein, dann wieder raus, dann wieder anders, dann wieder rein....da ist es einfacher alles drinzulassen und dann Projektabhängig zu aktivieren. Wenn man das richtig macht, dann kann das bestimmt funktionieren und ist weniger Arbeit. Ab einer bestimmten Komplexität, kann man es anders gar nicht mehr handhaben.
Ich habe das vor vielen Jahren auch begonnen in einem Teil unserer Software zu machen. Ich habe damit nur gute Erfahrungen gemacht. Aber es erfordert viel Disziplin. Man muss sehr aufpassen, wenn man etwas ändert. Quick&Dirty fürs aktuelle Projekt ist das nicht mehr.
Die Frage ist natürlich auch, wieso immer so viele Varianten vom gleichen existieren. Das kann ja wieder verschiedene Ursachen haben. Ich habe oft den Eindruck, dass außerhalb der Softwareabteilungen niemanden klar ist, wie komplex die Auswirkungen kleinster Änderungen sein können. Da meint es jemand gut und erzeugt damit Chaos.
Darf ich fragen auf welcher Plattform das ganze läuft?
Wie die Software so geworden ist, kann ich nur vermuten. Ich gehe mal davon aus, dass die Programmierer irgendwann keine Lust mehr hatten bei jedem Projekt wieder Dinge in die Software einzubauen, die dann beim nächsten mal wieder raus müssen, dann wieder rein, dann wieder raus, dann wieder anders, dann wieder rein....da ist es einfacher alles drinzulassen und dann Projektabhängig zu aktivieren. Wenn man das richtig macht, dann kann das bestimmt funktionieren und ist weniger Arbeit. Ab einer bestimmten Komplexität, kann man es anders gar nicht mehr handhaben.
Ich habe das vor vielen Jahren auch begonnen in einem Teil unserer Software zu machen. Ich habe damit nur gute Erfahrungen gemacht. Aber es erfordert viel Disziplin. Man muss sehr aufpassen, wenn man etwas ändert. Quick&Dirty fürs aktuelle Projekt ist das nicht mehr.
Die Frage ist natürlich auch, wieso immer so viele Varianten vom gleichen existieren. Das kann ja wieder verschiedene Ursachen haben. Ich habe oft den Eindruck, dass außerhalb der Softwareabteilungen niemanden klar ist, wie komplex die Auswirkungen kleinster Änderungen sein können. Da meint es jemand gut und erzeugt damit Chaos.
Darf ich fragen auf welcher Plattform das ganze läuft?
- Beiträge
- 11.614
- Reaktionspunkte
- 3.874
Ich bring hier mal noch einen weiteren Spieler auf's Feld:
Der Kunde mit seiner Instandhaltung.
Wir als Kunde fordern das SPS-Programm ohne Bausteinschutz oder ähnliches.
Kommt die Instandhaltung nicht mit dem SPS-Programm zurecht, dann kann das durchaus Folgen haben.
Aufgrund von negativen Erfahrungen wurden und werden die Liefervorschriften (und ich denke nicht nur bei uns) immer weiter verschärft.
Mittlerweile musste der erste Lieferant seine Software komplett neu schreiben.
Ein anderer Lieferant hatte aufgrund seiner Software so ein mieserables Scoring, dass er jahrelang keine Anlage mehr an uns verkauft hat.
Erst nachdem er seine Standardsoftware überarbeitet hat, kam er wieder zum Zug.
Fazit:
Die Ausführung von Hard- und Software ist auch ein Verkaufsargument ... Zumindest für Folgeanlagen.
Gruß
Blockmove
Der Kunde mit seiner Instandhaltung.
Wir als Kunde fordern das SPS-Programm ohne Bausteinschutz oder ähnliches.
Kommt die Instandhaltung nicht mit dem SPS-Programm zurecht, dann kann das durchaus Folgen haben.
Aufgrund von negativen Erfahrungen wurden und werden die Liefervorschriften (und ich denke nicht nur bei uns) immer weiter verschärft.
Mittlerweile musste der erste Lieferant seine Software komplett neu schreiben.
Ein anderer Lieferant hatte aufgrund seiner Software so ein mieserables Scoring, dass er jahrelang keine Anlage mehr an uns verkauft hat.
Erst nachdem er seine Standardsoftware überarbeitet hat, kam er wieder zum Zug.
Fazit:
Die Ausführung von Hard- und Software ist auch ein Verkaufsargument ... Zumindest für Folgeanlagen.
Gruß
Blockmove
Draco Malfoy
Level-1
- Beiträge
- 1.168
- Reaktionspunkte
- 82
Mmm... die Wünsche sind hehr, es ist alles schön & gut
Aber es gibt da so n Paar Nuancen:
- 1) Wenn ich als Lieferant geschützte Bibliotheken in SCL habe, die für eure Instandhaltung nicht relevant sind, warum muss ich diese für euch öffnen ? Es ist unser geistiges Eigentum.
- 2) Wenn eure Instandhalter nicht mit SCL in diesen Bibliotheken zurechtkommen - ist es mein Problem oder deren Problem ? Im anderen Fällen und bei anderen Kunden müssen die da auch nicht dran.
- 3) Man sollte schon noch in der Lage sein, auch andere als gewohnte Software zu akzeptieren, wenn sie denn vernünftig strukturiert, sachgemäß, einheitlich, sinnvoll, stringend und auf hohem Niveau ausgeführt ist. Für Hersteller von Anlagen ist es ein Super-Gau, wenn eurer Speziallfall eine komplett kundenspezifische Software erfordert. Hersteller haben ja Hunderte von zum Teil ähnlichen oder baugleichen Anlagen. Da lässt sich kein Geschäft machen, wenn man für jeden Kunden die Software neu schreiben muss. Das könnte dann der Kunde vielleicht selber machen, oder diesen Mehraufwand entsprechend bezahlen.
Nichtdestotrotz sind mir die Schwierigkeiten für einen Anlagenbetreiber durchaus bewusst. Dann kommt halt irgendeine Firma XY aus WasWeißIch, und stellt ihm eine Anlage, wo noch auf dem Niveau von 1980 in absoluten Adressen, indizierten Zeigern und Merkern programmiert wird. Das muss man auch irgendwie noch unterbinden können.
Zuletzt bearbeitet:
- Beiträge
- 6.344
- Reaktionspunkte
- 1.541
-> Hier kostenlos registrieren
Es wird mir wohl ewig ein Rätsel bleiben, wo die Grenze zwischen "für die Instandhaltung relevant" und "für die Instandhaltung irrelevant" verläuft. Besser gesagt: warum die Ansichten hierüber manchmal so eklatant auseinanderklaffen - z.B. zwischen Lieferanten und Kunden.
Mal ganz abgesehen von der Diskussion um "geistiges Eigentum", welcher Lieferant möchte tolerieren, wenn ein Instandhalter auf seiner verzweifelten Suche nach der Ursache eines Problems sich in "BlackBox"-Bereiche verrennt und dort anfängt, an Symptomen herumzudoktern, statt die Ursache einzukreisen und sich ggfs an den Lieferanten zu wenden?
Draco Malfoy
Level-1
- Beiträge
- 1.168
- Reaktionspunkte
- 82
Weil es eine klare Abgrenzung zwischen den Verantwortungsbereichen verschiedener Servceebenen gibt. Im Normalfall sollte es so eine Abrenzung geben. Der Service des Kunden sollte Zugang haben zu:
- Schrittkettenprogrammierung;
- Stellungsüberwachung von Pneumatik, Endlagen, Schutztüren, Zuhaltungen;
- Rückmeldungen von Sicherungen, Schützen, elektronischen Selektivitätsmodulen;
- Ansteuerung von Peripherie, Magnetventilen, Zylindern etc.
- Sicherheitsprogrammierung.
Der Service des Kunden hat kein eigentlich sinvolles Anrecht darauf, solche Sachen wie Kommunikationstreiber, Standardbausteine zum Einlesen/Schreiben von AI / AQ, Treiberbausteine für die Kommunikation mit anderen busfähigen Geräten, Diagnosebasuteine für die Feldperipherie, Treiberbausteine für die Antriebstechnik, Materialtracking, Datenhandling, IO-Link Datenanbindung usw. auseinanerpflücken zu können. Diese Bausteine sollten aus einer zentralen Library kommen und bereits umgänglich getestet sein und einfach funktionieren. Ggf. mit einer Beschreibung dazu.
S. auch, wie das zum Beispiel im VW Standard (VASS) gelöst ist. Dort hats zwar auch Quellen zu den FBs, dort geht aber vom Service in der Regel niemand dran, und das dürfen sie auch nicht so ohne Weiteres.
Zuletzt bearbeitet:
- Beiträge
- 11.614
- Reaktionspunkte
- 3.874
Wir verbieten keine Form von moderner Programmierung, ganz im Gegenteil.
Es gibt aber Vorgaben, wie:
- Schrittketten in Graph
- Bausteine mit überwiegend logischen Verküpfungen (Betriebsarten, Verriegelung, ...) in KOP / FUP
- Gliederung der Programms entsprechend der Anlagenstruktur
- ...
Das Thema Know How Protect führt natürlich zu Diskussionen und natürlich gibt es auch berechtigte Interessen auf Lieferantenseite. Aber bislang gab es immer eine Lösung.
Es zeigt sich eigentlich bei dem Thema Programmierung das selbe Bild wie hier im Forum:
Es sind oft die "alten" Programmierer, die wesentlich aufgeschlossener und innovativer sind, als die Jungen.
Ist letztlich auch klar. Jemand der von der Hochsprachenprogrammierung kommt, tut sich mit Graph, KOP und FUP einfach schwerer.
Die Programme im S5-Stil haben in den etzten Jahren deutlich abgenommen.
Gruß
Blockmove
- Beiträge
- 6.344
- Reaktionspunkte
- 1.541
-> Hier kostenlos registrieren
... und auch mit SCL/ST, sobald es um BitVerknüpfungen ("BOOL") geht. Die BitVerknüpfungen scheinen mir der gemeinsame Nenner des SchwerTuns zu sein. Das fällt natürlich besonders bei KOP, FUP und Graph auf, die sich für BitVerknüpfungen eher anbieten als SCL/ST.
- Beiträge
- 11.614
- Reaktionspunkte
- 3.874
... und auch mit SCL/ST, sobald es um BitVerknüpfungen ("BOOL") geht. Die BitVerknüpfungen scheinen mir der gemeinsame Nenner des SchwerTuns zu sein. Das fällt natürlich besonders bei KOP, FUP und Graph auf, die sich für BitVerknüpfungen eher anbieten als SCL/ST.
Natürlich kann man mit SCL genauso Bits verküpfen.
Aber bei der Fehlersuche ist's halt nervig.
Die SCL-Statusdarstellung bei TIA (und auch Codesys) ist nicht sonderlich gut.
Gruß
Blockmove
gerribaldi
Level-2
- Beiträge
- 88
- Reaktionspunkte
- 15
Also bei CodeSys 2.x war es bescheiden, aber ab 3.x ist die Darstellung doch eigentlich ziemlich gut. Von daher finde ich das nicht problematisch....
