drfunfrock
Level-1
- Beiträge
- 934
- Reaktionspunkte
- 72
-> Hier kostenlos registrieren
Update
Ich habe als blutiger SPS-Anfänger (keine Vorkenntnisse) mit einer Beckhoff-Soft-SPS eine Produktionsanlage für elektronische Module von Grund auf neu programmiert und wegen guter Erfahrung mit dieser, will ich einmal meine Erfahrungen hier niederschreiben.
Die Anlage wurde vor etwa 4 Jahren auf Basis einer Montrac-Bahn aufgebaut. Am Anfang war es nur ein Ring mit etwa 10 Stationen. Seitdem wurde die Anlage immer wieder erweitert und nun hat die Anlage 40 Stationen mit 4 Paralellspuren.
Die Programmierung hielt nicht so ganz mit den Erweiterungen mit, so dass man getrosst von einem Chaos sprechen konnte. Den einzigen Vorwurf, den man dem verantwortlichen Ing. hätte machen können, war der dass er nicht gegenüber dem Management energisch genug auftrat. Nun er hatte dann das Unternehmen auch nach 4 Jahren verlassen, weil er die Überstunden satt hatte.
Als die nochmalige Erweiterung anstand, kapitulierten die beteiligten Techniker und nichts ging mehr. Diverse Stationen für die Widerstandstrimmung mit dem Laser standen ungenutzt herum. Den Vorschlag alles neu zu machen, wagten sie auch nicht. Zu gross war die Angst wieder am Ausgangspunkt zu landen. Da ich kein Urlaubsanspruch letztes Jahr hatte, versuchte ich in der Urlaubszeit mit den beiden zusammen einen simplen Moore-Automaten in ST für eine ungenutzte Station zusammenzubasteln. Es klappte, nur die Turnaroundzeiten für die Phoenix-SPS warten grausig (10min).
Daraufhin informierte ich mich über diverse SPS und bin an Beckhoff hängengeblieben, weil
- die Turnaroundzeiten unter 30s lagen
- eine Demoversion 15 Tage funktionfähig war, so dass wir einiges erproben konnten.
- Die Doku ist wirklich übersichtlich.
- Das Packet von Beckhoff war einfach zu ordern. Zusatzoptionen waren erstmal nicht notwendig.
Siemens fiel aus dem Raster, weil ich mit der Webseite meine Probleme hatte. Der Seitenaufbau war träge und es war nicht zu erkennen, was nun gekauft werden musste. Sagen wir es einmal so, es war meine Unkenntnis.
Nach 3 Tagen konnten wir uns entschliessen zum Chef zu laufen, um das Projekt zu starten. Schnell also PC mit TwinCat bestellt und warten. Da Beckhoff sich gerade erweiterte wurden daraus 3 Monate. Während dieser Zeit habe ich dann ins Blaue hinein programmiert, ohne eine Zeile an der Realität checken zu können. Im nachhinein war das nicht schlecht, da ich so Zeit hatte mehr über das Programmierkonzept nachzudenken. Als die SPS kam, hatten wir dann genau noch 8 Wochenenden Zeit, da in der Woche die Produktion mit der alten SPS lief.
Wir haben die Anlage so organisiert, das zu jedem Wagen eine Art Rezept mitgeführt wird. Ein Pointer zeigt auf den aktuellen Prozess, der für die Produktion notwendig ist. Bietet eine Station diesen Prozess an, wird dieser ausgeführt. Die Eingangsstation hat einen Barkodeleser, der die Wagennummer liest. Dort werden dann auch die Wagendaten initialisiert. Da so ein Leser 2K Euro kostet und damit nur einer gekauft wurde, muss die Wagennummer im Programm für jede Station verwaltet werden. Das wurde über eine FIFO für jede Station realisiert. Das Problem hier ist, dass die Anlage gestoppt werden muss, wenn es hier Probleme mit Unter- oder Überlauf gibt. Diese geschahen schon deshalb, weil einige Stationen schlecht justiert waren.
Die Stationen arbeiteten unabhängig vom Wagenkode, so dass die Kommunikation über Messages gesteuert wird. Das hatte den Vorteil, dass die Stationen in einem Task liegen können, der eine Zykluszeit von nur 20ms hat, während der Wagenkode eine Zykluszeit von 50ms hatt. Die 50ms musste ich wählen, weil ansonsten die Ausgangssensorensensoren der Weichen nicht schnell genug gelesen worden wären. Ich hätte diese natürlich auch in einen Extra-Task packen können.
Der Wagenkode war nicht trivial, weil ich im Programm immer die Wagennummer mitzuschleppen hatte. An den Weichen muss man in Abhängigkeit der Weichenstellung die Wagennummer an die nächste Station senden. Weichen werden benötigt, da Stationen gleicher Funktion parallel liegen, um die Kapazität zu erhöhen. Mittlerweile kann ich das auch so steuern, dass Stationen mit gleicher Funktion auch hintereinander liegen können. Die Steuerung erfolgt über die Prozesslisten. Das Programmierkonzept in ST ist für eine zyklusorientierte SPS recht heftig, dafür aber übersichtlich und einfach zu erweitern. Der zu bezahlende Preis war der Grosse dafür notwendige PC.
TwinCAT war trotz diverser Fehler meinerseits unproblematisch. Die Konfiguration des Interbusses machte leichte Probleme, nachdem wir ein RS232-Modul entfernt hatten, aber ansonsten hat man sich in die Software sofort hineingefunden. Das schöne an TwinCat ist, man kann viel probieren ohne sich in endlosen Konfigurationsdialogen zu verlieren.
Zudem kann man sich die Demoversion installieren und kann dort programmieren, um dann den Kode übers Netzwerk auf die SPS zu schicken. Es gibt also keine speziell zu bezahlende Entwicklungsumgebung. Nach 15 Tagen funktioniert auf dem eigenen PC nur die SPS nicht mehr. Der Compiler usw. läuft weiter. Das gab uns die Sicherheit, dass wie auch mit einem def. PC keine Probleme bekommen, wie mit Phoenix. Wir verloren damals eine Phoenix-Entwicklerlizenz, weil der PC kaputt ging und die Lizenz an den PC gebunden war.
Der einzige Wermutstropfen ist die ADS-Anbindung über TCP/IP an den PC für die Einstellung der SPS und der Kontrolle der Produktion. Es gibt willkürlich Verbindungsabbrüche, die vom VB-Programm abgefangen werden, die aber "Reste" in der SPS hinterlassen, so dass die Prozessorlast stetig steigt. Nach 2 Tagen benötigt die SPS einen Reboot.
Da dasselbe auch mit der Entwicklerumgebung passiert, ist das wohl ein grundsätzliches Problem von Beckhoff. Es hat sich aber schon gebessert. Für viele Anwendungen dürfte das ein KO-Kriterium sein. Schade eigentlich.
Ein weiteres Problem stellen die Montrac-Stationen dar, da die nur eine Sensor für die Wagendetektion haben. Wenn ein Operator Mist baut und den Wagen rückwärts schiebt, wird dieser 2 mal gezählt und der FIFO-Unterlauf ist absehbar. Ein ähnliches Problem ist die Justage dieser Sensoren, so dass unstabiles Verhalten von Sensoren zum FIFO-Unterlauf führen.
Ich würde es so nicht mehr machen wollen. Am besten jede Station hat einen RFID-Leser, so dass die FIFO-Verwaltung entfällt und die Anlagenstops unwahrscheinlicher werden. Nun ja, die Produktivität der Anlage wurde um 250% gesteigert und die Chefetage ist erstmal zufrieden.
ch habe das mit dem .NET-Interface von Beckhoff gemacht. die Gründe waren:
- VB ist hier akzepiert
- Das .NET-Interface hatte gute Schnittstellen, die die Entwicklung von eigenen Obekten ermöglichen.
- Hier haben wir eine Windowskultur und wer will den PC pflegen?
Das Problem war die Verbindung aufzubauen und zu halten. Wenn der PC zu stark belastet war, gab es einen Verbindungsabruch. Ich habe dann Threads genommen, damit erreichte ich weniger Timeouts. Es gibt allerdings auch noch andere Verbindungsabbrüche, deren Grund ich nicht ermitteln kann. Mein Programm baut die Verbindung sofort wieder auf, aber schön ist das nicht. Mit den neueren Version von TwinCat ist die Verbindung jetzt zuverlässig geworden.
Doc Funfrock
Ich habe als blutiger SPS-Anfänger (keine Vorkenntnisse) mit einer Beckhoff-Soft-SPS eine Produktionsanlage für elektronische Module von Grund auf neu programmiert und wegen guter Erfahrung mit dieser, will ich einmal meine Erfahrungen hier niederschreiben.
Die Anlage wurde vor etwa 4 Jahren auf Basis einer Montrac-Bahn aufgebaut. Am Anfang war es nur ein Ring mit etwa 10 Stationen. Seitdem wurde die Anlage immer wieder erweitert und nun hat die Anlage 40 Stationen mit 4 Paralellspuren.
Die Programmierung hielt nicht so ganz mit den Erweiterungen mit, so dass man getrosst von einem Chaos sprechen konnte. Den einzigen Vorwurf, den man dem verantwortlichen Ing. hätte machen können, war der dass er nicht gegenüber dem Management energisch genug auftrat. Nun er hatte dann das Unternehmen auch nach 4 Jahren verlassen, weil er die Überstunden satt hatte.
Als die nochmalige Erweiterung anstand, kapitulierten die beteiligten Techniker und nichts ging mehr. Diverse Stationen für die Widerstandstrimmung mit dem Laser standen ungenutzt herum. Den Vorschlag alles neu zu machen, wagten sie auch nicht. Zu gross war die Angst wieder am Ausgangspunkt zu landen. Da ich kein Urlaubsanspruch letztes Jahr hatte, versuchte ich in der Urlaubszeit mit den beiden zusammen einen simplen Moore-Automaten in ST für eine ungenutzte Station zusammenzubasteln. Es klappte, nur die Turnaroundzeiten für die Phoenix-SPS warten grausig (10min).
Daraufhin informierte ich mich über diverse SPS und bin an Beckhoff hängengeblieben, weil
- die Turnaroundzeiten unter 30s lagen
- eine Demoversion 15 Tage funktionfähig war, so dass wir einiges erproben konnten.
- Die Doku ist wirklich übersichtlich.
- Das Packet von Beckhoff war einfach zu ordern. Zusatzoptionen waren erstmal nicht notwendig.
Siemens fiel aus dem Raster, weil ich mit der Webseite meine Probleme hatte. Der Seitenaufbau war träge und es war nicht zu erkennen, was nun gekauft werden musste. Sagen wir es einmal so, es war meine Unkenntnis.
Nach 3 Tagen konnten wir uns entschliessen zum Chef zu laufen, um das Projekt zu starten. Schnell also PC mit TwinCat bestellt und warten. Da Beckhoff sich gerade erweiterte wurden daraus 3 Monate. Während dieser Zeit habe ich dann ins Blaue hinein programmiert, ohne eine Zeile an der Realität checken zu können. Im nachhinein war das nicht schlecht, da ich so Zeit hatte mehr über das Programmierkonzept nachzudenken. Als die SPS kam, hatten wir dann genau noch 8 Wochenenden Zeit, da in der Woche die Produktion mit der alten SPS lief.
Wir haben die Anlage so organisiert, das zu jedem Wagen eine Art Rezept mitgeführt wird. Ein Pointer zeigt auf den aktuellen Prozess, der für die Produktion notwendig ist. Bietet eine Station diesen Prozess an, wird dieser ausgeführt. Die Eingangsstation hat einen Barkodeleser, der die Wagennummer liest. Dort werden dann auch die Wagendaten initialisiert. Da so ein Leser 2K Euro kostet und damit nur einer gekauft wurde, muss die Wagennummer im Programm für jede Station verwaltet werden. Das wurde über eine FIFO für jede Station realisiert. Das Problem hier ist, dass die Anlage gestoppt werden muss, wenn es hier Probleme mit Unter- oder Überlauf gibt. Diese geschahen schon deshalb, weil einige Stationen schlecht justiert waren.
Die Stationen arbeiteten unabhängig vom Wagenkode, so dass die Kommunikation über Messages gesteuert wird. Das hatte den Vorteil, dass die Stationen in einem Task liegen können, der eine Zykluszeit von nur 20ms hat, während der Wagenkode eine Zykluszeit von 50ms hatt. Die 50ms musste ich wählen, weil ansonsten die Ausgangssensorensensoren der Weichen nicht schnell genug gelesen worden wären. Ich hätte diese natürlich auch in einen Extra-Task packen können.
Der Wagenkode war nicht trivial, weil ich im Programm immer die Wagennummer mitzuschleppen hatte. An den Weichen muss man in Abhängigkeit der Weichenstellung die Wagennummer an die nächste Station senden. Weichen werden benötigt, da Stationen gleicher Funktion parallel liegen, um die Kapazität zu erhöhen. Mittlerweile kann ich das auch so steuern, dass Stationen mit gleicher Funktion auch hintereinander liegen können. Die Steuerung erfolgt über die Prozesslisten. Das Programmierkonzept in ST ist für eine zyklusorientierte SPS recht heftig, dafür aber übersichtlich und einfach zu erweitern. Der zu bezahlende Preis war der Grosse dafür notwendige PC.
TwinCAT war trotz diverser Fehler meinerseits unproblematisch. Die Konfiguration des Interbusses machte leichte Probleme, nachdem wir ein RS232-Modul entfernt hatten, aber ansonsten hat man sich in die Software sofort hineingefunden. Das schöne an TwinCat ist, man kann viel probieren ohne sich in endlosen Konfigurationsdialogen zu verlieren.
Zudem kann man sich die Demoversion installieren und kann dort programmieren, um dann den Kode übers Netzwerk auf die SPS zu schicken. Es gibt also keine speziell zu bezahlende Entwicklungsumgebung. Nach 15 Tagen funktioniert auf dem eigenen PC nur die SPS nicht mehr. Der Compiler usw. läuft weiter. Das gab uns die Sicherheit, dass wie auch mit einem def. PC keine Probleme bekommen, wie mit Phoenix. Wir verloren damals eine Phoenix-Entwicklerlizenz, weil der PC kaputt ging und die Lizenz an den PC gebunden war.
Der einzige Wermutstropfen ist die ADS-Anbindung über TCP/IP an den PC für die Einstellung der SPS und der Kontrolle der Produktion. Es gibt willkürlich Verbindungsabbrüche, die vom VB-Programm abgefangen werden, die aber "Reste" in der SPS hinterlassen, so dass die Prozessorlast stetig steigt. Nach 2 Tagen benötigt die SPS einen Reboot.
Da dasselbe auch mit der Entwicklerumgebung passiert, ist das wohl ein grundsätzliches Problem von Beckhoff. Es hat sich aber schon gebessert. Für viele Anwendungen dürfte das ein KO-Kriterium sein. Schade eigentlich.
Ein weiteres Problem stellen die Montrac-Stationen dar, da die nur eine Sensor für die Wagendetektion haben. Wenn ein Operator Mist baut und den Wagen rückwärts schiebt, wird dieser 2 mal gezählt und der FIFO-Unterlauf ist absehbar. Ein ähnliches Problem ist die Justage dieser Sensoren, so dass unstabiles Verhalten von Sensoren zum FIFO-Unterlauf führen.
Ich würde es so nicht mehr machen wollen. Am besten jede Station hat einen RFID-Leser, so dass die FIFO-Verwaltung entfällt und die Anlagenstops unwahrscheinlicher werden. Nun ja, die Produktivität der Anlage wurde um 250% gesteigert und die Chefetage ist erstmal zufrieden.
ch habe das mit dem .NET-Interface von Beckhoff gemacht. die Gründe waren:
- VB ist hier akzepiert
- Das .NET-Interface hatte gute Schnittstellen, die die Entwicklung von eigenen Obekten ermöglichen.
- Hier haben wir eine Windowskultur und wer will den PC pflegen?
Das Problem war die Verbindung aufzubauen und zu halten. Wenn der PC zu stark belastet war, gab es einen Verbindungsabruch. Ich habe dann Threads genommen, damit erreichte ich weniger Timeouts. Es gibt allerdings auch noch andere Verbindungsabbrüche, deren Grund ich nicht ermitteln kann. Mein Programm baut die Verbindung sofort wieder auf, aber schön ist das nicht. Mit den neueren Version von TwinCat ist die Verbindung jetzt zuverlässig geworden.
Doc Funfrock
