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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.