Page 1 of 1

Python Skript - CANbus

Posted: 21 Jun 2024, 09:05
by kuegerls
Hallo,

wenn ich per Programm, welches in einem eigenen Task mit niedrigerer Priorität ausgeführt wird, ein Python-Skript (erstellt eine CSV Datei) mit SysProcess.SysProcessExecuteCommand2 ausführe, wird die CANbus Verbindung unterbrochen, laut Fehlermeldung vom Master (extern). Ich verstehe nicht ganz was das eine mit dem anderen zu tun hat? Wie kann ich per Programm ein Python-Skript ausführen ohne dass während der Ausführung die CANbus Verbindung unterbrochen wird?

Im CODESYS sind in den Log-Einträgen meines CANopen-Device und CANbus keine Fehler zu finden.

mein System:
RevPi Connect S: 6.1.46-rt13-v7l, Codesys Runtime 4.10.0.0, revolutionpibridge-V1.4.1.0
RevPi Con Can

Vielen Dank im Voraus!

LG
Stefan

Re: Python Skript - CANbus

Posted: 21 Jun 2024, 09:47
by dirk
Hallo Stefan, du verwendest CODESYS mit dem RevPi Con CAN und möchtest via Python in eine CSV Datei schreiben.

Es gibt bei den Prioritäten und Prozessen generell zu beachten, dass es nicht zu Prioritäten Inversion kommt. Das kann passieren, wenn ein Betriebsmittel blockiert wird z.B. beim I/O Daten schreiben in eine Datei.

Ein Quickhack aus meiner Sicht wäre, wenn du ins TMPFS schreibst, also z.B. nach "/tmp/log.log". Denn das befindet sich im RAM Speicher.
Eine weitere Idee ist, dass Du die Linux oder CODESYS Bordmittel nutzt und hier eine Recherche machst, was typischerweise der beste Weg ist für ein Logging mit CODESYS:
https://forge.codesys.com/neighborhood

Du kannst mir gerne einen SOS-Report zukommen lassen. Wie das funktioniert, steht hier:
https://kunbus-gmbh.atlassian.net/servi ... 2036400208

Re: Python Skript - CANbus

Posted: 21 Jun 2024, 13:01
by kuegerls
Hallo Dirk,

das Python-Skript holt sich via OPCUA Empfangs-Datenobjekte, erstellt daraus eine Kurvenbahn und speichert die Daten der Bahn in eine CSV Datei. Kann das der Grund für eine Betriebsmittelblockade sein?

Ich habe dir einen SOS-Report gesendet.

Re: Python Skript - CANbus

Posted: 24 Jun 2024, 09:35
by kuegerls
Hallo Dirk,

habe das Python Skript mal ohne OPCUA Verbindungsaufbau ausführen lassen, die CANbus Verbindung wird nicht unterbrochen. Beim nächsten Versuch habe ich über das Skript die OPCUA Verbindung aufbauen lassen, ohne das ich Daten abrufe oder schreibe, die CANbus Verbindung wird wieder unterbrochen.

Führe ich das Skript manuell per CMD aus, tritt die CANbus Unterbrechung nicht auf.

Re: Python Skript - CANbus

Posted: 25 Jun 2024, 18:22
by u.biakoup
Hallo stefan,

Dass die CANbus-Verbindung nur dann unterbrochen wird, wenn das Python-Skript über OPC UA eine Verbindung aufbaut und dass dies nicht geschieht, wenn das Skript manuell über die Kommandozeile ausgeführt wird, weist auf ein Timing- oder Ressourcenproblem hin. Hier sind einige spezifische Ansätze zur Untersuchung und möglichen Lösung:
  • Unterschiedliche Prioritäten und Umgebungen:
Wenn das Skript manuell ausgeführt wird, läuft es möglicherweise mit einer anderen Priorität oder in einer anderen Systemumgebung als wenn es über SysProcess.SysProcessExecuteCommand2 gestartet wird.
  • Timing- und Synchronisationsprobleme:
Der Zeitpunkt des Verbindungsaufbaus könnte andere Prozesse beeinflussen, insbesondere wenn das Skript automatisch gestartet wird.

Lösungsansätze
  • Überprüfung der Task-Priorität:
Stelle sicher, dass die Priorität des Tasks, der das Skript startet, nicht zu hoch ist. Setzen Sie die Priorität des Tasks bewusst niedrig.
  • Setzen der Prozesspriorität mit nice:
Stelle sicher, dass das Python-Skript mit niedriger Priorität ausgeführt wird, auch wenn es automatisch gestartet wird.
Beispiel in CODESYS (im Skript-Aufruf):

Code: Select all

SysProcess.SysProcessExecuteCommand2('nice -n 19 python /pfad/zum/skript.py', ...)
  • Ressourcenkontrolle mit cgroups
Verwende cgroups, um die Ressourcennutzung des Python-Skripts zu kontrollieren.
  • Verzögerung und Pausen einführen:
Füge vor und nach dem OPC UA Verbindungsaufbau Pausen ein, um sicherzustellen, dass der Verbindungsaufbau nicht plötzlich zu Lastspitzen führt.
  • Erstelle eines separaten Threads oder Prozesses:
Führe den OPC UA Verbindungsaufbau in einem separaten Thread oder Prozess durch, um die Hauptanwendung nicht zu blockieren
  • Analyse der Systemressourcen:
Überwache die Systemressourcen, um festzustellen, welche Ressourcen beim automatischen Start des Skripts belastet werden.
Tools wie htop, iotop oder dmesg können hier hilfreich sein
Einige Informationen kann ich von dem SOS Reports herausnehmen. Ich werde hier noch weitere Ansätze posten, nachdem ich das SOS-Report, die du geschickt hat, fertig analysiert habe

Mit freundlichen Grüßen

Ulrich Kouatang Biakoup | Field Application engineer