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

Reentranz der SysLibFile-Funktionen

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

SC24
RTOS 1.40
CoDeSys 2.3.9.19
extsd 1.40
extusb 2.07

Beim Einloggen in ein laufendes CoDeSys-Projekt mit der IDE führt es regelmäßig dazu,
dass die IDE versucht, Dateien auf den IPC hochzuladen (vornehmlich die WebVisu-Dateien).
Dies ist aber nicht notwendig, da das Projekt nicht geändert wurde, auch keine Neucompilation.

Anschließend kommen Fehlermeldungen wie z.B.
File transfer failed: 'webvisu.htm'
Laufzeitfehler #35 (webvisu.htm)

Zum Programm:
In einer IEC-Task wird ein File alle 5 Sekunden geschrieben. Dabei werden die Funktionen aus
der SysLibFile.lib verwendet: SysFileOpen, SysFileWrite, SysFileClose. Die Filefunktionen werden nur in dieser Task benutzt.

Das Problem tritt auf, egal ob auf Flash, USB oder SD geschrieben wird. In einigen Fällen hat es dazu geführt, dass das Codesys-Programm gestoppt wurde oder dass das Filesystem (dir-Befehl) nicht mehr lesbar war.

1. Wie geht Codesys mit parallelen Filezugriffen um?
2. Wie geht RTOS(Filesystem, Treiber) mit parallelen Filezugriffen um?
3. Sind die Filefunktionen der SysLibFile.lib reentrant?
4. Wann wird eine neue Version der CoDeSys-IDE freigegeben?

Es muss immer ein Monitoren des laufenden Codesys-Programms, WebVisu oder IDE,
möglich sein, ohne dass das Programm instabil oder sogar gestoppt wird.

mfG. Markus Mehlan

Hallo Herr Mehlan,
Wenn ich richtig verstanden habe haben Sie auf dem SC24 ein Boot Projekt laufen und wollen sich dann einloggen und dann wird immer alles Übertragen!?
Da muss was an ihrem Projekt nicht ganz sauber sein, wenn alles richtig ist macht der CoDeSys das nicht.
Wenn Sie uns auch noch mitteilen könnten was Ihr Problem ist könnten wir vielleicht helfen.
Aus ihrem Text kann ich leider nicht herauslesen was das Problem eigentlich ist.
>Es muss immer ein Monitoren des laufenden Codesys-Programms, WebVisu oder >IDE, möglich sein, ohne dass das Programm instabil oder sogar gestoppt wird.
Ist es auch, hier liegt eindeutig ein Fehler in ihrem Projekt vor.
Was für eine SDK Version benutzen Sie?
Sie können bei 3S eine neue CoDeSys Version herunterladen (.24) wir werden bei uns erst Anfang 2011 eine neue CoDeSys Version in unserem Download – Center anbieten.
Wenn Sie uns mal ihr Projekt mal zusenden könnten, kann ich gerne mal rein schauen.
Mit freundlichen Grüßen
i.A. Günter Berberich

Hallo Herr Berberich,

ich habe ein Testprojekt (DB54) hochgeladen. Bei diesem Projekt fällt auf,
dass alle 6 Schreiboperationen ein Ausreißer in der Taskzykluszeit zu sehen ist.
Normale Zeit: ca 40ms
Ausreißer: ca 900ms
Dies passiert nur, wenn auf A: geschrieben wird. Wenn man auf die SD-Karte (B:) oder auf den USB-Stick (D:)
schreibt, läuft alles normal. Das komplette Programm kann ich Ihnen nicht schicken.

Zu Ihren Fragen:
1. SDK:CoDeSysatCHIP_SDK_Update_03_2010 /CLIB 2.20

2. Das Problem ist, dass In einigen Fällen das Einloggen dazu führt, dass das laufende Codesys-Programm gestoppt wurde oder dass das Filesystem (dir-Befehl) nicht mehr lesbar war.

In diesem Zusammenhang brauche ich Antworten auf die schon von mir gestellten Fragen:
1. Wie geht Codesys mit parallelen Filezugriffen um (Zugriff von IEC + Zugriff vom OS)?
2. Wie geht RTOS(Filesystem, Treiber) mit parallelen Filezugriffen um?
3. Sind die Filefunktionen der SysLibFile.lib reentrant (auch systemweit)?

