TIA Möglichkeit mit einer CPU1214C einen I²C-Bus zu betreiben

Zuviel Werbung?
-> Hier kostenlos registrieren
Gibt es eine Möglichkeit an der CPU 1214C /1214C-G2 ein I²C Gerät anzusprechen?
Ist das eine 1:1-Verbindung nur zwischen S7-1200 und einem Gerät? Oder ein I²C-Bus? Datenübertragung in beiden Richtungen?

Die Verwendung von E/A's im Programm ist da etwas langsam
Man kann die E/A auch viel schneller lesen und schreiben als im OB1 Zyklus. Hier gab es schon mal ein Projekt, um einen Soft-UART zum Senden mit 9600 Bit/s zu realisieren, was letztlich aber gescheitert ist wegen nicht abstellbaren Programmunterbrechungen jede Millisekunde durch die Firmware der S7-1200. I²C ist da allerdings viel unempfindlicher, da können ja quasi beliebig langsam die Bits rausgeschoben werden.

Vermutlich wäre aber ein Extra Microprozessor (ggf. mit fertiger I²C-Lib) einfacher zu verwenden.
 
Benutze eine Raspberry Pi mit Snap7.
Programm musst du halt selber schreiben.
Wir benutzen das um ein i²c prom zu lesen, sowie Umgebungsvariablen (Luft- ,druck, -feuchte und temperatur) dem Prozess zur Verfügung zu stellen.
i2c lesen
snap7 mit beispielen
Die Daten werden zyklisch nach dem Messen in einen Datenbaustein geschrieben. Die Verbindung zum Raspi wird mit einem Watchdog über wacht.
 
Es geht da um eine Kabelgebundene "Fernbedienung" (einige Taster und ein paar LED's) das jetzt ein kleines Display bekommen soll.

Halt alles möglichst einfach...
 
Benutze eine Raspberry Pi mit Snap7.

Der Nachteil ist, dass der RPi etwas Zeit zum Booten benötigt. Wenn man die Anlage einfach ausschaltet, können Fehler beim Schreiben entstehen. D.h. man muss das Dateisystem schreibgeschützt einhängen, um den Problemen aus dem Weg zu gehen.

Da ist ein Mikrocontroller besser geeignet, denn der ist unter einer Sekunde Betriebsbereit und Ausschalten kann man den auch einfach.
Sofern kein WLAN benötigt wird, würde ich z.B. einen RP2040 verwenden. Für Ethernet kann man einen W5500 verwenden, der via SPI angebunden wird.

Die Logik zur Ansteuerung des Displays würde ich komplett im Controller integrieren. Am besten ist es, wenn man mit der SPS nur Register lesen/schreiben muss und der Controller den Rest macht. So hat man eine klare Trennung.

Als Protokoll kann man Modbus oder MQTT verwenden. MQTT hat den großen Nachteil, dass man einen Broker benötigt.

Programmieren kann man die Controller mit C/C++, Micropython/Circuitpython oder Javascript. Ob die Runtime für Javascript auch den W5500 unterstützt, weiß ich nicht. Micropython kann das auf jeden Fall. Mit C/C++ kann man alles machen.
 
Ich habe mich für Lesen/Schreiben von DBs entschieden, weil die Übertragung einfach als Abgleich von Datensätzen klappt.
FreePascal geht auch für Picos.
Die Applikation schreibt auch nichts auf das Dateisystem.
Egal, war ein Vorschlag.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Applikation schreibt auch nichts auf das Dateisystem.
Bezüglich des RPi werden Log-Dateien vom Betriebssystem geschrieben. Das reicht schon aus, um das Dateisystem zu korrumpieren. Wenn man oft genug hart ein/ausschaltet, hat man irgendwann den Punkt erreicht, wo das Dateisystem nicht mehr repariert werden kann. SD-Karten sind auch empfindlicher, als HDD/SSD/NVME.

Ein Mikrocontroller schreibt nur Log-Dateien, wenn man das in der Applikation programmiert. Falls man irgendwas schreibt, sollte man das auf einer SD-Karte machen. SD-Karten lassen sich ziemlich einfach über das SPI-Protokoll anbinden. Aber wenn eh nichts geschrieben werden soll, ist das überflüssige Arbeit.
 
Bezüglich des RPi werden Log-Dateien vom Betriebssystem geschrieben. Das reicht schon aus, um das Dateisystem zu korrumpieren. Wenn man oft genug hart ein/ausschaltet, hat man irgendwann den Punkt erreicht, wo das Dateisystem nicht mehr repariert werden kann. SD-Karten sind auch empfindlicher, als HDD/SSD/NVME.

Ein Mikrocontroller schreibt nur Log-Dateien, wenn man das in der Applikation programmiert. Falls man irgendwas schreibt, sollte man das auf einer SD-Karte machen. SD-Karten lassen sich ziemlich einfach über das SPI-Protokoll anbinden. Aber wenn eh nichts geschrieben werden soll, ist das überflüssige Arbeit.
Also das würde ich mal mit "Es war einmal" betiteln.
Ich hab hier 2 Raspi die mehrere Jahre 24/7 ohne irgendwelche Probleme gelaufen sind.
Das Kartensterben war in den Anfangszeiten noch ein Thema, heute ist es extrem selten geworden.
 
Für den RPi gibets mittlerweile NVMe Adapter die vernünftig laufen.
Logs auf SD würd ich auch vermeiden, aber auf die SSD hab ich da kein Problem.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es geht da um eine Kabelgebundene "Fernbedienung" (einige Taster und ein paar LED's) das jetzt ein kleines Display bekommen soll.

Halt alles möglichst einfach...
Dann ist der Raspberry Pi aber doch auch ein bisschen übertrieben, oder?
So rein aus dem Bauch heraus würde ich da auch eher zu der Lösung von @DeaD_EyE tendieren. Wäre auch kompakter.

Alternativ Modbus TCP oder serielle Schnittstelle zur Kommunikation.
 
Für den RPi gibets mittlerweile NVMe Adapter die vernünftig laufen.
Logs auf SD würd ich auch vermeiden, aber auf die SSD hab ich da kein Problem.
Die heutigen Speichercontroller sind auch intelligenter als früher.
Da hast du ein ähnliches Speicherzellenmanagement wie bei SSD. Daher macht das heute keinen so großen Unterschied mehr.
Was sowohl SD als auch SSD unter Umständen nicht mögen ist der harte Poweroff beim Raspi.
Ist zwar auch nicht mehr so kritisch, aber es kann noch passieren.
Da hast du dann mit der SD den Vorteil, dass sie etwas einfacher zu wechseln ist als eine NVMe.
Das Duplizieren ist mit ner SD sowieso leichter.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab hier 2 Raspi die mehrere Jahre 24/7 ohne irgendwelche Probleme gelaufen sind.
Das Kartensterben war in den Anfangszeiten noch ein Thema, heute ist es extrem selten geworden.

Ich habe damals einen Remote-Controller für LiFePO4-Akkus entwickelt. Durch das harte Ausschalten gab es mit dem rootfs regelmäßig Probleme und die RPis konnten nicht mehr booten.

Das hat sich erst verbessert, nachdem ich das root-Dateisystem schreibgeschützt eingehängt habe.
Eine zusätzliche Datenpartition war weiterhin beschreibbar.

Es waren über 100 RPis, die verkauft worden sind. Also habe ich etwas Erfahrung damit, was die SD-Karten betrifft.
Die liefen alle im 24/7 Betrieb und sind ausgefallen, wenn die Kunden den Akku vergessen haben aufzuladen.
 
Zurück
Oben