www.beck-ipc.com
www.beck-ipc.comwww.beck-ipc.com  | ImprintImprint
FAQFAQ  | SearchSearch  |
RegisterRegister   |LoginLogin

Webvisu verursacht instabiles System

Questions and discussions about the CoDeSys SDK with the IPC@CHIP® plattform.
Hallo Herr Pribil,

endlich bin ich der Thematik "Wachstum von TCPIPMEM" ein Stück voran gekommen.

Beim "Eindampfen" meines Beispielprojekts habe ich auch die scheinbar kritischen Module mit Dateihandling genauer unter die Lupe genommen und alle denkbaren Fehlerquellen mit Meldungen abgefangen. Im Betrieb zeigte sich, daß keine Fehlermeldungen geworfen werden. Das "Aufräumen" in meinen Modulen hatte aber den Nebeneffekt, daß das Wachstum von TCPIPMEM deutlich verlangsamt wurde. es dauerte 5...6 Tage bis die 512kByte-Grenze erreicht wurde, vorher waren es nur wenige Stunden. Eine Erkärung habe ich nicht dafür, der Code ist nicht weniger geworden, eher mehr wegen der Fehlerabfragen. Die zeitliche Belastung scheint eine bedeutende Rolle zu spielen.

Wegen dieses günstigeren Verhaltens habe ich das Problem erst einmal in der Priorität herabgestuft. Zumal in meiner realen Applikation das Fehlverhalten von TCPIPMEM nicht gezielt stimuliert wird.

Zur Erinnerung: Das kritische Verhalten von TCPIPMEM wird dann provoziert, wenn Datei-Lesen, Datei-Schreiben und Webvisu häufig ausgeführt werden.

Das ist der Stand bis gestern, 28.03.2011.

In der Zwischenzeit habe ich meine Applikation weitergeführt und vor allem auch um Webvisu-Anteile ergänzt. Hier habe ich auch Masken aus anderen Projekten importiert. Die importierten Masken beinhalten üblicherweise auch Objekte die in ihren Eigenschaften auf Variablen verweisen, die im Zielprojekt so nicht vorhanden sind. Wenn diese Variablen dann durch Wegnahme des Häkchens "gegraut" werden, ist die Codesys-IDE 2.3.9.19 damit zunächst zufrieden.

Spätestens ab der Version 2.3.9.24 ist es damit vorbei. Die IDE wirft Warnungen beim Übersetzen, diese sollten ernst genommen und vollständig eliminiert werden. Alle Visualisierungsobjekte müssen "gecleant" werden. es dürfen keine "Leichen" im Kontextmenü "Element konfigurieren" mitgeführt werden. Es reicht nicht aus, den Haken beispielsweise bei "Variabe toggeln" wegzunehmen, das Feld dahinter muss leer sein, oder mit einer gültigen Variable belegt sein. Inaktiv und "ausgegraut" reicht nicht!
Wenn "Programm ausführen" mit inaktiven Formeln und Platzhaltern hinterlegt ist, führt das sogar zum reproduzierbarem Absturz der IDE! Das ist ein neues Feature ab Version 2.3.9.24.

Mit einem Projekt, das zur Übersetzungs- und auch zur Downloadzeit ohne jegliche Warnung geladen werden kann, habe ich im Moment scheinbar keine Probleme mehr mit TCPIPMEM!!!
Ich verwende im Moment schon die Codesy-IDE 2.3.9.26.

Ich kann dringend die Codesys-IDE ab Version 2.3.9.24 empfehlen und rate, akribisch jede Warnung zu verfolgen und auszumerzen.

Meines Wissens ist von Beck die Version 2.3.9.24 noch nicht offiziell freigegeben.

Soweit mein Wissensstand, ich werde weiter beobachten und berichten.


Einen schönen Gruß von

GeraldB

Hallo zusammen,

das oben beschriebene Problem liegt nun drei Jahre zurück.

Mein System läuft seitdem im 24/7 Betrieb, nahezu störungsfrei. Aber eben nur nahezu.

Ich habe in gewissen Abständen (Wochen bis Monate) einen "Hänger": Ich kann nicht auf die Webvisu zugreifen und beim Telnet-Zugriff erhalte ich beim Tasks-Kommando immer eine Auslastung von nahezu 100%!