mfG. Markus Mehlan
Attachments
FileTestOrig.zip
(171.31 KiB) Downloaded 159 times

Hallo Herr Mehlan,

Ihr Test Programm funktioniert bei mir ohne Fehler.
Kommt dieser Fehler nur bei einem SC24 vor oder auf mehreren?
Wenn es nur auf einem vorkommt, können Sie mal bitte das Laufwerk A:\ neu formatieren!
Über Flash / format_sc2x.hex
Nach dem was Sie geschrieben haben würde ich fast behaupten ihr File System auf A:\ ist defekt.

>ich habe ein Testprojekt (DB54) hochgeladen. Bei diesem Projekt fällt auf,
>dass alle 6 Schreiboperationen ein Ausreißer in der Taskzykluszeit zu sehen ist.
>Normale Zeit: ca 40ms
>Ausreißer: ca 900ms
>Dies passiert nur, wenn auf A: geschrieben wird. Wenn man auf die SD-Karte (B:) oder auf den USB-Stick (D:)
>schreibt, läuft alles normal. Das komplette Programm kann ich Ihnen nicht schicken.

Diese Ausreißer in der Taskzykluszeit sind normal, es kommt immer darauf an was noch für Tasks laufen und wie die Prioritäten gesetzt sind.
Wie viele Daten per schreib Operation übertragen Sie?
Wie haben Sie die Prioritäten in der Chip.ini gesetzt?

>1. Wie geht Codesys mit parallelen Filezugriffen um (Zugriff von IEC + Zugriff vom OS)?
>2. Wie geht RTOS(Filesystem, Treiber) mit parallelen Filezugriffen um?
>3. Sind die Filefunktionen der SysLibFile.lib reentrant (auch systemweit)?

RTS macht keine Datei direkten zugriffe nur über das RTOS.
Wenn das IEC Programm in nur einem IEC Task File operationen macht, gibt es keine parallele zugriffe.
Wenn andere Programme zugreifen(außerhalb vom RTS) kann diese passieren.
Aber niemals können / sollten unterschiedliche Prozesse gleichzeitig auf die gleiche Datei zugreifen.

Mit freundlichen Grüßen
i.A. Günter Berberich

Hallo Herr Berberich,

3. Sind die Filefunktionen der SysLibFile.lib reentrant?

Die Fehler kommen auf mehreren SC24 vor.

WIr greifen auf verschiedene Datein zu. Z.B. schreibt das IEC-Programm auf die Datei
A:\Betr.txt und über FTP lade ich eine Datei nach A:\abc.txt.

mfG. Markus Mehlan

Hallo Herr Mehlan,

>3. Sind die Filefunktionen der SysLibFile.lib reentrant?
Nein Funktionen von SysLibFile.lib greifen auf RTOS Funktionen zb. fRead oder fWrite zu hier finden Sie Info in der RTOS Docu.
Wir konnten leider ihr Problem bei uns nicht nach voll ziehen.
Setzen Sie die SC24 in einer eigenen Hardware ein?
Um ihnen weiter zu helfen benötigen wir eine Hardware wo dieses Problem erscheint.

Mit freundlichen Grüßen

i.A. Günter Berberich

Hallo Herr Berberich,

wir müssen die SysLibFile.lib verwenden, da wir Logs auf dei SD-Karte schreiben. Da die verwendeteten Funktionen, wie schon vermutet, nicht reentrant sind, sind Probleme schon vorprogrammiert, z.B. bei gleichzeitigen Zugriffen auf das Dateisystem durch FTP oder die Codesys-IDE. Die Probleme treten eventuell nur auf, wenn man eine höhere Taskauslastung hat. Gleichzeitiger Dateisystemzugriff hat bei uns mehrmals dazu geführt, dass das Dateisystem korrupt wurde und/oder die IEC-Applikation instabil wurde.
Eigene Dateizugriffe können wir durch entsprechende Maßnahmen (Semaphoren) entkoppeln, aber nicht die Dateizugriffe des RTOS/Codesys.
Wir setzen den SC24 in einer eigenen Hardware ein. Das Problem ist aber ein grundlegendes und muss deswegen auch auf anderer Hardware auftauchen. Was können Sie sich als Lösung/Workaround vorstellen?

