SysLibFile und Taskkonfiguration

[m.hoeft]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich habe folgendes Szenario:

• ein Wago PFC200 steuert eine Spielhilfe für eine Orgel
• es gibt mehrere Nutzer, die sich mit einem RFID-Chip anmelden
• jeder Nutzer hat seine eigenen Einstellungen
• es gibt einen Haupttask mit höchster Priorität (6), der auf die Nutzereingaben reagiert
• weitere Tasks, auch Hintergrundtasks, versorgen den Chipleser, verschiedene Anzeigen usw.

Die Einstellungen werden in Binär-Dateien auf einer SD-Karte gespeichert, die gelesen werden, wenn sich der Nutzer anmeldet, und geschrieben, wenn er eine Einstellung ändert. Die Aufrufe SysFileRead und SysFileWrite habe ich direkt in den Haupttask eingebunden.

Wago rät von diesem Vorgehen ab. Sie empfehlen, Lesen und Schreiben in einen Hintergrundtask auszulagern. Eine wirklich zwingende Erklärung warum, konnte ich aber leider nicht bekommen. Deshalb würde ich gerne die Meinung der anderen Fachleute hören.

Soweit ich beobachten kann (was Wago auch bestätigt), verlängert sich die Laufzeit für einen Zyklus erheblich, deutlich über das eingestellte Aufruf-Intervall hinaus. Wegen der hohen Priorität werden natürlich auch die anderen Tasks blockiert. Aber kann das zu ernsthaften Problemen führen?

Nach meinem (zugegeben anfängerhaften) Verständnis ist dieses Verhalten eigentlich sogar erwünscht, weil der Controller erst wieder reagiert, wenn Lesen/Schreiben vollständig abgeschlossen sind.

Viele Grüße Michael Hoeft

 

[holgermaik]

Aber kann das zu ernsthaften Problemen führen?

Ich kann mir unter eine Spielhilfe zwar nichts vorstellen, denke aber mal da dies in deinem Fall nicht schön aber auch nicht störend ist.

Wenn du jetzt aber mal an einen Maschine denkst, die ein Bediener ausschalten möchte, und er muss warten, bis der Controller die SD Karte gelesen hat
ist diese Programmierung völlig inakzeptabel.
Holger

 

[b4w3f]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es ist die Frage was eine Spielhilfe ist. Bei der Stuerung von Mechaniken ist das lesen und schriben von Dateien im Haupttask ein Nogo. Wenn deiner Stuerung es aber egal ist, wenn ein Task mal 500- 1000 ms (auch gerne länger) daert ist das alles kein Problem. Kann man in der Zeit des Lesen/Schreibens irgendwelche Eingaben bedienen, werden diese Eingaben nicht erkannt.

 

[excelite]

Wenn du die Syslibfile Funktionen blockieren diese solange die Abarbeitung der Task. Es gibt in Codesys V2 auch die SysLibFileAsync diese arbeitet nicht mit den Funktionen, sondern mit Funktionsbausteinen. Es gibt dann eine Executeeingang und eine Done wenn dieser fertig ist. Diese kannst du wenn du möchtest auch in deine Maintask einhängen da diese nicht blockierend sind. Macht die Integration aber deutlich aufwändiger da man nicht nur eine Funktion aufruft und fertig, sondern das Executesignal setzen, rücksetzen und Done abfragen muss.

Die gleiche Geschichte gilt auch für SysLibSocket und SysLibSocketAsync. Alle Funktionen sinds stets blockierend.

Soweit ich weiß machen die Async FB im Prinzip das was du tun solltest. Die ziehen im Hintergrund eine Task auf, erledigen dann den Job per synchroner Funktion, beenden die Task anschließend wieder und geben das Done zurück.

 

[m.hoeft]

