Auf S7-1200 via Modbus von CODESYS RaspberryPi zugreifen, Teil 1

Damit man auf die Siemens S7-1200 PLC via Modbus drauf zugreifen kann muss man erstmal die 1200 etwas konfigurieren und die Bausteine für den MB_SERVER erstellen.

Bei der S7-1200 folgendes einstellen:

1200 IP-Adresse einstellen
IP-Adresse einstellen

 

1200 Takt- & Systemmerker
Takt- & Systemmerker einstellen

 

Danach denn den Datenbaustein erstellen der als Holding Register für den Modbus-Server der 1200 dient, wobei der DB keinen optimierten Bausteinzugriff nutzen darf:

Datenbaustein
Datenbaustein anlegen

 

Optimierter Bausteinzugriff
Optimierter Bausteinzugriff AUS

 

Nun entweder einen FC anlegen in den die Netzwerke für den Modbus-Server hinein kommen und diesen FC dann in OB1 aufrufen, oder alles in OB1 direkt einfügen:

Testwerte
Ein paar Testwerte um später die Übertragung zu testen.

 

Modbus-Server
MB_SERVER

Am besten ersteinmal folgende Werte wählen:
CONNECT_ID = 1 (man kann auch mehrere MB_SERVER starten, dann muss jeder eine einzigartige ID haben, z.B. indem sie fortlaufend nummeriert werden)
IP_PORT = 502
MB_HOLD_REG = P#DB1.DBx0.0 WORD 25 (bedeutet das Holding-Register hat als Quelle DB1 und beginnt bei DBX0.0 und hat eine Länge von 25 WORD)

Danach Programm übersetzen und übertragen. Falls ein Fehler auftritt kann die Fehlermeldung mit Hilfe des STATUS und der Hilfe-Funktion nachgesehen werden, da dort alle Statusmeldungen aufgeschlüsselt sind.

CODESYS OPCUA Server auf dem Raspberry

Um Variablen aus der Symbolkonfiguration innerhalb des Projektes per OPCUA-Server „sichtbar“ zu machen muss bei Einstellungen der Symbolkonfiguration die Option OPC UA-Features unterstützen aktiviert sein.
Weiterhin müssen die entsprechenden Symbole einen Haken haben um sie zu „veröffentlichen“.
codesys_symbolkonfiguration

 

 

 

Weiterhin hatte ich noch mit anderen Problemen rund um den OPCUA-Server zu kämpfen und habe diese wie folgt gelöst…
Da der OPC-Server irgendwie nicht starten wollte, muss man die CODESYSControl.cfg Bearbeiten und die Daten für den OPC-Server anhängen:
sudo nano /etc/CODESYSControl.cfg
Dort den Bereich [CmpOPCUA] suchen, dieser war bei mir aber gar nicht vorhanden, daher habe ich ihn ans Ende der Datei angehängt, und zwar mit folgenden Angaben:
[CmpOPCUA]
NetworkAdapter=eth0
NetworkPort=4841

Weiterhin hatte in Verbindungsprobleme zu dem OPC-Server, was wohl daraus resultiert das der OPC-Server gestartet wird, bevor beim Raspberry eth0 aktiv ist.
Das kann man manuell beheben indem man den Prozess neu startet, siehe dazu CODESYS Prozess starten oder stoppen.
Oder als Workaround in /etc/init.d/codesyscontrol bei do_start einen sleep 10 einfügen.

Dazu ist auch folgender Link sehr hilfreich: Raspberry PI mit Codesys zum OPC UA Server
Dank dieser Seite benutze ich Prosys OPC UA Client zum Testen des OPC UA Servers.

Konsolenbefehle von CODESYS auf dem Raspberry ausführen

Um innerhalb eines Codesys-Programmes Konsolenbefehle von Raspberry auszuführen muss man im Vorhinein kleine Änderungen machen.
Ersteinmal die Config CODESYSControl.cfg ändern mit:
sudo nano /etc/CODESYSControl.cfg
Dort den Bereich [SysProcess] suchen, dieser sieht am Anfang wie folgt aus:
[SysProcess]
Command.0=shutdown

Diesen könnte man nun wie folgt ändern um ALLE Befehle zu erlauben:
[SysProcess]
Command=AllowAll

Aus Sicherheitsgründen sollte man aber die folgende Methode wählen!
Möchte man aber nur bestimmte Befehle erlauben kann man z.B. die Zeile mit dem weiteren Befehl an hängen:
[SysProcess]
Command.0=shutdown
Command.1=echo