mfG. Markus Mehlan

Hallo Herr Mehlan,
wir werden dieses Problem mit Hilfe ihren Infos, versuchen bei uns nach zu vollziehen.
Da CoDeSys auf RTOS Funktionen zugreift liegt mit Wahrscheinlichkeit das Problem beim RTOS.
Wir werden uns im Januar gleich an dieses Problem annehmen und versuchen so schnell wie möglich eine Lösung zu finden.
Wir bedanken uns für Zusammenarbeit und wünschen Ihnen ein frohes Weihnachtsfest, Gesundheit und Erfolg für das kommende Jahr.

Mit freundlichen Grüßen
i.A. Günter Berberich

Hallo Herr Berberich,

nun sind schon 3 Monate vergangen...
Wie sieht es aus mit der Lösung?

mfG. Markus Mehlan

Sehr geehrter Herr Mehlan,

Sorry das es so lange gedauert hat, aber wir denken jetzt auch ihren Fehler mit der neuen RTOS Version 1.4 und der Nachfolgende CoDeSys Änderung behoben ist.

Wir haben zwischendurch noch einen Fehler in unsere RTS-Bibliothek gefunden.
Unter bestimmten Umständen hatte der Fehler das Effekt das bei der Funktion CONCAT ein CPU-Register nicht gesichert wurde. Hiermit könnte eine sog. Zeitbombe gestellt werden der schon bei vielen Kunden sehr komische Effekte generiert hat (Divide Error im CTRL Task, TCP/IP Mem Überlauf, 100% CPU-Auslastung usw.).

Anbei habe ich für Ihnen einen reduzierten Zip-Archiv angehängt. Dies sollen Sie in die Installationsverzeichnis des SDKs auspacken (der Verzeichnis mit die folgenden Subdirs: Bin, Doc, Samples, Templates, Tools) und damit die Libs und RHI.H Dateien überschreiben.
Den ZIP enthält neue Bibliotheken für das RTS und der rhi.h Datei für alle Samples und Templates.

Nachdem Sie mit das Auspacken in diesen Verzeichnis, die Libs und Rhi.h Dateien überschrieben haben, müssen Sie noch in die von Ihnen generierten IEC-Plattforme die rts_v2_f.lib selber ersetzen. Am einfachsten geht dies mittels folgendes Szenario:
- Löschen Sie in ihren IEC-Plattform die Inhalte der Subverzeichnisse rts/lib und rts/Include.
- Starten Sie den IEC-Platform Builder Tool mit den Option "/F".
- Öffnen Sie die zum IEC-Platform gehörende xml-Beschreibungsdatei.
- Generieren Sie das Platform neu (Make-Button)

Mittels den Option "/F" erzählen Sie den IEC-Platform Builder um in einen schon existierendes IEC-Platform für das RTS die fehlende Dateien neu an zu legen. Die zu aktualisierende Dateien haben wir gerade vorher gelöscht.
Nachdem sollen Sie ihr IEC-Platform neu kompilieren und aufspielen.

Mit freundlichen Grüßen
i.A. Günter Berberich
Attachments
Update_03_2011.zip
(2.28 MiB) Downloaded 150 times

Hallo Herr Berberich,

die beschriebenen Änderungen funktionieren formal einwandfrei.
Aber der Linkerlauf beim Erzeugen des "myrts.exe" wirft Fehlermeldungen:

Undefined symbol _RHICTRLCycleStart in module bc_rhi
Undefined symbol _RHICTRLCycleEnd in module bc_rhi
Undefined symbol _RHICTRLPrgReset in module bc_rhi
Undefined symbol _RHIIOConfigChanged in module bc_rhi
Undefined symbol _RHIIOUpdateStart in module bc_rhi
Undefined symbol _RHIIOUpdateEnd in module bc_rhi


Haben Sie dafür einen Lösungsvorschlag?

Mit freundlichem Gruß
GeraldB

Return to CoDeSys SDK


Who is online

Users browsing this forum: No registered users and 1 guest


cron