KRC2 Fehler (C3ARC) Zeitüberschreitung.... RAM updaten?

  • Hallo zusammen


    Habe einen komischen Fehler auf einer KRC2 mit WinXP und Softwareversion 5.2.14:

    Wenn ich per WinXP-Dateifreigabe auf eine Datei zugreife, ändere und speichern will, dann stürzt der Dateibrowser des KRC HMI irgendwie ab (ebenfalls verliere ich dann Zugriff auf diese Dateifreigabe). Es erscheinen keine Dateien mehr im KRC HMI und der Ladebalken rechts mitte/unten lädt ewig (gem. Bild im Anhang). Unten erscheint die Fehlermeldung Nr. 24, Abs. "C3ARC", Meldung "Zeitüberschreitung in". Zu dieser Meldung gibt es keine Hilfe und auch in der Doku ist diese Meldungsnummer gar nicht aufgeführt.


    Ich ändere immer Dateien auf diese Weise ab, auf mehreren KRC2 Robotern (immer danach natürlich auf dem KCP2 die Datei noch einmal öffnen, etwas ändern und speichern, damit die Änderung aktiv wird). Wurde auch bei diesem früher so gemacht. Als erstes dachte ich an HDD Defekt: Habe ich also eine neue HDD eingebaut mit einem Full-Backup (HDD Klon) von vor 2 Jahren wo das sicher noch ging mit der Freigabe - und Backup des aktuellen Roboter Programm eingespielt (das konnte ich noch archivieren und wieder laden). Gleiches Ergebnis: Stürzt wieder ab. Trotz Absturz ist noch interessant, dass ich auch nach dem Absturz in Automatik Extern schalten kann und die Roboterzelle läuft und wählt anscheinend das nötige Programm an; Es erscheint nur der Programmcode nicht auf dem KCP2 sondern man sieht nur den Dateibrowser, der ewig lädt...


    Was könnte noch diesen Fehler hervorrufen? Hat jemand Erfahrungen damit? Welche Logdateien könnten helfen?

    Vielen Dank!


  • KUKA Handwerk
    Anzeige
  • Meine mich erinnern zu können, diesen Effekt mal durch ein ungültiges Zeichen bekommen zu haben.

    Die KRC2 war ja lange relativ empfindlich gegen Umlaute etc.

    Ich würde mal mit einem Editor, der Regular Expressions kann, nach nicht-Ascii-Zeichen suchen über alle Dateien im Archiv..


    Grüße,

    Michael

  • Was mir gerade noch einfällt: manche Editoren haben einen eingebauten Eifer, Codierungsprobleme selbst umgehen zu wollen. UltraEdit z. B. kann man locker dazu überreden, in den Dateikopf ein Unicode-BOM zu schreiben. Das sieht man dann natürlich nicht, wenn man dieselbe Datei mit demselben Editor wieder öffnet, stört aber die KRC vor dem &COMMENT ... etc. ungemein.

    Sehen kann man das mit dem primitiven Windows-Editor.


    Grüße,

    Michael

  • ... ich kenne das Phänomen auch, allerdings im Zusammenhabg von zu vielen Dateien im Programmverzeichniss und zu wenig Arbeitsspeicher. Du kannst dir die Speicherauslastung ja mal anschauen -> Hilfe/info

    Die Abnahme von "GOTO" Anweisungen verhält sich reziprok zur Qualität einer Programmierung

  • Danke an euch für die schnelle Antwort! Ich habe mit folgendem Befehl (funktioniert auf einem UNIX-System) das KRC Backup Archiv geprüft: grep -r --color='auto' -P -n "[\x80-\xFF]" *

    (hier gefunden: https://stackoverflow.com/ques…-all-non-ascii-characters)


    Habe im momentanen sowie im letzten Programmstand keine nicht-ASCII Zeichen gefunden. Nur ein paar Binary Files und Logfiles geben an:

    Arbeitsspeicher-Auslastung ist gem Hilfe/Info bei 70%. Das Programm auf dem Roboter ist ausserdem recht klein im vergleich zu was ich schon gesehen habe...


    Umlaute hat es relativ viele drin in Kommentarzeilen, aber schon seit mehreren Jahren und verschiedensten Versionen des Roboter-Programms. Hat immer funktioniert...


    An was könnte es noch liegen?

  • Moin,

    es ist keine gute Idee, Dateifreigaben auf den R1 Ordner zu legen.

    Das Echtzeitbetriebssytem der Steuerung greift während des Betriebes auf diesen Ordner zu. Zwangsläufig muss es da zu Konflikten kommen.

    never touch a running system

  • Ist aber nichts anderes als das, was Windows auch macht, und funktioniert eigentlich immer, mit den bekannten Einschränkungen. Jeder weiß, dass man es nicht darf, und jeder macht es trotzdem.


    lukelukeluke : Kommt der Hänger denn erst, wenn Du dieses Verzeichnis wie im Bild öffnen willst oder allgemein beim Aufbau des Dateibrowsers von der wurzel aus? Eigentlich ist das im Bild ja nur der Vorgang, der immer kommt, wenn man versucht, ein Verzeichnis anzeigen zu lassen. Nur hier eben mit einem Timeout-Fehler.

    Unter anderem nimmt der "Explorer" ja auch *.zip-Dateien auseinander und stellt sie im Bereich "Archive" dar. Irgendeine Datei kann eben nicht angezeigt werden, warum auch immer. Ich würde im Weiteren jetzt alles aus dem Zugriffsbereich des Explorers rausschieben und nach und nach wieder reinholen. Wird ja eine bestimmte Datei sein, die irgendwie vermurkst ist, oder ein Symlink, oder irgendwas Böses.

    Das wird mit KUKA gar nichts zu tun haben, sondern ist eher ein Windows-Problem. Hast Du mal versucht, nur mit dem "richtigen" Windows-Explorer (lokal) das fragliche Verzeichnis anzeigen zu lassen?


    Grüße,

    Michael

  • Hallo


    Den Hänger erkenne ich, indem ich auf einem Remote-PC per Windows eine Datei editiere (direkt via Netzwerkfreigabe) und im Moment als ich speichern drücke, kommt auf meinem Remote-PC "keine Antwort" und die Netzwerkfreigabe stürzt rgendwie ab (in Windows Explorer kann ich nicht mehr auf das Volume zugreifen). Auf dem KRC2 HMI kann ich dann noch 2-3 mal den Ordner wechseln im HMI Browser, danach kommt für ewig nachher der ladende Balken. Sieht also schon aus dass hier Windows ein Problem hat im Moment als ich die Datei remote speichern will.


    Wenn ich das Programm ganz lösche (also nach einem Kaltstart alle Files auswählen und löschen) kann ich wieder Files bearbeiten, auch über die Netzwerkfreigabe. Aber irgendwie die bisherigen Files nicht...


    Habe nun gesehen das RAM schon relativ fest ausgelastet ist (Hilfe->Info) zeigt zwischenzeitlich doch z.B. 95% an. Nun habe ich von 2x128MB auf 3x128MB erweitert (hatte noch einen exakt gleichen Riegel von einer anderen KRC2). Danach erst mal Bildschirm schwarz. Nachdem ich erst mal CMOS Clear Jumper gesetzt habe, MB Batterie kurz raus, startet der PC trotzdem nicht. Habe dann in einem anderen Forumartikel gelesen dass man den Startknopf des Mainboard / ATX Powersupply kurzschliessen muss und danach direkt KUKA defaults laden:

    KRC2 PC läuft nicht

    Danach startet der PC wieder aber ganz am Anfang kommt "Memory Testing: 262144K OK. Also nix von 384MB...? Auch im KUKA HMI unter Hilfe->Info steht "Arbeitsspeicher: 256 MB". Habe auch in Foren gelesen dass man nichts ändern muss nach Memory Update, auch keine Änderung in memconfig.ini. Das BIOS scheint ja schon nicht alles zu erkennen, doch dort gibts keine Einstellungen zur Menge von RAM bez. den einzelnen Slots. Windows zeigt Unter "Systemsteuerung -> System" auch "256 MB" an..


    Was gibt hier noch für Tricks?


    Mainboard ist SOYO SY-7VBA133K

  • lukelukeluke

    Changed the title of the thread from “KRC2 Fehlermeldung 24 (C3ARC) Zeitüberschreitung” to “KRC2 Fehler (C3ARC) Zeitüberschreitung.... RAM updaten?”.
  • ...

    Habe nun gesehen das RAM schon relativ fest ausgelastet ist (Hilfe->Info) zeigt zwischenzeitlich doch z.B. 95% an. Nun habe ich von 2x128MB auf 3x128MB erweitert (hatte noch einen exakt gleichen Riegel von einer anderen KRC2). Danach erst mal Bildschirm schwarz. Nachdem ich erst mal CMOS Clear Jumper gesetzt habe, MB Batterie kurz raus, startet der PC trotzdem nicht. Habe dann in einem anderen Forumartikel gelesen dass man den Startknopf des Mainboard / ATX Powersupply kurzschliessen muss und danach direkt KUKA defaults laden:

    KRC2 PC läuft nicht

    ..

    Moin,

    offensichtlich ist der neue RAM Riegel nicht passend.

    Weiterhin gibt es , wie ich mich dunkel erinnern kann, nur bestimmte RAM Kombinationen, mit der die KSS umgehen kann. Dazu ghört garantiert nicht , dass drei der 4 Steckplätze belegt sind.


    Selbst auf die Gefahr hin, dass ich wiederhole: Ein Zugriff auf die Daten im R1 Ordner zur Laufzeit der KSS ob über Netzwerk oder direkt, ist nicht empfehlenswert. Das Echtzeitbetriebssystem der KSS greift auf diese Daten zu!

    never touch a running system

  • ..das soyo Mainboaard hat meines wissens nur 3 DIMM Steckplätze, aber du hast recht otto, da war mal was mit 2 oder 4 dimmriegeln - 3 gingen bei manchen Mainboards nich

    Die Abnahme von "GOTO" Anweisungen verhält sich reziprok zur Qualität einer Programmierung

  • ..das soyo Mainboaard hat meines wissens nur 3 DIMM Steckplätze, aber du hast recht otto, da war mal was mit 2 oder 4 dimmriegeln - 3 gingen bei manchen Mainboards nich

    Das Mainboard hat definitiv 3 DIMM Steckplätze.

    Und ja, habe auch schon dazumals ein System mit diesem Board mit 3x128MB, WinXP, V5.x und WinAC ausgestattet und dies lief zuverlässig.

    Ein 5.2.x Standard-System von dazumals sollte aber problemlos mit 256MB auskommen.


    Selbst auf die Gefahr hin, dass ich wiederhole: Ein Zugriff auf die Daten im R1 Ordner zur Laufzeit der KSS ob über Netzwerk oder direkt, ist nicht empfehlenswert. Das Echtzeitbetriebssystem der KSS greift auf diese Daten zu!

    Solche Abstürze führen zu grossen Logfiles und "müllen" dir die Kiste zu. (ADS.....log, CPDownDumpx.bin, ttxx.log, tsm...log, Sockerr..log, etc.)


    Es lohnt sich, Systeme z.T wirklich neu aufzusetzen mit neuesten Windows-Versionen (welche hast Du, XP's gab's diverse #10 noch????), neuester KSS (V5.2.21) und neuesten Optionen, wenn vorhanden. Auch Daten aus altem Archiv gleiche ich gerne manuell ab mit neuem Archiv und übernehme sie aus altem Archiv manuell. So kriegst Du eine saubere Kiste hin.


    Trotz Absturz ist noch interessant, dass ich auch nach dem Absturz in Automatik Extern schalten kann und die Roboterzelle läuft und wählt anscheinend das nötige Programm an; Es erscheint nur der Programmcode nicht auf dem KCP2 sondern man sieht nur den Dateibrowser, der ewig lädt...

    Programme laufen in "VxWorks / RAMDISK" ab. HMI läuft in Windows. Da Du im Windows rumwurstelst, typischer Effekt. Shared Memory Netzwerk, dass zwischen VxWorks und Windows den Datenabgleich macht, wird gestört. Folge, HMI kann sich nicht mehr aktualisieren mit den Daten von VxWorks. Timeouts, hängende BOF, etc.

    VxWorks braucht Windows zum Leben nur bedingt. Darum kein Wunder, das die Progs laufen und auf der HMI die RAMDISK-Folders des VxWorks nichts mehr anzeigen.


    Netzwerkeinstellungen, die Du verwendest?

    Treiber Netzwerkkarte der MFC2 wurden mal manuell installiert oder mit Installation Windows?


    Wieso nicht einfach kurz über die BOF das xx.src auf D: oder Netzlaufwerk kopieren, bearbeiten, und wieder über die BOF reinkopieren.

    Dann sollte es auch gleich "kompiliert, geprüft" werden.

    Wenn Du ein Fernwartungstool installiert hast, kannst Du das, wenn richtig eingerichtet, alles von extern machen.

    Oder halt gleich ein Remote Downloader verwenden.

    Manche Maenner bemuehen sich lebenslang, das Wesen einer Frau zu verstehen. Andere befassen sich mit weniger schwierigen Dingen z.B. der Relativitaetstheorie.

  • Dieses Problem hat mich jetzt wirklich lange verfolgt und nun glaube ich die Lösung gefunden zu haben: Habe einen anderen Laptop (mit Windows 7 Pro) verwendet und plötzlich ging's wieder - bis dieser Windows Update (v.A. Update KB4516065) ausgeführt hat. Scheint also wirklich dass dieses Update auf dem Programmier-Client, welcher auf die Dateifreigabe auf der KRC2 (SAMBA / CIFS Server) zugreift, diese zum Absturz (den man nur mit Neustart beseitigen konnte) bringen kann.

    Nun verwende ich einen älteren Windows XP PC welcher Files auf der KRC2 via Netzwerkfreigabe bearbeitet - ohne Probleme!

    Das Mainboard hat definitiv 3 DIMM Steckplätze.

    Und ja, habe auch schon dazumals ein System mit diesem Board mit 3x128MB, WinXP, V5.x und WinAC ausgestattet und dies lief zuverlässig.

    Ein 5.2.x Standard-System von dazumals sollte aber problemlos mit 256MB auskommen.

    Bei mir hat 3x128MB irgendwie bis zum Schluss nicht funktioniert, obwohl ich 3x gleiche 128MB Chips (aus einer anderen KRC2) hatte. Habe dann noch vor ich das Problem wie oben beschrieben gelöst hatte den RAM auf 2x256mb geupdated, was aber keine Verbesserung brachte. (Verschlechterung auch nicht, läuft seit dann mit 512mb statt 256mb).

    An den Treibern habe ich nie was geändert, ist jeweils gem. orig. Installation von KUKA. Nur an der 2. Netzwerkkarte setze ich jeweils eine statische IP, die braucht ja die KRC2 intern nicht.


    Natürlich geht auch via D: die Files hochzuladen, ist halt jedes mal etwas umständlicher. Ich muss ja so schon bereits die bearbeitete Datei auf dem KCP2 jeweils noch mal öffnen - ändern - und wieder speichern, damit die Änderungen wirksam werden.

    "Remote Downloader" sagt mir irgendwie was, habe ich wohl schon mal gehört. Habe am Anfang meiner Programmierzeit alternativen recherchiert (auch z.B: "Orange Edit") aber hier nichts wirklich schlaues gefunden.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now