WinCC TIA WinCC Professional V13 SP2: C-Skripte Funktion "xcLogMessage" -> was macht das?

[Grimsey]

Zuviel Werbung?
-> Hier kostenlos registrieren

TIA WinCC Professional V13 SP2: C-Skripte Funktion "xcLogMessage" -> was macht das?

Hallo zusammen,

ich habe eine kurze Frage zu C-Skripten unter WinCC Professional V13 SP2:

für jeden Bildwechsel auf der Visu ist ein C-Skript erstellt.

#include "GlobalDefinitions.h" 
void OnReleaseLeft(char* screenName, char* objectName, char* propertyName, UINT flags, int x, int y)
{
//Fügen Sie den Code ab hier ein
xcLogMessage(screenName);
xcLogMessage(objectName);
xcLogMessage(propertyName);
BST_WorkfieldOpen(screenName, "m_pic_alarm");

ich würde gerne wissen, was die Funktion "xcLogMessage" bewirkt.

Hintergrund ist der, dass es sporadisch zu enormen Verzögerungen bei der Kommunikation zwischen den Clients und dem Server und dann der SPS kommt.
Die Bediener müssen teilweise mehrere Sekunden auf eine Taste drücken, bis der Befehl/Signal in der SPS ankommt.
Beim Aufruf mancher Bilder hängt sich der Client auch auf und ich wollte mich mal auf die Suche nach der Ursache machen.

 

[Thomas_v2.1]

Das sieht für mich nach einer selbst geschriebenen Funktion aus, genauso wie BST_WorkfieldOpen die meine ich aus einem Siemens Beispielprojekt stammen dürfte.

Vermutlich wird dort nur der String vom Parameter per printf ausgegeben (eingepackt in einen debug-level o.Ä.), oder möglicherweise auch in eine Datei geschrieben was zu den Problemen führen könnte. Zur Runtime sollte bei WinCC Prof. eigentlich auch noch Apdiag verfügbar sein, das würde ich mal starten und sehen was dort für Meldungen auflaufen. Wenn es viele Fehler gibt führt das auch zur Verlangsamung.

 

[Grimsey]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke Thomas,

Du hast vollkommen Recht.
Es ist eine selbtgeschriebene Funktion die scheinbar so alle Aktionen in Textdateien abspeichert.
Auch die BST_WorkfieldOpen existiert als C-Skript.
Werde ich mir anschauen.

xcLogMessage werde ich mal im gesamten Projekt entfernen und schauen wie es danach.
Vorher natürlich Projekt sichern.

 

[Ralle]

Ich habe ebenfalls mit WinCC Prof. 15.1 Probleme bei den Fensterwechselzeiten gehabt.
Das dauerte bei den Clients schon mal 7!!! Sekunden.

Nach langem Forschen die Ursache:
Ich hab in jedem Fenster das Alarm-Control als einfache Meldezeile, weil WinCC sowas nicht extra anbietet. Bei der Migration aus WinCC 7.2 über 7.4 wurden im Alarm-Control alle möglichen Optionen angehakt (Automatisch von TIA).
Nachdem ich diese Auswahl in WinCC Prof. später bei jedem Alarmcontrol eingeschrängt hatte sind es "nur" noch 1.5 Sekunden. Bei einem rel. kleinen Projekt mit 13 projektlosen Clients ist WinCC Prof. leider zeimlich lahm, also verschwende nicht zu viel Zeit auf Verbesserungen der Performance. Es ist einfach langsam.

PS: Auf dem Server selbst ist die Performance besser.

 

[Grimsey]

@Ralle,

hab vielen Dank für Deinen Erfahrungsbericht.
Leider betrifft es bei meinem System (1 Server, 2 Clients) nicht die Bildwechsel, sondern wirklich die Signalübertragung von Schaltflächen.
Ich hatte das Thema hier im Forum vor einigen Monaten schonmal angestoßen.
Es ist wirklich leider so, dass es sporadisch nach einer gewissen Zeit dazu kommt, dass die Bediener mehrere Sekunden eine Taste betätigen müssen bis das Signal in der Steuerung verarbeitet wird. Das ist so natürlich nicht zumutbar und macht uns auch oft Probleme.
Ich habe diesbezüglich bereits SIEMENS kontaktiert und nun auch einen Service-Einsatz geordert.
Vorab habe ich mir nun nochmal das Projekt angesehen und bin dabei auf das Skript gestoßen. Ich wollte halt gerne alle noch in Frage kommenden Ursachen beseitigen.
Da das Skript wirklich bei jeder Aktion auf der Visu aufgerufen wird (Fensterwechsel, Bedienungen, etc...wirklich alles und überall) habe ich es jetzt mal komplett auskommentiert.

Auf dem Server selbst läuft auch hier alles super schnell und bestens

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir haben auch oft Probleme mit "Wartezeiten", das betrifft in unserem Fall vor allem Scripte, die Daten per Ethernet an einen Server versenden und eine Antwort bekommen. Das dauert mal 2, mal 10 Sekunden, bis di Antwort kommt und man kann einfach nicht herausfinden woran es genau liegt. Der Server des Kunden antwortet sofort (300ms). Es scheint so, als ob die Scriptengine machmal nicht hinterherkommt und sich die Scripte stauen. Dann heißt es warten, denn hier gilt, immer schön eines nach dem anderen. Absolut tötlich sind "Warteschleifen" oder Wartezeiten in Skripten. Das hält den kompletten Verkehr auf. Wir hatten ein eigenes ActiveX, das sollte auf Daten warten, das ging so nicht, WinCC kam ins stottern, weil alles warten mußte. Also wurde umgeschrieben auf ein Art "Pollen". Laüft alles auf dem Server.
Siemens war nie hilfreich, entweder wollten die das Problem gar nciht erst verstehen oder sie haben niemanden, der sowas kann. Ich kann mir kaum vorstellen, dass wir die Einzigen sind, die mit derarteigen Problemen kämpfen. Die Bordmittel des WinCC-Paketes, um solchen Problemen auf den Grund zu gehen, sind leider extrem bescheiden und absolut unzureichend. Ich frage mich seit Jahren, wie damit ganze Fabriken gesteuert und visualisiert werden?