TIA Problem mit Multiuser V15 - Saftey Bausteine

[Domi93]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,

Wir nutzen Multiuser schon seit einiger Zeit gezwungener Maßen. Mittlerweile verwenden wir V15, diese hat auch bis vor kurzem ganz gut funktioniert. Bevor jemand fragt, wir verwenden v15 update 3 von Multiuser.

Problem:

Jedes mal wenn wir Änderungen in FB, FC´s etc. durchführen, dann führen diese nach dem Einchecken am Server und erneutem aktualisieren der lokalen Session dazu, dass der Zeitstempel des Saftey Programmes unterschiedlich ist (Saftey-Code ist derselbe).
Somit müssen wir jetzt jedes mal wenn wir nur die kleinste Änderung machen, die CPU auf Stopp setzen, was sehr nervig ist und auch extrem viel Zeit kostet, zumal wir dadurch auch andere Anlagenabschnitte für kurze Zeit deaktivieren.

Habe bereits das Projekt als Single-User Projekt vom Server exportiert und damit ein komplett neues Multiuser-Projekt erstellt, dies hat leider auch nicht gebracht.
Neue Lokale Sessions erstellt an den Clients, funktioniert auch nicht.

Es passiert definitiv erst nach dem Synchronisieren mit dem Server, da wenn ich die Änderung mache und einspiele bevor ich mit dem Server synchronisiere alle Bausteine "Grün" sind.

Vielleicht hat von euch jemand dasselbe oder so ein ähnliches Problem gehabt?

Danke.

 

[Zombie]

Ich rate einfach mal, das wird eine Inkompatibilität der beiden Anwendungen sein.

Bei dem Safety Gedöns darf sich nichts ändern. Beim Einchecken wird aber der zuletzt reingeladene Programmcode mit dem vom Server überschrieben, der auch von einem anderen Benutzer stammen kann.
Hast du mal versucht, jedesmal vor dem einchecken alle Safety Bausteine mit einer blauen Flagge zu versehen?
Somit wird die Version die du auf deinem Rechner hast beibehalten und auf den Server geladen, anstatt andersherum.

€:
Ich meine damit, dass man festlegen müsste, wer bei dem Safety Gedöns der Master ist. EIner hat die aktuellen Bausteine, dann dürfte aber auch einzig dieser das Projekt in die CPU laden.
Widerspricht dem Gedanken von Multiuser aber so ziemlich auf jedem Level

 

[Domi93]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja ich weiß was du meinst, aber wir arbeiten nicht an den Saftey Bausteinen. Nur an normalen Fb's etc. Es hat bis jetzt auch immer funktioniert.

Ich werde das gleich mal testen dann.

Danke

 

[Astralavista]

Wir verwenden die gleiche Konstellation in einem aktuellen Projekt, aber mir ist in Bezug auf Safety diese Problematik noch nicht aufgefallen. Zusätzlich haben wir aber PositioningAxis Technologieobjekte in der Software und bei uns passiert dein genanntes Problem mit den Technologieobjekten. Nach jedem einchecken muss die CPU auf Stopp gesetzt und zusätzlich die Servoachsen ausgeschaltet werden um die CPU laden. Das kostet richtig Zeit.

 

[maxder2te]

Hallo Leute,

Wir nutzen Multiuser schon seit einiger Zeit gezwungener Maßen. Mittlerweile verwenden wir V15, diese hat auch bis vor kurzem ganz gut funktioniert. Bevor jemand fragt, wir verwenden v15 update 3 von Multiuser.

Problem:

Jedes mal wenn wir Änderungen in FB, FC´s etc. durchführen, dann führen diese nach dem Einchecken am Server und erneutem aktualisieren der lokalen Session dazu, dass der Zeitstempel des Saftey Programmes unterschiedlich ist (Saftey-Code ist derselbe).
Somit müssen wir jetzt jedes mal wenn wir nur die kleinste Änderung machen, die CPU auf Stopp setzen, was sehr nervig ist und auch extrem viel Zeit kostet, zumal wir dadurch auch andere Anlagenabschnitte für kurze Zeit deaktivieren.

Habe bereits das Projekt als Single-User Projekt vom Server exportiert und damit ein komplett neues Multiuser-Projekt erstellt, dies hat leider auch nicht gebracht.
Neue Lokale Sessions erstellt an den Clients, funktioniert auch nicht.

Es passiert definitiv erst nach dem Synchronisieren mit dem Server, da wenn ich die Änderung mache und einspiele bevor ich mit dem Server synchronisiere alle Bausteine "Grün" sind.

Vielleicht hat von euch jemand dasselbe oder so ein ähnliches Problem gehabt?

Danke.

Servus.

Ich hab diese Woche mit dem gleichen Problem gekämpft und es ließ sich schließlich recht einfach beheben.
Server-Ansicht öffnen, in der Server-Ansicht die gesamte CPU neu übersetzen. Wichtig: der Übersetzungsvorgang darf keine Fehler liefern.

