Hallo liebe Leute, mit einem Rigol-Oszi möchte ich ein RS485-Signal Entziffern, welches von einem pH-Sensor generiert wird. Der Sensor hat vier Litzen: gelb: Signal (RS485-A) blau: Signal (RS485-B) braun: positive Versorgung (12...24V DC) schwarz: negative Versorgung (0V) Kann ich diese abgebildete Spitze verwenden um das RS485-Signal abzutasten? Ist die kleine Krokodilklemme in diesem Fall Ground oder "nur" um Impedanz-Probleme vorzubeugen? Bisher verwendete ich immer nur für langsame, analoge Signale mit BNC. Mit seriellen Schnittstellen kenn ich mich nur wenig aus. Vielen Dank
:
Verschoben durch Moderator
> Ist die kleine Krokodilklemme in diesem Fall Ground oder > "nur" um Impedanz-Probleme vorzubeugen? Diese doofen Krokoklemmen sind GND und muessen selbstverstaendlich mit Ground deines Signals verbunden sein. Bei Signalen von hoher Frequenz ist diese Verbindung wegen der Impedanz der 10cm Zuleitung nicht ausreichend, deshalb gehoert zu einem Tastkopf auch immer so eine kleine Massefeder. Bei RS485 wirst du vermutlich nur so 9600 bis 115200Baud uebertragungsrate haben. Also wirst du Signale bis maximal 1Mhz Bandbreite sehen wollen und deshalb ist dann die Krokoklemme ausreichend und erforderlich. Wenn man mit mehreren Tastkoepfen misst dann sollte man eigentlich auch jeden irgendwo mit der Krokoklemme an GND anklemmen. Allerdings wenn man weiss was man da macht und keine sauberen Bilder rumzeigen muss, dann kann man da schon mal etwas vernachlaessigen. .-) Ich empfehle dir mal die unterschiedlichen Klemmungen, auch mit Massefeder, auszuprobieren damit du den Unterschied siehst und ein Gefuehl dafuer bekommst wann man etwas locker sehen kann und wann nicht. Vanye
Die "richtige" Methode, ein differenzielles Signal wie RS-485 zu messen, ist zwei Kanäle für A und B (jeweils relativ zur Masse) zu benutzen und das Oszilloskop A−B berechnen zu lassen. Aber wenn du nicht viele Störungen hast, dann geht auch einfach nur A.
> Die "richtige" Methode, ein differenzielles Signal wie RS-485 zu messen, > ist zwei Kanäle für A und B Ach komm, das ist die richtige Methode um stoerungsfreien Betrieb fuer ein 1000m langes Kabel im harten Industrieeinsatz sicher zu stellen. Aber um mit dem Oszi ein paar Daten abzuschnorcheln reicht es einfach nur A oder B zu belauschen. Vanye
Und wenn schon richtig dann richtig richtig mit einem richtigen Differenztastkopf SCNR ;-)
Vielen Dank schon mal. Langsam tut sich etwas (s. Foto) Leider sieht man noch nicht scharfe Kanten und Pulse, wie erwartet...und der RX-Decoder zeigt zwar Zahlen an, aber noch keine Wörter.. Irgendwelche Ideen?
> Irgendwelche Ideen?
Nun, als erstes mal schalte den Eingang deines Oszi auf DC um. :-D
Vanye
Und es könnte Sinn machen, die GND-Klemme des Tastkopfs auch auf GND zu legen. Da es sich da um PE der Steckdose handelt in der das Oszi steckt, könnte es je nach Restschaltung und Netzteil schlecht sein, A oder B nach PE kurzzuschließen...
Jens M. schrieb: > Da es sich da um PE der Steckdose handelt in der das Oszi steckt, könnte > es je nach Restschaltung und Netzteil schlecht sein, A oder B nach PE > kurzzuschließen... Die Gnd-Klemme hat weder an A noch an B irgendetwas zu suchen. Sonst muss der RS485-Treiber den ganzen Aufbau mit durch die Gegend schleifen.
Rainer W. schrieb: > Die Gnd-Klemme hat weder an A noch an B irgendetwas zu suchen. Ja ach. Die Klemme ist klar an "blau", und das ist Lysandros schrieb: > blau: Signal (RS485-B) Ups... Rainer W. schrieb: > Sonst muss der RS485-Treiber den ganzen Aufbau mit durch die Gegend > schleifen. Chuck Norris macht auch keine Pushups, er drückt die Erde runter. Sieht man hier auch am Skopbild.
Laut einige im Internet zu findender Beschreibungen sprechen diese Bodensensoren offenbar Modbus RTU, vermutlich als Slave. Dementsprechend sollte sich gar nichts auf den Datenleitungen tun. Je nachdem, ob die EIA-485 korrekt abgeschlossen und mit Failsafe-Beschaltung versehen ist, sollte A dann irgendwo zwischen ca. 1,5 V und 5 V hängen und B zwischen 0V und ca. 2,5 V, wobei A immer positiver als B sein dürfte. Folglich muss der Sensor also an einen Modbus Master angeschlossen sein, der ihn periodisch mit der richtigen Baudrate, Übertragungsparametern und Adresse abfragt. Auf dem Oszilloskop kann man meist Master und Slave sehr gut daran unterscheiden, dass sie leicht unterschiedliche Signalpegel treiben.
> Folglich muss der Sensor also an einen Modbus Master angeschlossen sein,
Sicher, ohne Arme keine Kekse. Datenuebertragung muss schon da sein
wenn man was sehen will.
Vanye
Lysandros schrieb: > Irgendwelche Ideen? Du misst Mist (aka. Störungen). Kein Wunder bei dem Messaufbau. Als Tipp: um zu sehen, was da grade so an Störungen unterwegs ist, halte ich kurz vor der Messung die Tastspitze mal kurz an die angeklemmte Masseklemme. Wenn du dann keine schnurgerade Linie auf 0V siehst, sind eh schon Störungen ubterwegs. > und der RX-Decoder zeigt zwar Zahlen an Und so gut wie jede Zahl endet mit einem Fragezeichen... Kurz: der wird aus jedem Signal irgendwas herausrechnen. Halt einfach mal nur den Finger an die Spitze. Du wirst die Lottozahlen sehen.
Der Decoder bemühst sich, aus den 50mV-Spitzen zu machen was er kann. Normal sollten da eher ganze Volt rauskommen, und nicht so schön regelmäßige Elkonachladekurven.
Ein USB RS485 Adapter und eine Modbus Software helfen da. Da dein Rigol auch 16 Digitaleingänge hat hilft vllt. auch ein Blick ins Manual.
Tatsächlich steht in der Anleitung (aus Fernost, die Übersetzung ist so-la-la), dass man ein Modbus-RTU einsetzen soll. Verstehe ich es richtig, dass ich die Messwerte über einen "Host" aktiv abfragen muss, über Leitung "B" ? Ich hatte gehofft, dass der Sensor mit einer festen Rate die Werte liefert...
Ja, wenn es ModbusRTU ist musst du den Sensor abfragen. Aber nicht über B, A & B gehören zusammen, das ist eine differentielle Übertragung, d.h. "A+ und B-" ist ein Bit, "A- und B+" das andere. Im Prinzip eine normale Halbduplex Serielle Schnittstelle, nur mit anderen Spannungspegeln.
Lysandros schrieb: > Tatsächlich steht in der Anleitung (aus Fernost, die Übersetzung ist > so-la-la), dass man ein Modbus-RTU einsetzen soll. Verstehe ich es > richtig, dass ich die Messwerte über einen "Host" aktiv abfragen muss, > über Leitung "B" ? Ich hatte gehofft, dass der Sensor mit einer festen > Rate die Werte liefert... Das ist bei Modbus unüblich. Der Sensor ist höchstwahrscheinlich als Slave implementiert und sendet von sich aus nichts. Wenn Du eine Doku des Sensors hast, stelle sie hier doch mal ein
Vanye R. schrieb: >> Die "richtige" Methode, ein differenzielles Signal wie RS-485 zu messen, >> ist zwei Kanäle für A und B > > Ach komm, das ist die richtige Methode um stoerungsfreien Betrieb fuer > ein 1000m langes Kabel im harten Industrieeinsatz sicher zu stellen. > Aber um mit dem Oszi ein paar Daten abzuschnorcheln reicht es einfach > nur A oder B zu belauschen. > > Vanye Außer irgendwer sendet Stuss auf der Leitung wodurch das Signal nicht korrekt ist.
> Ich hatte gehofft, dass der Sensor mit einer festen > Rate die Werte liefert... Nein, du hoffst komplett falsch. Lies dir irgendwo ein paar Grundlagen zu Modbus an! Oder kauf dir dieses Kabel. (teuer aber stressfrei) https://ftdichip.com/products/usb-rs485-we-1800-bt/ Oder in billig: https://de.aliexpress.com/item/1005006003176867.html Wenn du dann Modbus kapiert hast kannst du mit hterm einfach ein paar Bytes senden und er wird dir antworten. Wenn du auf bloed spielen willst kannst du auch noch das hier kaufen: http://www.simplymodbus.ca/download.htm Noch ein Wort zur Aufmunterung: Modbus gilt als der einfachste der industriellen Feldbusse. .-) Vanye
Lysandros schrieb: > Ich hatte gehofft Aus eigener Erfahrung: das ist keine geeignete Basis für erfolgreiche Elektronikentwicklung. Wenn man ein Bussystem verwenden will, dann muss man sich zuallererst mal die Grundlagen dieses Bussystems aneignen. Dann kann man versuchen, selber mit diesem Bus zu fahren. Aber einfach nur "reinsitzen" und hoffen, dass der Bus dorthin fährt, wo man gerne hinwill, führt in den allermeisten Fällen nicht zum gewünschten Ziel. Lysandros schrieb: > welches von einem pH-Sensor generiert wird. Probieren wirs mal so: von welchem pH-Sensor soll da was gesendet werden? Gibt es da auch ein Manual dazu? Oder wenigstens eine Typbezeichung?
Lothar M. schrieb: > Gibt es da auch ein Manual dazu? Ich hatte den TO auch schon gebeten alle Unterlagen einzustellen. Denn er hat welche: "Tatsächlich steht in der Anleitung (aus Fernost, die Übersetzung ist so-la-la), dass man ein Modbus-RTU einsetzen soll"...
Und hier mein Setup, daraus soll ich eine Industrie-4.0-Telemetrie MacGyvern :/ Das kleine Board ist: https://www.conrad.de/de/p/max485-ttl-to-rs485-switch-schalter-5v-modul-fuer-arduino-raspberry-pi-802243984.html#productDescription
:
Bearbeitet durch User
In der Anleitung sind doch die meisten wichtigen Parameter beschrieben. Und wie zu erwarten war, handelt es sich um einen Modbus Slave. Und noch einmal die wichtige Frage: Was glaubst Du denn mit dem Oszilloskop messen zu können, wenn der Sensor nicht von einem Host abgefragt wird? Die einzigen Informationen, die man darüber herausbekommen kann, sind gg. die Terminierung und die Fail-Safe-Pegel.
Gut, jetzt ist einiges klarer. Vielen Dank euch allen Habe gerade über Minicom (ähnlich wie PuTTy) versucht eine Verbindung aufzubauen aber es passiert nichts; ich kann keine Commands über den Rechner an den Sensor senden...Es ist als ob der USB/RS485-Converter den Sensor nicht bemerkt. Ich versuche es womöglich jetzt mit einem Microcontroller.
Lysandros schrieb: > Es ist als ob der USB/RS485-Converter den > Sensor nicht bemerkt. Du kannst aber auf der RS485-Seite mit dem Oszi messen, ob sich auf der Leitung etwas tut. Vielleicht schickst du auch nur das falsche Kommando!?
> ich kann keine Commands über den Rechner an den Sensor senden...
Warum glaubst du wohl hab ich oben hterm gesagt? Du glaubst doch nicht
im Ernst das ein Empfaenger die Ewigkeiten warten welche die glibbrige
Masse zwischen deinen Ohren braucht um einzelne Zeichen zu tippen oder?
Du must eine korrekte Nachricht mit korrekter Pruefsumme an einem Stueck
schicken.
Vanye
Lysandros schrieb: > Habe gerade über Minicom (ähnlich wie PuTTy) versucht eine Verbindung > aufzubauen aber es passiert nichts; ich kann keine Commands über den > Rechner an den Sensor senden... Hast Du mittels Oszilloskop verifiziert, dass Minicom keine Zeichen an den Sensor schickt? Wie erzeugst Du die binären(!) Zeichenfolge mit dem Befehl? Wie erzeugst und sendest Du die korrekte CRC? Woher stammt das zugehörige Generatorpolynom? Hast Du verifiziert, dass die Zeichen schnell genug gesendet werden, d.h. Modbus T35 einghalten wird? > Es ist als ob der USB/RS485-Converter den > Sensor nicht bemerkt. Das hast Du wie verifiziert? > Ich versuche es womöglich jetzt mit einem Microcontroller. Um Dir die nächsten Probleme einzuhandeln, ohne dass Du die Ursache der Fehlversuche mit dem PC geklärt hast? Hast Du denn die offizielle Modbus-RTU-Spezifikation konsultiert und verstanden, was darin enthalten ist?
:
Bearbeitet durch User
Dietrich L. schrieb: > Vielleicht schickst du auch nur das falsche Kommando!? Ich vermute ja sehr stark, dass er händisch ein paar ASCII-Zeichen schickt, inklusive der Zeichenfolge "CRC". Und T35 läuft zwischendurch jeweils hundertmal ab.
Lysandros schrieb: > Habe gerade über Minicom (ähnlich wie PuTTy) versucht eine Verbindung > aufzubauen aber es passiert nichts; ich kann keine Commands über den > Rechner an den Sensor senden...Es ist als ob der USB/RS485-Converter den > Sensor nicht bemerkt. Ich versuche es womöglich jetzt mit einem > Microcontroller. Ist das wirklich die serielle Schnittstelle /dev/tty.usbserial-AK966VDV Schau mal mit ls -la /dev/tty* nach, was es da alles gibt Und ja: Linux unterscheidet zwischen Gross- und Kleinschreibung, also auch ls -la /dev/*USB* und ls -la /dev/*ACM*, denn serielle Schnittstellen können auch /dev/ttyACMx heissen
:
Bearbeitet durch User
Hey zusammen, aktuell sende ich keine Befehle an den Sensor. Bin noch nicht soweit. Hatte erwartet, dass im Minicomputer etwas wie "waiting for commands" erscheint, und ich dann eine Zeichenreihe rausschicken kann. Ich hänge jetzt den Oszi drann. Viele Grüße
Lysandros schrieb: > Hatte erwartet, dass im Minicomputer etwas wie "waiting > for commands" erscheint, und ich dann eine Zeichenreihe rausschicken > kann. Wo genau hast Du das in der offiziellen Modbus-Spezifikation gelesen? > Ich hänge jetzt den Oszi drann. Das ist generell eine gute Idee, um zu schauen, ob überhaupt Zeichen geschickt werden. Aber ohne Kenntnisse des Protokolls wirst Du nicht beurteilen können, ob das einigermaßen Modbus RTU entspricht.
Lade Dir QModMaster runter, stelle ModbusRTU und 9k6 8N1 ein und lese die in der Doku angegebenen Register aus. Wenn das dann klappt kannst du dir die Kommunikation gerne mit dem Oszi ansehen. Ist aber eigentlich unnötig, ModBusRTu ist sehr gut dokumentiert. Ob Du dann einen eigenen Modbus-Master programmieren willst oder lieber was fertiges nimmst kannst Du dir dann überlegen. Ach so: Modbus-Frames müssen am Stück geschickt werde. Zeichenweises eintippen klappt nicht. Wenn Du das Modbus-Telegramm von Hand erzeugen möchtest musst Du es vorher zusammentippen und dann am Stück abschicken. Für solche Sachen nehme ich gerne Realterm, einfach weil ich das schon seit Ewigkeiten benutze :-)
:
Bearbeitet durch User
Liebe Leute, inzwischen habe ich folgendes Zubehör: ==> Adapter-Board mit MAX485: Dokumentation ist wie Kraut und Rüben: https://eckstein-shop.de/MAX485ModuleTTLSwitchSchaltertoRS-485ModuleRS4855VModul . Ich weiss nur, dass der grüne Phoenix-Header für pin A bzw. pin B vorgesehen ist, aber noch nicht was die Steckleisten-Pins sollen. ==> USB/RS485-Konverter: keinerlei Artikelnummer oder Datenblatt vorhanden. Wie würdet ihr den Sensor am besten verdrahten? Braucht es überhaupt das MAX485-Board? Macht der USB-Adapter dasselbe? Soll ich aus dem Computer oder aus dem Mikrocontroller am besten dem Sensor den Befehl senden, dass er mir die Messewerte bitte zurücksendet? Besten Dank
Beantwortest Du vielleicht auch noch mal alle Dir gestellten Fragen? Die Pinbelegungen und -bedeutungen folgen doch direkt aus den üblichen Signalbezeichnungen für EIA-422/485 auf der UART-Seite. In den meisten Fällen können hierbei für EIA-485 DE und RE miteinander verbunden werden, abhängig davon, ob man ein lokalen Echo der gesendeten Daten wünscht oder nicht. Das hängt natürlich von Deiner konkreten Implementierung des Modbus-Protokolls(tacks) ab. Hast Du denn mittlerweile mal die Modbus-Spezifikation gelesen und verstanden?
Hi, danke schon mal. Ja, auf https://modbus.org habe ich die Spezifikation gelesen und langsam checke ich es. Ich frage mich, wie ich nun die benötigte Bitfolge vom Rechner an den Sensor sende. Habe per "minicom" eine Verbindung zum USB-Konverter aufgebaut. Und dieser blinkt, sobald ich auf der Tastatur drücke. Auch am Oszilloskop tut sich was, aber dessen RS232-Decoder zeigt mir nicht den Buchstaben an, auf den ich drücke :/ Mir ist auch noch nicht klar, wie ich jetzt eine ganze Bit-Abfolge inkl. Addressfeld, Functionscode et.c. auf ein Mal sende. Ist dieser Link sinnvoll? https://unix.stackexchange.com/questions/117037/how-to-send-data-to-a-serial-port-and-see-any-answer
:
Bearbeitet durch User
Lysandros schrieb: > Mir ist auch noch nicht klar, wie ich jetzt eine ganze Bit-Abfolge inkl. > Addressfeld, Functionscode et.c. auf ein Mal sende. Mit einem Programm wie HTerm, das ist für sowas ideal. Denn kann man Daten als ASCII, Hex, Dezimal und Binär eingeben und anzeigen. https://www.der-hammer.info/pages/terminal.html
Habe es jetzt probiert, mit CoolTerm. Obwohl ich Charakter-Strings senden kann und dabei die TX-Leuchte kurzzeitig aufblinkt, erhalte ich keine Antwort: die RX-Leuchte bleibt Dunkel. Der Sensor zieht konstant etwa 10mA, was eigentlich plausibel ist. Wie könnte ich das Troubleshooten? Danke
Du musst die Werte binär schicken. Ein Byte mit dem Wert 1 und ein Text mit dem Inhalt "0x01" sind nicht das gleiche.
Lysandros schrieb: > Habe es jetzt probiert, mit CoolTerm. > Obwohl ich Charakter-Strings senden kann und dabei die TX-Leuchte > kurzzeitig aufblinkt, erhalte ich keine Antwort: die RX-Leuchte bleibt > Dunkel. Ich weiß nicht wie Coolterm arbeitet, aber ich glaube deine Eingabe ist falsch. Die Schreibweise 0x als Vorsilbe wird nur in C und anderen Programmiersprachen verwendet, aber meist nicht bei der Eingabe in Terminalprogrammen. Da schreibt man nur die reinen Hexzahlen. Probier mal. 010300060001640B Das solltest du auf deinem Oszi prüfen, ob die Zeichen so auch rauskommen.
:
Bearbeitet durch User
Du musst ins Menu Connection/Send String gehen und dann HEX auswählen. Dort kann man die Hexzahlen direkt eingeben. Siehe Anhang.
Hi, danke euch allen. Jetzt kommt zumindest etwas zurück auf RX :) Es ist allerdings noch nicht lesbar...Habe alle Einstellungen nochmals geprüft: Baudrate, Data-Bits, Parity, Stop-Bits. Trotzdem erhalte ich noch keine lesbaren Werte :/ Und wenn ich die Baudrate ändere (aktuell bei 9600), dann kommt nichts mehr zurück.
:
Bearbeitet durch User
Lysandros schrieb: > Es ist allerdings noch nicht lesbar... Die Tatsache, dass der Sensor überhaupt antwortet, ist schon ein sehr deutliches Zeichen dafür, dass Deine Requests gültig sind und auch die physikalische Verbindung funktioniert. Was erwartest Du denn für eine Darstellung? Wie sehen denn die Zeichen der Antwort in Binär- oder Hex-Darstellung aus? Wenn Du die Modbus-Spezifikation gelesen und VERSTANDEN hättest, wäre Dir das auch klar. Willst Du eigentlich für die echte Anwendung auf eine der vielen vorhandenen Modbus-Implementierungen zurückgreifen oder alles selbst implementieren? Auch wenn Du letzteres vorhast, ist es äußerst lehrreich, sich mal die Quellcodes anderer Implementierungen anzuschauen und diese auch untereinander zu vergleichen, denn es gibt viele verschiedene Wege, Protokollstacks zu implementieren. Ebenfalls sehr wichtig bei der Auswahl solch einer Implementierung ist natürlich die Frage, von welcher Programmiersprache bzw. Laufzeitumgebung heraus die Verwendung erfolgen soll.
:
Bearbeitet durch User
Nimm doch bitte das vorgeschlagene HTerm. Damit kannst du HEX und ASCII gleichzeitig sehen. Und in der Protokollbeschreibung steht doch eindeutig drin, das da nur Rohwerte/Hexwerte geantwortet werden. Da kommt kein Text "Es hat jetzt PH1,23". In deiner ASCII Dartstellung ist vermutlich alles kleiner 0x32 einfach ein Punkt.
Lysandros schrieb: > Trotzdem erhalte ich > noch keine lesbaren Werte Doch doch, wenn der Sensor antwortet, kann man seine Werte auch lesen. Du bist schon wieder drauf reingefallen wie Zahlen dargestellt werden, damit Mensch sie lesen kann. Der nächste Schritt ist dann, das du begreifst wie die Prüfsumme erstellt wird.
:
Bearbeitet durch User
Lysandros schrieb: > geprüft: Baudrate, Data-Bits, Parity, Stop-Bits. Trotzdem erhalte ich > noch keine lesbaren Werte :/ Doch. Aber du musst dein Coolterm auf HEX-Darstellung umschalten. Oder Hterm verwenden.
https://www.protoconvert.com/softwaretools/modbus/modbusmastersimulator.aspx Kann einfach einzelne Register abholen. Dann braucht Dein PC noc eione serielle Schnittstelle mit einem RS232/RS395-Converter.
Endlich funktioniert es, ihr habt recht gehabt:) Die ASCII-Antworten direkt in HEX umwandeln zu lassen war ein guter Tipp. Dies kann man ja leicht in Dezimal umrechnen. Und wie die Prüfsumme erstellt wird mittels CRC-16 checke ich. Ich versuche jetzt das ganze in Zephyr RTOS umzusetzen, deren Beispiel ist allerdings etwas kryptisch. Falls ich Fragen habe, melde ich mich wieder
Lysandros schrieb: > Endlich funktioniert es, ihr habt recht gehabt:) > Die ASCII-Antworten direkt in HEX umwandeln zu lassen war ein guter > Tipp. Den hat keiner gegeben. Du solltest die ANZEIGE auf HEX umstellen! Denn normalerweise zeigen Terminalprogramme ASCII an.
Hallo nochmal, habe jetzt den Rechner durch ein Nordic-μCU ersetzt und versuche von dort aus mit dem Sensor zu kommunizieren, per MAX485. Jedes mal wenn auf Boot-Klicke, sollte die μCU als Modbus-Kunde eine Anfrage senden. Mich wundert ist folgendes: 1) das DE-Signal (Driver-Enable) in türkis, sieht nicht gut aus und ist verzerrt. 2) das DI-Signal (Driver-Input) in gelb, scheint einen konstant Offset zu haben und es ist kaum eine Bit-Sequenz erkennbar Hat jemand evtl. Hinweise? Thanks
Lysandros schrieb: > habe jetzt den Rechner durch ein Nordic-μCU ersetzt und versuche von > dort aus mit dem Sensor zu kommunizieren, per MAX485. Jedes mal wenn auf > Boot-Klicke, sollte die μCU als Modbus-Kunde eine Anfrage senden. > Mich wundert ist folgendes: > 1) das DE-Signal (Driver-Enable) in türkis, sieht nicht gut aus und ist > verzerrt. Da ist nichts verzerrt, nur eine HF-Störung überlagert. > 2) das DI-Signal (Driver-Input) in gelb, scheint einen konstant Offset > zu haben und es ist kaum eine Bit-Sequenz erkennbar Deine Amplitude ist mit ca. 400mV auch "etwas" klein. Da gibt es einen Kurzschluß und es treiben zwei Ausgänge gegeneinander. > Hat jemand evtl. Hinweise? Du solltest die Screenshot Funktion des Oszilloskops nutzen. Dein Masseanschluß der Tastköpfe ist fragwürdig. DE ist high active und darf logischerweise nur aktiv sein, wenn dein Modbus Sender sendet. Das muss direkt nach dem letzten, gesendeten Zeichen wieder LOW werden, damit du die Antwort vom Bus/Sensor empfangen kannst. Denn das ist alles halbduplex.
:
Bearbeitet durch User
Außerdem hängt dein RE in de Luft. Das macht man nicht, selbst wenn das Ding einen internen Pull-Up Widerstand hätte. Meistens verbindet man RE und DE direkt, dann hört man seine gesendeten Daten nicht. Dann braucht es noch einen Pull-Up Widerstand an RX vom uC. Denn RO geht auf Tristate, wenn RE inaktiv ist. An deinem Bus fehlt das Bias-Netzwerk, damit der Bus bei Inaktivität auf HIGH gezogen wird. Klassischer Fehler. https://www.mikrocontroller.net/articles/RS-485#Weitere_Hinweise
Am Tastkopf den "1x<->10x Schieber" beachten auf 10x stellen und den jeweiligen Oszi-Kanal bei "Probe" entsprechend auch auf "10x" einstellen. Sieht hier so aus, als ob das nicht ganz übereinstimmt.
Hallo zusammen, habe jetzt das RE mit dem DE kurzgeschlossen. Und zunächst den Sensor entfernt um zu sehen, was der MAX485 alleine macht. Folgende Hürde entsteht: Das TTL-Signal aus dem μCU wird vom Oszi sauber dekodiert, allerdings nur, solange es nicht am DI (Driver-Input) des MAX485 verbunden ist...Wenn ich es am MAX485 anschließe, dann läuft die Dekodierung so la-la, oft werden die falschen Bitfolgen entziffert...
Lysandros schrieb: > Das TTL-Signal aus dem μCU Das ist kein TTL-Signal, sondern ein 5V-CMOS-Signal. > Wenn ich es am MAX485 anschließe, dann läuft die > Dekodierung so la-la, oft werden die falschen Bitfolgen entziffert... Wenn der aktuelle Aufbau immer noch so wie auf dem zuvor veröffentlichten Foto aussieht, dann liegt das an der fehlenden Masseverbindung zwischen Microcontrollerboard und dem Pegelwandler. Und NEIN, das ist nicht verhandelbar, auch wenn Du irgendwo von jemand anderem ahnungslosen aufgeschnappt hat, dass das ja nicht wichtig wäre und der Onkel des Dackels seines Schwippschwagers neulich auch keine Masseverbindung gemacht hatte und Muttis Haartrockner trotzdem funktionierte. Warum sind so viele Leute heutzutage nicht mehr bereit, sich auch nur ansatzweise mal mit den allerelementarsten Grundlagen der Elektrotechnik und Physik zu beschäftigen, die wir früher(tm) schon im Kindergarten vermittelt bekamen?
:
Bearbeitet durch User
Guten Morgen miteinander, inzwischen habe ich den μCU-Ground auf den IC-Ground gelegt und es sieht gut aus! Das Signal bleibt gut erkennbar. Leider kommt nach dem MAX485, bei "A" noch bei "B" garnichts an...man sieht nur dass sich der Pegel ändert, wenn man das Signal am DI rausschickt. Aber es ist keinerlei Bitfolge erkennbar. Vielen Dank für eure Tipps dazu auch
Lysandros schrieb: > Leider kommt nach dem MAX485, bei "A" noch bei "B" garnichts an...man > sieht nur dass sich der Pegel ändert Ich sehe nicht einmal das. (Und dein Oszi hat eine Screenshot-Funktion.)
Lysandros schrieb: > Aber es ist keinerlei > Bitfolge erkennbar. Na dann hast du es vermutlich mal wieder geschafft, das DE-Signal zu unterbrechen. Dann sind die Treiber inaktiv (tristate). Du bist schon ein echter Künstler . . . Betreibe eine systematische Fehlersuche!
Hi nochmal, die Screenshot-Funktion ist leider nicht verfügbar aufgrund von USB-Vorschriften (IT). Jetzt kommt das richtige Signal hinten (zwischen A/B) an, allerdings nur wenn der DE-Pin komplett offen bleibt und von der μCU entkoppelt wird^^ Dann liegen nämlich bei DE von alleine ca. 5V an, woher verstehe ich nicht. Irgendwie machen meine 3.3V-DE aus dem Mikrocontroller Probleme:/ So werde ich auch keine Signale an RI vorerst empfangen können...
:
Bearbeitet durch User
Oh ja, 5V-Chips direkt an 3,3V-Chips anschließen, das hat schon immer bestens funktioniert, da sind nie Fehler oder gar Defekte aufgetreten.
Lysandros schrieb: > Hi nochmal, die Screenshot-Funktion ist leider nicht verfügbar aufgrund > von USB-Vorschriften (IT). Wollen wir wetten, daß die in dem OSZI NICHT gesperrt ist? > Jetzt kommt das richtige Signal hinten (zwischen A/B) an, allerdings nur > wenn der DE-Pin komplett offen bleibt und von der μCU entkoppelt wird^^ Unsinn. > Dann liegen nämlich bei DE von alleine ca. 5V an, woher verstehe ich > nicht. Dann hast du was falsch verbunden oder sonstigen Kurzschluß. Denn der MAX485 hat keinerlei interne Pull-up/Down Widerstände. > Irgendwie machen meine 3.3V-DE aus dem Mikrocontroller Probleme:/ > So werde ich auch keine Signale an RI vorerst empfangen können... Nö. Der MAX485 hat TTL Schaltschwellen und kann sicher mit 3,3V angesteuert werden. Da gibt es eher ein Problem in der Gegenrichtung. Zwischen RO und deinem RXD des Mikrocontrollers sollte man 1-5k zur Strombegrenzung schalten, denn der MAX485 gibt 5V aus und dein 3,3V uC ist vermutlich NICHT 5V tolerant.
Vielen Dank nochmal, mein DE-Pin war invers programmiert, sprich active=low. Das war der Fehler. Ich schaue mir das mit den Pull-up/Down Widerständen nochmals genauer an. Beste Grüße
Lysandros schrieb: > Hi nochmal, die Screenshot-Funktion ist leider nicht verfügbar aufgrund > von USB-Vorschriften (IT). Was hat irgendeine USB-Vorschriften (IT) damit zu tun? Steck einen USB-Stick in das Oszi, kopiere dir Daten dort drauf und poste über ein Smartphone.
Lysandros schrieb: > Ich schaue mir das mit den Pull-up/Down > Widerständen nochmals genauer an. Wenn Dein Microcontrollereingang nicht 5V-tolerant ist, dann ist womöglich der Microcontroller eh schon hinüber. Das muss sich nicht in einem Totalausfall äußern, sondern es kann auch deutlich subtilere Fehlfunktionen geben. Und dabei geht es nicht nur um Pull-Up/-Down, sondern eben um die Pegelanpassung in Empfangsrichtung. Ein einfacher Serienwiderstand kann ggf. ausreichen. Ich würde auf Nummer Sicher gehen und einen Spannungsteiler vorsehen. Letzterer verhindert zuverlässig, dass es insbesondere bei niedriger Stromaufnahme des Microcontrollerteils zu einem "Durchschlagen" des Signals auf die Versorgungsspannung kommen kann. Das führt dann zwar zu keinem Defekt, aber z.B. Oszillatoren oder PLLs können aus dem Tritt geraten. Falls der ADC verwendet wird und die Versorgungsspannung als Referenz verwendet, kann es ggf. zu unnötig großen Messfehlern kommen.
Bitte 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.