wie kommt das denn zu stande das wenn ich mit r öffne, mir eine handle nummer angezeigt wird aber diese jede sekunde wechselt und zwar zwischen ca 6 verschiedenen werten. aber es existiert doch nur eine datei mit dem namen auf der karte

Zitat:
aber es existiert doch nur eine datei mit dem namen auf der karte

Das mag schon sein, aber die Nummer ändert sich mit jedem Zugriff, das ist nichts anderes als bei Visual Basic. Lesend kannst Du auch mehrmals zugleich auf ein und dieselbe Datei zugreifen, dann bekommt jeder Programmteil seine eigene "Zugriffsnummer", die Software muß wissen wohin mit dem Ergebnis des Zugriffs.

und wieso klappt das nicht mit 'a' oder 'w' ?

Siehe weiter oben:

SysFileOpen EINMALIG aufrufen, bzw. so oft bis ein gültiges Handle (Rückgabewert > 0) auftritt.

!!! DANACH NICHT MEHR AUFRUFEN !!!

Dann ändert sich auch das Handle nicht mehr.

Hi schmandy

Ich werde mal versuchen, ein Example zu schreiben, das

ziemlich Hardwareunabhängig ist.

(Soweit als auch ein Filesystem vorhanden ist)

Kann ich mit deiner Unterstützung rechnen ?

Hi Erik

Zitat:
SysFileOpen EINMALIG aufrufen, bzw. so oft bis ein gültiges Handle (Rückgabewert > 0) auftritt.
!!! DANACH NICHT MEHR AUFRUFEN !!!
Dann ändert sich auch das Handle nicht mehr.

Volle Zustimmung.

Ergänzend noch zu sagen.

Vor beenden b.z.w. NACH dem öffnen mit SysFileOpen, nachdem

du das Programm verlassen willst --> Handle mit SysFileClose SCHLIESSEN ! ! !

(Das bleibt sonst möglicherweise offen, und diese sind je nach Harware

auf etwa 8 Dateien begrentzt )

Eventuell komplett die Spannung von Controller nehmen.

Test sollte zuerst mit "Lese-Operationen" geprüft werden.

Kopieren einer Dateien die du Auslesen kannst z.b. mit ftp !

Hinweise auf meiner Homepage "ftp-Handling".

vielen dank für eure ganzen bemühung dieses forum ist echt klasse!!!!!!

@gravieren

ich bin für alles zu haben aber ich muß halt dazu sagen das ich mich erst seit 2 wochen mit der ganzen sache beschäfftige.

mit dem "nur einmal öffnen" meinst ihr das so das die file nur einmal im prg geöffnet werden darf oder einmal im zyklus? weil wenn es nämlich nur einmal im prg sein darf dann weiß ich wo der fehler ist.

so wie ich es jetzt hab öffnet er sie in jedem zyklus(oder vesucht es zumindest).dann müßte ich ja quasi eine bedingung vorran stellen die testet ob die dat_handle > 0 ist und wenn ja soll er gleich in sysfilewrite springen

könnte das so gehen?

Hi schmandy

Zitat:
ich bin für alles zu haben aber ich muß halt dazu sagen das ich mich erst seit 2 wochen mit der ganzen sache beschäfftige.

Meinst du CoDeSys oder Dateihandling.

Zitat:
mit dem "nur einmal öffnen" meinst ihr das so das die file nur einmal im prg geöffnet werden darf oder einmal im zyklus?

Äh, um Missverständnisse zu vermeiden.
Programm starten.
Irgendwann, in irgend einen Zyklus verwendest du den "SysFileOpen".
Du merkst dir diesen einen Aufruf.

Danach darf man diesen Aufruf NICHT mehr machen.
Denn bei jedem Aufruf öffnest du ein neues Handle.
Bei einem Halben dutzend "handles" hast du keine mehr.

Zitat:
weil wenn es nämlich nur einmal im prg sein darf dann weiß ich wo der fehler ist.

Das ist Erik Rede.

Zitat:
so wie ich es jetzt hab öffnet er sie in jedem zyklus(oder vesucht es zumindest).

Nach ca. 80ms hast du keine Handles mehr.

Zitat:
dann müßte ich ja quasi eine bedingung vorran stellen die testet ob die dat_handle > 0 ist und wenn ja soll er gleich in sysfilewrite springen
könnte das so gehen?

Nein.

