Feldbuskommunikation verschiedener Potentiale

[Robin B. (rouben)]

Guten Tag zusammen

Ich hoffe ihr seid alle wohlauf trotz den schwierigen Bedingungen.

Ich habe vor kurzem ein "altes Projekt" wieder aufleben lassen, an dem 
ich vor ein paar Jahren gearbeitet habe. Ich habe versucht das Projekt 
zu beschreiben und ein Konzeptschema angehängt. In der Hoffnung nicht 
allzu fest in die Details gehen zu müssen.


Zur Übersicht:
Der Aufbau ist recht simpel. Ich habe wie im "Schema" ersichtlich, viele 
solcher Spannungsquellen mit einem Mikrocontroller, Sensoren, eine 
Hochfrequente Anwendung und das ganze angesteuert über I2C in Serie 
geschaltet. Diese Module agieren als Slaves und werden von einem Master 
"überwacht" und auch angesteuert.

Zu meinem Problem:
Die Anwendung als solches ist nicht unbedingt relevant, das funktioniert 
schon sehr zuverlässig. Ich habe eine Frage zu der Kommunikation mit 
diesen Modulen. Um das Problem mit den verschiedenen Potentialen aus dem 
Weg zu gehen, basiert die Kommunikation im Moment drahtlos. Das war für 
den ersten Schritt okay aber für das weitere Vorgehen ist mir eine 
drahtlose Kommunikation nicht zuverlässig genug. Weiter sollte der Bus 
auf ca. 1ms synchronisiert sein, um schnell auf eine physikalische 
Veränderung zu reagieren.

In der Firma in der ich arbeite, benutzen wir EtherCat für die 
Kommunikation. Deshalb habe ich mir überlegt einen "EtherCat Slave" aus 
meinen Modulen zu machen und diese über Ethernet zu verbinden. Der 
Master könnte dann ein Linux Rechner sein, der das System überwacht und 
steuert. Die Ethernet Schnittstellen gibt es meines Wissens galvanisch 
getrennt, das müsste ja theoretisch funktionieren.

Zu meiner Frage:
Ich benutze EtherCat leider nur als Kommunikationsprotokoll in 
Verbindung mit fertigen Klemmen und Bausteinen von Beckhoff und habe 
keine Erfahrung einen solchen Slave selber zu entwickeln. Ist mein 
Vorgehen hier Sinnvoll oder gibt es eine sehr viel einfachere Art mein 
Problem zu lösen? Manchmal sehe ich den Wald vor lauter Bäumen nicht 
mehr und bin froh um andere Meinungen.

Ich bedanke mich schon jetzt für eure Antworten.

Liebe Grüsse
Rouben

[Pandur S. (jetztnicht)]

Kann man machen. allerdings zieht Ethernet relativ viel Strom fuer die 
moegliche Bandbreite. Falls diese Bandbreite nicht benoetigt wird, wuerd 
ich's sein lassen. Und einen sonstigen seriellen Bus wie einen RS485, 
RS422 verwenden. Funk ist nicht zuverlaessig, und zu teuer im Vergleich 
zu Alternativen. Allenfalls kommt man mit weniger Strom durch.
Das Ganze ist so unklar beschrieben, dass nicht wirklich rauskommt worum 
es geht. Soll der BUS die I2C Devices in Serie verbinden ?

Weswegen sind die Potentiale unterschiedlich ?
Egal, Falls wirklich noetig wuerd ich etwas wie ADuM 1301 oder so zum 
Trennen verwenden. Das laeuft mit 2mA oder so.

> ..und habe keine Erfahrung einen solchen Slave selber zu entwickeln.

Ohne gar nichts wird's schwierig.

[Manfred S. (Firma: Manfred) (xfred343)]

Über I2C bin ich da sehr skeptisch, welche Entfernungen gibts da zu 
überwinden? Bau dir doch auch eine Vernetzung über LAN auf, fast jeder 
Mikrokontroller kann Ethernet als Option und da hast dann keine 
Potentialprobleme und eine moderne universelle Verkabelung mit 
Standardkomponenten.

Ich selbst steuere Beckhoff Ethernet-Busklemmen über Port 502 problemlos 
via Windows-Rechner an, ein Winsock-Steuerelement und ein paar 
Modbus-Befehle (das sind eh nur ein paar Bytes) reichen dafür 
vollkommen, über Linux sollt das alles noch viel einfacher gehen..

