Hi, Wieder mal ein Idiot, der sich nicht ausreichend mit der Materie beschäftigt hat und mit Schwachsinn leben muss. Hier die Ausgangssituation: Ich baue ein System um selbstgebaute sensoren über rs485 anzubinden. Das Protokoll ist kein Problem, ich bin Informatiker von Beruf. Ich bin gezwungen rs485 zu verwenden. Die Gründe dafür seien mal verschwiegen, aber das ist fix. Ich bin gezwungen ein mehr oder weniger mult master system zu bauen, da eine Vorgabe ist, dass die Teilnehmer regelmäßig Messwerte übertragen. Auch diese Bedingung ist nicht verhandelbar. Bei meiner Anwendung geht es darum ein schon verkorksten System zu erweitern, wo sich jemand keine Gedanken gemacht hat. Das zu ändern ist weitgehend unmöglich - for ausgesetzt, ich bin nicht bereit das ganze System gegen Widerstand durchzusetzen... Jetzt meine Fragen: Zur hardware: Wie ist das mit Kollisionen? Muss ich die vermeiden, weil dann was kaputt geht? Wenn ja, was müsste ich tun, damit das kein Problem mehr ist? Was müsste ich machen, wenn ich will dass ich Kollisionen erkennen kann? Gibt's chips, die da mein Leben einfacher machen? Zur Software: Was könnte ich machen um möglichst einfach Kollision zu erkennen? Die Details kriege ich raus und ich hab auch schon ein bisschen nachgedacht. Ich wollte nur mal hören wie viel ich vergessen habe! Ich lese den Bus, während ich sende. Lese ich was anderes als das was ich empfangen habe nicht zu dem passt, was ich senden wollte, dann warte ich, bis der Bus für eine zufällige Zeit inaktiv ist (der selbe Wert auf dem Bus liegt) Danach versuche ich nochmal zu senden.
:
Bearbeitet durch User
Ich habs mir überlegt, ich schreibe doch etwas genauer was mich dazu zwingt. Mein zukünftiger Schwiegervater macht smart home in wenig smart und wenig praktisch. Da er in der "Industrial automation Branche" arbeitet, ist er mit sps systemen (namentlich Siemens s7) vertraut und verwendet die. Er hasst Funk und glaubt kabel sei das einzig wahre. Fakt ist, dass er nicht wirklich sps programmieren kann. Ich bin mir sicher um kleinere Änderungen in einem bestehenden System zu machen reicht es, aber um eine Anlage in Form seines Hauses zu entwerfen wahrscheinlich nicht. Er hat wahllos Dinge mit max485 an eine bus master Karte geworfen und mach gruselige Dinge mit Bitrate umstellen und so. (Ganz verstanden habe ich es nicht) um einzelne Geräte ansprechen zu können. Er hat noch nicht entdeckt, dass es Protokolle wie modbus gibt, die er verwenden könnte um nicht für alles manuell senden und empfangen zu müssen. Er hat sich ein "Gateway" genaut, damit er Signale von seinen enocean tastern bekommt un auch das hängt am selben rs485 bus. Dieses Gateway ist ein max485 mit einem enocean Trasciever Modul. Er wollte jetzt einige sensoren an den Bus bringen. Hauptsächlich selbstgebaute kleine Thermostate. Ich hab Mitleid gehabt und gesagt ich bau ihm die Thermostate, damit sie am Ende auch ordentlich funktionieren. Ich hab schon versucht ihn zu überzeugen, dass es intelligenter wäre die Geräte, die kein Modbus rtu sprechen mit einem arduino oder anderem auszustatten, damit sie es doch tun. Er lehnt das aber ab, weil das was er bisher hatte ja schon funktioniert und er dafür das sps Programm umbauen müsste. Er will unbedingt, dass die sensoren eine art push Modell machen, damit er nicht jeden sensor für die Werte befragen muss. Er will da einen Empfänger block haben, der die Nachrichten parst und die datenpunkte setzt. Er lehnt es kategorisch ab solche Dinge einem I-Broker oder vergleichbaren auf einem raspberry pi zu übertragen. Seiner Meinung geht "solcher Verbraucher müll" ja dauernd kaputt. Ich möchte mein System so robust wie möglich machen, damit es nicht heißt, dass ich Unsinn gebaut habe. Ich möchte mich im Fehlerfall mit einem usb Adapter auf den Bus hängen können um mir diagnosedaten zu holen, ohne jedes mal die sensoren aus ihren Ecken zu zerren. Ich möchte, dass meine Diagnosesoftware automatisch alle sensoren enumerieren kann und automatisch herausfindet welche Fähigkeiten ein Knoten hat, damit ich flexibel bin welche sensoren in Zukunft gebraucht werden. Die Software soll Einstellungen Runter- und Hochladen können. Die Kollisionserkennung will ich aus zwei Gründen haben. 1. Dieses enocean Ding Kann jeder Zeit in eine übertragen rein kacken. 2. Wenn auto Enumeration an ist, hätte ich gerne dass ich nicht jede mögliche ID überprüfen muss, sondern dass ich einen broadcast schicke und alle Antworten. Damit das keinen heillosen Terror gibt, muss ich Kollisionen vermeiden und im Zweifel einen retransmit vornehmen. Ich benutze zumindest bei den Thermostaten auf Grund des enorm großen Flash esp8266 Module. Da wäre modbus tcp über WLAN oder LAN besser geeignet, aber es mangelt an Adern und der möglichkeit neue LAN Kabel einzuziehen wo sie gebraucht werden. Wenn ich hat bock drauf habe, schau ich mal, ob ich nicht einen stm32 dazu bringe von eine externen Flash zu booten und da ein kleines rtos drauf laufen zu lassen. Can wäre eigentlich unendlich viel besser geeignet, aber da muss man ja auch wieder was ändern. Ich wäre bereit gewesen eine eigene profibus Bibliothek zu schreiben und ihm Geräte Dateien zu machen, damozt die kack dinger gut in tia integrierbar sind, aber er will sich keine profibus Karte kaufen. Er verwendet eine gecrackte Version von step7, so dass ich die umbauten nicht mal für ihn machen könnte. Eine codesys soft CPU um die ganzen sensoren zu aggregieren und dann über profinet an seine s7 zu übertragen lehnt er ab, weil der ja mit codesys nicht zurecht kommt und er alles zentral in der s7 haben will. Seine ganze Haus automation ist in ladder logic geschrieben und so überrsichtlich wie wie der Kabelsalat unter meinem Schreibtisch. Ob ich noch mehr bereits überlegt hatte, weiß ich nicht mehr. Das Projekt war zwischenzeitlich pausiert um mein. Studium voran zu treiben. Ich hoffe das waren alle meine bisherigen Infos zu dem Projekt und wieso meine Vorgaben nicht weiter verhandelbar sind.
RS485 kann verschieden verdrahtet werden. 1. Alle Knoten parallel. 2. Ein Knoten ist Master. Der Ausgang (Master)geht an die Eingänge der der Slaves. Die Ausgänge der Slaves sind mit dem Eingang am Master verbunden. Die Methode "2." viel leichter zu programmieren.
Laß das Projekt sein. Weder wirst du dich mit deinem Schwiegervater einigen, noch verstehst du auch nur ansatzweise wie ein Bussystem auf unterster Ebene arbeitet. Damit der Bus funzt, müssen alle Knoten die gleiche Sprache sprechen und am besten von dir selber programmiert sein. Das läuft dann darauf hinaus, daß jeder Knoten einen Emulator für die dahinterliegende verschiedene schwiegervatergestrickte Schaltung brauch. So viel Zeit hast du doch nicht! Ob CAN oder RS485 oder Ethernet wäre im Prinzip recht egal. Man kann alles zum Laufen bringen.
Und dann ist noch die Frage, ob er halbduplex (2 Leitungen) oder fullduplex (4 Leitungen) verkabelt hat. Wenn Fullduplex liegt, dann halbiert sich das Kollisionsproblem. Ausserdem ist Push bei RS485 sehr unüblich, eigentlich fragt der Master seine Slaves immer ab und dann ist Fullduplex schon per se kollisionsfrei und halbduplex auch, wenn der Master ein wenig mitdenkt. Ich würde zuerst heiraten und später den Herrn von seinem Konzept abbringen. Das Kabel besser als Funk ist, stimmt aber schon. Nur nimmt man heute keinen Klingeldraht mehr sondern CAT.
Stefan S. schrieb: > Wie ist das mit Kollisionen? Muss ich die vermeiden, weil dann was > kaputt geht? Dein Telegramm geht kaputt. Mehr nicht. > Was könnte ich machen um möglichst einfach Kollision zu erkennen? Prüfsummen berechnen und mit übertragen. Stefan S. schrieb: > Ich bin gezwungen ein mehr oder weniger mult master system zu bauen, da > eine Vorgabe ist, dass die Teilnehmer regelmäßig Messwerte übertragen. Ich würde da nur 1 Master machen, und der fragt dann zyklisch alle Knoten nach ihrem Befinden. Alles andere ist Gebastel, das dir irgendwann (ich vermute recht schnell) auf den Kopf fällt. Denn wenn die andern Teilnehmer nicht in eine laufende Übertragung hinein starten dürfen, müssen sie ja jedes Telegramm auswerten. Und dann gibt es immer noch das Problem beim ersten Byte, denn während das übertragen wird weißt du noch gar nicht, dass der Bus schon belegt ist.
Irgendwann hat mal jemand vorgschlagen, einen CAN- statt eines RS485-Transceivers wegen der andersartigen Endstufe zu verwenden. Die Daten muss man dann trotzdem zurücklesen und mit den gesendeten vergleichen. Ich habe es nie getestet. Entweder Single-Master oder sogar nur (halbduplex-)peer-to-peer. PS: sooo viel Text könnte man vermutlich auch durch ein Bild ersetzen.
Stefan S. schrieb: > Ich lese den Bus, während ich sende. Lese ich was anderes als das was > ich empfangen habe nicht zu dem passt, was ich senden wollte, dann warte > ich, bis der Bus für eine zufällige Zeit inaktiv ist (der selbe Wert auf > dem Bus liegt) Du kannst bei 485 nicht zurücklesen (bzw. Du liestnur Deinen Kram zurück). Das geht bei CAN, hat aber große Einschränkungen. Ggf. gehen Can-treiber. Was nicht geht, sind 2 Köche ohne Rezept und ohne gemeinsamen Horizont. Stefan S. schrieb: > Er will unbedingt, dass die sensoren eine art push Modell machen, damit > er nicht jeden sensor für die Werte befragen muss. Diese Formulierung zeigt es: entweder sollst Du seinen Code in HW fixen oder ihr redet aneinander vorbei. Automatische Adressierung, aber für eine Anfrage reicht es nicht? Und wenn die enocean ungefragt feuern bei höherer Auslastung, dann sind die nicht integrierbar. In Funk sind die kein Problem, da die Frequenz nur sehr schwach belegt ist, die Telegramme kurz und wiederholt sind UND notfalls nochmals gedrückt wird. Wenn Dein Schwiegervater aber genau das als Grundlage nimmt und mit Verlusten lebt, ist das evt. ok.
Matthias S. schrieb: > Das Kabel besser als Funk ist, stimmt aber schon. Nur nimmt > man heute keinen Klingeldraht mehr sondern CAT Jein, das hängt stark von der Anwendung ab. RS485 hat durchaus noch seine Berechtigung. Ethernet ist vergleichsweise aufwendig zu verkabeln. Jeder Teilnehmer benötigt seinen eigenen Strang, die Länge ist auf 100m begrenzt, am Sternpunkt wird ein Switch benötigt und am Teilnehmer braucht man einen Abschluß in Form einer Dose oder eines Keystones. Jetzt stell dir vor, der Busteilnehmer ist bspw. ein RFID-Kartenleser. Bei RS485 schraubst du den einfach auf eine Hohlwand- oder Unterputzdose, nachdem du die zwei oder drei Doppeladern angeschlossen hast, was mit dem üblichen J-Y(St)Y "Telefonkabel" easy von der Hand geht. Und nun versuch das Gleiche mit Ethernet. Selbst bei den tief ausgeführten Dosen wirst du Mühe haben, das störrische CAT7-Kabel mitsamt Keystone und Patchkabel überhaupt in der Dose unterzubringen. Dazu kommt noch der deutlich höhere Stromverbrauch bei Ethernet. Der Switch alleine zieht schon viel mehr Strom als alle Busteilnehmer auf einem vergleichbaren RS485-Bus zusammen. Bei den heutigen und künftig zu erwartenden Strompreisen ist das nicht mehr vernachlässigbar. Auch das Kabel ist bei CAT doppelt bis 3x so teuer und man benötigt aufgrund der Sterntopologie sehr viel mehr davon. Ich denke, RS485 wird uns noch sehr lange erhalten bleiben.
Icke ®. schrieb: > das störrische CAT7-Kabel Allerdings spielt natürlich ein Ethernet, das CAT7 Kabel braucht, auch in einer ganz anderen Liga als ein RS485. Oder eher Ethernet im Allgemeinen... > RS485 wird uns noch sehr lange erhalten bleiben. Sicher, aber dann sollte man eben auch Protokolle darauf fahren, die funktionieren. Und eben nicht irgendwelche Teilnehmer irgendwann drauflosquasseln lassen.
Ich hatte mit Absicht keine CATegorie genannt. Aber Ethernetkabel, egal welcher Quali, hat verdrillte Doppeladern, die auch für RS485 sehr schön sind und auch in genügender Anzahl für Fullduplex vorhanden sind. Macht man RS485 vom Protokoll her wasserdicht, ist das auch immer noch ein guter Bus und sehr zuverlässig. Nur ist eben Push von Slaves unüblich und das aus gutem Grund.
:
Bearbeitet durch User
Wenn RS485 Multimaster vorgegeben ist, wuerde ich ein Token rumlaufen lassen. Dann gibt's keine Kollisionen mehr. Der minimale Aufwand ist das Token Recovery. Alles im Detail nachzulesen unter Arcnet. Suche in Microchip.com nach Arcnet. https://www.microchip.com/wwwproducts/en/COM20019i https://www.microchip.com/wwwproducts/en/COM20020i Beide koennen ueber RS485 arbeiten diese Chips haben das ganze Protokol per Hardware eingebaut. Mit der Hardwareloesung kriegt man den Bus voll, db zu 100% ausgelastet. Das Konzept geht aber auch in Software.
:
Bearbeitet durch User
Stefan S. schrieb: > Ich möchte, dass meine Diagnosesoftware automatisch alle sensoren > enumerieren kann Sorry, aber Ihr beiden kommt aus so krass unterschiedlichen Ecken, das es da eigentlich nur knallen kann. RS485 ist super robust, hat mit Kollisionen kein Problem und nur Masochisten versuchen auf Gewalt ein Multimastersystem damit zu bauen. Dein Schwiegervater hat den low end Ansatz, wie er seit Jahrzehnten selbst auf winzlings MCU super funktioniert, ohne das nach xx Schreibzugriffen die SD Karte verreckt oder da ein 2Ghz Arm Multicore die Arbeit einer 8Mhz Cent MCU macht. Worin er sich irrt, ist eben der Multimastersansatz. Du kommst aus der großen IT Ecke, wo Recourcen im Überfluss zur Verfügung stehen und ohne OS garnichts geht. Kenne ich aus der Zusammenarbeit mit unserem Softwarearchitekten. Ich toggle ein Bit in ASM auf einem PIC10Fxxx, wo er die Minimumanforderung bei Linux mit Realtime Erweiterung und 512K RAM sieht, damit aber auf ein Timing kommt bei dem ich mir die Haare raufe. Ihr seid nicht kompatibel. Ihr versteht nicht das beide Ansätze ihre Berechtigung haben. Du hälst Ihn für ein Fossil, er Dich für einen überkompliziert denkenden Nerd, der Bitgeschubse auf unterster Hardwareebene kein Stück gecheckt hat. Er hat recht mit Funk, denn wer Funk kennt, nimmt Kabel. Enocean kann nur Funk und das auch nur solange die Energie des Tasterdrucks reicht. Daher der Gateway. SPS ist erst seit relativ kurzer Zeit ein Industrie PC der alle Freiheiten bietet. Davor waren das MCUs mit extrem begrenzen Fähigkeiten. Du hast keinen Respekt vor seiner langjährigen Tätigkeit und die Erfahrungen die er dabei gesammelt hat. Daher hat er auch keinen Respekt vor dem was Du sagts, denn Du hast irgendwo ganz oben angefangen, wo tausende Mannjahre Entwicklung in der unteren Hardwarebene bereits für Dich geleistet wurden. Du rufts irgendeine Funktion im OS auf. die alles für Dich tut und dafür sorgt das Nachrichten es irgendwie korrekt bis zu Deiner Funktion schaffen. Die Magie dahinter ist Dir fremd. RS485 ist Hardware pur, ohne das ausgefuchste Zauberwerk das ein Bosch CAN Kontroller macht. Alleine das Du Bitraten Einstellung für gruselig hälst, würde Dich für mich als Ansprechparter disqualifizieren. Du kannst die ganz großen Entwürfe sicher gut, wenn dahinter eine fette Infrastruktur steht. Für schmale und robuste Systeme bist Du einfach nicht der Mann. Wir sollten mal für die Luftfahrt ein Protokoll in unsere Lichtschalter implementieren, bei dem bereits die Klartextmeldung der Selbsttestanalyse größer waren als der Speicher der MCUs. Die ganze PCB war Daumennagelgroß, aber man rennt da gegen eine mentale Wand, weil der ITler einfach nicht begreifen kann das eine MCU auf 3x3mm Footprint und µA Stromaufnahme einfach kein Raspi ist und ein Raspi ungefähr 25 mal so groß wie das komplette Endprodukt. Es ist zum verzweifeln als Hardwerker mit euch großen IT Jungs zu reden. Ihr habt einfach überhaupt kein Verständniss dafür das ein winziger Sensor keine CPU mit MMU, Linux, SSD und GB weise RAM enthält und in der Reduktion auf das wesentiche die Eleganz und Robustheit liegt. Die Altsysteme meines Ex AGs konnten nicht die Welt, laufen aber zum größten Teil seit >20J ohne Wartung, ohne Störung. Die Neusysteme mit Linux und Flash Speicher sind bei jeder Liegezeit zu Hauf bei ihm und immer wieder, wieder und wieder ist es der Flash Speicher oder etwas in dem OS, das mit irgendwas anderem kollidiert. CPU Boards sind nicht mehr verfügbar, OS Updates wegen alter Hardware nicht möglich und wenn, dann mache die oft mehr neue Probleme als sie alte lösen. Nachentwicklung und Neuzertifizierungen blockieren die Entwicklung und kosten Unsummen. Mitlerweile hat er den Markt komplett verloren, weil die Neusysteme zu komplex und vollgestopft waren und die Kunden es einfach satt hatten das auf einen Schlag plötzlich ganze Funktionsblöcke ausfallen und dafür der Flieger zur Wartung muss. Das schaut man sich nur kurz an, bis man der Konkurrenz die Chance gibt es besser zu machen. Der Ruf ist dann ruiniert. Steig im Guten aus, solange Ihr noch miteinander sprecht, oder akzeptiere seine Vorgaben, wie Du es auch bei Deinem Arbeitgeber tun müsstest.
Falls du doch den steinigen Weg des Kriegers gehen willst, wäre eine gute Vorlage das LocalTalk Buch von Apple. Kann man wohl mittlerweile frei downloaden. Da ist alles genau beschrieben, inkl. Kollisionsvermeidung und Enumeration der Knoten. Apple hatte RS422 verwendet, was du gleichsetzen kannst. Bezüge zu restlichen Apple-Gedöhns kann man locker freidenken. Eine gute Vorlage. Und schau dir MACA von Phil Karn an.
Ich habe jetzt nicht ganz verstanden, wo das Problem liegt...außer dass es zwischen dir und deinem Schwiegervater sicher keine "Männerfreundschaft" geben wird. Offensichtlich gibt es doch ein System, das nun erweitert werden soll. Wo wäre dabei denn das Problem? Sind die Erweiterungen nur schwierig oder unmöglich aus deiner Sicht? Klar auch, dass der Vadder kein komplett neues System möchte. Also wo fängt man an mit der Vergrößerung??? Gruß Rainer
Wenn die Leitungen hochohmig genug sind, können bei RS-485 2 Transmitter ihre Nachricht gleichzeitig senden und einwandfrei zurück lesen, d.h. eine Kollision wird nicht erkannt. Ein Spannungsabfall von 0,2V an den Leitungen reicht dazu vollkommen aus. Die Transceiver können hohe Ströme liefern und es dauert ne Weile, ehe der thermische Schutz abschaltet. RS-485 als Multimaster ohne zusätzliche Protokollschicht ist also eine verdammt blöde Idee und wird fehlschlagen. Nimm CAN oder SPE.
:
Bearbeitet durch User
Peter D. schrieb: > Wenn die Leitungen hochohmig genug sind, können bei RS-485 2 Transmitter > ihre Nachricht gleichzeitig senden und einwandfrei zurück lesen Richtig. Aber selbst wenn die niederohmig genug sind, kann alleine durch die Laufzeit der Signale an beiden Enden einer Übertragung in dem Moment alles gut sein. Die Kollision findet erst später statt. Ohne starkes Protokoll und Fehlererkennung kann dieses ständige Chaos wieder zu gültigen Telegrammen führen, und allen möglichen Kram auslösen. Jede CRC hat auch ihre Grenzen und wenn ich nur genug Fehler produziere, komme ich irgendwann mal damit durch. Ich frage mich ohnehin, warum ständig alle möglichen Leute RS485 als Multimaster vergewaltigen wollen. Master Slave funzt super mit RS485. Robuster geht es doch kaum. Warum braucht jetzt alle Welt CAN, für ein popeliges Winzsystem? Nur weil CAN jeden Scheiss wieder ausbügelt, den ich nicht gebacken bekomme? Oder das Schreckgespenst das der Master ausfallen könne? Der Master entscheidet wann er Werte braucht, nicht der u.U. ständig feuernde Slave. EIN Knoten reicht um alles totzuquatschen, wenn er z.B. Sensorbruch hat und daraufhin permanent ungefragt neue Daten auf den Bus legt, weil die sich seiner Ansicht nach doch ständig ändern. So ein zusammengestückeltes Multimastersystem ist völlig undeterministisch. Ich weiß nie wie lange ich es immer wieder versuchen muss bis meine Nachricht ankommt, da ich auf meiner Seite ohne ACK auch garnicht wissen kann ob die richtig angekommen ist. Nun habe ich vielleicht richtig übertragen, aber das ACK wird zernagelt. Also sende ich neu. Das tun dan genug Knoten unhd der Bus ist tot. Ein Master Slave kann trotz niedriger Bitrate den Bus perfekt ausnutzen und so eine Robustheit erreichen die kein Multimaster bringt.
Prokrastinator schrieb: > Ich frage mich ohnehin, warum ständig alle möglichen Leute RS485 als > Multimaster vergewaltigen wollen. > Master Slave funzt super mit RS485. Exakt! Das kann jeder mittelmäßige Denker sauber programmieren, einschließlich Fehlererkennung usw. Wenn's was größeres ist, dann nimmt man selbstverständlich vorhandene und etablierte "Busse" und erfindet nicht das Rad an dieser Stelle neu! Bei einem einigermaßen komplexen System hat man weiß Gott andere Probleme zu lösen, als auf der untersten Ebene Master und seine Freunde zu verwalten :-) Gruß Rainer
Beitrag #6754461 wurde von einem Moderator gelöscht.
Das einzige was man aus diesem Thread mitnehmen kann ist dass man sich seinen Schwiegervater garnicht sorgfältig genug aussuchen kann. Georg
Er verbaut aus Prinzip keine mikrocontroller. Er hat doch seine s7. Ich bin zwar Informatiker und normalerweise spielen ein paar KB RAM keine Rolle bei mir, aber ich bin privat seeehr vertraut mit embedded system. Naja, seine eigenen Basteleien beinhalten niemals irgendwelche dinge die man programmiert. Abgeshen von dieser s7 Steuerung. Und meines Wissens hat er nie mit etwas anderem gearbeitet. Ich halte es für gruselig, dass er mit 9500 baud den Beamer anspricht, mit 9600 baud die Solaranlage und mit 9700 baud die von einem Kollegen vor langer Zeit mal mit arduino gebauten led Streifen. Das finde ich gruselig und nicht die baudrateneinstellungen. Mal ganz abgesehen davon, dass ich nix dagegen sagen würde, wenn wenigstens sein s7 Projekt halbwegs irgendwie strukturiert wäre, so dass man Dinge ändern kann. Oder wenn wenigstens alles halbwegs funktionieren würde hätte ich nicht das geringste Problem. Allerdings tut es das nicht und so möchte ich mir vorbehalten, dass ich - vorausgesetzt ich arbeite mich in die siemens Software ein, da Ich bei mir im Labor nur mit codesys arbeite - alle Funktionen die er gebaut hat mindestens genauso gut und wenn nicht sogar besser schaffen würde als er. Ich habe durchaus Erfahrung mit embedded Programmierung auf kleinste Systemen wie atiny mit 256B RAM oder dem üblichen arduino. Allerdings hatte ich dank corona jetzt auch länger Pause, weil das Studium meine gesamte Freizeit gefressen hat. Mal abgesehen davon läuft mein erstes eigenes mikrocontroller Projekt jetzt auch schon 15 Jahre ohne Probleme. Es war ein datenlogger der unseren heizölverbrauch mit einem aus zwei alu Streifen misst. Und bald wird er zugunsten einer neuen Pelletheizung stillgelegt. Auch wenn ich dir bei Teilen nicht zustimmen kann, kann ich verstehen wieso du so geantwortet hast. Wenn man am Anfang schon schreibt man ist Informatiker geht natürlich jeder sofort davon aus, dass ich von low level keine Ahnung habe. Dass dem nicht so ist, kann natürlich keiner wissen wenn ich das nicht sage... Und ansonsten kann ich nur sagen, dass ich davor viel für mich selbst an mobilen sensor Netzen gespielt habe und da nur esp8266 und esp32 programmiert habe. Außerdem ist seine Anforderung ein touch Display mit einer ansprechenden ui, so dass - vorausgesetzt man hat kein intelligentes Display wo wieder ein stm32 oder so drauf steckt - keine Schance das mit einem kleinen Pic oder atmel Controller zu lösen. Leider.
Lothar M. schrieb: > Ich würde da nur 1 Master machen, und der fragt dann zyklisch alle > Knoten nach ihrem Befinden. > Alles andere ist Gebastel, das dir irgendwann (ich vermute recht > schnell) auf den Kopf fällt. Das halte ich für das beste. Ich werde versuchen ihn davon zu überzeugen, dass dieser Ansatz besser ist. Matthias S. schrieb: > Und dann ist noch die Frage, ob er halbduplex (2 Leitungen) oder > fullduplex (4 Leitungen) verkabelt hat. Halbduplex. Er hat nur zwei Adern, deswegen kann ich das ziemlich sicher sagen. Abdul K. schrieb: > Weder wirst du dich mit deinem Schwiegervater einigen, noch verstehst du > auch nur ansatzweise wie ein Bussystem auf unterster Ebene arbeitet. Darüber könnten wir streiten. Es stimmt, dass ich noch nie Hardware Treiber designt habe, aber ich habe bereits mehrfach eigene bussysteme gebaut. Meist auf Basis von can. Nicht mit mcp2515 Chips, sonder meist mit dem can Controller im stm32. Außerdem hätte ich keine Probleme, wenn ich nicht augenscheinlich sinnlose Vorgaben von außen hätte. A. S. schrieb: > Du kannst bei 485 nicht zurücklesen (bzw. Du liestnur Deinen Kram > zurück). Das geht bei CAN, hat aber große Einschränkungen. Ggf. gehen > Can-treiber. Danke für die Info. Das hab ich mir zwar schon gedacht, hab es aber irgendwie ziemlich verinnerlicht da ich persönlich lieber mit can arbeite als mit rs485. A. S. schrieb: > Automatische Adressierung, aber für eine Anfrage reicht es nicht? Die automatische addessierung habe ich mir als optionales Ziel vorgenommen um mir das Leben zu erleichtern, wenn er zu mir kommt und behauptet "Dein scheiß funktioniert nicht". Außerdem wäre zwar ein dips halter zum einstellen einer manuellen addresse sinnvoll, aber mit der platzvorgabe wäre der wahrscheinlich nicht günstig zu platzieren und lötpads dafür finde ich doof. A. S. schrieb: > entweder sollst Du seinen Code in HW fixen Den Eindruck würde ich gewinnen, wenn ich nicht objektiv wäre. Praktisch würde ich sagen, ich kann seinen Code nicht fixen, weil ich da wahrscheinlich grundlegend einiges am step7 Projekt ändern müsste. Wenn ich das dürfte, würde ich für die led Streifen und den Beamer neue Boards mit modbus rtu und nem atmega oder so bauen und die Thermostate auch modbus sprechen lassen. Das hätte den Vorteil, dass man dafür device Dateien schreiben und step7 beibringen könnte dass diese rs485 karte ein modbus master ist. Schon hätte ich keine Probleme mehr. Prokrastinator schrieb: > Ein Master Slave kann trotz niedriger Bitrate den Bus perfekt ausnutzen > und so eine Robustheit erreichen die kein Multimaster bringt. Ich glaube langsam multi master ist hier der falsche Begriff. Mit ging es eigentlich nur darum, dass mehr als nur die sps ohne Anfrage senden kann. Er wollte gerne dass die Dinger ihre Messwerte selbstständig jede Minute melden. Rainer V. schrieb: > Offensichtlich gibt es doch ein System, das nun erweitert werden soll. > Wo wäre dabei denn das Problem? Sind die Erweiterungen nur schwierig > oder unmöglich aus deiner Sicht? Jap, das System funktionierte bisher für 3 led strips und einen Beamer und eine Solaranlage sehr gut. Der Beamer antwortet nie, da TX an den max485 den er bekommen hat garnicht angeklemmt ist. Um den zu steuern sendet er einen in ein int array kodieren string auf einer baudrate die der Beamer versteht. Die LED Streifen bekommen strings mit folgendem Muster "#rrggbb" wobei nur wichtig ist ob eine Farbe 0 ist oder nicht. Die Solaranlage spricht modbus und da hat er die Telegramm die er hinschicken will in einem datenbaustein als int arrays abgelegt. Mittlerweile hat er anscheinend festgestellt, dass das enocean gateway, dass nur ein enocean transceiver Modul ist, wo TX an einen max485 gelötet ist auf dem Bus zu haben keine gute Idee ist und hat dem den zweiten Kanal der sps Karte gegeben. Jetzt sollen plötzlich Thermostate dazu kommen, die gleichzeitig Luftdruck und Luftfeuchtigkeit messen. Die sollen jede Minute ist-Temperatur, soll-Temperatur, Luftdruck und Luftfeuchtigkeit melden. Gleichzeitig sollen die auch den soll-Wert vorgegeben bekommen können und sie sollen Meldungen aus der sps anzeigen können. Ich glaube die Thermostate zu bauen geht schon, aber ich fürchte damit man das sinnvoll machen kann müsste sich am bisherigen System einiges verändern, so dass man ungefähr fast von vorne anfangen kann. Aus meiner Sicht wäre die sauberste und wahrscheinlich am besten erweiterbare Lösung die Teile die kein modbus sprechen abzuschaffen und durch modbus zu ersetzen, damit die sps das heavy lifting mit dem pollen der Thermostate und ggf anderen sensoren erledigen kann ohne dass er sich darum kümmern muss. Den Vorschlag habe ich noch nicht mit ihm diskutieren können. Rainer V. schrieb: > Das kann jeder mittelmäßige Denker sauber programmieren, einschließlich > Fehlererkennung usw. Wenn's was größeres ist, dann nimmt man > selbstverständlich vorhandene und etablierte "Busse" und erfindet nicht > das Rad an dieser Stelle neu! Bei einem einigermaßen komplexen System > hat man weiß Gott andere Probleme zu lösen, als auf der untersten Ebene > Master und seine Freunde zu verwalten :-) Wie wahrscheinlich oben scvjon hundert mal erwähnt :-) es gibt kein System und den bereits bestehenden, etablierten Bus namens modbus hat er sammt robuster Implementierung abgewiesen als "Das ist zu kompliziert". schwitz schwitz also hab ich mir gedacht, dass ich ihm was ganz einfaches baue wo es ein bte gibt, das die ID des Knotens enthält, ein zweites was die Art des Messwerts enthält und dann 2 byte wo der Messwert jeweils in tausendstel drin steht. Viel einfacher schaffe ich nicht. Rainer V. schrieb: > Klar auch, dass der Vadder kein komplett neues System möchte. Vollkommen verständlich, aber aus meiner Sicht gab es bisher kein einheitliches System. Sondern nur 3 komplett unabhängige Mechanismen, die zufällig auf dem selben Kanal einer rs485 Karte liegen. Damit zu integrieren ist immer witzig.
Peter D. schrieb: > RS-485 als Multimaster ohne zusätzliche Protokollschicht ist also eine > verdammt blöde Idee und wird fehlschlagen. Auf jeden Fall :-D Das war ja der Auslöser für den thread... Ich hab keine Ahnung wie ich eine einfache Protokoll layer auf den Bus bekomme, die damit klar kommt, dass da potentiell grade ein ganz anderes Protokoll gesprochen wird und dich unterbricht. Sollte ich aber meinen zukünftigen Schwiegervater richtig verstanden haben, dass sein enocean max485 auf einem anderen Bus lebt und er sich überreden lassen dass Push kein gutes Modell für rs485 ist, wird das alles ganz einfach. Sollte er sich überreden lassen die alten unzusammenhängenden Systeme durch ein kohärentes Protokoll - sei es custom oder modbus - zu ersetzen wird es sogar wartbar. Vielen Dank bisher erstmal für die rege Beteiligung 😍☺️ und vielen Dank für die Infos und die neuen Denkanstöße die ich durch euch bekommen habe 😅
Du könntest ein "System im System" aufbauen. Jeder Busteilnehmer bekommt einen Adapter, der die Aufgabe hat, entweder die Signale auf Trägerwellen zu modulieren/demodulieren, oder indem du mit unterschiedlichen Spannungspegeln arbeitest und diese übereinander legst, oder Beides. Ein Aufmischen einer von den Teilnehmern zu modulierenden Trägerwelle mit kleinem Spannungshub auf das aktuelle System könnte sogar ganz ohne Adapter an Seinen Geräten auskommen, oder benötigt höchstens ein paar (Z)Dioden und Widerstände zum Schutz der Eingänge. Geht alles in Hardware... Die mögliche Störanfälligkeit steht auf einem anderen Blatt... Natürlich fehlt dann noch der Tranceiver an der SPS, um Deine Signale irgendwie einzuspeisen, aber du hast die Anzahl der zusätzlichen Master auf Einen reduziert und freie Hand für die Zukunft.
:
Bearbeitet durch User
Stefan S. schrieb: > Ich glaube langsam multi master ist hier der falsche Begriff. Mit ging > es eigentlich nur darum, dass mehr als nur die sps ohne Anfrage senden > kann. Er wollte gerne dass die Dinger ihre Messwerte selbstständig jede > Minute melden. Das ist Multimaster. Stefan S. schrieb: > automatische addessierung Blöde Idee. Nur in der Theorie gut. Wir haben das gerne durch Pinprogramming am Stecker gelöst. Das können Brücken im Stecker sein, oder auch ein Widerstand, der über den ADC die Adresse festlegt. Musst nur die Level mit ausreichend Abstand definieren um die Adressen klar unterscheiden zu können. So hat jede Position ihre eigene Adresse, auch bei Slave Wechsel. Stefan S. schrieb: > Den Eindruck würde ich gewinnen, wenn ich nicht objektiv wäre. Du bist alles andere als objektiv. Das ist auch okay, aber halte Deinen Weg nicht für den objektiv richtigen. Wir mussten häufig mehrere inkompatible Geräte an den gleichen Bus hängen, ob uns das gepasst hat oder nicht. Grundsatzdiskussionen halfen da einfach nicht. Wenn mir jetzt jemand mit wenig Berufserfahrung sagt (es mich spüren lässt) das er alles besser kann als ich und ich das alles ganz falsch sehe, werde ich auch schmallippig. Also hinnehmen was man nicht verändern kann und sich auf die paar verhandelbaren Punkte konzentriere die man verändern kann, oder es sein lassen. Ist keine Schande. Stefan S. schrieb: > 3 komplett unabhängige Mechanismen, > die zufällig auf dem selben Kanal einer rs485 Karte liegen. 😂🤣😂 Oh scheiße ... Also 3 Baudraten, 3 Protokolle + Multimaster auf einem RS485 Bus. Also ist das fremde Protokoll + Baudrate nicht von Übertragungsfehlern zu unterscheiden, dabei muss aber jeder Knoten selbst entscheiden wann er die retransmission startet. Ich rate mal wild, das Du dann ab 20-30% Busauslastung einen retransmission Sturm erntest der den ganzen Bus bis Power Reset oder glücklicher Zufall lahmlegt. Ich verstehe zwar das Dich das unglücklich macht, was ich aber nicht verstehe ist das Du dann nicht ganz gesittet, ruhig und sachlich begründet und im Guten Deine Mitarbeit aufkündigst. Statt dessen führt Ihr so eine Art Anschisswettbewerb. Er ist doof weil er 'nur' S7 kann, ihm damit aber auch Erfahrungen in der MCU Implementierung fehlen. Du kannst das alles besser, meinst Du, er sieht aber einen Jüngling der erstmal nur ne große Klappe hat, vollgestopft ist mit Theorie und dann vögelt der Idiot auch noch seine kleine Prinzessin. Sicher das es bei Euerm Konflikt tatsächlich nur um Bussysteme geht? ;-) Ich habe sowas schon gemacht. Dem potentiellen Kunden gesagt, das ich gerne mit ihm das nächste Projekt mache, aber bei diesem unsere Vorstellungen so weit auseinandergehen, wir beide so sehr aus Überzeuging auf unseren Wegen beharren, das wir da einfach nicht zusammenkommen und ich kein Interesse daran habe mich mit dem zu zerstreiten. Hilft doch niemanden, wenn man sich schon bei der grundsätzlichsten Basis nicht einigen kann. Tipp: 3 Protokolle mit drei Baudraten auf einem Bus geht. Aber nur wenn der Slave ausschliesslich dann sendet, wenn er dazu aufgefordert wird, auf keinen Fall darf der NACK alleine senden, UND der Master spricht alle 3 Protokolle und ist der einzige der mit allen spricht. Den würde ich als Gateway zwischen S7 und dem Chaoskram setzen. So kann Vatti seine S7 machen und bekommt was er will und Du hast eine gute Chance das sicher zum laufen zu bekommen. Aber spiel Dich nicht tot, mit Analysefunktionen, automatischer enumeration und ähnlichem. Das ist ein einfaches, plattes, straight forward Ding, kein Windows PC im Workgroup Netz. Reihum alle Adressen abfragen, Protokoll wechsel, abfragen usw. und von vorn. Hat ein Slave während drei Durchläufen nix verwendbares gesagt, kommt der in die Fehlerliste und ein definierter Fehlerwert wird an die S7 gemeldet. Ist er wieder da, wird der Fehlerzustand aufgeboben. Rest ist S7 Sache.
Ich habe jetzt nicht alles gelesen - gibt es irgendwo eine Begründung für die Multimasterforderung? Ja, nice to have, mehr aber auch nicht. Gibt es ein tatsächliches Bandbreitenproblem oder nur ein eingebildetes/befürchtetes? Klar klingt es erst mal bescheuert alle 100ms einen Taster/Schalter abzufragen, der vielleicht einmal am Tag (oder auch gar nicht) betätigt wird. Aber solange Buszeit vorhanden ist spielt das keine Rolle. RS485 funktioniert bei hausüblichen Leitungslängen mit Klingeldraht locker mit 1Mbit. Wenn Multimaster zwingend erforderlich sein sollte: CAN.
H.Joachim S. schrieb: > Wenn Multimaster zwingend erforderlich sein sollte: CAN. Oder einfach nur CAN-Treiber, die automatisch kollisionsfest sind. Gerne wiederhole auch ich es: kein Multimaster verwenden! Matthias S. schrieb: > Ich würde zuerst heiraten und später den Herrn von seinem Konzept > abbringen. Bei dem Vater? Wer weiß, wie die Tochter gepolt ist? Zeig dem Schwiegervater, wo der Hammer hängt ;-)
Prokrastinator schrieb: > Wir mussten häufig mehrere inkompatible Geräte an den gleichen Bus > hängen, ob uns das gepasst hat oder nicht. Allerdings habt ihr wahrscheinlich nicht alle bis auf ein Gerät selbst gebaut und hättet die Chance gehabt einen Einheitlichen Bus zu bekommen.
Prokrastinator schrieb: > Also 3 Baudraten, 3 Protokolle + Multimaster auf einem RS485 Bus. Multimaster noch nicht. Das soll ich grad bauen. Aber bisher gibt bei ihm schon das restliche Chaos und ich habe keine Idee, wieso das bisher funktioniert hat
H.Joachim S. schrieb: > Ich habe jetzt nicht alles gelesen - gibt es irgendwo eine Begründung > für die Multimasterforderung? Ja, nice to have, mehr aber auch nicht. > Gibt es ein tatsächliches Bandbreitenproblem oder nur ein > eingebildetes/befürchtetes? Klar klingt es erst mal bescheuert alle > 100ms einen Taster/Schalter abzufragen, der vielleicht einmal am Tag > (oder auch gar nicht) betätigt wird. Aber solange Buszeit vorhanden ist > spielt das keine Rolle. > RS485 funktioniert bei hausüblichen Leitungslängen mit Klingeldraht > locker mit 1Mbit. > Wenn Multimaster zwingend erforderlich sein sollte: CAN. Die Begründung ist, dass er ein push Modell für die Messwerte will damit er einfach nur lauschen braucht. Und das bandbreitenproblem ist bisher nur möglich. Es geht momentan um eine relativ übersichtliche Anzahl von Knoten und 60sek. Update intervall. Mir ging es darum, daß wenn die rtcs in den Controllern durch Zufall mal so driften das zwei parllel versuchen ihre Werte zu pushen, dann sollen keine Daten verloren gehen. Wäre can eine Option, wäre ich nicht hier.
Ich habe auch viele Jahre in der Industriautomtion gearbeitet aber RS485 Geräte mit den hier genannten "krummen" Baudraten sind mir dabei nie begegnet. Was verspricht sich der Hersteller von diesem technischen Blödsinn?
Stefan S. schrieb: > Die Begründung ist, dass er ein push Modell für die Messwerte will damit > er einfach nur lauschen braucht. Und wenn alle gleichzeitig Puschen, geht es in die Hose! Gut, jetzt kommt das Gegenargument, das sei nicht so wichtig. Dann mache einen "Single Listener" Bus: wenn etwas Sinnvolles ankommt, ist es gut, wenn nicht, auch egal.
m.n. schrieb: > Wer weiß, wie die Tochter gepolt ist? Zumindest mir gegenüber meckert sie immer über Dinge die bei ihm - aus verständlichen Gründen - komisch oder umständlich sind. Dass da manche Dinge komisch sind, würde ich ohne negativ gemeinte Wertung darauf zurückführen, dass er keine oder fast keine Erfahrung hat, wenn es um Programme geben die sequenziell ablaufen müssen. Ein Beispiel dekobeleuchtung in der Küche. Da sind wlan birnen verbaut, die ich auf tasmota umgerüstet habe, damit er die überhaupt per sps steuern kann. Da war geplant buttons für die einzelnen Farben zu machen und wenn eine Farbe gedrückt wird, dann soll erst das relais eingeschaltet werden damit die Lampen Strom bekommen. Da zumindest in seinem ersten test auf einer sps die er zum testen nimmt - den ich gesehen habe - nicht gewartet wurde bis die Lampen sich mit dem wlan verbunden haben, war im ausgeschalteten Zustand jede Taste ein ein Schalter ohne die Farbe zu setzen. Der zweite test, den ich gesehen habe war mit einem ein Schalter und dann warten bevor man eine Farbe wählen kann. Später gab es noch einen test mit warten, aber da ging es mal und mal nicht und jetzt muss man in den nebenraum zum hmi display, oder das Handy aus der Tasche holen. Da ich mit ziemlich sicher bin, dass es möglich ist mit einer sps einen ping zu machen, oder er einfach einen raspberry pi als mqtt broker ansprechen könnte, der Dan das komplizierte macht, glaube ich die von mir vorgeschlagenen Lösungen wären objektiv robuster gewesen
Stefan S. schrieb: > Mir ging es darum, daß wenn die rtcs in den Controllern durch Zufall mal > so driften das zwei parllel versuchen ihre Werte zu pushen, dann sollen > keine Daten verloren gehen. Die Controller können ihre driftenden RTCs doch neu kalibrieren durch Mithören, was denn "die anderen so sagen". Beispiel: - Updateintervall 60 sec. - 12 Sensoren. Der 1. Sensor ruft: "Ich bin Sensor 1, es ist 22 Grad warm". Der 2. Sensor ruft 5 Sekunden später: "Ich bin Sensor 2, bei mir sind es 25 Grad". Der 3. Sensor ruft 5 Sekunden später: "Ich bin Sensor 3, bei mir sind es leider nur 7 Grad. Ich bin nämlich der Kühlschrank!". usw. usw. Das heisst: Der Sensor N+1 meldet sich genau 5 Sekunden nach Sensor N. Es werden relative Zeitscheiben und keine absoluten verwendet. Dann entfällt die Problematik der Kollisionen - zumindest, was Deine Sensoren betrifft. Allerdings gibts einen Haken: Sobald Sensor N ausfällt, hängt die Geschichte. Kann man aber mit Timeouts lösen: Meldet sich Sensor N für längere Zeit nicht, kickt man ihn aus der Kette raus.
:
Bearbeitet durch Moderator
Prokrastinator schrieb: > Wir mussten häufig mehrere inkompatible Geräte an den gleichen Bus > hängen, ob uns das gepasst hat oder nicht. Wir hatten auch den Eindruck, daß der adressierte Mode oft nicht gründlich getestet wurde. Die Geräte antworteten nicht immer oder stürzten komplett ab. Die Lösung, jeder RS-485 Teilnehmer bekommt seinen privaten RS-485. Dazu nehmen wir einen Ethernet auf 16* RS-485 Gateway.
Stefan S. schrieb: > Allerdings habt ihr wahrscheinlich nicht alle bis auf ein Gerät selbst > gebaut und hättet die Chance gehabt einen Einheitlichen Bus zu bekommen. Hihi, zwei zueinander inkompatible Geräteserien kamen tatsächlich aus eigener Hand. Weil unsere super duper Softwarearchitekten ganz tolle Ideen hatten, leider aber ausblendeten das es reichlich alte Geräte gab, die genauso weiter verwendet werden sollten, weil wir sonst schon wg. der FW Änderung durch die Rezertifizierung gemusst hätten, dann aber nach den verschärften aktuellen Regeln. (Luftfahrt. Willst Du nicht bezahlen müssen) Du siehst also, das man sich auch selbst wunderschön die Karten legen kann, wenn man Dinge nicht zuende denkt. Einen anderen Fall hatten wir in einem Flieger in dem der RS485 nicht gerade sauber verlegt war. Die Treiberleistung des Masters reichte nicht mehr für das schlechte Netz und die vielen Slaves. Das Protokoll hatte eine so schwache Fehlererkennung das jeder 128te Fehler statistisch wieder ein gültiges Wort ergab. Also fing irgendwann ein Slave an zu senden, weil er dachte er sei dran. Das zernagelte die nächte Übertragung und die Beleuchting fing wie mit Fieberschüben an verrückt zu spielen. Kaskadeneffekt. Dauerte unterscheidlich lange und hörte irgendwann auf oder auch nicht. Die Lösung war ein brutaler Treiber am Master, der einfach alles plattmachte was versuchte zu senden, sonst hätten wir 160 Slaves anfassen müssen. Rückkanal war in dem Fall nicht zwingend notwendig. Frank M. schrieb: > Allerdings gibts einen Haken: Also quasi ein Token, das verloren geht. Und schon sind wir wieder bei der Problematik, das irgendjemand nun das Token neu erstellen muss. Hilft alles nix. So schiebt man das Problem von links nach rechts und wieder zurück. Im Endeffekt muss es einen geben der mehr darf als all anderen. Also einen Master. Also warum dann nicht gleich einfach machen und Master Slave nehmen? Alles steht und fällt nun mit dieser nutzlosen Forderung nach Multimaster. Ist einfach quatsch für ein system das nur einmal jede Minute einen neuen datensatz braucht, der ohnehin nur von einem einzigen Busteilnehmer ausgewertet wird. CAN ist dafür gedacht das jeder seinen Sermon ablässt und jeder sich daraus nimmt was er braucht. Ist doch hier völlig overdone. Peter D. schrieb: > Die Lösung, jeder RS-485 Teilnehmer bekommt seinen privaten RS-485. Kann man manchmal so machen, pervertiert aber den Nutzen von RS485 und lässt den Verkabelungsaufwand explodieren.
Prokrastinator schrieb: > Peter D. schrieb: >> Die Lösung, jeder RS-485 Teilnehmer bekommt seinen privaten RS-485. > Kann man manchmal so machen, pervertiert aber den Nutzen von RS485 und > lässt den Verkabelungsaufwand explodieren. Was soll man machen, wenn das System ausgeliefert werden muß. Zeit, auf Nachbesserung zu warten, hat man nicht. Ich wollte damit auch zeigen, daß RS-485 bei weitem nicht so einfach zuverlässig zu machen ist, wie CAN. CAN läuft einfach von sich aus, ohne jede Haken und Ösen.
Klar, CAN kommt ja auch aus einer Hand und ist HW+SW in einem, so verpackt das man fast nix mehr kaputtmachen kann. Mir will nur nicht in den Kopf warum man ohne CAN so furchtbar aufgeschmissen sein kann, weil man so ein deppert einfaches Ding wie RS485 nicht zum laufen bekommt, wenn man doch alle Knoten selbst baut.
Ich sehe jetzt nur eine Möglichkeit: du dokumentierst das jetzige, funktionierende System als "Black-Box" und suchst/ bastelst dir eine Schnittstelle dahinein und baust das neue System genau da dran! Das ganze steht und fällt natürlich mit dieser Schnittstelle! Da mußt du Gehirnschmalz reinstecken...innerhalb deines neuen Systems kannst du dann machen was du willst. So würde ich es machen :-) ...und kann es sein, dass der Vadder 3 verschiedene Baudraten nutzt, weil er nicht geschnallt hat, dass man den Teilnehmern einer Schnittstelle Adressen zuordnen kann??? Ich kann aber trotzdem das "menschliche" Problem gut nachfühlen. Als mein Vater frisch in die Rente entlassen, auf die Idee kam, seine schöne Märklin-Anlage auf digital umzubauen, haben sich ähnliche Abgründe aufgetan. Obwohl man sich da eigentlich nur raushalten sollte, geht das aber in Verwandschaft nicht ganz so einfach. Viel Erfolg...Rainer
Beitrag #6755269 wurde von einem Moderator gelöscht.
Prokrastinator schrieb: > weil man so ein deppert einfaches Ding wie > RS485 nicht zum laufen bekommt, wenn man doch alle Knoten selbst baut. Na klar, Profibus, Modbus usw. haben die Entwickler mal eben so nebenbei aus dem Ärmel geschüttelt. RS-485 macht für Datensicherheit absolut nix. Alles muß der Protokollstack machen. Daher fallen damit auch so viele auf die Nase, weil sie glauben, sie könnten es besser, als die Profis.
Peter D. schrieb: > RS-485 macht für Datensicherheit absolut nix. Alles muß der > Protokollstack machen. Daher fallen damit auch so viele auf die Nase, > weil sie glauben, sie könnten es besser, als die Profis. Naja, der Transport Layer kann für die Datensicherheit halt prinzipiell nur wenig tun. Und wenn man einen funktionierenden Stack braucht, ist kaufen nicht unbedingt die schlechteste Lösung - falls ein kein open source Projekt gibt. Alternativ lässt sich bei (sehr) kleinen Stückzahlen auch ein Protokollkonverter einsetzen.
Stefan S. schrieb: > Ich halte es für gruselig, dass er mit 9500 baud den Beamer anspricht, > mit 9600 baud die Solaranlage und mit 9700 baud die von einem Kollegen > vor langer Zeit mal mit arduino gebauten led Streifen. Die Idee, die nicht aktiven Teilnehmer mit Framing-Errors zuzuballern, verschlägt einem die Sprache. Sie zeugt davon, daß der Entwickler bezüglich Datenkommunikation auf absolut unterster Stufe steht. Jegliche Weiterarbeit an so einem vergurkten Konzept ist sinnlos.
Falls der Bus nur 2 Drähte haben darf (+ einen 3. für Masse), würde ich alle Knoten parallel schalten. Die Software könnte man als Ring konzipieren.
Frank M. schrieb: > Das heisst: Der Sensor N+1 meldet sich genau 5 Sekunden nach Sensor N. > Es werden relative Zeitscheiben und keine absoluten verwendet. > > Dann entfällt die Problematik der Kollisionen - zumindest, was Deine > Sensoren betrifft. Allerdings gibts einen Haken: Sobald Sensor N > ausfällt, hängt die Geschichte. Kann man aber mit Timeouts lösen: Meldet > sich Sensor N für längere Zeit nicht, kickt man ihn aus der Kette raus. Die Idee ist spitze. Sowas hätte ich mir schon früher erhofft.
Die Lösung wäre auch gut. Zumindest jedes Protokoll bekommt seinen eigenen Bus um Geld zu sparen. Allerdings müssten dafür cat Kabel gelegt werden. Rs485 ist es ja nur geworden, weil die Kabel schon liegen
Peter D. schrieb: > Daher fallen damit auch so viele auf die Nase, > weil sie glauben, sie könnten es besser, als die Profis. Man muß nicht besser sein als die Profis, wenn man ein kleines System ohne Zukaufkomponenten baut. Man braucht nur einen Master + ein sehr einfaches Protokoll, mit Adressierung + Payload + Checksumme. Ich muss doch zu nix kompatibel sein. RS485 macht seine Sache sehr gut, nur darf man da eben nicht mit völlig überzogenen Vorstellungen rangehen und sich aus Unkenntniss oder Ignoranz einen Haufen Fehlerquellen reindesignen. Ich halte für so ein System mit RS485 ASCII Modbus für eine gute Wahl. Man verbaut sich nicht die Möglichkeit Zukaufkomponenten zu verwenden, muss nicht das Rad neu erfinden und kann am Bus mit jedem Terminalprg mitlesen. Ich habe aber den Eindruck, das bei dem Projekt keiner von beiden weiß was er da tut und warum RS485 dann der falsche Bus dafür ist.
Stefan S. schrieb: > Ich halte es für gruselig, dass er mit 9500 baud den Beamer anspricht, > mit 9600 baud die Solaranlage und mit 9700 baud die von einem Kollegen > vor langer Zeit mal mit arduino gebauten led Streifen. Was soll das bringen, 9500 bzw. 9700 wär eigentlich in der Toleranz eines auf 9600 eingestellten UARTs, +-5% sollte der mitmachen.
Die allermeisten UARTs kann man auf solche krummen Werte überhaupt nicht einstellen. Man lernt nie aus...
Abdul K. schrieb: > Die allermeisten UARTs kann man auf solche krummen Werte überhaupt nicht > einstellen. Nicht am PC. Über den Baudratengenerator in der MCU kann ich machen was ist will. Am besten dabei nicht den Fehler zwischen gewünschter und realer Baudrate ausrechnen und auch nicht verifizieren wie stabil der Taktgeber eigentlich ist. Man versaut sich mit sowas nur die Überraschung und die lauschigen Abende der Fehlersuche.
Prokrastinator schrieb: > Klar, CAN kommt ja auch aus einer Hand und ist HW+SW in einem, so > verpackt das man fast nix mehr kaputtmachen kann. > > Mir will nur nicht in den Kopf warum man ohne CAN so furchtbar > aufgeschmissen sein kann, weil man so ein deppert einfaches Ding wie > RS485 nicht zum laufen bekommt, wenn man doch alle Knoten selbst baut. Hier ist die Antwort zumindest aus meiner Seite relativ einfach. Die nicht vorhandene Grundstruktur. Gäbe es irgendeine konstante an der ich mich festhalten könnte, wäre es wahrscheinlich auch einfacher. So muss ich jedem und allem Misstrauen, weil ich weiß, dass es im Master zumindest in der Anwendung die auf der sps läuft um die sps zum Schweigen zu bringen wenn auf Antwort gewartet wird. Das bedeutet im schlimmsten Fall ist sogar der Master das Problem. Mit dem Bitrate duarnd umstellen kann ich mich auch nicht drauf verlassen, dass Anfragen an mich immer mit der richtigen Bitrate kommen, weil auch dafür nichts im sps Code ist. Und dass dass ich Telegramme ohne Fehler bekomme kann ich auch nicht garantieren. Ich habe auch schon geschaut, ob die sps irgendwie halbwegs einfach crc kann, damit ich in die Telegramme prüfsummen schreiben kann. Leider scheint das nicht so ohne weiteres als alleinstehende Block zur Verfügung zu stehen. Kann aber nochmal schauen.
Stefan S. schrieb: > Und dass dass ich Telegramme ohne Fehler bekomme kann ich auch nicht > garantieren. Kann man nie. Wie gesagt, RS485 ist ein schöner Bus, aber er braucht ein paar Vorbedingungen. Ich kenne das Spiel bis zum Erbrechen, das aus einem System bei dem man nur sehr indirekt auf Hardware zugreifen kann und nie genau weiß in welchen zeitlichen Zusammenhängen das geschieht, auf einen Bus wie RS485 im Halbduplex Betrieb zugegriffen werden soll. Das ist jedes einzelne Mal krachend gescheitert, genau so wie ich es in endlosen Diskussionen zuvor gesagt habe und endete darin, das zwar irgendein Linux das ganze gesteuert hat, dazu aber eine kleine MCU mit auf die PCB kam, die den RS485 betütert hat. Ich wiederhole meinen Tipp, der wohl nicht ganz verstanden wurde: Was Du brauchst ist ein Master, der zwischen SPS und den Slaves sitzt und das enge Timing macht. Die SPS bekommt nur noch die aufbereiteten Daten des Busmasters über eine kurze Leitung, auf der man einfach davon ausgeht das hier keine Übertragungsfehler vorliegen, bzw. eine einfache Checksumme nimmt, die ganz leicht zu erzeugen ist. Ein Slave wird gefragt und hat dann eine Zeitspanne x darauf zu reagieren. Das tut er oder er tut das nicht, aber der Master geht danach zum nächsten Slave über. So bekommt man verlässliche Roundtripzeiten. Alles unter 0,3Sek wird von uns als 'sofort' wahrgenommen. Bis zu einer Sekunde würde ich noch als zumutbar annehmen. Als Roundtripzeit ist das eine Ewigkeit. Ein Slave antwortet nur, wenn er alles auch korrekt verstanden hat und die CRC stimmt. Darf er auch antworten wenn die CRC nicht stimmt, wird es passieren das der Fehler in der Adressierung lag und er antwortet obwohl er nicht gemeint war, was die nächste Übertragung zerstört und Kaskadeneffekte aus wild feuernden Slaves verursacht. Die unterschiedlichen Baudraten und Protokolle sind totaler Murks, aber wenn der Teil des Systems unveränderlich ist, kann man das bei Deinen extrem entspannten Zeitanforderungen trotzdem schaffen. Selbst wenn einige Slaves ein Protokoll sprechen das so garnichts an Sicherheit enthält, erkennt der Master eben einen Wert erst als gültig, wenn er drei Mal hintereinander gleich war. Jeder Slave der noch von Dir bearbeitet werden kann, bekommt eine starke CRC verpasst, um wenigsten da die Fehlerrate zu senken. Multimaster ist aber der Tod. Deine Probleme werden sich aufsummieren, bis phasenweise nur noch totaler Müll über den Bus kommt. 9K6 bps ist noch relativ entspannt, auch was die Terminierungen angeht. Ich vermute der RS485 Bus ist so verkabelt, wie er designt wurde, also als heilloses Chaos aus Bussegmenten mit langen Stichleitungen, ohne Failsafe Rs und ohne sinnvolle Terminierung? Dann weiter runter mit der Datenrate. Soweit wie es die Antwortzeiten zulassen. Um so kleiner werden die Probleme. Das alles hat überhaupt nix mit der SPS zu tun. Die bekommt die Daten so wie sie sie will, mit der immer gleichen Baudrate. Der Busmaster hat die Aufgabe den Dreck zu managen. Wenn Du dem alten Fuchs in sein SPS Programm reinfuhrwerkst, wird das nur kräftig scheppern. Man kann nicht zwei Böcke in einem Topf kochen. Jedes Projekt braucht saubere Trennstellen zwischen denen die daran arbeiten, sonst haut man sich die Köppe ein. Gerade wenn man schon so übereinander denkt wie ihr. Also, wenn Du das machen sollst, legst Du die Trennstelle fest, machst Deinen Teil, er macht seinen. Will er das nicht, steig aus. (prx) A. K. schrieb: > Passender Genrebegriff: fubar. Klar, aber da trennt sich die Spreu vom Weizen. Mit einem weißen Blatt Papier anzufangen ist immer viel einfacher. Das Kunststück ist es eine völlig verfahrene Kiste vorzufinden und das Geklöter in 'Blöd aber unveränderlich' und 'veränderlich' zu entflechten. Teil 2 ist leicht. Teil 1 wird auf 'unschön' und 'unmöglich' sortiert. Unmöglich scheint aber nicht zu ziehen, denn der Kram läuft doch wohl schon. Also muss man sich fragen, warum man das nicht einfach tut, wenn es unveränderlich und unschön, aber nicht unmöglich ist? Wenn es unmöglich ist, dann ist es das ja vielleicht auch, weil es MIR unmöglich ist. Also bin ich in der Lage mich da zu entwickeln, oder ist mir das auch unmöglich? Die verfahrenen zwischenmenschlichen Zustände sind immer Teil des Problems. Also raus aus der 'der ist doof' Sackgasse, hin zu 'wie bekommen wir halbwegs schmerzfrei die Kuh vom Eis' Dazu gehört auch das man aussteigt wenn man begreifen muss das einfach der Wille fehlt. Mir würde der Wille fehlen mir das anzutun ohne dafür angemessen entlohnt zu werden. Aber gerade als ITler mit noch wenig berufserfahrung kann man hier eine sehr wertvolle Lektion über Führungsqualitäten lernen. Denn die alte, eingefahrene Entwicklungsabteilung in der man später mal landet ist kein Stück anders als der alte Sack. Wenn ich da nur klugscheisse und rumbocke, halte ich mich nicht lange.
rµ schrieb: > 9700 wär eigentlich in der Toleranz > eines auf 9600 eingestellten UARTs, +-5% sollte der mitmachen. Nein. Das geht rein mathematisch nicht. Unabhängig von Baudrate oder Störungen, zumindest nicht bei 8-Bit-Daten.
A. S. schrieb: >> 9700 wär eigentlich in der Toleranz >> eines auf 9600 eingestellten UARTs, +-5% sollte der mitmachen. > > Nein. Das geht rein mathematisch nicht. Unabhängig von Baudrate oder > Störungen, zumindest nicht bei 8-Bit-Daten. Ich komme auf 1% Abweichung bei 9600 vs 9500. plus ggf ungenauem Takt durch R/C- oder Keramik-Oszillator. Wo sieht deine Mathematik das Problem?
Prokrastinator schrieb: > Was Du brauchst ist ein Master, der zwischen SPS und den Slaves sitzt > und das enge Timing macht. Was für ein enges Timing denn? Ich hab noch nie einen gesehen, der auf einer SPS die UART-Hardware direkt bedient. In der SPS ist z.B. eine Lib, die Modbus RTU/ASCII macht. Und nur mit dieser Lib wird im SPS-Programm kommuniziert. Das SPS-Programm muß auch nirgends anhalten. Es wird eine Nachricht generiert und irgendwann meldet die Lib ein Ereignis (Antwort empfangen, Fehler, Timeout), das man dann auswertet. Das ganze Protokollgedöns erfolgt im Hintergrund (UART-Interrupt) und interessiert den SPS-Programmierer auch nicht.
(prx) A. K. schrieb: > Wo sieht deine Mathematik das Problem? Sorry. Zuviel zitiert. Ich bezog mich auf die 5%.
Du brauchst keine technische Beratung, du brauchst eine Beziehungsberatung. Anders kann ich mir nicht erklären warum jemand freiwillig zustimmt an so einem System mitzubasteln. Nun gut, du kannst zum Beispiel den Bus auf SAE J1708 erweitern http://www.ti.com/lit/an/snla038b/snla038b.pdf Dann kann wenigstens die Hardware nicht in Flammen aufgehen. Die darauf aufbauende Layer 2 Kollisionserkennung in Software hast du nach deinen eigenen Aussagen im Griff > Das Protokoll ist kein Problem, ich bin Informatiker von Beruf Was kann da schon schief gehen? (kicher)
A. S. schrieb: > (prx) A. K. schrieb: >> Wo sieht deine Mathematik das Problem? > > Sorry. Zuviel zitiert. Ich bezog mich auf die 5%. Das kommt auf den UART drauf an, bei 8 Bit Nutzdaten und 16-fach Oversampling sollte es sich aber knapp ausgehen. 8 Bit Daten + 1 Start- + 1 Stop-Bit ergibt 10 Bit-Zeiten. Bei 16-fach Oversampling wäre das Stop-Bit bei Takt 144 bis Takt 160. Bei 5% Abweichung und Sampling zur Mitte (also bei Takt 152) würde das übertragene Stop-Bit bei Sample-Zeit gerade schon begonnen bzw. gerade noch nicht geendet haben (5% von 144 Bit-Zeiten = 7,2 Bit-Zeiten). Sampling an 3 Takten pro Bit + Mehrheitsentscheidung sollte genauso gerade noch funktionieren.
rµ schrieb: > Sampling an 3 Takten pro Bit + Mehrheitsentscheidung sollte genauso > gerade noch funktionieren. Das samplen des stoppbits erfolgt nach 9.5 Bits. für eine 5% schnellere baudrate, kann dieser mehr als 1 stoppbit fahren (10/1,05 ist >9,5) Eine 5% langsamere sendet vor dem Stopp das letzte datenbit und braucht dafür 9/0,95 Bits, also 9,47 Bit. Fürs erkennen darf also max ein jitter von <1/30tel Bit sein, d.h. 64-faches sampling geht so gerade bei perfekten Signalen und ohne Parity. Also ja, geht theoretisch, aber nicht mit 99,9% der HW. Deshalb nimmt man in der Praxis etwa 3% als wirklich maximale Abweichung (insgesamt, nicht einer +3, der andere -3)
Peter D. schrieb: > In der SPS ist z.B. eine Lib, die Modbus RTU/ASCII macht. Und nur mit > dieser Lib wird im SPS-Programm kommuniziert. Dann les den Thread nochmal aufmerksam. Stefan S. schrieb: > Er hat wahllos Dinge mit max485 an eine bus master Karte geworfen und > mach gruselige Dinge mit Bitrate umstellen und so. (Ganz verstanden habe > ich es nicht) um einzelne Geräte ansprechen zu können. > > Er hat noch nicht entdeckt, dass es Protokolle wie modbus gibt, die er > verwenden könnte um nicht für alles manuell senden und empfangen zu > müssen. Anscheinend soll jedes Gerät wahllos losfeuern können, weil der Vati eben per Hand das Master Slave Timing nicht hinbekommt. Peter D. schrieb: > Was für ein enges Timing denn? Na genau das was man für Master Slave braucht. Der Slave hat ja nur einen kleinen Zeitschlitz um zu antworten. Oder wie soll der Bus wieder frei werden für die nächste Übertragung?
Wahllos stupides losfeuern geht ja durchaus auch, man kommt dann aber nicht über 30% Busauslastung, im Gegensatz zu intelligenten Varianten. Diese Zahlen sind relativ unabhängig von der eigentlichen Bustechnologie. Bei Ethernet, was einen etwas intelligenten Ansatz hat, sind es 70%. Das oben erwähnte LocalTalk kommt höher, da es vor der eigentlichen Übertragung der Daten noch ein kurzes Statuspaket austauscht. Den genauen Wert hier kenne ich nicht, schätze mal 85%. Tokenring bzw. SingleMaster kommt natürlich noch höher. Für alle Fälle benötigt man eine effektive Erkennung defekter Datenpakete. CRC plus Sequenznummer bietet sich an.
Natürlich wird innerhalb der sps der sendebaustein von Siemens benutzt, aber nicht in einer Weise wie Siemens das empfiehlt, wenn man nicht eine Abstraktion wie modbus rtu oder etwas anderes verwendet. Darum geht es hier aber nur nebensächlich. Und auch Timings etc sind kein Problem, da eine Rs485 Buskarte verwendet wird (genaues Modell ist mir unbekannt) Wenn ich mich recht erinnere empfiehlt Siemens bei dem Betrieb mehrerer Protokolle, dass man einen Merker verwendet um zu speichern welches Protokoll gerade hören soll und entsprechend die anderen aussperrt. Ich hab mir selbst ein bisschen Gedanken gemacht und bin gedanklich bei einer Art unicast und broadcast System. (Ich hoffe das ist der richtige Name für das was ich meine...): Der master kann entweder einen request senden, der eine eindeutige ID enthält um nur ein Gerät anzusprechen, oder eine id, die mehrere Geräte anspricht (bei mir im Beispiel mal je 8Bit). Das höchste Bit sagt mir, ob das broadcast oder direkter Zugriff ist. Damit halbiere ich zwar die Anzahl der Adressen, 128 addressen sollten aber dicke reichen (zumindest vorerst.) Wenn das oberste bit der addresse gesetzt ist, gibt der rest die addresse des ersten Knotens an, der antworten soll. Jetzt kommt zur Vereinfachung eine Annahme: Addressen sind immer um genau 1 aufsteigend. (das wird durch einen provisioning Prozess gewährleistet, wegen dem ich eine Möglichkeit haben will alle Knoten zu enumerieren.) Jedenfalls geht er erste Knoten der angesprochen wird jetzt hin, macht sein Ding und antwortet. Empfängt Knoten 2 die Antwort von Knoten 1, weiß er dass er als nächstes sein Ding machen soll und wartet eine Zeit, damit der Master einen retransmit anstoßen könnte. Passiert das nach der vorgegebenen Zeit nicht, wird er automatisch auch sein ding machen und antworten. Jetzt noch kurz dazu, wie ich mir das provisioning vorstelle. Das wird nicht mit der sps geschehen, sondern mit einem PC und usb nach rs485 wandler. Jenachdem welchen Controller ich am Ende verwenden werde esp8266, stm32 oder msp430 habe ich entweder eine Mac addresse, eine Seriennummer, oder ich generieren beim ersten Start eine zufällige addresse aus mehreren byte. (mehrere bytes im unprovisionierten Zustand haben den Grund, damit nicht ausversehen zwei Exemplare ein gleiches Byte in der entsprechenden default addresse haben.) Ich hoffe 2 byte sind ausreichend um mit hinreichender Wahrscheinlichkeit zu garantieren, dass keine 2 Knoten die selbe ID besitzen können? Wenn dann doch eine Kollision auftreten sollte, kann ich ja folgendes machen, dass die Knoten ihre ID anzeigen und das Programm kann sagen zieh mal alle doppelten ivon ID sowieso vom Bus ab und drücke OK. Da bereits provisionierte Knoten provisioning Nachrichten ignorieren, ist es kein Problem, wenn eine zufällige ID mit einer bestehenden Kolidiert. Das Programm muss dann einfach nur alle möglichen id's für unprovisionierten Geräte durchgehen und fragen ob da ein Gerät ist. Wenn ja wird sich das gemerkt und der Knoten mit seiner ID angezeigt. Anschließend werden basic Infos, wie Modell und Firmware version, von allen vorhandenen Knoten geholt. Jetzt kann man dann seine Einstellungen anpassen und den Knoten sprechende Namen geben und so weiter. Da multicast mit nicht provisionierten Geräten nicht funktioniert, bekommt jeder Knoten einzeln seine Einstellungen gesagt und am Schluss gibt es eine Nachricht, die für alle die provisionierung abschließt und alle (auch die bereits provisionierten Knoten resettet). Auch dieser Reset hat einen Sinn und zwar hätte ich gerne, dass die Knoten nach einem reset erstmal nur auf eine Initialisierung reagieren, in der sie ihre Soll-Werte gesagt bekommen, sagen die ein kleine Versuchen auf mit Initialen Messwerten und ihrer Adresse und ggf ihrem lesbaren Namen und gehen dann in Normalbetrieb. Dadurch verspreche ich mir, dass man Probleme einfacher aufdecken kann. Der reset passiert am besten nicht automatisch, sondern erst auf nutzereingabe, damit man eine Chance hat sicherzustellen, dass die angezeigten Einstellungen an allen Knoten richtig sind. Also ist das Ding was "Esszimmer-Terrasse" heißt auch wirklich da angebracht. Danach Einstellungen ändern geht ohne neu provisionieren zu müssen. Und Sachen wie ein menschenlesbarer Name, ein Raum und so sind nur als sanity check gegenüber dem Menschen. Und um zum Beispiel sagen zu können "ich will alle Messwerte aus dem Wohnzimmer" soll es die Nachrichten optional mit einem Feld geben, wo man einen key rein tun kann, also zum Beispiel eine Raum-ID. Dazu muss mann dann zwar wissen, was die erste Adresse des Raums ist, oder ich sage, dass die addressen die angesprochen werden und auf die der key nicht passt mit einer arte "Nope" Wert antworten der sagt dass sie nicht gemeint sind. Dann wäre sogar die addresse egal. Und um. Meine Telegramme von anderem Unsinn zu unterscheiden hab ich mir überlegt, am Anfang steht ein Start byte und am Ende ein Stopp byte. Ungefähr so wie das bei midi Sysex Nachrichten ist. Da steht am Anfang immer eine 240 und am Ende immer eine 247. Meint ihr das Konzept ist zumindest im Grundsatz sinnvoll? Wo seht ihr offensichtliche Probleme? Und sollte ich mir die Mühe machen, mir ne s7 von ihm geben lassen und nen Funktionsbaustein zum generieren und parsen von Nachrichten für ihn bauen?
Stefan S. schrieb: > Wo seht ihr offensichtliche Probleme? Das Du nach dutzenden von Beiträgen, in denen Dir Leute helfen wollten, die Erfahrung haben, immer noch stur das gleiche Ding durchziehen willst, wie im Eröffnungspost. Ein simples kleine System muss auf Gewalt aufgebläht werden weil das nunmal bei Dir im Kopf so rumspukt. Statt aber einen Bus zu nehmen der dafür erheblich besser geeignet wäre, oder gleich ein etabliertes System wie KNX o.ä. zu adaptieren, muss es der RS485 mit einem dutzend selbst gewählter Fallstricke sein. Es gibt nicht einen Master, nein, S7 UND PC müssen was machen UND die Slaves müssen wissen wer als nächstes dran ist UND ein Mechanismuss der die Scherben aufkehrt wenn was schiefgeht muss geschrieben werden. Das ist eine so grauenhafte Kopfgeburt das das System Deines Schweigervaters dagegen grundsolide wirkt. Das nennt man Beratungsresistent und beratungsresistente beraten zu wollen ist ein sinnloses Unterfangen. Also viel Spaß dabei und nette Diskussionen mit Deinem Schwiegervater wenn die ganze Grütze nur noch von Dir verstanden werden kann, wenn in einem der unzähligen Ebenen was schiefläuft und niemand weiß mehr wo er noch suchen soll.
Prokrastinator schrieb: > Das nennt man Beratungsresistent und beratungsresistente beraten zu > wollen ist ein sinnloses Unterfangen. Man kann es auch versöhnlicher sehen: Selbst wenn man 5 Jahre ein Bussystem nutzt, lernt man nicht, warum dies so und das so gemacht ist. Man nimmt es hin und denkt: "irgendwas mussten sie ja entscheiden, die haben sich vermutlich nichts dabei gedacht". Erst wenn man selbst eine Adressierung am (parallelen) Bus versucht hat, wenn man selber eine Leitungs-Störung sucht, wenn der dritte Baustein Telegramme verschluckt und man das mit Kondensatoren und einem Nop vermeintlich löst, dann erkennt man, warum erfolgreiche Busprotokolle so sind, wie sie sind.
A. S. schrieb: > Man kann es auch versöhnlicher sehen: Das kann man und das tue ich auch eine zeitlang. Aber wenn jemand immer nur wieder die gleiche Frage stellt, die Antworten nicht beherzigt, selbst offensichlich keinerlei Praxiserfahrung hat aber wortreich die Arbeit anderer schlechtmacht, dann ist auch mal vorbei mit versöhnlich und es gibt klare Worte. Beim Chef gibts die Versetzung in einen Bereich in dem man weniger Schaden anrichten kann und weniger Tumulte bei den entnervten Kollegen auslöst oder den Stiefel. Also sind klare Worte doch eine Möglichkeit endlich mal die Message zu begreifen, bevor die Konsequenzen weit unangenehmer sind. Schönes ist selten wahr und wahres ist selten schön. So ist das Leben abseits der behüteten Uni / FH in denen man wunderhübschen aber in der Realität völlig untauglichen Konzepten frönen kann. Das scheint die größte und schwierigste Aufgabe zu sein, wenn man jemanden frisch aus der akademischen Ausbildung zu einem nützlichen Mitarbeiter formen muss. Ansonsten kann man mit dem schönen Titel lieber in den Vertrieb gehen und die Luftschlösser an Kunden verkaufen, die genausowenig Plan davon haben. Die arme Sau die das umsetzen muss wird dann für den dysfunktionalen Kram gekreuzigt, aber davon bekommt man dann ja nicht mehr viel mit.
Hier muß ich Pro mal recht geben. Ich dachte gerade, jetzt fängt er ja wie sein Schwiegervater an, genau die gleiche ungute Mischung aus Viertelwissen und beratungsresistenz. Und es ärgert mich, wenn ich direkt rauslesen kann, daß die genannten Referenzen jedenfalls nichtmal halbwegs wahrgenommen wurden. Denk einfach dran, da wo du jetzt bist, waren viele schon lange vorher. Und die armen Mitbewohner... Was, wenn Opa mal paar Wochen im Krankenhaus weilt? Gottseidank hab ich nur mechanische Lichtschalter ohne Logik. Viel Glück
Man könnte einen richtig schlechten Witz draus machen: Kommen ein Anlagenbauer und ein Informatiker in eine Bar. Fragt der Wirt "Na, wo ist euer Aufsicht führender Netzwerktechniker?"
Hallo Zusammen, ich habe die ganze Diskussion durchgelesen und ich muss sagen es war höchst unterhaltsam und informativ zugleich - eine sehr gute Mischung wie ich finde ;). Ansonsten kann ich mich diversen Vorpostern nur anschließen bezüglich der Vorzüge eines einfachen Master-Slave Systems. Ich habe vor kurzem RS-485 anhand der Vorlage von Nick Gammon umgesetzt, was für mich (ohne jahrelange praktische Erfahrung) "relativ" einfach war (ohne Oszilloskop wäre ich allerdings verloren gewesen). Vielleicht interessiert sich noch der ein oder andere für diese Quelle: https://www.gammon.com.au/forum/?id=11428 Ansonsten würde mich noch interessieren, ob jemand in diesem Zusammenhang etwas zu ARCNET und den CircLink Controllern von Microchip sagen kann. Mit diesen ist ein deterministischer Multi-Master Betrieb möglich soweit ich verstanden habe, weil der Token-Ring quasi hardwaremäßig implementiert ist.
Soviel zu aufmerksam :D, ARCNET wurde am Beginn der Diskussion bereits erwähnt von Pandur S., das hatte ich in der Zwischenzeit wohl schon wieder vergessen bzw. bin ich ursprünglich wegen der Erwähnung von ARCNET überhaupt auf diese Diskussion gestoßen. Vielleicht wäre es sinnvoll einen eigenen Beitrag zu diesem Thema zu machen... (ARCNET Vorteile/Nachteile, Erfahrungen etc)
Zuschauer schrieb: > (ohne Oszilloskop > wäre ich allerdings verloren gewesen) Ich hab mir mal den CAN-Bus auf dem Oszi angeschaut, aber nur rein aus Interesse. Zur Programmentwicklung war das nicht notwendig. Einfach die Bittimingseinstellungen aus dem Beispielcode kopiert und der CAN-Bus läuft. Der Hauptaufwand bei CAN ist, sich ein Protokoll auszudenken, wenn Pakete >8 Byte übertragen werden sollen, z.B. Flashimages für den Bootloader. Ich kann nicht verstehen, warum jeder sämtliche Sicherungs- und Arbitrierungsschichten immer noch bei RS-485 zu Fuß entwickeln will.
:
Bearbeitet durch User
Peter D. schrieb: > Ich kann nicht verstehen, warum jeder sämtliche Sicherungs- und > Arbitrierungsschichten immer noch bei RS-485 zu Fuß entwickeln will. Ja, das ist tatsächlich blöd. Aber wenn man RS485 als klassischen Master Slave Bus einsetzt, ist der immer noch ein sehr guter, robuster und billiger Bus. Diese Multimaster Protokolle auf RS485 machen nur das Timing undeterministisch und werfen eine Haufen Probleme auf die völlig unnötig sind.
Zuschauer schrieb: > (ARCNET Vorteile/Nachteile, Erfahrungen etc) ARCNET war vor dreißig Jahren eine tolle Sache, da die entsprechenden Netzwerkkarten deutlich billiger als Ethernetkarten waren. Mittlerweile dürfte sich das komplett umgekehrt haben. Das ganze ist auf einem technischen Stand von Mitte der 1990er Jahre stehengeblieben, und auch die jüngsten Datenblattrevisionen der CircLink-Controller sind schon schlappe 14 Jahre alt. Abgesehen von ein paar Nischenanwendungen mit Kompatibilitätsanforderungen ist das also ein ziemlich totes Pferd. Viele der ARCNET-Komponenten gibt es auch nur noch antiquarisch oder bei den Distributoren als "Sonderbestellung ab Werk". Wer mit solchen Komponenten heutzutage noch eine Neuentwicklung startet, darf sich nicht wundern, wenn diese in absehbarer Zeit komplett vom Markt verschwinden. Ein anderes Problem ist natürlich die Anbindung solch eines Controllers. Die Typen von Microchip (ehemals SMSC) haben ein klassisches paralles Businterface nach 808x- bzw. 68xx-Art. Natürlich kann man auch auf aktuellen Microcontrollern das entsprechende Timing in Software nachbilden, aber das kostet einen Haufen GPIO-Pins. Und "dicke" aktuelle Mikroprozessoren haben ja meist nur ein sehr schnelles paralleles Businterface für DRAMs und höchstens noch für ein paralleles Flash. Ob man die für externe Peripherie auf gemächlichen klassischen ISA-Takt heruntergetaktet bekommt, ohne gleichzeitig auch die Speicherzugriffe auszubremsen. Solch ein Peripherie-Interface ließe sich natürlich mit Leichtigkeit auf einem FPGA bzw. SoC mit FPGA-Anteil realisieren, z.B. Xilinx Zynq. Will man aber wirklich ein 50-100 EUR-SoC statt eines 3 EUR-Microcontrollers verwenden, nur um ein totes Pferd dranzuklöppeln?
Andreas S. schrieb: > Wer mit solchen > Komponenten heutzutage noch eine Neuentwicklung startet, darf sich nicht > wundern, wenn diese in absehbarer Zeit komplett vom Markt verschwinden. Wer aber aktuelle Komponenten verwendet die alle wollen, bekommt derzeit auch nichts. Also halbwegs aktuelle Exoten, die niemand auf der Kette hat, scheinen gerade der Weg zu sein lieferfähig zu bleiben.
Max M. schrieb: > Wer aber aktuelle Komponenten verwendet die alle wollen, bekommt derzeit > auch nichts. Da stimme ich durchaus zu. > Also halbwegs aktuelle Exoten, die niemand auf der Kette hat, scheinen > gerade der Weg zu sein lieferfähig zu bleiben. Es ist aber ein großer Unterschied, ob man nur innerhalb eines Geräts auf leicht exotische Teile setzt oder ob man sich durch die Verwendung eines exotischen Bussystems für viele Jahre festlegt, insbesondere auch in Hinblick auf Erweiterungen. Schließlich reden wir ja nicht davon, einen leicht angestaubten Ethernetcontroller zu verwenden, sondern einen nahezu untergegangenen "Standard" mit 30 Jahre alten Bauelementen.
Ich frage mich was hier für ein Problem konstruiert wird. Fakt ist, der Bus geht elektrisch nicht kaputt. Also bleiben nur noch die Protokoll kollisionen. Und da hast du das gleiche Problem wie bei den Funklösungen. Jeder rotzt seine Daten auf den Bus wie er will und die Empfänger haben nur das Problem der Filterung. Das Prinzip funktioniert millionenfach, warum soll es nicht funktionieren nur weil das Medium Kabel und nicht Luft ist? Jede Master Slave Konstruktion ist aufwändiger und fehleranfälliger. Jedenfalls hat sich dein Schwiegervater einen schönen Test ausgesucht um festzustellen ob du würdig genug für die Mitgift bist. Verspiel lieber die Chance nicht mit solchem Geschwafele von neuer Hardware oder Modus oder oder....
temp schrieb: > Jeder rotzt seine Daten auf den Bus wie er will und die > Empfänger haben nur das Problem der Filterung. > Jede Master Slave Konstruktion ist aufwändiger > und fehleranfälliger. Dann hast Du es weder verstanden noch jemals selber sowas gebaut. Die Kollision zerstört das Telegramm. Das muss der jeweilige Sender erstmal erkennen, er muß vom Bus gehen, eine zufällige Zeit warten und es nochmal versuchen. Der Empfänger hat absolut garnichts empfangen das er sich zuordnen kann. Da ist nur noch Müll auf der Leitung. Also muss der Sender nach ausbleibenden ACK nochmal senden. Das tun aber alle Sender deren Telegramm zerstört wurde und bis dahin senden vielleicht auch schon andere, das Spiel wiederholt sich und es gibt immer mehr Kollisionen die alle irgendwie nach zufälliger Wartezeit aufgelöst werden müssen. Ist die Zeit nicht zufällig, fangen immer wieder alle zum gleichen Zeitpunkt an und das klappt nie. Klar, alle wollen nur senden wenn der Bus frei ist, aber zwischen Erkennen und Senden vergeht Zeit. Und wann werde ich mein telegram los, wenn gerade chaos pogo ist? Irgendwann, wenn es gerade mal wieder geht. Das ist totaler selbstquälersicher Müll das so zu machen. CAN löst das in Bitzeit auf ohne dabei das dominante Bit zu zerstören. Bei RS485 kann man erkennen das irgendwas am Byte zerstört wurde, wenn man beim Senden den Empfänger aktiv lässt. Nur das das nur bei Kollisionen funzt die nicht an weit entfernten Abschnitten passieren und man das erst bearbeitet, während der Uart bereits das nächste Byte raushaut. Man zerstört also immer einen relativ langen Abschnitt. Derartige Kollisionsbusse werden mit steigender Busteilnehmerzahl und Sendungsbedürfniss immer instabiler und können in den Zustand kommen das eine ganze Zeit garnichts mehr geht. Master Slave ist absolut deterministsich. Da hat der Slave ein Zeitfenster zu antworten und das darf er nur wenn er danach gefragt wird.
Max M. schrieb: > Dann hast Du es weder verstanden noch jemals selber sowas gebaut. > Die Kollision zerstört das Telegramm. > Das muss der jeweilige Sender erstmal erkennen, er muß vom Bus gehen, > eine zufällige Zeit warten und es nochmal versuchen. > Der Empfänger hat absolut garnichts empfangen das er sich zuordnen kann. > Da ist nur noch Müll auf der Leitung. Ach ne. Wieder so ein Schlaumaier. Kein Sender muss erkennen wenn er mit einem anderen kollidiert. Oder wie machen das Funkthermometer? Die Kollision wird billigend in Kauf genommen, aber die Sender müssen die Packete in unregelmäßigen Abständen wiederholen. Einer Funkfernbedienung für eine Steckdose bleibt auch nichts anderes übrig als die Packete zu wiederholen, ohne dass sie überhaupt eine Ahnung davon hat ob die Steckdose das empfangen hat. Ob etwas vernünftig empfangen wurde bestimmt einzig und allein der Empfänger mit seinen Filtern/CRC- und Plausibilkitätschecks. Klar kann man so einen "Bus" nicht auslasten, so wie der Eingangspost aber war, ist er das ja sowieso nicht. Die Anforderung von oben waren kurze Datenpackete an die Thermostate zu senden ohne Rückkanal. Also gibt es eh einen Master (für diesen Zweck) und wenn der alle 5min + rand() ms sein Packet wiederholt, kommt es auch irgendwann an. Das ganze verhält sich exakt so wie mit Funk. Und wenn ich so eine Lösung schon am Laufen habe und es sollen nur ein paar Thermostate dazukommen, dann würde ich mir einen andern Schwiegersohn suchen wenn er nur große Fress hat aber so eine Kleinigkeit nicht gebacken kriegt. Und ja ich habe so einem Bus seit ewigkeiten am Laufen mit einem Sack voll Temperatur/Feuchtsensoren, Gas-/Wasser- und Eltrozählern. Und das mit einem Draht und nicht mit RS485. Leute es geht hier nicht um große Datenraten und nur um kleine Datenpackte. Bei Funk im 868MHz Bereich ist man auch je nach Frequenz auf 0,1% bis 1% Sendedauer pro Knoten beschränkt. Max M. schrieb: > Da ist nur noch Müll auf der Leitung. Gut dass du uns das jetzt sagst, und dass jegliche Funktechik auf 433MHz und 868MHz nicht funktionieren kann, weil die Sender ja keine Kollisionserkennung haben. Du bist eindeutig zu schlau für diese Welt oder in deinem Hamsterrad gefangen.
A. S. schrieb: > Und wenn die enocean ungefragt feuern bei höherer Auslastung, dann sind > die nicht integrierbar. In Funk sind die kein Problem, da die Frequenz > nur sehr schwach belegt ist, die Telegramme kurz und wiederholt sind UND > notfalls nochmals gedrückt wird. > > Wenn Dein Schwiegervater aber genau das als Grundlage nimmt und mit > Verlusten lebt, ist das evt. ok. Genau so siehts aus. Er transportiert das was vorher Funk war jetzt nur per Draht weiter und ist sich der Problematik bewust. Und wenn jetzt beim 3s-Drücken so eines Tasters mal ein Temperatursensor nicht übertragen wird, geht die Welt nicht unter, so schnell ändern sich keine Temperaturen. Es geht hier um ein bischen Heimautomatisierung, dass das in einem Auto oder einer Maschine was völlig anderes ist, sollte jemdem klar sein.
temp schrieb: > Jedenfalls hat sich dein Schwiegervater einen schönen Test ausgesucht um > festzustellen ob du würdig genug für die Mitgift bist. Verspiel lieber > die Chance nicht mit solchem Geschwafele von neuer Hardware oder Modus > oder oder.... ...sie wußten verlässlich, die Tochter ist grässlich...der Becher liegt heute noch unten. (Heinz Erhard, der Tauchenichts) Gruß Rainer
demo schrieb: > , dann würde ich mir einen andern > Schwiegersohn suchen wenn er nur große Fress hat aber so eine > Kleinigkeit nicht gebacken kriegt. Leider oder auch zum Glück liegt das nicht im Ermessen der Eltern, auch nicht bei der Auswahl der Schwiegertochter.
demo schrieb: > Kein Sender muss erkennen wenn er mit > einem anderen kollidiert. Ach so. Du meinst einen erbärmlich zusammengestümperten Hobby Heimwerken Bus der der nach Prinzip Hoffnung funktioniert. Das konnte ich ja nicht wissen. Hätte ich mir aber denken können, weil wir a: bei mc.net sind b: du ständig RS485 mit Funkt vergleichst
Zuschauer schrieb: > Ansonsten würde mich noch interessieren, ob jemand in diesem > Zusammenhang etwas zu ARCNET und den CircLink Controllern von Microchip > sagen kann. Es gibt Industriebereiche mit hohen Stückkosten der Geräte, in denen ARCNET noch im Einsatz ist. Hauptsächlich, weil man das da schon seit zig Jahren einsetzt und keinen Grund hat, das zu ändern, solange man die Komponenten kriegt. Es ergibt aber keinerlei Sinn, ARCNET bei Neuentwicklungen überhaupt in Betracht zu ziehen.
:
Bearbeitet durch User
Max M. schrieb: > Ach so. > Du meinst einen erbärmlich zusammengestümperten Hobby Heimwerken Bus der > der nach Prinzip Hoffnung funktioniert. > Das konnte ich ja nicht wissen. > Hätte ich mir aber denken können, weil wir > a: bei mc.net sind > b: du ständig RS485 mit Funkt vergleichst Erbärmlich? Niemals, denn das ist das Prinzip wie sicher über 99% aller verkauften Heimautomationssachen funktionieren. Was gibt es ausser den massenhaft verkauften Funklösungen im 868MHz und 433MHz Bereich noch? KNX klar, das ist aber eine komplett andere Liega und fristet im Vergleich zum Massenmarkt eine Nischendasein. Es ist auch nicht das was oben gefordert war oder schon im Betrieb ist. Und durch das bestehende Funk zu RS485 Gateway ist die Richtung ja sowieso schon vorgegeben. WLAN? Ok da gibt es eine Busdisziplien, bei DECT auch. Trotzdem arbeitet die Masse der verkauften Geräte nach dem Prinzip Hoffnung oder besser nach dem Prinzip Wahrscheinlichkeit. Und klar, ich vergleiche RS485 in diesem Fall mit Funk. Der einzige Unterschied besteht im Medium. RS485 hat noch den Vorteil, dass man durch höhere Bitraten die Wahrscheinlichkeit von Kollisionen deutlich verringen kann im Verhältnis zu bestehenden Funklösungen wie FS20 und Kollegen. Klar kann man auf RS485 ein vernünftiges Protokoll aufsetzen das Kollisionen vermeidet. Das kann man bei Funk auch, macht nur kaum einer da man mit Fremdstörern immer rechnen muss. Und egal ob man sein eigenes Protokoll auf CAN oder RS485 Basis fährt, nach deiner Definition bleibt auch das bloss ein "erbärmlich zusammengestümperten Hobby Heimwerken Bus" weil er nur zu seinen eigenen Geräten kompatibel ist. Das Problem der Möglichkeit einer Fremdwartung hat man auf der anderen Seite immer. Auch bei KNX. Oder man bezahlt sich dumm und dämlich. So wie ich das oben lese ist das alles aber sowieso nur die Spaßerweiterung. Fällt es aus ist zwar der Komfort nicht mehr da, funktionsfähig bleibt das Haus aber.
H.Joachim S. schrieb: > Leider oder auch zum Glück liegt das nicht im Ermessen der Eltern, auch > nicht bei der Auswahl der Schwiegertochter. Glück trifft es besser. Die Hälfte der Menschheit hat dieses Glück sicher noch nicht, und auch in D ist es mittlerweile auch nicht unbedingt selbstverständlich.
Nimm ein raspi Lade dir qt runter Lade dir Libmodbus runter Setze alle Teilnehmer auf gleiche bus aber mit verschiedene slave Adresse (ReihEE) gleiche Baud,parity.. Hole dir einen Usb-rs485 Wandler aus Mallorca Mach jetzt Licht an Licht aus - Uppsala machs automatisch 9600-8-N-1 -,,--- $home/liegestuetze.bin
Fitnesscouch schrieb: > Nimm ein raspi > Lade dir qt runter > Lade dir Libmodbus runter > Setze alle Teilnehmer auf gleiche bus aber mit verschiedene slave > Adresse (ReihEE) gleiche Baud,parity.. > > Hole dir einen Usb-rs485 Wandler aus Mallorca > > Mach jetzt Licht an Licht aus - Uppsala machs automatisch > > 9600-8-N-1 -,,--- $home/liegestuetze.bin Willst du uns damit den (umgekehrt proportionalen) Zusammenhang zwischen Hirnleistung und Krafttraining beweisen?
demo schrieb: > Funklösungen im 868MHz und 433MHz Sorry, aber damit vergleiche ich nicht. Erstmal ist Funk was völlig anderes als RS485 und zum anderen erwarte ich von einem Bussystem das Nachrichten in einem definiertem Zeitraum ankommen und es eine Fehlerbehandlung gibt. Bei denn billigem Funk Schrott geht das kaum anders, als einfach los zu feuern, weil die 2€ Türklingel nicht mal einen Rückkanal hat und auch nicht beliebig oft senden kann, um die Batterie zu schonen. Man muss eben so lange Klingeln bis es dann irgendwann mal geht. Aber das ist eben Müll für Bastler ohne Anspruch. Ich hatte mehr als eine dieser Funk Kisten. Ich baue professionelle Steuerungssysteme mit RS485. Aktionen müssen zuverlässig innerhalb eines definierten Zeitfensters übertragen werden oder das Gerät wird als fehlerhaft markiert und die Service Crew muss ran. Das Busteilnehmer mal ja, mal nein, mal irgendwann, mal nie, mal erst beim 5ten Versuch funktionieren ist einfach undenkbar. Der Kunde drückt nicht 1-8mal den Lichttaster bis das geht oder will brennend ins Meer stürzen, weil der Feuermelder sein Telegramm wegen Busstörung nicht loswerden konnte. Der haut uns das um die Ohren und geht zu jemanden der seinen Job versteht. Der Bus muss mit 2 Teilnehmern genauso determisistisch funktionieren wie mit 64 Teilnehmer. Und das tut Dein Chaos Kollisions 'Bus' eben nicht. Ist mir auch völlig egal wann der Slave meint seine Daten loswerden zu wollen. Wichtig ist nur wann und wie oft ich die brauche.
Gibts eigentlich professionelle Steuersysteme mit notwendig deterministischem Verhalten, die dafür Funk verwenden? Mir scheint das leicht widersprüchlich. Was jemand in seiner privaten Bude verbaut, und ob dabei das Ziel wichtiger als der Weg dorthin, ist eine andere Sache. Mancher fühlt sich als Hard- und Software-Dompteur nur ernst genommen, wenn es schwierig ist. Man kommt auch mit dem Helikopter auf viele Berge, aber das ist irgendwie nicht das Gleiche. ;-)
:
Bearbeitet durch User
Ist so wie über die optimale CPU-Architektur zu sinnen. Einen Bus zu entwickeln, kann sehr intellektuell fordernd sein und füllt garantiert viele Winterabende. Ich schleppe meine Ideen diesbezüglich schon seit 35 Jahren mit mir rum.
Abdul K. schrieb: > Ich schleppe meine Ideen diesbezüglich schon seit 35 Jahren mit mir rum. Sind das Ideen geblieben, oder wurden sie auch mal realisiert? ;-)
Ich hatte mit ähnlichen Designs in der Industrie zu tun. Die waren also real. Ansonsten bevorzuge ich KISS, also mechanische direkt schaltende Lichtschalter ohne BluescreenLED ;-) Aber ja, ich bin ziemlich weit mit meinen Ideen und werde es wohl bald mal real aufbauen/programmieren. --- Der Thread hier ist aber für die Tonne, wenn ich mir den Eröffnungspost nochmals durchlese. Da frag ich mich, was ein Informatiker lernt? --- Gibt es irgendwelche PC-Sotware, die über serielle Schnittstelle Streßtests fahren kann?
:
Bearbeitet durch User
Abdul K. schrieb: > Der Thread hier ist aber für die Tonne, wenn ich mir den Eröffnungspost > nochmals durchlese. Da frag ich mich, was ein Informatiker lernt? Kommt drauf auf die Richtung an. Wer sich auf KI, Linguistik, oder Mensch-Maschine-Kommunikation spezialisiert (*), hat zu RS485 weniger Beziehung als der die Leitungen verlegende Elektriker. ;-) *: Begriffe aus meiner Zeit. Ist schon länger her.
:
Bearbeitet durch User
Der postet aber dann doch nicht hier. Grübel Abdul, laß dich jetzt nicht verleiten....
Also ich muss sagen oft ist ein Bus einfacher aufgebaut wie viele denken. Kommt halt immer darauf an was gemacht werden soll, ein gutes Pferd springt immer nur so hoch wie es muss, und alle mir bekannten Busse in der Industrie, nutzen einfach nur das als Baudrate was auch wirklich nötig ist. Ich muss aber sagen dass ich nur mit Zeit unkritischen Systemen arbeite. Aber es ist alles mögliche dabei z.b. onewire, rs485, und diverse Sonderformen. Und dementsprechend ist es meistens sogar Master-Slave mäßig aufgebaut. Ein differentieller Bus begegnet mir im Alltag sehr oft, aber ob der jetzt als Master Slave, oder Multimaster arbeitet würde mich auch mal interessieren. Ich würde einfach schauen wie bekannte Busse die Probleme gelöst haben, z.b. der Canbus über die identifier diese 11bit Zahlen welche jeweils immer nur von einem Teilnehmer benutzt werden dürfen, und eine Rangordnung der Wichtigkeit der nachrichten darstellen. Usw usw. Aber dann kommt man auch ganz schnell wieder dahin einfach was anderes zu benutzen. Dann stimme ich den Leuten hier zu das ein Master Slave Bus komplett ausreichend ist. Es gibt einfach ganz wenige Situationen wo so viele zeitkritische Aktionen über viele Teilnehmer verteilt stattfinden. Aber genau das ist auch die einzige Situation wo wirklich ein Multimaster Bus benötigt wird. Und kein KNX ist alles andere als tot, wird andauernd irgendwo verbaut. Und preislich gesehen auch nicht viel teurer wie irgendwas anderes, ich bekomme ein 32 Eingänge Aktor potentialfrei für 300 €, und 24 bistabilen Relais 16 Ampere für 350€, und da ist alles schon drin damit es funktioniert. Wenn ich das ganze mit etwas anderen Steuern will gibt's Millionen Gateways. Und wenn ich dann noch irgendwo in besonderen Taster mit einer LED Anzeige hin haben will geht das auch ohne Probleme. Also ich würde nicht canbus verwenden, der Stromverbrauch ist zu hoch.
DANIEL D. schrieb: > Also ich würde nicht canbus verwenden, der Stromverbrauch ist zu hoch. Allein diese Aussage reicht um dich völlig zu disqualifizieren
Ich könnte dieses Thema ja mal final beenden. Ich habe das Problem jetzt schon länger gelöst und hab mich gewundert, wieso der Thread in den letzten Tagen wieder so unglaublich viel los war. Ich hab nachgeschaut und ein 3. Physisches Kabel gefunden. Dieses Kabel missbrauchen Ich als "Interrupt" Leitung. Sollte wirklich jemals ein Knoten nicht warten können bis der Master wieder pollt, dann kann er diese Leitung auf 0 ziehen und der Master pollt sofort alle. Die slaves haben eine Offene addresse. Also die addresse kann beliebig lang eingestellt werden die Länge der addresse kann der Master mit der addresse 0 und einem command einstellen. Da ich ja sowieso zwei klemmblöscke haben sollte, damit man einfach Durch verbinden kann, hab ich mir gedacht anstatt max485 nehme ich einen Chip von Texas instruments - schon länger her, dass ich die Hardware gebaut habe und weiß grad nicht genau welchen. Mit dem hab so eine Art unterbrechbare Brücke gebaut. Für den Fall, dass das Gerät nicht initialisiert ist, sind beide Seiten nicht verbunden. Ein Gerät allein wird sich die 1 geben, damit der Master mit ihm reden kann und die Brücke zwischen links und rechts (So hab ich die Seiten vom Bus genannt) bleibt offen. Kommt der Master online, so sendet er ein init command. An ID 1. Knoten 1 weiß jetzt ob der Master links, oder rechts von ihm ist. Dem Master antwortet der Knoten mit einem Ack Befehl und schickt in die andere Richtung einen "Inc" Befehl. Dieser veranlasst den nächsten Knoten seine ID zu erhöhen. Anschließend sendet der neue Knoten 2 ein ack an Knoten 1. Wenn Knoten 1 das ack empfängt, dann schickt er ein Online Befehl an den Master und schaltet sich selbst transparent. Nun geht das selbe Spiel nur mit init für Knoten 2 weiter, bis zum letzten Knoten. Hier für das Beispiel nehme ich mal Knoten 3 als letzten an. Bekommt Knoten 3 auf den Inc Befehl 1 Sekunde keine Antwort, so geht er davon aus, dass er der Letzte ist. Er merkt sich selbst, dass er eob (End of Bus) ist und sendet einen End Befehl an den Master. Dieser weiß dann ebenfalls dass der enumeration Vorgang beendet ist und geht iintern von Wartung zu Betrieb über. Mag sehr konfus klingen, funktioniert aber super. Das transparent schalten passiert mittels dma. Das ist zwar nicht ganz transparent, weil es eine minimale Verzögerung bringt, aber halb so schlimm. Ich hoffe ja nicht, dass es mal mehr als ein paar Knoten geben wird. Und der Master ist ein raspberry pi mit einem python script, der mittels des s7 Protokolls in die Sps schreibt. Und für all das andere brauchen nur Knoten 1 und der letzte Knoten sich kennen. Knoten eins schickt telegramme, die mit der ide des letzten Knotens und ein paar 0 bytes geframed sind weiter an den End-Knoten. Das ist gemacht worden, damit auch andere Knoten irgwendwo dazwischen liegen können und das funktionieren sollte. Der Letzte entfernt das framing und leitet das Telegramm weiter. Und mit der Antwort passiert das gleiche nur umgekehrt. Ich hab nur keine Lösung für das baud umschalten gefunden und so kurzer Hand entweder bestehende Knoten umgebaut um an meinem Bus zu funktionieren. Bei ein paar Teilnehmern musste ich komplett neue Knoten bauen, aber jetzt ist alles entweder transparent oder umgebaut. Und das beste ist, dass die SPS nur in ihren Daten lock schreiben muss und mein Master bekommt die Veränderung mit. Mein Master hat auch ein Webinterface, um mapping zwischen Variablen in der SPS und Knoten machen zu können und alle möglichen Dinge an Knoten einzustellen. Das System würde nur davon verbessert, wenn ich busfaults erkennen könnte um dem Master meldung machen zu können und damit die Knoten zwischen denen der Defekt aufgetreten ist das anzeigen können. Sry für die vielen Fehler in diesem Beitrag. Der ist von einem Handy aus getippt und ich fürchte ich hab nicht alle Fehler oder autokorrektur Ausrutscher gefunden.
Stefan S. schrieb: > Und der Master ist ein raspberry pi mit einem python script, der mittels > des s7 Protokolls in die Sps schreibt. Und das alles um ein paar Lampen, Sensoren und Taster zu bedienen? Naja, haupsache es geht bei dir und du bist glücklich.
(prx) A. K. schrieb: > Gibts eigentlich professionelle Steuersysteme mit notwendig > deterministischem Verhalten, die dafür Funk verwenden? Mir scheint das > leicht widersprüchlich. K.A. aber vorstellbar. An sich ist es egal ob RS485 Bus oder Funk. Es muß nur eine regelmäßige Kommunikation geben, bei der gecheckt wird ob jedes Gerät verfügbar und wie dessen Status ist. Bei einem Kollisionsbus darf ich eben die Bandbreite nur zu ca. 30% auslasten um ein halbwegs stabiles Zeitverhalten zu haben. Nur das dann bei Funkstörung eben die Warnlampen angehen und auf einen Feuermelder übertragen würde das eben bedeuten das der Bereich durch eine Person so lange überwacht werden muss bis die Funktion wieder hergestellt ist. Wer Funk kennt, nimmt Kabel. Bei einem Master Slave Bus fragt der Master jedes Gerät so schnell ab, wie er die Daten braucht. Er kann auch Gerät 1,5 und 8 sehr häufig abfragen und andere nur in großen Abständen. Die Bandbreite lässt sich sehr effektiv nutzen. Wild drauf los feuernde Slaves machen nichts schneller. Die zernageln ggf. nur die Telegramme der Slaves, die schnell hätten melden müssen, das aber nicht konnten, weil ein völlig uninteressanter Slave Sprechdurchfall hatte.
Stefan S. schrieb: > hab mich gewundert, > wieso der Thread in den letzten Tagen wieder so unglaublich viel los > war. Geht ja schon lange um prinzipielle Dinge am RS485 und über Bussysteme generell. Ist doch schön wenn ein Thread über die eigentliche Fragestellung hinaus lebt, ohne das es nur noch um gegenseitiges niedermetzeln geht.
(prx) A. K. schrieb: > Gibts eigentlich professionelle Steuersysteme mit notwendig > deterministischem Verhalten, die dafür Funk verwenden? Mir scheint das > leicht widersprüchlich. Ja, so etwas gibt es natürlich, und zwar auch für hohe Anforderungen bezüglich der funktionalen Sicherheit. Viele Baumaschinen bzw. -fahrzeuge können heutzutage mit einer portablen Funkfernsteuerung bedient werden, was tatsächlich zu einem deutlichen Sicherheitsgewinn führt. Das ganze setzt aber voraus, dass es in jeder Situation einen sicheren Betriebszustand gibt, der bei Störungen der Funkübertragung eingenommen werden kann. Folglich muss es eine fortlaufende Kommunikation geben, deren Aussetzen hinreichend zügig erkannt werden kann. Bei solch einer Baumaschine bedeutet das dann einfach das Anhalten. Ein Hubmagnet o.ä. darf dabei natürlich nicht gelöst werden. Wir haben vor einigen Jahren für mehrere Kunden entsprechende Voruntersuchungen und Konzepte erstellt. Besonders gut kam dabei an, den Fernsteuersender mit einem Beschleunigungs- bzw. Lagesensor auszustatten, um das Herunterfallen bzw. Ablegen auf den Bedienelementen zu erkennen. Das ganze kombiniert man dann vorzugsweise auch mit einer Art Watchdogfunktionalität, d.h. die Empfängerseite sendet Challenges, die durch das Bediengerät bearbeitet und zusammen mit den Steuersignalen zurückgesendet werden. Dies aber auch nur zusätzlich zur kryptografischen Signatur der Datenpakete.
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.