Anschließend die lokale Session aktualisieren (es darf kein Baustein in einer Session markiert sein).


Der Grund warum das so funktioniert, ist mir nicht ganz 100%ig einleuchtend, ich kann lediglich eine Vermutung anstellen:
Generell empfiehlt Siemens beim Einsatz des MUS ja, dass Änderungen im Safety-Teil nur in der Server-Ansicht gemacht werden. Das Ändern von Safety-Bausteinen in der lokalen Session und das anschließende Einchecken ist zwar möglich, allerdings wird nur der Baustein selbst eingecheckt, nicht jedoch der übersetzte Code (in Form des invertierten Programms im Ordner 'Compiler-Bausteine').

Offenbar wurde in einer lokalen Session ebenfalls was im Safety-Teil verändert und eingecheckt. Bei jedem Aktualisieren der lokalen Session wird nun der "alte" übersetzte Safety-Code und der "neue" Safety-Baustein lokal aktualisiert und lokal neu übersetzt. Das ergibt jedes mal neue Zeitstempel und das von dir beschriebene Verhalten.


lg

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir verwenden die gleiche Konstellation in einem aktuellen Projekt, aber mir ist in Bezug auf Safety diese Problematik noch nicht aufgefallen. Zusätzlich haben wir aber PositioningAxis Technologieobjekte in der Software und bei uns passiert dein genanntes Problem mit den Technologieobjekten. Nach jedem einchecken muss die CPU auf Stopp gesetzt und zusätzlich die Servoachsen ausgeschaltet werden um die CPU laden. Das kostet richtig Zeit.

Dass beim Laden von Technologieobjekten ein STOP gefordert wird kann an sich 3 Ursache haben:
1. Fehler in den internen Date des Projekts - war bei uns bei einem von V13.1 auf V14.1 hochgezogenen Projekt der Fall. Nach Reparatur durch Siemens war da Ruhe.
2. Du möchstes das Objekt selbst (also den DB) laden, während das Technologieobjekt freigegeben ist. Das geht so nicht - dass die CPU einen STOP ist zwar zweckmäßig aber nicht notwendig. Es reicht das ausschalten mittels MC_Power mit Enable=false.
3. Wird der Instanz-DB (oder der DB, in dem die Multi-Instanzen liegen) einer MC_-Anweisung geladen, so darf die betreffende Anweisung aktuell nicht aktiv sein. Das ist z.B. der Fall, wenn MC_Halt aufgerufen bleibt, wenn MC_Power mit Enable=false bearbeitet wird. Der Halt löst zwar nichts mehr aus und liefert auch keinen Fehler, aber die Instanz lässt sich nicht mehr laden. Wird MC_Power mit Enable=False aufgerufen und sonst ist kein Auftrag mehr aktiv, lässt sich die Instanz ohne STOP laden.

Nun gilt es noch, die Ursache für einen der 3 Effekte zu finden:
Für Technologieobjekte gilt fast das gleiche wie für Safety-Bausteine: Siemens empfiehlt, sie nur in der Serverprojekt-Ansicht zu ändern. Sie können aber auch lokal verändert und geladen werden. Ich würde dir ebenfalls empfehlen, mal in der Serveransicht alles zu übersetzen.


Warum das zu so eigenartigen Effekten führt, ist mir erst diese Woche Dienstag klar geworden (ich hole kurz aus):

Der Eincheck-Mechanismus unterstützt nur gewisse Objekte, angefangen von Projektbibliotheks-Elementen über Variablentabellen, Bausteine, Datentypen usw. Es wird NUR das eingecheckt, was markiert ist.
Bis zur V14 musste man alles manuell markieren, was man einchecken wollte. Mit V15 wurden Bausteine, Variablen usw., die man lokal verändert hat, automatisch markiert - was ein ectremer Fortschritt war.

Der "Auto-Markier"-Mechanismus versagt allerdings an einigen Stellen - und zwar immer dann wenn entweder der Compiler eingreift und automatisch Bausteine aktualisiert, oder wenn ein Auto-Ersetzungsmechanismus des TIA-Portal eingreift.

Ein Beispiel:
Wird an Technologieobjekten etwas verändert (z.B. die Zuordnung zu einem S120-Antrieb), dann wird nicht nur das Technologieobjekt damit verändert, sondern auch der MC_Servo und der MC_Interpolator werden neu generiert. Die beiden OBs werden allerdings nicht zum Einchecken markiert.

Ein weiteres Beispiel sind die Safety-Compiler-Bausteine.

Ein drittes Beispiel:
Werden lokal Variablentabellen verändert (z.B. Eingangsvariablen umbenannt), dann werden zwar die Variablen zum Einchecken markiert, nicht aber die Bausteine, in denen sie verwendet werden.

lg