Im CODESYS Projekt SysProcessExecuteCommand (aus der SysProcess.library) oder SysProcessExecuteCommand2 (der ist neu in SP7 und liefert den Rückgabewert in die IEC Welt hoch) aufrufen.
Btte unbedingt dieses Kommando (welches man dann z.B. über die PiFace-Taste starten könnte) in einem eigenen Task aufrufen, das ist wichtig(diese Kommando’s sind blockierend d.h der Task in IEC steht solange..)!
IF xRun THEN
SysProcessExecuteCommand('echo test > /dev/ttyO1', ADR(Result));
xRun := FALSE;
END_IF

Ein anderes Beispiel kopiert aus dem SPS-Forum:
IF xRun THEN
SysProcess.S ysProcessE xecuteCommand('echo test > /dev/ttyO1', ADR(Result));
xRun := FALSE;
END_IF

Speicherkarte durch log-Dateien „zugemüllt“

Nun war zum zweiten Mal meine Speicherkarte beim RaspberryPi rappelvoll.
Was auch leider bedeutete das OpenHAB nicht richtig läuft.
speicher_voll_01

Wenn man in der Konsole mit der TAB-Taste ein Namen ergänzen wollte, kam folgende Fehlermeldung: „cannot create temp file for here-document: Auf dem Gerät ist kein Speicherplatz mehr verfügbar“.

Mit sudo find / -type f -size +50M habe ich erstmal alle Dateien gesucht die größer sind als 50mb.
Wers ganz genau wissen möchte kann auch folgendes verwenden:
sudo find / -type f -size +50M| xargs ls -lahS

Das brachte mich dann auf die Spur riesiger Logdateien.

Ein Blick mit ls -l --block-size=M im Verzeichnis „/var/log“ brachte folgendes zum Vorschein:
speicher_voll_02

Log-Dateien die jeweils Gigabyte groß sind, sind natürlich nicht so toll.
Eine Suche bei Googel ergab das ich an meiner „logrotate“ was einstellen müsste.
Bevor ich dies tun kann, muss ich aber erst mit „rm“ mal ein bischen Platz schaffen.

Ein Blick in die logrotate Konfigurationsdatei mit sudo nano /etc/logrotate.conf brachte nun folgende Einstellungen zu Tage:
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# uncomment this if you want your log files compressed
#compress
.... plus noch ein paar mehr Einstellungen.

Dies habe ich nun erstmal geändert in:
# rotate log files daily
daily
# keep 3 days worth of backlogs
rotate 3
# create new (empty) log files after rotating old ones
create
# uncomment this if you want your log files compressed
compress

Das Beseitigt zwar erstmal nicht mein Grundproblem, sondern begrenzt die Auswirkungen.
Siehe auch: logrotae manpages

Ein manuelles ausführen von sudo logrotate -f /etc/logrotate.conf führte auch zu keinem Fehler, also sollte mein OpenHAB erstmal wieder stabil laufen.

Timer mit Verlängerung

var Timer FlurBewegungsmelder_timer = null

rule "Flur-Licht Bewegungsmelder"
when
Item Flur_Bewegungsmelder changed
then
if(Flur_Bewegungsmelder.state == OPEN && FlurBewegungsmelder_timer == null) {
sendCommand(Schalter_Flur, ON)
FlurBewegungsmelder_timer = createTimer(now.plusMinutes(2)) [|
sendCommand(Schalter_Flur,OFF)
FlurBewegungsmelder_timer = null
]
}
else if (Flur_Bewegungsmelder.state == OPEN) {
FlurBewegungsmelder_timer.reschedule(now.plusMinutes(2))
}
end

Statische IP-Adresse v4 unter Raspbian Jessie

Prüfen ob der DHCPD-Service überhaupt läuft mit:
sudo service dhcpcd status

Ist der Dienst installiert aber abgeschaltet, diesen erst aktivieren, erst dann empfiehlt dich das bearbeiten der Konfigurations-Datei:
sudo service dhcpcd start
sudo systemctl enable dhcpcd

Sollte der dienst laufen kann man mit sudo nano /etc/dhcpcd.conf die Konfigurations-Datei bearbeiten und folgendes anhängen:
interface eth0
static ip_address=192.168.0.10/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.1

Wobei /24 die Kurzschreibweise für die Netmask 255.255.255.0 ist.

Danach sudo reboot oder sudo service networking restart

ping: icmp open socket: Operation not permitted

Wenn ich in der Konsole bei meinem raspberry ping 192.168.0.1 eingeben möchte um zu schauen ob der Netzwerkteilnehmer erreichbar ist kam folgende Fehlermeldung: ping: icmp open socket: Operation not permitted

Googel ergab folgende Vorangehensweise:
Ersteinmal in die Konsole eingeben:
ls -l `which ping`
Dort sollte als Rückgabe so etwas kommen:
-rwsr-xr-x 1 root root 30856 2007-07-06 02:40 /bin/ping
Wenn an der vierten Position kein „s“ steht kann man dies korrigieren mit:
sudo chmod u+s `which ping`

Quelle: http://ubuntuforums.org/showthread.php?t=927709