TIA Durch Hardware-Optionen-Handling lange Anlaufzeit der CPU

[Eraser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo alle zusammen,

ich habe bei einem neu erstellten Programm einer Maschine, welche mit verschiedenen Optionen ausgeliefert werden kann, nun alle Optionen in einem Projekt vereinigt, sodass nur ein TIA-Projekt gewartet werden muss. Dies können eine ganze Station (wie hier der zweite G120C) oder auch nur einzelne DI/DO-Karten sein.

Dazu habe ich die komplette Hardware im Geräte-Manager definiert und im OB100 (Startup) werden zu Beginn dann einige Hardware-Teile, welche bei der aktuellen
Ausführung der Maschine nicht vorhanden sind, dann deaktiviert. Die jeweiligen Option-Bits am REQ-Eingang sind immer fix gesetzt pro Maschine.

Nun ist es so, dass bei einem Neustart der Maschine die CPU SEHR lange braucht um auf RUN zu schalten (mehrere Minuten).
Ich schätze, dass dies deswegen so ist, da der OB100 zu diesem Zeitpunkt noch nicht abgearbeitet wird und deswegen die Hardware, welche physikalisch nicht vorhanden ist, während des Online-Checks nicht gefunden und somit darauf gewartet wird.

Was ist eure Meinung hierzu?
Wie kann ich diesen Umstand lösen oder gibt es hierfür eine bessere Lösung?

Danke

mfg Wolfgang

 

[Matze001]

Es gibt doch in den Hardwareeinstellungen eine Einstellung für die max. Hochlaufzeit, und ob die Steuerung bei Ist / Soll Unterschied anläuft.
Wie hoch ist diese Zeit bei Dir eingestellt?

Grüße

Marcel

 

[ChristophD]

Zuviel Werbung?
-> Hier kostenlos registrieren

was steht den im Diagpuffer wo die zeit verbraten wird?

 

[Eraser]

Die Steuerung läuft bei Soll/Ist Unterschieden an, so ist es auch eingestellt.
Die Hochlaufzeit könnte ich mal zum Testen reduzieren, danke.

Die Zeit ist meiner Meinung nach eine reine Wartezeit bis die ganze Hardware vorhanden ist.

Schöner wäre es, wenn man den Anlauf bei Unterschieden deaktiviert, sodass die Module stimmen müssen bzw. mindestens höherwertiger sein müssen. Aber dass würde mit meiner Lösung die CPU wahrscheinlich gar nie anlaufen.

Wie löst ihr das mit den verschiedenen Hardware-Optionen bei Maschinen, wenn man nur ein Gesamt-Projekt haben will damit es einfacher zu warten ist?

 

[PN/DP]

Die Zeit ist meiner Meinung nach eine reine Wartezeit bis die ganze Hardware vorhanden ist.

Die ganze Hardware wird aber nicht vorhanden sein, deshalb wird die Wartezeit voll abgewartet.

Schöner wäre es, wenn man den Anlauf bei Unterschieden deaktiviert, sodass die Module stimmen müssen bzw. mindestens höherwertiger sein müssen. Aber dass würde mit meiner Lösung die CPU wahrscheinlich gar nie anlaufen.

Wie soll die CPU vor Ablauf der Wartezeit bei nicht vorhandener Hardware Unterschiede feststellen?

Wie löst ihr das mit den verschiedenen Hardware-Optionen bei Maschinen, wenn man nur ein Gesamt-Projekt haben will damit es einfacher zu warten ist?

Sobald eine Maschine ausgeliefert ist, ist das sowieso eine ganz individuelle Maschine. Es macht fast keinen Sinn mehr, nur noch ein einziges Projekt für alle jemals ausgelieferten Maschinen zu pflegen. Z.B. kann man dann das Programm einer Maschine nicht mehr beobachten (z.B. zur Problemsuche), ohne erst die aktuelle Offline-Version des Programms in die Maschine zu laden. Oder das Programm aus der Maschine nach Offline zu laden.

Dieses ganze Optionenhandling in Runtime halte ich für überbewertet und eher "Faulheit". Aber gut, ich habe noch nicht bei einem Maschinenbauer gearbeitet, der sooo viele fast gleiche modulare Maschinen baut, daß sich der ganze Aufwand für das Optionenhandling irgendwo rechnen würde, außer für wenig ausgebildete Service-Kräfte.

Harald

 

[R4m80]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dieses ganze Optionenhandling in Runtime halte ich für überbewertet und eher "Faulheit". Aber gut, ich habe noch nicht bei einem Maschinenbauer gearbeitet, der sooo viele fast gleiche modulare Maschinen baut, daß sich der ganze Aufwand für das Optionenhandling irgendwo rechnen würde, außer für wenig ausgebildete Service-Kräfte.

Es gibt auch Fälle wo in Anlagen je nach Prozess oder Bearbeitungsteil unterschiedlich Teilnehmer eingerüstet werden können.

Dazu habe ich die komplette Hardware im Geräte-Manager definiert und im OB100 (Startup) werden zu Beginn dann einige Hardware-Teile, welche bei der aktuellen
Ausführung der Maschine nicht vorhanden sind, dann deaktiviert. Die jeweiligen Option-Bits am REQ-Eingang sind immer fix gesetzt pro Maschine.

Teilnehmer im OB100 zu deaktivieren hallte ich für keine so gute Idee, da der verwendete Baustein dazu mehrere Zyklen durchlaufen sollte und der Anlauf-OB nur einmal abgearbeitet wird.

 

[PN/DP]

Es gibt auch Fälle wo in Anlagen je nach Prozess oder Bearbeitungsteil unterschiedlich Teilnehmer eingerüstet werden können.

OK, wenn zur Laufzeit die Hardware umgebaut wird, dann ist das Aktivieren/Deaktivieren von Hardware zur Laufzeit sinnvoll.

Hier scheint es mir aber eher darum zu gehen, daß sich eine bei der Auslieferung bestehende Konfig nicht mehr ändert. Da finde ich es besser, die bei der Maschine nicht mitgelieferten Hardware-Komponenten in der Hardware Konfig zu löschen und die zugehörigen Programmteile nicht mehr aufzurufen (über urlöschfeste/nullspannungsfeste Konfigurations-Bits/Variablen in DB). Und dann startet die CPU auch zügig.

Harald

 

[SPS-Bitschubser]

Also das mit den options handling ist schon eine schöne Sache. Spart viel Arbeit bei Nachrüstung etc.
Aber es bringt einen nur solange was wie man nur mit den damals angelegten Hardwarekomponenten Arbeitet.
In der Momentanen Zeit wo alles verbaut wird was am schnellsten geliefert wird. Behindert einen das optionshandling eher als es hilft. Und in 10 Jahren wenn was kaputt ist und nixht lieferbar muss man eh zaubern.

 

[Eraser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die ganze Hardware wird aber nicht vorhanden sein, deshalb wird die Wartezeit voll abgewartet.

Ja sehe ich auch so.

Wie soll die CPU vor Ablauf der Wartezeit bei nicht vorhandener Hardware Unterschiede feststellen?

Sie soll nicht vor Ablauf der Wartezeit das erkennen können, sondern nach der Wartezeit dass die CPU wegläuft.
Wenn die Hardware aber nicht zusammenpasst, da diese ja erst im Programm deaktiviert wird, so würde sie dann nicht weglaufen.
Deswegen muss meiner Meinung nach der Anlauf bei Unterschieden in diesem Fall immer aktiviert sein.

Sobald eine Maschine ausgeliefert ist, ist das sowieso eine ganz individuelle Maschine. Es macht fast keinen Sinn mehr, nur noch ein einziges Projekt für alle jemals ausgelieferten Maschinen zu pflegen. Z.B. kann man dann das Programm einer Maschine nicht mehr beobachten (z.B. zur Problemsuche), ohne erst die aktuelle Offline-Version des Programms in die Maschine zu laden. Oder das Programm aus der Maschine nach Offline zu laden.

Hier geht es nicht darum, dass nur ein Programm für die Inbetriebnahme und das spätere Service besteht, sondern dass ein Programm für die Initial-Inbetriebnahme der Maschine genommen werden kann, welches immer am aktuellen Stand ist. Nach der Inbetriebnahme wird das Projekt separat unter diesem Auftrag abgelegt. Sinn davon ist, dass man Software-Änderungen und Verbesserungen nur in einem Vorlage-Projekt zu ändern hat und nicht, wie in unserem Fall, bei einer Maschinentype 5 verschiedene Projekte hat und eine potentielle Änderung dann manuell auf allen 5 Projekten durchgeführt werden muss, damit alle Vorlagen am neuesten Stand bleiben. Bei unseren Maschinen kann sich der Kunde zwischen verschiedenen Maschinenteilen und Funktionen entscheiden und da kann es sein, dass eine Variante einmal pro 10 Jahren verkauft wird, eine andere aber 10x pro Jahr.

Teilnehmer im OB100 zu deaktivieren hallte ich für keine so gute Idee, da der verwendete Baustein dazu mehrere Zyklen durchlaufen sollte und der Anlauf-OB nur einmal abgearbeitet wird.

Danke für die Info, das werde ich dann ändern.

Hier scheint es mir aber eher darum zu gehen, daß sich eine bei der Auslieferung bestehende Konfig nicht mehr ändert. Da finde ich es besser, die bei der Maschine nicht mitgelieferten Hardware-Komponenten in der Hardware Konfig zu löschen und die zugehörigen Programmteile nicht mehr aufzurufen

Bei uns kann es hier aber sein, dass ein Kunde erst später die Maschine erweitert und so muss nicht das ganze Projekt geändert, sondern lediglich ein Bit umgeschaltet werden.

Also das mit den options handling ist schon eine schöne Sache. Spart viel Arbeit bei Nachrüstung etc.

Sehe ich auch so.

Aber es bringt einen nur solange was wie man nur mit den damals angelegten Hardwarekomponenten Arbeitet.

Darum bleiben wir meist sehr lange auf einer Hardwareplattform und auf denselben Komponenten (wenn möglich).
Aber stimmt schon, in der jetzigen Zeit ist das etwas schwieriger...

Und in 10 Jahren wenn was kaputt ist und nixht lieferbar muss man eh zaubern.

Das stimmt...

 

[DOD666]

Kurze Anmerkung, ich würde nie im Anlauf warten was man findet und damit die Konfiguration festlegen, das führt dazu das bei defekten Teilnehmern sich die Maschine umkonfiguriert.

Ich mache das im Programm, so dass anhand der Optionen geprüft wird ob alle Teilnehmer da sind.

Erst wenn alle da sind wird die normale Programmberarbeitung freigegeben.

 

[Eraser]

Kurze Anmerkung, ich würde nie im Anlauf warten was man findet und damit die Konfiguration festlegen, das führt dazu das bei defekten Teilnehmern sich die Maschine umkonfiguriert.

Wie meinst du das bzw. wo wird das gemacht?
Die Konfigurationsbits werden fix gesetzt und nicht bzgl. einer Abfrage der Hardware.

 

[Matze001]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hab so böses Zeug auch mal gemacht.

Ich hab immer die gleiche SPS und es können verschiedene Roboter eingesetzt werden (Kuka, Fanuc, Abb,....)
Ich hab alle konfiguriert und Anlauf bei Soll/Ist Unterschied + geringe Wartezeit eingestellt.
Anschließend mit der PN-Diagnose geschaut welcher von den Teilnehmern kommt, und die anderen deaktiviert.

Das war eine recht coole und elegante Lösung, die für diesen Sonderfall gut funktioniert hat.

Grüße

Marcel

 

[DOD666]

Na ja einen DB anlegen und da Variablen rein. Z.B. "MitStationBohren" damit dann den FU und ggf. I/O station aktivieren oder deaktivieren mit DP_ACT. Die teilnehmernummer kennst du ja dann auch, weißt also wo du die Diagnose auswerten musst. Wenn das aktiviert ist und die Kommunikation nicht läuft weißt du das dein Teilnehmer ausgefallen ist obwohl er laut anlagenkonfiguration da sein muss.

So kann der Inbetriebnehmer die Anlage nach Vorgabe konfigurieren und das Programm weiß dann wie die Hardware sein soll.

Gruß

 

[Eraser]

Na ja einen DB anlegen und da Variablen rein. Z.B. "MitStationBohren" damit dann den FU und ggf. I/O station aktivieren oder deaktivieren mit DP_ACT.

Ja genauso hab ich es bei mir gemacht und schaue nicht drauf was da ist und konfiguriere dann dementsprechend die Hardware um, sondern die Hardware ist von Anfang an in der Software fix vorgegeben.

Dachte du meintest wegen diesem Statement, dass ich das so gemacht hätte:

Kurze Anmerkung, ich würde nie im Anlauf warten was man findet und damit die Konfiguration festlegen, das führt dazu das bei defekten Teilnehmern sich die Maschine umkonfiguriert.

Alles klar, danke für Eure Meinungen hierzu