Grüß euch,
wir planen in Zukunft neue Sensortechnologie einzusetzen die über eine
MODBUS Schnittstelle anstatt einer 4..20mA Schnittstelle funktioniert.
Früher war es möglich bei Sensordefekt einfach den Sensor zu wechseln
oder mit anderen zu tauschen. In Zukunft ginge das nicht, wir müssten
dem Kunden jeden Austauschsensor zuvor auf die richtige Adresse
programmieren. Auch gehe ich davon aus, dass die Kunden auf die Idee
kommen werden bei defekt weniger wichtige mit wichtigeren Sensoren zu
tauschen, was hohe Finanzielle Schäden verursachen kann....
Die Kunden sind idR nicht qualifiziert, deswegen möchte ich auf jeden
Fall solche Situationen ausschließen.
Idee :
In jeder Anschlussbox an der die Sensoren mit Steckern angeschlossen
werden, eine kleine Platine (mit Atmega8 oä.) unterzubringen, die
zunächst den Sensor vom Bus getrennt hält und die Adresse im Sensor
programmiert. (Adresse ist dem uC vorher selbst
einprogrammiert/"gejumped" worden bei Montage der Anlage). Ich gehe
natürlich davon aus das die Elektronik den Sensor deutlich überlebt.
Ist die Adresse programmiert kann der Sensor mit dem Bus bzw. der SPS
verbunden werden. Praktischerweise sollte die Platine dann auch per
MODBUS erreichbar sein um evtl. Diagnoseinformationen bereitzustellen
(kein Sensor verbunden, Sensor antwortet nicht, etc...).
Es gibt also zwei Modi:
1. Verbindung zwischen Sensor(Slave) und uC(Master)
2. Verbindung zwischen Sensor(Slave), uC(Slave) und SPS(Slave)
Um die Impedanz des Bus nicht in den Keller zu drücken war meine erste
Idee zwei RS485 Treiber (zb. LT1785) "Rücken an Rücken" zu betreiben,
also jeweils RO und DI zu verbinden und im Modus 1 einen Treiber
auszuschalten.
Im zweiten Modus dann aber beide Treiber aktivieren. Allerdings muss
dann TXD/RCV am uC gedreht werden.
Fragen :
1. Mit welcher Schaltung kann ich TXD/RCV am uC drehen / welcher uC kann
das von hause aus?
2. Wenn ich die zwei Treiber Rücken an Rücken betreibe, bekomme ich dann
eine Rückkopplung (zweidraht RS485 ), sodass die Signale reflektiert
werden?
3. Wenn JA, welcher alternative Aufbau bietet sich an, ohne das die
Busimpedanz sich verschlechtert, bzw. weiter 32 Geräte betrieben werden
können? (Der Sensor kann 32 Geräte treiben, der LT1785 bis zu 128)
Pin Programming.
Jede Position hat die Adresse im Stecker über Brücken kodiert.
So übernimmt der Sensor bei Power On automatisch seine Adresse.
Wenn Du nur wenig Pins frei machen kannst dann geht das auch über
Widerstände und einer AD Auswertung.
Ein 10bit Wandler sollte mit hinreichender Genauigkeit 32 Werte klar
unterscheiden können.
Wenn Du schon eine 'Sockelelektronik' einsetzen willst, warum gibst Du
nicht der die Adresse und läßt sie für alle Sensoren auf einen
Startdardadresse übersetzen? Dann kann man die Sensoren wieder beliebig
wechseln und der Bus sieht jemeils einen Telnehmer.
Das wird z.B. bei Brandmeldeanlagen gern so gemacht,
Danke für die schnellen Antworten.
Pin Programming.
Wäre eine Möglichkeit aber auf die Elektronik des Sensors selbst habe
ich wenig bis keinen Einfluss.
Addresse Übersetzen.
Ich bin mir nicht sicher ob das die Komplexität nicht erhöht. Ich müsste
dann einen uC mit zwei UARTs haben(?) der quasi die MODBUS Telegramme
durchschleift und die Adresse austauscht, die Checksum prüft und
ebenfalls ändert. Ich wollte FreeModbus verwenden, das wäre dann
wahrscheinlich nicht mehr so einfach möglich, da dann zwei Instanzen
laufen müssten. Allerdings hätten sich auch meine ursprünglichen Fragen
erübrigt.
Joel Linn schrieb:> wir planen in Zukunft neue Sensortechnologie einzusetzen die über eine> MODBUS Schnittstelle anstatt einer 4..20mA Schnittstelle funktioniert.
Wie wärs stattdessen mit IO-Link? Da bleibt die Topologie weitgehend wie
früher, jeder Sensor hängt sternförmig an seinem eigenen Port am IO-Link
Master, nur die Kommunikation ist digital. Du kannst Du den Sensor
einfach austauschen weil er keine eigene Adresse hat, Hauptsache er wird
wird wieder in den richtigen Port gestöpselt.
Joel Linn schrieb:> anstatt einer 4..20mA Schnittstelle funktioniert.
Ich dachte sowas hat man schon erfunden, HART im Multidropbetrieb.
Mehrere Sensoren an einer 4mA Schleife die gleichzeitig als
Energiequelle dient.
Joel Linn schrieb:> Wäre eine Möglichkeit aber auf die Elektronik des Sensors selbst habe> ich wenig bis keinen Einfluss.
Die Auswahl der Sensoren ist begrenzt. So auch meine Möglichkeiten.
Also physisch den Bus umzuschalten nur um ausgetauschte Sensoren zu
konfigurieren kommt mir reichlich umständlich vor. Die Vorteile vom Bus
(einfachere Verkabelung) hat man damit schon fast wieder aufgegeben. Das
muß doch auch irgendwie per Software/Protokoll gehen.
Z.B. könnte der Kunde, nachdem er einen Sensor ersetzt hat der
Zentrale/SPS irgendwie bescheidgeben: "Sensor 17 getauscht". Dann wird
die Zentrale versuchen, den Sensor anzusprechen; es kommt keine Antwort;
das ist OK. Dann muß die Zentrale den unkonfigurierten Sensor ansprechen
und ihm die Adresse 17 zuweisen, fertig. Das setzt natürlich voraus, daß
man immer nur einen Sensor gleichzeitig tauscht, bzw. nach jedem
gewechselten Sensor an der Zentrale die Konfiguration vornimmt. Und
unkonfigurierte Sensoren müssen mit dem normalen Busprotokoll erreichbar
sein, z.B. unter einer default-Adresse.
Joel Linn schrieb:> wir planen in Zukunft neue Sensortechnologie einzusetzen die über eine> MODBUS Schnittstelle anstatt einer 4..20mA Schnittstelle funktioniert.
weshalb? Verfügbarkeit? Weniger Verkabelung?
Ich habe gelesen, dass die Sensoren fertige Zukaufteile sind.
Was ist mit der Zentrale? Ist das auch ein fertiges Zukaufteil, oder
machst Du die selber?
Was für Sensoren sind das (Link)?
fchk
Joel Linn schrieb:
> Addresse Übersetzen.> Ich müsste dann einen uC mit zwei UARTs haben(?)
das wäre nun wirklich kein Problem
> der quasi die MODBUS Telegramme durchschleift und die Adresse> austauscht, die Checksum prüft und ebenfalls ändert.> Ich wollte FreeModbus verwenden
Warum? Der Übersetzer muss doch nichts über den Inhalt des Frames
wissen, nur, dass das erste Byte die Adresse ist und wie man das Ende
des Frames findet. Die Anzahl der Datenbytes hat doch auch einen festen
Platz im Frame? Und wenn nicht, muss er eben die Bytes um 2 verzögert an
den Sensor weitergeben; er muss dann per Time-Out das Ende erkennen,
bevor er die originalen CRC-Bytes weitergibt.
Man könnte auch die gleiche Übersetzer-Hardware verwenden und die
Adresse des Sensors trotzdem umprogrammieren (auf die Adresse des
Übersetzers). Dann könnte er die Frames 1:1 weiterleiten, aber nur die
mit seiner Adresse. Dadurch gibt es keine Antwort, wenn jemand Sensoren
vertauscht. Im dem Fall könnte der Übersetzer alle Adressen
durchprobieren und den Sensor umprogrammieren.
Was davon einfacher ist, hängt wohl davon ab, wie einfach sich die
Sensor-Adresse umprogrammieren lässt.
Oder ich würde einfach mal beim Sensorhersteller anrufen und fragen wie
sowas bei anderen Kunden in der täglichen Praxis üblicherweise
gehandhabt wird, Du bist ja sicher nicht der erste der sich diese Frage
stellt.