• Flankenwechsel von Signal.

(Webvisu, Eingang, Timer alls 10 minuten ...)

• Ansprung von Funktion zum öffnen einer Datei.

• Merken das 1malig erfolgt ist. (dhdl := TRUE)

• Beim nächsten Durchlauf abfragen und NICHT mehr offnen.

• Abfragen ob Dateihandle gültig.

• Falls ja, schreiben/lesen in die Datei.

• Beim schreiben merken, dass "text" geschrieben wurde.

Ansonsten schreibt er den Text bei jeden Zyklus neu.

(Je nach text hast du keinen Dateispeicher mehr frei.

• Nach erfolgreichem Schreiben, falls du NICHTS mehr speichern willst die Datei schliessen.

(ACHTUNG nur 1 x schliessen und NICHT bei jedem Zyklus neu

• Hintergrund: Eine SPS ist KEIN "Von Neumann-Rechner"

Die SPS wartet NICHT bei jedem Befehl bis er ausgeführt wurde.

D.h. Speicherst du eine Datei mit z.b. 1.250.000 Zeichen könnten Sekunden vergehen.

In dieser Zeit würde die SPS stehen/Stopen, was ja keiner eigentlich mag.

TIP, Hol dir nochmals die Examples von meiner Homepage.

Drucke Sie dir aus.

Die Datei-Librarys von mir sind eigentlich NUR verpackte SysFile.. Funktionen.

(Wollte die verpacken, um vom wesentlicche NICHT abzulenken)

Schau dir die vorgehensweise NOCHMALS an.

Nach 2-3 mal lesen wirst du verstehen, wie dir Sache läuft.

danke gravieren für die sehr umfangreiche beschreibung..

werde sie auf jedenfall heut durcharbeiten und dann sollte es funktionieren.

und zu deiner 1. frage:

ich beschäfftige mich mit CoDeSys allgemein erst seit zwei wochen..

wir programmieren hier eigentlich nur außschließlich nur siemens sps.

aber mir gefällt die Entwicklungumgebung von codesys immer besser

wie gesagt ich geh es nochmal durch und danke nochmal!!!

so ich hab es endlich geschafft mit dem schreiben,zwar in einer weise die mir nicht ganz logisch erscheint:

und zwar hab ich bevor ich sysfileopen aufruf eine sysfileclose gesetzt.

und siehe da es funktioniert

dank euch allen nochmal..

Hallo

Also, sorry, aber du hast das Prinzip immer noch nicht verstanden...

Wenn du jetzt immer einen FileClose() vor dem FileOpen() aufrufst, dann mag das wohl funktionieren, aber es ist immer noch falsch.

Beim FileClose() wird dein im letzten Zyklus geöffnetes Filehandle wieder ungültig und mit FileOpen() ein neues erstellt.

Besser wärs, wenn du den FileOpen() machst, dir das Handle merkst, dann deine FileRead() / FileWrite() so oft wie benötigt aufrufst und anschliessend einen FileClose() aufrufst.

Dann wird das beim nächsten mal schreiben auch ohne vorherigen FileClose() funktionieren.

Gruss

Erik

HI

also ehrlich gesagt geb ich zu das ich das nicht verstehe weil es mir auch total unlogisch erscheint.

aber anders geht es nicht. wenn ich die reihenfolge einhalte open->write->close bekomm ich noch nicht einmal eine nummer zugewiesen die ich dann eventuell merken könnte. und es kommt immer die fehlermeldung. öffne ich allerdings die datei mit dem mode 'r' bekomm ich eine nummer.

aber egal es funktioniert ich werde mich aber damit noch ein wenig weiter beschäfftigen. leider hab ich jetzt die steuerung nicht mehr weil ich sie weggeben mußte.

aber trotzdem vielen dank

Hallo schmandy,

ich habe Dir mal ein Beispiel angehängt, in dem in einer XC201 auf die MMC geschrieben wird. Zum Schreiben habe ich eine Statemachine implementiert, die in jedem Durchlauf nur eine Funktion ausführt. Die Statemachine läuft in einer niederprioren Task. Der Watchdog ist momentan nicht aktiviert, weil die Zugriffe (Schreiben) auf die MMC stark von der Datenmenge und vom Typ der MMC abhängt. Ich habe MMCs untersucht die teilweise bis zu 300ms brauchten, um um eine gewisse Datenmenge zu schreiben (ist halt 'ne serielle Schnittstelle).

Die genauen Zeiten bekommst Du raus, wenn Du im Browser den Befehl "tsk" eingibst.

Ich hoffe, es hilft Dir weiter.

Gruß

Klaus

FileWriteExample.pro [31.57 KiB]

ich danke dir für dieses sehr schöne beispiel.. leider kann ich es nicht einmal testen weil ich keine steuerung mehr hab vielleicht bekomm ich ja mal noch eine.aber dieses beispiel ist sehr einleuchtend..

danke!!!

So, dann will ich diesen Beitrag noch mal aufgreifen. Habe ein ähnliches Problem, allerdings kann ich nicht die selbe Lösung nutzen.

Muss Messwerte in eine Datei schreiben, das wird alle 30s oder jede Minute passieren. In der Zwischenzeit soll die Datei aber wieder geschlossen werden, um bei einem Stromausfall keinen allzu großen Datenverlust zu haben.

Ich habe nun also mein Hauptprogramm, das die Messwerte einließt, und in einer AS die 3 Schritte Open, Write und Close. Die Datei wird auch geöffnet, die Daten werden geschrieben, aber beim close kommt immer der Watchdog-Fehler. Es sei denn man benutzt den Einzelschrittmodus, da wird die Datei auch ordnungsgemäß geschlossen, und man kann die Datei lesen.

MfG Joachim.

Hi

Zitat:
Ich habe nun also mein Hauptprogramm, das die Messwerte einließt, und in einer AS die 3 Schritte Open, Write und Close. Die Datei wird auch geöffnet, die Daten werden geschrieben, aber beim close kommt immer der Watchdog-Fehler. Es sei denn man benutzt den Einzelschrittmodus, da wird die Datei auch ordnungsgemäß geschlossen, und man kann die Datei lesen.

Mach doch mal ein Testprogramm.

Schreibe alle Minute eine Text-Zeile hinein.

Lese das Filehandle "vor den 3 Aktionen aus".

Lese das Filehandle "nach de 3 Aktionen" aus.

Wird das Filehandle grösser als 7 ?

Weitere Frage, wertest du die "Return"-Codes aus ?

Wo kommt ein Fehler.

Das schreiben der Dateien erfolgt NICHT in 1 CPU-Zyklus.

(Es werden meherer Zyhlen hierfür benötigt)

Teste doch mal unter Umständen mein Example auf meiner Homepage.

Klappt es hiermit.

Von hier aus kannst du weiter aufbauen.

Wie immer sind wir für ein Feedback dankbar.

Also das Filehandel ist größer als sieben, ist glaub ich sogar größer als sieben-stellig .

Verändert sich aber auch nicht, also ist immer die selbe Ziffernfolge. Also bei jedem Datei-Zyklus das selbe Handel.

Mein Problem ist wohl doch ein anderes als das ursprüngliche in dem Topic. Habe den Watchdog deaktiviert, und jetzt läuft es auch. Die Datei wird angelegt, und die Werte werden in die Datei geschrieben, und diese wird orgentlich geschlossen. Man merkt merklich das der Schritt SysFileClose sehr lange dauert, und das PLC_PRG da eine sehr lange Pause macht (über 1s).

Hi Joachim Ueltzen

Zitat:
Also das Filehandel ist größer als sieben, ist glaub ich sogar größer als sieben-stellig .
Verändert sich aber auch nicht, also ist immer die selbe Ziffernfolge. Also bei jedem Datei-Zyklus das selbe Handel.

Die "handles" eines WAGO 750-841 nehmen den Wert 1 bis ca. 7 an.
Leider hast du die Hardware NICHT angegeben.

Zitat:
Mein Problem ist wohl doch ein anderes als das ursprüngliche in dem Topic. Habe den Watchdog deaktiviert, und jetzt läuft es auch.

Seltsam !

Zitat:
Man merkt merklich das der Schritt SysFileClose sehr lange dauert, und das PLC_PRG da eine sehr lange Pause macht (über 1s).

Ach so, die CPU-Zeit ist da wohl etwas lange geworden.

Naja, Echtzeit hin oder her, sollte die CPU-Zeit mal 1 oder 2 Sekunden sein, ist das nicht weiter schlimm

Spasbeiseite, mir würde das einen "Schock" versetzen.

Steuert die SPS irgendwas wichtiges.

Du willst "nur" Messwerte in eine Datei schreiben.

Hier fehlen dir möglicherweise einige Daten bei der Aufzeichnung ?

(Oder wird erst kurz vor dem Schreiben die Me?werte gelesen)

Dieses "Verhalten" der CPU würde mich beunruhigen.

Hast du alles in eine Task geschrieben, ODER für das Sichern eine eigene Task erzeugt.

Ist die Haupttask freilaufend.

Ich denke, ich sollte dieses eigenlich triviale Problem mal "analysieren".

(Leider fehlt mir momentan die Zeit)

Moin

Wenn das Filehandle eine mehr als 7 stellige Zahl ist, dann vermutlich: 4294967295.

Das wäre dann ein -1, also ein ungültiges Handle.

Sprich eine Fehlermeldung von FileOpen().

Falls das eine RTE, oder was ähnliches mit ner Festplatte ist, dann dauert ein Filezugriff um die 15ms. Egal ob lesend oder schreibend.

Wenn FileClose() so lange dauert, dann ist was Faul, oder das Medium ist ein Flash-Speicher, und der gesammte Puffer wird 'am Stück' geschrieben.

Sollte die SPS zwischendurch noch was wichtigeres tun, dann muss das Filehandling in eine extra Task (nieder priorisiert) ausgelagert werden. Das würde ich aber sowieso empfehlen.

Gruss

Erik

Hallo zusammen,

wer sich mal die Mühe macht und die Dok vom 3S liest, wird feststellen, dass SysFileOpen() eine NULL zurückliefert, wenn's nicht geklappt hat. Alles andere sind gültige Handles.

Die XC200 benutzt im Gegensatz zur XC100 die SysLibFile vom 3S, d.h.

es sind Funktionen (keine FBs) , die im Zyklus ausgeführt werden. Die XC100 benutzt FBs, die in einer Hintergrundtask laufen.

Ich habe mal ein Beispiel angehängt., wie man in der XC200 mit Files umgehen kann. Wichtig ist das Handling in einer separaten Task mit genug Laufzeit und die Statemachine, sonst schlägt der Watchdog an. Die Zeit zum Schreiben hängt stark von der zu schreibenden Datenmenge ab, außerdem wird die interne Flashdisk zunehmend fragmentiert, wenn oft geschrieben wird, d.h. die Zugriffe werden mit der Zeit langsamer.

Gruß

Klaus

FileWriteExample.pro [31.57 KiB]

Mahlzeit

Die Dokumentation ist wohl für die meisten Zielsysteme korrekt, aber die RTE bringt definitiv ein -1 zurück, wenn kein Handle verfügbar ist.

Darum funktioniert in diesem Fall eine Abfrage auf <> NULL auch nicht .

Gruss

Erik

Kurzer Auszug aus den Quellen vom RTS der FileOpen-Funktion:

            hFile = CreateFile(....)

           ........



if (hFile == INVALID_HANDLE_VALUE)

    return NULL;

Ist doch eine NULL, oder?

Gruß

Klaus

Hi

Ich hab leider keine Quellen der SysLibFile() für die RTE.

Aber wie gesagt, NULL stimmt fast immer, ausser bei der RTE.

Darum frage ich das Handle auf > 0 ab, dann passts bei allen Zielsystemen.

Gruss

Erik

So, dann will ich mich hier auch mal zurückmelden. Hatte nen paar private Dinge zu klären. Und arbeite jetzt an dem Projekt weiter. Bin noch dabei ein paar Änderungen vorzunehmen. Aber in einer Woche muss das Problem mit der langen Speicherzeit dann gelöst sein.

Wenn ichs gelöst habe, oder weiß was es verursacht hab werd ichs dann hier noch mal posten.

(könnte wie Softwerker59 meint ja wirklich nur an dem Flash-Speicher liegen den ich im Moment noch zu Testzwecken nutze)

So, hab meine einzelnen Unterprogramme jetzt mal über die Tasksteuerung laufen lassen, und da klappts dann auch.

Was mich da nur ein bisschen stutzig macht sind die Zykluszeiten, meistens liegen sie in einem verkraftbaren Bereich (16ms bei FileClose), aber die maximale Zykluszeit liegt hier bei 211ms, und das ist dann ja doch recht lange.

Werd wohl mal ne eigene Bibliothek dafür schreiben, und schaun obs dann etwas schneller geht.