[Robin B. (rouben)]

Pandur S. schrieb:
> Und einen sonstigen seriellen Bus wie einen RS485,
> RS422 verwenden.
> Egal, Falls wirklich noetig wuerd ich etwas wie ADuM 1301 oder so zum
> Trennen verwenden. Das laeuft mit 2mA oder so.
Das werde ich mir anschauen Danke.

> Das Ganze ist so unklar beschrieben, dass nicht wirklich rauskommt worum
> es geht. Soll der BUS die I2C Devices in Serie verbinden ?
Der I2C auf dem Slave liest ein paar Temperatur Sensoren, sowie einen 
Spannungs- und Strom Sensor aus und schaltet die HF Anwendung ein und 
aus. Mit der Kommunikation zum Master, möchte ich die Sensorwerte und 
die Steuerung von allen Slaves auslesen bzw. schalten können. Die Slaves 
haben alle eine eigene separate Spannungsquelle und werden mit der 
Serienschaltung der Slaves zu einer "grossen Spannungsquelle".

> Weswegen sind die Potentiale unterschiedlich ?
Alle Slaves liegen auf einem anderen Potential, da sie eine separate 
Spannungsquelle besitzen und der Mikrocontroller von dieser gespiesen 
wird.

>> ..und habe keine Erfahrung einen solchen Slave selber zu entwickeln.
>
> Ohne gar nichts wird's schwierig.
Programmiererfahrung habe ich schon. Nur über die Entwicklung von 
EtherCat Geräten weis ich nichts. Erste Infos im Internet haben gezeigt, 
dass das doch ein erheblicher Aufwand mit sich bringt. Bevor ich mich da 
hineinstürze, wollte ich mich informieren, ob ich mich in die richtige 
Richtung bewege.

[Wolfgang (Gast)]

Robin B. schrieb:
> Alle Slaves liegen auf einem anderen Potential, da sie eine separate
> Spannungsquelle besitzen und der Mikrocontroller von dieser gespiesen
> wird.

Redest du von einem BMS oder warum kannst du die GNDs nicht alle 
verbinden.

[Robin B. (rouben)]

Wolfgang schrieb:
> Robin B. schrieb:
>> Alle Slaves liegen auf einem anderen Potential, da sie eine separate
>> Spannungsquelle besitzen und der Mikrocontroller von dieser gespiesen
>> wird.
>
> Redest du von einem BMS oder warum kannst du die GNDs nicht alle
> verbinden.

Ja, genau. Wäre wohl einfacher gewesen das von Anfang an zu erwähnen.

[Peter D. (peda)]

Für Ethernet gibt es den W5500, der den Großteil des Protokolls schon 
intern macht (bis zu 8 hardware sockets). Da gibt es auch fertige Module 
günstig zu kaufen. Erfahrungen habe ich damit aber noch nicht.

Ich würde eher den CAN-Bus empfehlen, da hat man besonders wenig 
Protokoll-Gedöns zu implementieren. Im Prinzip nur Adresse + Daten, 
fertig. Alles was bei RS-485 zur Übertragungssicherung nötig ist, fällt 
weg.
Als µc z.B. ATmega64M1.
CAN-Trenner gibt es von AD und TI, z.B. ISO1050.

[Pandur S. (jetztnicht)]

Dafuer hat CAN das 64bit pro message limit. Ich wuerd's deswegen nicht 
nehmen.

[Peter D. (peda)]

Pandur S. schrieb:
> Dafuer hat CAN das 64bit pro message limit.

Was in der Praxis keinerlei Problem darstellt. Man kann einen 
Messagepuffer in Ruhe auslesen, während ein anderer schon das nächste 
Paket empfängt.
Der ATmega64M1 hat 6 Puffer.
Es gibt auch CAN-Bootloader für FW-Updates.

[c-hater (Gast)]

Pandur S. schrieb:

> Dafuer hat CAN das 64bit pro message limit.

Naja, ein Protokoll darauf zu setzen, was größere "Pakete" oder gar 
Streams ermöglicht, ist ja nun wahrlich kein Hexenwerk, zumal sich das 
CAN-Protokoll selber schon um einige wesentliche Aspekte der Sache 
kümmert.

Das einzige Problem könnte die relativ geringe erreichbare 
Nettodatenrate sein. Aber für die Anwendung des TO wäre das aber sicher 
noch kein Problem.