Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
Für Zuhause habe ich mir eine kleine Home - Steuerung für meine Funksteckdosen gebastelt.
Erste Variante war, das ich via "Sys Execute Process" ein Skript ausgeführt habe, um mittels 433 Mhz Befehle zu übertragen.
Nach "Learning - by - Doing" habe ich nun den OPC - UA Server in Betrieb genommen und meine eigenen Skripte für die Funkübertragung geschrieben.
Nachdem das 433Mhz Signal ja auf best. Pulslängen aufgebaut ist, konnte ich das direkt via GPIO Zugriff von Codesys nicht realisieren. Alleine schon wegen der Zykluszeit.
Soweit so gut....
Die Variante senden klappt wunderbar. Nun habe ich das ganze auch für Empfangen implementiert. Es gibt in GitHub ein einfaches Tool um empfangene Codes einzulesen. (Code, Protocol, Pulslänge)
Sobald ich dieses starte im LX-Terminal empfängt er wunderbar den Code ohne großartige Störungen oder irgendeinem Datenmüll.
Wenn ich nun die Runtime starte, kommt ein absoluter Datenmüll über das Skript rein. Die Pulslänge verlängert sich usw.
Zykluseinstellung: 5ms, Zyklischer Aufruf
Ich habe zum Testen, mal die GPIOs aus der Konfiguration entfernt und die Runtime nochmals gestartet.
-> Gleicher Effekt
Progamm verkleinert (Einfaches PLC-PRG mit nem einfachen Counter)
-> Effekt nicht so stark, aber dennoch vorhanden
Änderungen an der Zykluszeit
-> Keine Veränderung
In meinen Augen gibt es eigentlich nur folgende Möglichkeiten, die diesen Effekt erzeugen könnten:
1.) Runtime benötigt zuviel CPU Last, sodass das System schlichtweg hängt (synchron!?), wobei die CPU Last bei Max. 6% liegt...
2.) Runtime greift im Hintergrund auf die GPIO zu, obwohl diese überhaupt nicht implemtiert sind und blockiert mir hier das Python Skript.
Könnte dem so sein?
Danke für eure Ideen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Es ist so das die "normale Raspberry PI SL" an den ersten Core pinnen. ( gehe davon aus das du PI2/PI3 oder PI4 verwendest)
Sprich du könntest versuchen ( keine Ahnung wie das geht - google) ob man das python script irgendwie dazu bewegen kann, einem anderen Core wie den ersten zu laufen.
Klar ne andere Option ( ohne Garantie auf Erfolg) wäre die Raspberry MC Runtime zu verwenden und versuchen in CODESYS zu verteilen. ( auch das was du in deinem Python machst in CODESYS aufrufen)
die MC läuft nicht ohne gekaufte Lizenz, es gibt da keinen Demo mode.
Klar mit ner rt_preempt gepachten Kernel version des RASPIN könntest du auch noch ein paar Versuche machen.
Grüße
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Originally created by: *michi
Hallo zusammen,
ich sitze hier gerade vor einem kleinen Problem:
Für Zuhause habe ich mir eine kleine Home - Steuerung für meine Funksteckdosen gebastelt.
Erste Variante war, das ich via "Sys Execute Process" ein Skript ausgeführt habe, um mittels 433 Mhz Befehle zu übertragen.
Nach "Learning - by - Doing" habe ich nun den OPC - UA Server in Betrieb genommen und meine eigenen Skripte für die Funkübertragung geschrieben.
Nachdem das 433Mhz Signal ja auf best. Pulslängen aufgebaut ist, konnte ich das direkt via GPIO Zugriff von Codesys nicht realisieren. Alleine schon wegen der Zykluszeit.
Soweit so gut....
Die Variante senden klappt wunderbar. Nun habe ich das ganze auch für Empfangen implementiert. Es gibt in GitHub ein einfaches Tool um empfangene Codes einzulesen. (Code, Protocol, Pulslänge)
Sobald ich dieses starte im LX-Terminal empfängt er wunderbar den Code ohne großartige Störungen oder irgendeinem Datenmüll.
Wenn ich nun die Runtime starte, kommt ein absoluter Datenmüll über das Skript rein. Die Pulslänge verlängert sich usw.
Zykluseinstellung: 5ms, Zyklischer Aufruf
Ich habe zum Testen, mal die GPIOs aus der Konfiguration entfernt und die Runtime nochmals gestartet.
-> Gleicher Effekt
Progamm verkleinert (Einfaches PLC-PRG mit nem einfachen Counter)
-> Effekt nicht so stark, aber dennoch vorhanden
Änderungen an der Zykluszeit
-> Keine Veränderung
In meinen Augen gibt es eigentlich nur folgende Möglichkeiten, die diesen Effekt erzeugen könnten:
1.) Runtime benötigt zuviel CPU Last, sodass das System schlichtweg hängt (synchron!?), wobei die CPU Last bei Max. 6% liegt...
2.) Runtime greift im Hintergrund auf die GPIO zu, obwohl diese überhaupt nicht implemtiert sind und blockiert mir hier das Python Skript.
Könnte dem so sein?
Danke für eure Ideen
Hi,
hm.. welchen PI verwendest du?
nur paar Ideen:
Es ist so das die "normale Raspberry PI SL" an den ersten Core pinnen. ( gehe davon aus das du PI2/PI3 oder PI4 verwendest)
Sprich du könntest versuchen ( keine Ahnung wie das geht - google) ob man das python script irgendwie dazu bewegen kann, einem anderen Core wie den ersten zu laufen.
Klar ne andere Option ( ohne Garantie auf Erfolg) wäre die Raspberry MC Runtime zu verwenden und versuchen in CODESYS zu verteilen. ( auch das was du in deinem Python machst in CODESYS aufrufen)
die MC läuft nicht ohne gekaufte Lizenz, es gibt da keinen Demo mode.
Klar mit ner rt_preempt gepachten Kernel version des RASPIN könntest du auch noch ein paar Versuche machen.
Grüße
Edwin