Durch einen Reset=eboot kann ich die Situation temporär bereinigen. Ich sehe aber, daß eine Retain-Variable, welche ich in einem externen I2C-Speicher ablege, nicht mehr mit dem korrekten Wert beim Start belegt ist.
Hier habe ich den Verdacht, daß der I2C-Bus langfristig das System beeinflusst.

Der Wert von TCPIPMEM bleibt aber stabil! Dieses ehemalige Problem durch die Codesys-IDE scheint stabil gelöst zu sein, siehe meine letzter Beitrag.
Ich kann das nur einkreisen, indem ich das I2C-Handling versuchsweise komplett ausklammere.

Neue Brisanz kam jetzt ganz aktuell in das Thema, weil mit den Update von Java auf 1.7.0_51 keine Codesys2.3-Webvisu mehr funktionierte, nur noch Sicherheitshinweise und Blockage! Das betrifft nicht nur Beck, sondern auch Wago und andere.
Hier hat 3S reagiert und eine neue Codesys-IDE 2.3.9.43 zur Verfügung gestellt. Das Problem scheint damit behoben zu sein.
Meine Webvisu läuft jetzt wieder, aber meine Applikation schmiert sofort nach dem Start ab. Tasks liefert 100% Auslastung und mein SPI-Bus spinnt.
Auch ein Downgrade auf die alte Codesys-IDE 2.3.9.38 konnte die Applikation nicht mehr retten. Anscheinend hat sich soviel "Unrat" im System angesammelt, der durch einen normalen Reboot nicht bereinigt wird! Dieses System läuft seit einem halben Jahr ohne PowerOff!

In diesem Thread hat sich anfangs auch Herr Siegl eingeklinkt. Mit dem Abstand von drei Jahren sehe ich jetzt auch die mögliche Verbindung dieser Problemkreise über die Nicht-Reset-Fähigkeit der IPC-Hardware!

Die Fragen an Beck lauten konkret:
- Wie sieht es mit einer Freigabe von Codesys 2.3.9.43 aus.
- Kann der SC24 auch ohne PowerOff einen echten Hardware-Reset ausführen
- Welche C-Lib und welches RTOS müssen mindestens eingesetzt werden, um eine stabile Hardware zu gewährkleisten?
- Kann das RTOS-Upgrade auf 1.8 erfolgen ohne das eigene Codesys-Bibliotheken mit der neuesten C-Lib übersetzt werden müssen?

Ob es dazu eine Rückmeldung geben wird?

Vielen Dank im Voraus und
Schöne Grüße

Hallo,

zur Frage "Kann das RTOS-Upgrade auf 1.8 erfolgen ohne das eigene Codesys-Bibliotheken mit der neuesten C-Lib übersetzt werden müssen?":
Ein neues RTOS ist stets abwärtskompatibel, so dass Sie es aufspielen können, ohne ihre eigenen Programme neu kompilieren zu müssen.

Mit freundlichen Grüßen

Johannes Heinemann
Johannes Heinemann
Software Development
Beck IPC GmbH

Hallo,

Kann der SC24 auch ohne PowerOff einen echten Hardware-Reset ausführen

Das Ausführen des "reboot" Shell-Kommandos, bzw. die BIOS_Reboot() API sorgt dafür das der Hardware-Watchdog der CPU einen Hardware-Reset durchführt. Power-On und Reboot sollten sich daher gleich verhalten. Wie sich die Peripherie allerdings bei einem Reboot verhält kommt auf die Schaltung an. Der Reboot löst jedenfalls auch das Signal Reset-Out aus. I2C-Bausteine haben aber üblicherweise keinen Reset-Eingang. Wenn ein I2C Zugriff durch einen Reboot unterbrochen wurde, dann kann es sein das der I2C Baustein beim nächsten Start nicht korrekt funktioniert. Hier hilft dann die I2C_bus_reset() API weiter.

MfG,
André Pribil
Software Development
Beck IPC GmbH

Hallo,

GeraldB wrote:Wie sieht es mit einer Freigabe von Codesys 2.3.9.43 aus.


CODESYS 2.3.9.43 wird im März frei gegeben.

MfG,

Previous

Return to CoDeSys SDK


Who is online

Users browsing this forum: No registered users and 2 guests


cron