Differentiell-Taster für RS485?

[Lysandros (lys)]

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

[Vanye R. (vanye_rijan)]

> 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

[Clemens L. (c_l)]

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.

[Vanye R. (vanye_rijan)]

> 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

[Μαtthias W. (matthias)]

Und wenn schon richtig dann richtig richtig mit einem richtigen 
Differenztastkopf

SCNR ;-)

[Lysandros (lys)]

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?

[Vanye R. (vanye_rijan)]

> Irgendwelche Ideen?

Nun, als erstes mal schalte den Eingang deines Oszi auf DC um. :-D

Vanye

[Jens M. (schuchkleisser)]

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...

[Rainer W. (rawi)]

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.

[Jens M. (schuchkleisser)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Vanye R. (vanye_rijan)]

> 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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[Jens M. (schuchkleisser)]

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.

[Rüdiger B. (rbruns)]

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.

[Lysandros (lys)]

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...

[Jens M. (schuchkleisser)]

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.

[Jörg K. (joergk)]

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

[Tom G. (masterx244)]

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.

[Vanye R. (vanye_rijan)]

> 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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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?

[Jörg K. (joergk)]

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"...

[Lysandros (lys)]

Anbei die "Anleitung"-Fotos

[Lysandros (lys)]

Anbei weitere "Anleitung"-Fotos

[Lysandros (lys)]

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

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Lysandros (lys)]

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.

[Dietrich L. (dietrichl)]

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!?

[Vanye R. (vanye_rijan)]

> 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

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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?

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Stephan S. (uxdx)]

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

[Lysandros (lys)]

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

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Jörg K. (joergk)]

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 :-)

[Lysandros (lys)]

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

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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?

[Lysandros (lys)]

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

[Falk B. (falk)]

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

[Lysandros (lys)]

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

[Jens M. (schuchkleisser)]

Du musst die Werte binär schicken.
Ein Byte mit dem Wert 1 und ein Text mit dem Inhalt "0x01" sind nicht 
das gleiche.

[Falk B. (falk)]

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.

[Falk B. (falk)]

Du musst ins Menu Connection/Send String gehen und dann HEX auswählen. 
Dort kann man die Hexzahlen direkt eingeben. Siehe Anhang.

[Lysandros (lys)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.

[Benjamin K. (bentschie)]

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.

[Jens M. (schuchkleisser)]

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.

[Falk B. (falk)]

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.

[Hans-jürgen H. (hjherbert)]

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.

[Lysandros (lys)]

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

[Falk B. (falk)]

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.

[Lysandros (lys)]

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

[Falk B. (falk)]

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.

[Falk B. (falk)]

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

[Axel R. (axlr)]

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.

[Lysandros (lys)]

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...

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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?

[Lysandros (lys)]

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

[Clemens L. (c_l)]

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.)

[Falk B. (falk)]

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!

[Lysandros (lys)]

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...

[Jens M. (schuchkleisser)]

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.

[Falk B. (falk)]

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.

[Lysandros (lys)]

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

[Rainer W. (rawi)]

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.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

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.