ich nutze die Funktion "SysProcessCommand2" um an FHEM-Daten heranzukommen. Dazu rufe ich aus Codesys auf Betriebbssystemebene einen perl-Befehl auf und bekomme das Ergebnis zurück. Es gibt vielleicht schon elegantere Methoden für das Problem, aber mir geht es hier um das Verhalten von "SysProcessCommand2".
Meine Frage ist: übernimmt Codesys wieder die Steuerung, wenn der Linux-Betriebssystembefehl mit "&" in den Hintergrund geschickt wurde, oder wartet Codesys immer auf die Beendigung des Befehls ?
Ich konnte keine Unterschiede feststellen, ob ich ein "&" anhängte oder nicht. Mir fällt es auch schwer zu verstehen, wie das funktionieren soll, wenn ein Rückgabewert ins Codesys zurück soll, wenn Codesys selbst "schon viel weiter" im Programmablauf ist.
Leider habe ich noch keine halbwegs ausführliche Beschreibung für diesen Befehl irgendwo gefunden. Z.B. ist mir die Bedeutung und der Auslösezeitpunkt für pResult := ADR(Result) unklar (nicht wie der Pointer funktioniert, sondern was im Wert drinnen steht).
Wenn der Befehls definitiv erst beendet wird, kann man sich die zyklische Abfrage im Codesys-Programm sparen. Ich habe nie mehr wie einen Zyklus pro Aufruf erkennen können, aber ich hätte es schon gerne genau gewußt.
Wer kann da helfen oder sagen, wo's steht.
Viele Grüße
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
wird synchron aufgerufen, d.h die Task in der du es aufrufst ist so lange blockiert bis die Funktion die du aufrufst zurückkehrt
also bitte zwingend in einer anderen eigenen Task aufrufen. (Vor allem wenn du die Rückgabewerte in IEC verwendest macht ja & vermutlich keinen Sinn)
Hoffe das hilft dir so weiter.
Grüße
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo Edwin,
vielen Dank für Deinen Hinweis.
Die Erfahrung habe ich nun gemacht, das ich einen extra Task mit dem Systemaufruf laufen lassen muss. Denn ohne extra Task geht in Richtung Visualisierung gar nichts mehr. Und dort liegt auch mein Problem. Ich habe noch kein richtiges Gefühl für den Einfluss einer Task, die z.B. durch den Systemaufruf ausgebremst wird, auf den Rest der Tasks.
Viele Grüße
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ja extra Task ist ein "muss" und wenn du nicht willst das die Visu ausgebremst wird solltest du die Prio der SysProcess Task noch hinter die Visu Prio legen
Also z.B so PLC_PRG Prio 1Visu Task PRIO 29SysProcess PRIO 30
so sollte das dann keinen Einfluss mehr haben.
Grüße
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo,
ich nutze die Funktion "SysProcessCommand2" um an FHEM-Daten heranzukommen. Dazu rufe ich aus Codesys auf Betriebbssystemebene einen perl-Befehl auf und bekomme das Ergebnis zurück. Es gibt vielleicht schon elegantere Methoden für das Problem, aber mir geht es hier um das Verhalten von "SysProcessCommand2".
Meine Frage ist: übernimmt Codesys wieder die Steuerung, wenn der Linux-Betriebssystembefehl mit "&" in den Hintergrund geschickt wurde, oder wartet Codesys immer auf die Beendigung des Befehls ?
Ich konnte keine Unterschiede feststellen, ob ich ein "&" anhängte oder nicht. Mir fällt es auch schwer zu verstehen, wie das funktionieren soll, wenn ein Rückgabewert ins Codesys zurück soll, wenn Codesys selbst "schon viel weiter" im Programmablauf ist.
Leider habe ich noch keine halbwegs ausführliche Beschreibung für diesen Befehl irgendwo gefunden. Z.B. ist mir die Bedeutung und der Auslösezeitpunkt für pResult := ADR(Result) unklar (nicht wie der Pointer funktioniert, sondern was im Wert drinnen steht).
Wenn der Befehls definitiv erst beendet wird, kann man sich die zyklische Abfrage im Codesys-Programm sparen. Ich habe nie mehr wie einen Zyklus pro Aufruf erkennen können, aber ich hätte es schon gerne genau gewußt.
Wer kann da helfen oder sagen, wo's steht.
Viele Grüße
Thomas
Hallo Thomas,
so wirklich viel kann man dazu nicht sagen:
also bitte zwingend in einer anderen eigenen Task aufrufen. (Vor allem wenn du die Rückgabewerte in IEC verwendest macht ja & vermutlich keinen Sinn)
Hoffe das hilft dir so weiter.
Grüße
Edwin
Hallo Edwin,
vielen Dank für Deinen Hinweis.
Die Erfahrung habe ich nun gemacht, das ich einen extra Task mit dem Systemaufruf laufen lassen muss. Denn ohne extra Task geht in Richtung Visualisierung gar nichts mehr. Und dort liegt auch mein Problem. Ich habe noch kein richtiges Gefühl für den Einfluss einer Task, die z.B. durch den Systemaufruf ausgebremst wird, auf den Rest der Tasks.
Viele Grüße
Thomas
Hi Thomas,
ja extra Task ist ein "muss" und wenn du nicht willst das die Visu ausgebremst wird solltest du die Prio der SysProcess Task noch hinter die Visu Prio legen
Also z.B so
PLC_PRG Prio 1Visu Task PRIO 29SysProcess PRIO 30
so sollte das dann keinen Einfluss mehr haben.
Grüße
Edwin