Also ich versuche nochmal genauer zu erklären, was eigentlich passiert. Spielhilfe heißt in diesem Fall, dass der Organist eine Klangfarbe bzw. 1000 Klangkombinationen speichern kann. Diese Kombinationen werden im Arbeitsspeicher vorgehalten, damit sie aber nicht verloren gehen, zusätzlich auf der SD-Karte gespeichert. Bei jedem Neustart der Orgel werden die Kombinationen eingelesen. Bis die Orgel selbst spielbereit aufgepumpt ist, vergehen gerne 30 bis 60 Sekunden, also genug Zeit zum Einlesen. Genauso erfolgt das Schreiben nicht während des Spiels, sondern z. B. etwa so wie das Bearbeiten eines Textdokumentes. Man schreibt den Text und wenn man zufrieden ist, klickt man auf speichern. Das man dabei vielleicht auch mal einen Augenblick warten muss, wird glaube ich nicht als Betriebsstörung empfunden, sondern als Notwendigkeit akzeptiert. Zumal in meinem Fall das Lesen/Schreiben weniger als eine Sekunde dauert.

Soweit ich also Eure Antworten verstehe, bereitet dieses Vorgehen keine echten technischen Probleme.

 

[excelite]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nein - das ist kein Problem. Kannst du genau so machen wie du dir das vorstellst.

Wenn du die Daten die du abspeicherst im Binärformat lässt und diese "blind" in die Datei schreibst und anschließend diese wieder "blind" einliest und in deinen Abarbeitungsspeicher schiebst ist das kein Problem. Du darfst dann aber nicht auf die Idee kommen hier z.B. einen Parameter in der Struktur die dein Rezept/Spielhilfe/Kombination hinzuzufügen da sonst nur noch Kauderwelsch rauskommt da die SPS ja nicht weiß, dass sich die Größe geändert hat.

Falls du noch nicht weißt wie und was du für Parameter in der abzuspeichernden Sturktur brauchst gibt es 2 Varianten als Lösung:

1. (wenig Aufwand):
Einfach in der Struktur Dummyvariablen anlegen die du evtl. nutzt oder halt auch nicht. Dann ändert sich die Größe im Speicher nicht mehr
Bsp:
TYPE Kombination :
STRUCT
iParameter1 : INT := 0;
iParameter2 : INT := 0;
iParameter3 : INT := 0;
iParameter4 : INT := 0;
iParameter5 : INT := 0;
iParameter6 : INT := 0;
// hier einfach noch weitere anlegen, also besser mehr als du brauchst
END_STRUCT
END_TYPE

2. (viel Aufwand):
Daten nicht im Binärformat abspeichern, sondern als ASCII mit Identifier. Dann beim Einlesen Zeile für Zeile auslesen, nach dem Identifier suchen und den Parameter an die richtige Stelle kopieren. Das ist natürlich aufwändiger. Kann man im Prinzip mit einer INI Datei im PC Vergleichen. Da spielt es (meist) auch eine Rolle wo der Parameter steht, sondern nur, dass ein korrekter Idenfier davor steht und evtl. noch eine Gruppenbezeichnung.
Ein weiterer Bonuspunkt dieser Lösung ist, dass du die ASCII Datei dann einfach mit einem Editor aufmachen kannst am PC und diese beliebig edierten kannst. Quasi dein Abarbeitungsplan im Editor schreiben und diesen dann nachträglich einlesen. Nett ist auch, dass du so deine erstellen Abarbeitungen als Backup auch schön lesebar gespeichert hast.
Nachteil: Die Datei wird deutlich größer da du nun für jedes Zeichen in der Datei ein Byte belegst. Mit Identifiern usw. kommt da schnell was zusammen. Das Einlesen dauert auch deutlich länger. Ich weiß nicht um wieviele Parameter es sich bei dir handelt deshalb kann ich dir nicht sagen ob diese Lösung für deine Steuerung überhaupt möglich ist (Performance ausreichend?)

 

[m.hoeft]

Hallo excelite,

vielen Dank für Deine ausführliche Antwort. Format und Größe der Daten liegen fest, sie können und sollen zur Laufzeit nicht veränderbar sein. Das Lesen/Schreiben habe ich in eigene Funktionen ausgelagert, die zumindest die Größe der gelesenen/geschriebenen Daten mit der erwarteten Größe vergleichen und einen Fehler melden.

An die zweite Lösung habe ich auch schon gedacht, aber langfristig wird es wahrscheinlich auf eine Datenbank (SQL) hinauslaufen.

Gruß Michael