Forum: Mikrocontroller und Digitale Elektronik RS485 vermute Störsignale, wie entfernen


von Treffend E. (Gast)


Lesenswert?

Ich habe einen Sensor mit RS485 (ModBus) verbunden. Im Test auf kurze 
Distanz hatte dies gut funktioniert. Ich bekam zuerst den Wert 255 und 
nachher bei jeder Abfrage die korrekten Werte. Nun habe ich den Sensor 
an die lange Leitung angeschlossen und erhalte nun nur noch die Werte 
253 und 1. Auf der Platine glimmt TX und RX schwach, wenn nichts 
gesendet wird ( dann leuchtet sie). Ich vermute, dass dies Störsignale 
von einem anderen Gerät sind (Signal Begrenzungskabel).

Wie kann ich den Eingang A und B von den Störsignalen befreien? Mit 
Widerständen? Mit Kondensatoren?

Der Sensor hat die Anschlüsse 12V, GND, A und B. Signal wird auf UART 
konvertiert und geht auf einen Arduino.

von R42 (Gast)


Lesenswert?

Mach mal R42 kleiner.

von H. (Gast)


Lesenswert?

Manche Transceiver sind nicht sinnvoll vorgespannt, d.h. die Ruhepegel 
liegen so nahe beieinander, dass kleinste Störungen als Signal 
aufbereitet werden. Der altehrwürdige SN75176 ist so ein Beispiel. Hört 
sich so an, dass das bei Dir auch das Problem sein KÖNNTE. Google mal 
nach „rs485 bias“ für ein Netzwerk aus drei Widerständen, dass 
terminiert und gleichzeitig vorspannt.

von EAF (Gast)


Lesenswert?

Treffend E. schrieb:
> Ich vermute, dass dies Störsignale
> von einem anderen Gerät sind

Vermutungen kann man nicht mit Widerständen entfernen. Auch 
Kondensatoren helfen nicht dagegen.

Typische Fehler:
1. GND vergessen
2. Schlampige Terminierung

von Treffend E. (Gast)


Lesenswert?

Ich verwende das hier mit eingebautem und aktiviertem 120 Ohm 
Endwiderstand.

GND ist angeschlossen.

Was ist R42?

RS485 Bias Widerstände könnten helfen, gibt es da eine Empfehlung?

von M. K. (sylaina)


Lesenswert?

Vermuten ist zwar ganz nett aber nicht effektiv. Bevor man also versucht 
vermutete Störsignale zu entfernen sollte man schauen ob es wirklich 
Störsignale sind. Das hätte auch den Vorteil, dass man überhaupt auch 
weiß was hier stört und sinnvoll entstören kann. Aber: Was bringt einem 
Entstören wenn gar nix stört sondern der Sender z.B. nur zu schwach ist 
für die lange Leitung? Genau: Nix. Also, Oszi auspacken und 
Signalverlauf betrachten. Es kann erst sinnvoll weiter gehen wenn man 
das Problem verifiziert hat.

von A. S. (Gast)


Lesenswert?

Treffend E. schrieb:
> Was ist R42?

Na der kritische Widerstand und Deinem Schaltplan.

Obwohl, ... er ist schwer zu lesen, vielleicht in höherer Auflösung 
posten.

von Widerständler (Gast)


Lesenswert?

Treffend E. schrieb:
> Was ist R42?
Es ist ein vermuteter R, der dem TE mitteilen soll, dass er einen 
Schaltplan posten muss, oder dass man ohne desselben keine Vermutungen 
anstellen kann.

von TomA (Gast)


Lesenswert?

Hallo Treffend E.

Du kennst "Per Anhalter durch die Galaxis"? 42 ist die Antwort auf 
Alles, oder Nichts.

Ein paar Salamischeibchen mehr währen schon Aufschlussreich!

Welche Baudrate 100Baud oder 10MBaud?
Dein kurzes Kabel ist 10cm oder 10m lang?
Dein langes Kabel ist 10m oder 1,2km lang?
Die Übertragung erfolgt galvanisch getrennt?

Mit den gegebenen Infos ist die beste Antwort tatsächlich 42.

Gruss. Tom

von Treffend E. (Gast)


Lesenswert?

https://www.dfrobot.com/product-2392.html

Ich habe keinen Oszillator. Also ist es doch naheliegend testweise zu 
entstören…

Die Leitung ist unter 10 m. Kurz war ca 2m. Aber eben ohne die funkenden 
Begrenzungskabel. Baudrate ist 9600.

von DerDetlef (Gast)


Lesenswert?

RS485 bei 9600 Baud funktioniert auch bei ganz erheblich längeren 
Kabelstrecken. Da muss nichts "entstört" werden.

Was komisch riecht, ist, daß Du bei einem Modbus-Gerät irgendwelche 
Bytes mit irgendwelchen Werten empfangen willst, und die sich dann 
aufgrund von Übetragungsfehlern ändern sollen.

Das kann so nicht sein; Modbus ist ein Protokoll, das Datenpakete 
überträgt, die mit einer Prüfsumme geschützt sind. Die im Rahmen des 
Protokolls übertragenen Daten sind entweder einzelne Bits (Coil) oder 
16-Bit-Werte.

Was genau für ein Sensor ist das, mit dem Du da Daten auszutauschen 
meinst? (Typ, Datenblatt)

von Wolfgang (Gast)


Lesenswert?

Treffend E. schrieb:
> Ich habe keinen Oszillator. Also ist es doch naheliegend testweise zu
> entstören…

Naheliegend wäre, sich die Signale mit einem Oszi anzugucken und nicht 
per LED.

von TomA (Gast)


Lesenswert?

Eigentlich ist 10m Kabel bei 9600Baud keine Herausforderung für RS485, 
da halte ich Störungen ins Datenkabel für eher unwahrscheinlich! Bist Du 
sicher die beiden Signalleitungen (A und B) nicht vertauscht zu haben?
Hast Du Terminierungswiderstände an beiden Enden der Leitung probiert 
(bei einfachen verdrillten Leitungspaar sollten je ca. 150 Ohm passen, 
bei den gegebenen Bedingungen aber auch eher unwahrscheinlich.

Gruss. Tom

von TomA (Gast)


Lesenswert?

Ist das nett, sehe gerade im Fernsehprogramm heute kommt "42 - Die 
Antwort auf fast alles". 23:35 Uhr auf Arte.

von Treffend E. (Gast)


Lesenswert?

Es ist dieser Sensor:

https://wiki.dfrobot.com/RS485_Wind_Speed_Transmitter_SKU_SEN0483
1
 SerialWriteBuf(Anemometer_request, sizeof(Anemometer_request));
2
  Serial1.flush();
3
  byte Anemometer_buf[7];
4
  Serial1.readBytes(Anemometer_buf, 7);
5
  currentValue = (Anemometer_buf[4]);

von R42 (Gast)


Lesenswert?

Das ist mal wieder ein total geheimes Projekt.

von glas kugel (Gast)


Lesenswert?

R42 schrieb:
> Das ist mal wieder ein total geheimes Projekt.

... und Freitag war doch schon gestern.

von DerDetlef (Gast)


Lesenswert?

Nun, das ist ja tatsächlich ein Modbus-Gerät.

Wenn es Übertragungsfehler gibt, sind die kompletten Datenpakete 
betroffen, und das sollte Deine Software herausfinden. CRC-Fehler!

Wenn es aber keinen CRC-Fehler gibt, dann sollte die Übetragung korrekt 
sein.

Zeige die kompletten Modbus-Datenpakete und nicht nur die Nutzdaten.
Zum Abfragen sendest Du dem Sensor ja immerhin dieses aus acht Bytes 
bestehende Paket

02 03 02 00 00 00 01 84 39

und er antwortet mit einem aus sieben Bytes bestehenden Paket

02 03 02 00 25 3D 9F  (beispiel für den Wert 0x25 == 37 == 3.7 m/sec)

Jeweils die letzten beiden Bytes jedes Pakets sind der 16-Bit-CRC.

von Treffend E. (Gast)


Lesenswert?

Werd ich nochmals versuchen.

Was halt seltsam ist, es hat ja funktioniert.

von TomA (Gast)


Lesenswert?

Unter diesen, man kann schon sagen beinahe idealen Bedingungen 
funktioniert RS485 auch schon mal mit verpolten Leitungspaar.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Treffend E. schrieb:
> GND ist angeschlossen.
Du meinst damit "verbunden"?

Hast du schon mal einfach mit einem Oszilloskop die Signalqualität 
begutachtet? Sind die Flanken ok (steil und stetig)? Passt das, was du 
da siehst, zu dem, was der Empfänger an seinem Eingang verarbeiten kann? 
Siehst du irgendwelche Störungen?

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

Treffend E. schrieb:
> https://www.dfrobot.com/product-2392.html

Wenn ich mir den Schaltplan vom Board anschaue stelle ich mir die Frage 
wo der gemeinsame Anschluss von /RE & DE nach außen geführt ist. Das 
Signal  bzw. die Umschaltung muss man doch aktiv steuern. Oder nicht? 
Würde mir auch das flackern der Leds erklären. Offene Eingänge? Was 
meint ihr?

: Bearbeitet durch User
von EAF (Gast)


Lesenswert?

Veit D. schrieb:
> Das
> Signal  bzw. die Umschaltung muss man doch aktiv steuern. Oder nicht?

U4 tut das.

von Lothar (Gast)


Lesenswert?

Treffend E. schrieb:
> Ich habe einen Sensor mit RS485 (ModBus) verbunden

Hoffentlich nur A B und nicht auch GND

> Wie kann ich den Eingang A und B von den Störsignalen befreien?

Hatten das Problem auch mal, Störung hatte den Nullpunkt des 
differentiellen Signals verschoben. Einfachste Lösung günstiger Repeater 
an den Master d.h. Deine Platine z.B.:

https://www.meilhaus.de/ex-9510.htm

Übrigens A B ist bei ModBus kein "Eingang" sondern Master Request 
Response

von Hmmm (Gast)


Lesenswert?

Treffend E. schrieb:
> Ich vermute, dass dies Störsignale
> von einem anderen Gerät sind (Signal Begrenzungskabel).

Was passiert, wenn Du das Begrenzungskabel abklemmst? Ist dann der 
Fehler weg?

Was für ein Kabel verwendest Du für den RS485-Bus?

Sind alle 3 Adern (A, B und GND) der Teilnehmer verbunden? Hast Du für 
den Bus das richtige GND des Schnittstellenkonverters (GND2 im 
Schaltplan, weil galvanisch getrennt) verwendet?

Da Du kein Oszilloskop (das Du wohl mit "Oszillator" meintest) hast: 
Welche Spannungen misst Du mit einem Multimeter auf A und B (jeweils 
gegen GND), wenn kein Busteilnehmer sendet?

Treffend E. schrieb:
> RS485 Bias Widerstände könnten helfen, gibt es da eine Empfehlung?

Die sind auf Deinem Modul drauf (R1 und R8), allerdings mit 1k etwas 
gross, weil sich so bei 120-Ohm-Terminierung nur eine Differenz von 
knapp 0.15V (statt standardkonformer 0.2V) ergibt.

Ich denke nicht, dass es daran liegt, aber Du kannst die gerne durch 680 
Ohm ersetzen oder jeweils 2.2k parallelschalten, um bei rund 0.21V zu 
landen.

von Jobst M. (jobstens-de)


Lesenswert?

Treffend E. schrieb:
> Auf der Platine glimmt TX und RX schwach

Wenn Leitungen anfangen zu glimmen, fließt meist zu viel Strom.

(Komm mir nun nicht einer und erzählt mir etwas von LEDs. Das weiß ich. 
Die Beschreibung ist aber der Knaller! Eine Frechheit!)

Bild vom Aufbau?


Gruß
Jobst

von Stefan F. (Gast)


Lesenswert?

Das ist der Moment, wo man sich ein Oszilloskop ausleiht oder kauft.

Keine Arme - keine Kekse.

von Treffend E. (Gast)


Angehängte Dateien:

Lesenswert?

Also hier die Bilder vom Aufbau und alle Details.

Arduino ist ein Z-Uno (V1):
https://z-uno.z-wave.me

Spannungswandler ist der hier (eingestellt auf 12V > 5V):
MINI-360 HM MP1484 STEPUP STEPDOWN BUCK CONVERTER 2A DC-DC VARIABEL

RS485 to UART:
https://www.dfrobot.com/product-2392.html

Sensor:
https://wiki.dfrobot.com/RS485_Wind_Speed_Transmitter_SKU_SEN0483

Spannung liegt bei A und B jeweils auf GND zwischen 1.1 V und 1.2 V.

Hier noch der ganze Code (hat bei 2 m Kabellänge und in anderer Umgebung 
funktioniert):
1
ZUNO_SETUP_SLEEPING_MODE(ZUNO_SLEEPING_MODE_FREQUENTLY_AWAKE);
2
ZUNO_SETUP_CHANNELS(ZUNO_SENSOR_MULTILEVEL(ZUNO_SENSOR_MULTILEVEL_TYPE_GENERAL_PURPOSE_VALUE, SENSOR_MULTILEVEL_SCALE_PERCENTAGE_VALUE, SENSOR_MULTILEVEL_SIZE_TWO_BYTES, SENSOR_MULTILEVEL_PRECISION_ZERO_DECIMALS, getWind));
3
4
int counter = 0;
5
int highestValue = 0;
6
int currentValue = 0;
7
8
uint8_t Anemometer_request[8] = {0x02, 0x03, 0x00, 0x00, 0x00, 0x01, 0x84, 0x39};
9
10
void SerialWriteBuf(uint8_t *buffer, size_t size){
11
  while (size != 0) {
12
    Serial1.write((uint8_t) * buffer);
13
    buffer++;
14
    size--;
15
  }
16
}
17
18
void setup() {
19
  Serial.begin(9600);
20
  Serial1.begin(9600);
21
  delay(1000);
22
}
23
24
void loop() {
25
  SerialWriteBuf(Anemometer_request, sizeof(Anemometer_request));
26
  Serial1.flush();
27
  byte Anemometer_buf[8];
28
  Serial1.readBytes(Anemometer_buf, 8);
29
  currentValue = (Anemometer_buf[4]);
30
  if (currentValue == 255) {currentValue = 1;} // init is 255
31
  if (counter < 60){
32
    if (currentValue > highestValue) { highestValue = currentValue; } // new peak value
33
    counter = counter + 1;
34
  Serial.println(currentValue);
35
    delay(1000);
36
}
37
  else {  
38
    zunoSendReport(1);
39
    Serial.println("##########");
40
    Serial.println(highestValue);
41
    Serial.println("##########");
42
    delay(1000);
43
    highestValue = 0;
44
    counter = 0;
45
  }
46
}
47
48
long getWind(void) {
49
  return highestValue; //10m/s
50
}

von uff basse (Gast)


Lesenswert?

Treffend E. schrieb:
> Also hier die Bilder vom Aufbau und alle Details.

Ich liiieeeeebe diese fliegenden Aufbauten. Da bekommt man
die Funktionsgarantie wenigstens gleich mitgeliefert und
braucht sich nicht wundern.

Wundern braucht man sich auch nicht dass Fotos vom Aufbau
erst "nachgeliefert" werden.

von Treffend E. (Gast)


Lesenswert?

Sehr hilfreich - schlecht aufgestanden?

Glaubst du ernsthaft ich löte das alles zusammen, solange ich es noch 
testen muss.

Aber erst ist leider in diesem Forum normal, dass man erstmal angepöbelt 
wird. Es sind nicht alles Experten in Elektronik...

von Forist (Gast)


Lesenswert?

Treffend E. schrieb:
> alles.png
> 9,4 MB

Gelesen?
"Wichtige Regeln - erst lesen, dann posten!"

Was mag dieser Hinweis wohl bedeuten:
"Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. "

Von elementarsten Verständnis über Bildformate gar nicht zu reden 
...

Ein Foto bleibt ein Foto - auch auf dem Bildschirm.

von Treffend E. (Gast)


Lesenswert?

Können wir uns endlich wieder dem eigentlichen Thema zuwenden?

von Treffend E. (Gast)


Lesenswert?

Forist schrieb:
> Von elementarsten Verständnis über Bildformate gar nicht zu reden

Warum muss eigentlich immer beleidigend geantwortet werden?

Es ist nunmal so, dass man hochgeladene Bilder nicht mehr editieren 
kann, sonst hätte ich das bereits getan und auch das überflüssige Foto 
gelöscht...

Wenn du also nichts zum Thema beitragen willst, sondern dich nur gerne 
aufregst, geh doch bitte weiter.

von M. K. (sylaina)


Lesenswert?

Treffend E. schrieb:
> Ich habe keinen Oszillator. Also ist es doch naheliegend testweise zu
> entstören…

Ein Feuer kann man im Allgemeinen mit Wasser löschen...wenn da aber 
Natrium oder Magnesium brennt ist Wasser als Löschmittel keine gute 
Wahl. Und so verhält es sich bei deinem "Problem": Solange man nicht 
weiß, was hier genau wie nicht klappt ist Entstören nicht zwingend eine 
gute Wahl.

von Forist (Gast)


Lesenswert?

Treffend E. schrieb:
> Können wir uns endlich wieder dem eigentlichen Thema zuwenden?

... bei solchen Steilvorlagen?
Da kann man nicht immer widerstehen ;-)

Treffend E. schrieb:
> Es ist nunmal so, dass man hochgeladene Bilder nicht mehr editieren
> kann, sonst hätte ich das bereits getan und auch das überflüssige Foto
> gelöscht...

Man könnte sich vorher überlegen, was man da hochlädt.
Das Foto ist nicht überflüssig, sondern schlicht und einfach in einem 
denkbar ungeeigneten Bildformat.

> Wenn du also nichts zum Thema beitragen willst, sondern dich nur gerne
> aufregst, geh doch bitte weiter.

Der Beitrag zum Thema stand schon weiter oben: Probleme geht man am 
besten mit passendem Werkzeug an. Bei Übertragungen auf Schnittstellen 
arbeitet man sich dabei durch die ISO/OSI-Layer durch - angefangen mit 
der untersten Schicht, der  Bitübertragungsschicht. Kurz ein Oszilloskop 
und die passenden Kenntnisse zur Nutzung wären hier ausgesprochen 
nützlich.
https://de.wikipedia.org/wiki/OSI-Modell

Sich mit unzureichenden Messmitteln durch wackelige Aufbauten 
durchzukämpfen - am besten noch per Ferndiagnose, ist ein mühseliges 
Unterfangen.

von M. K. (sylaina)


Lesenswert?

Treffend E. schrieb:
> Hier noch der ganze Code (hat bei 2 m Kabellänge und in anderer Umgebung
> funktioniert):

Dann liegt es wahrscheinlich auch weniger am Code...aber vielleicht an 
den Einstellungen: Übertragungsraten, die auf 2m klappen können für 5m 
blöd sein da die Leitungsdämpfung z.B. dann einfach überwiegt. Da hilft 
dann auch kein Entstören, das ist dann sogar eher kontraproduktiv ;)

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

uff basse schrieb:
> Also hier die Bilder vom Aufbau und alle Details.

Stromversorgung über Dupont Kabel ist schon mal schlecht, bei GND 
besonders schlecht. Meine sind aus Eisen und haben beträchtliche 
Übergangswiderstände an den Kontakten.

Treffend E. schrieb:
> Glaubst du ernsthaft ich löte das alles zusammen, solange ich es noch
> testen muss.

Dazu würde ich rate. Schraubklemmen sind OK, aber diese Dupont Kabel 
taugen nur für Signale, nicht für Stromversorgung.

von Stefan F. (Gast)


Lesenswert?

Treffend E. schrieb:
> Warum muss eigentlich immer beleidigend geantwortet werden?

Niemand hat dich Beleidigt. Wenn du so weiter machst wirst du es 
allerdings bald erleben. Bedenke: Du bist hier derjenige, der kostenlos 
die Zeit anderer in Anspruch nimmt. Du musst den Gepflogenheiten des 
Forums unterwerfen, sonst wird das nichts.

Wenn du eher ein Chef-Typ bist, dann folge deiner Natur und bezahle 
andere dafür, deine Arbeit zu erledigen. Dann kannst du von ihnen 
einfordern, es so zu tun, wie es dir gefällt.

von DerDetlef (Gast)


Lesenswert?

O weh.
1
void loop() {
2
  SerialWriteBuf(Anemometer_request, sizeof(Anemometer_request));
3
  Serial1.flush();
4
5
  byte Anemometer_buf[8];
6
  Serial1.readBytes(Anemometer_buf, 8);
7
  currentValue = (Anemometer_buf[4]);
8
... etc

Du wertest also in keiner Weise aus, was das Gerät auf Deine Anfrage 
antwortet, sondern liest stumpf 8 Bytes und greifst Dir das fünfte 
davon.

Das ist Pfusch erster Güte. Denn das kann auch irgendein beliebiger 
Quatsch, irgendein Rauschen oder sonstwas sein.

Ich hab' ja schon geschrieben, daß Du die kompletten empfangenen Pakete 
ausgeben sollst - das kannst Du an dieser Stelle auch, Dein 
"Anemometer_buf" enthält sie alle.

Gib sie aus und vergleiche sie mit dem, was laut Beschreibung des 
Sensors zu erwarten ist. Bis auf die letzten beiden Bytes (CRC) ist das 
sehr genau vorhersagbar, die ersten vier Bytes (oder sogar fünf) müssen 
immer die gleichen Werte haben.

Haben sie die nicht, ist Dein Aufbau kaputt.

von Treffend-e (Gast)


Lesenswert?

Das ist mein erstes Projekt mit RS485. Ich werde mir mal die Ausgabe 
anschauen. Danke.

Ich frage ja das Signal an und lese dann aus. Sollte ich dann länger 
warten bis ich auslese ?

von Forist (Gast)


Lesenswert?

DerDetlef schrieb:
> Bis auf die letzten beiden Bytes (CRC) ist das
> sehr genau vorhersagbar

Eine CRC ist genau dafür gedacht, sie anhand des Dateninhaltes ganz 
genau verhersagen zu können. Dafür ist es natürlich erforderlich, den 
Algorithmus zur Berechnung zu nutzen. Eine vernünftige Empfangsroutine 
macht genau diese Vorhersage und vergleicht die empfangene CRC damit. 
Nur dadurch kann die CRC ihren Zweck erfüllen und auf Übertragungsfehler 
hinweisen.

von Klaus S. (kseege)


Lesenswert?

Treffend E. schrieb:
> Können wir uns endlich wieder dem eigentlichen Thema zuwenden?

Wen Du Dich abgeregt hast, können wir es versuchen.

1.Probleme auf seriellen Verbindungen ohne Oszilloskop lösen zu wollen, 
verlängert die aufzuwendende Zeit um den Faktor 10 bis 100, je nachdem, 
wie intelligent man sich anstellt.

2.Differentielle Übertragung (wie RS485 eine ist) ist dafür erfunden, 
den Einfluß von Einstreuungen unschädlich zu machen. Von allen möglichen 
Fehlern hat es die geringste Wahrscheinlichkeit.

3.Wenn man denn schon meint, man müßte mit der unwahrscheinlichsten 
Fehlermöglichkeit anfangen, gibt es einen einfachen Test.
Man wickelt sein langes Kabel zu einem nett aussehenden Knäuel zusammen 
und packt dieses in ein Blechkiste. Wenn der Fehler dann weg ist, waren 
es tatsächlich Einstreuungen. Dann denkt man aber nicht über Widerstände 
und Kondensatoren nach (fummeln am Symptom), sondern geht die Ursachen 
an, also z.B.:
A: Ausschalten der Störer
B: Abschirmung des Kabels, gute Erdung
C: verdrilltes Kabel verwenden

Gruß Klaus (der soundsovielte)

P.S. Daß A und B bei 1,1/1,2 Volt über Ground liegen, kommt mir 
verdächtig vor. Welchen Grund gibt es dafür? Versorgungsspannung der 
RS-485-Trieber nur auf 2,4 Volt?

von A. S. (Gast)


Lesenswert?

Treffend-e schrieb:
> Das ist mein erstes Projekt mit RS485. Ich werde mir mal die Ausgabe
> anschauen. Danke.
>
> Ich frage ja das Signal an und lese dann aus. Sollte ich dann länger
> warten bis ich auslese ?

An welcher Front arbeitest Du jetzt konkret? Aus meiner Sicht sind 
folgende Baustellen offen:

A) Verkabelung/Verdrahtung/Uart-Parameter: Wenn der Empfang bei 2 oder 
10m gestört ist, ist ein Bauteil defekt oder Du hast einen Fehler 
gemacht.

 * Falsch verdrahtet (wo war noch mal der Schaltplan/Verdrahtungsplan?)
 * Falsche UART-Parameter im uC (z.B. 2 Stoppbits statt einem, falscher 
Baudteiler)
  * Wackelkontakt / Kabelbruch

B) Auswertung/Modbus: Wenn das bei 2m funktioniert und bei 10m nicht, 
dann ist die SW ok und Dein Problem liegt bei A)


--> Wenn Uart-Zeichen verloren gehen, dann schau Dir unbedingt zuerst 
an, ob es UART-Fehler gibt.  Parity, Framing, sowas (keine Ahnung ob 
Modbus Parity hat) Oder les die Telegramme mit (Debugger, Ausgabe auf 
egal was, ...)

Miss die Ruhepegel nach, gegeneinander und gegen GND, auf beiden Seiten. 
Mit 2m und mit 10m (weil das im Gegensatz zu den aktiv-Pegeln auch mit 
einem DMM geht).

Kauf oder besorg Dir das einfachste Oszilloskop, dass Du finden kannst. 
Also so etwa 30€ oder selbstbau per Mikrofoneingang, das reicht für die 
serielle Schnittstelle mit 9.6 aus.

von Harald A. (embedded)


Lesenswert?

Ein Logic Analyzer für 10€ mit Sigrok an RX, TX usw. würde vermutlich 
auch schon Erkenntnisse bringen.

von DerDetlef (Gast)


Lesenswert?

Hier würde ein Anzeigen der vorliegenden Inforrmationen aber auch schon 
weiterhelfen.

Wenn das "Serial.flush" weggelassen wird, lässt sich sogar prüfen, ob 
das richtige gesendet wird.

Da dieses flush im "Quelltext" steht, nehme ich an, daß der 
RS485-Transceiver ein Sendeecho erzeugt.

wenn das so ist, sollte nach dem Senden das gesendete zurückgelesen und 
mit dem gesendeten verglichen werden. Damit kann man die Funktion des 
rs485-Transceivers prüfen.

> Ich frage ja das Signal an und lese dann aus. Sollte ich dann länger
> warten bis ich auslese ?

Das Warten übernimmt für Dich Dein Arduino, der die seriellen Daten 
empfängt. Nein, länger warten bringt hier gar nichts.

Du solltest aber auf jeden fall das flush weglassen; wenn das 
Modbus-Gerät nämlich sehr schnell antwortet, kann es sein, daß du nicht 
nur Dein (mögliches) Sendeecho, sondern auch schon den Anfang Deiner 
gewünschten Antwort wegwirfst.

Bastel Deine Software dahingehend um, daß Du jedes einzelne empfangene 
Byte ausgibst, idealerweise in hexadezimaler darstellung.

von EAF (Gast)


Lesenswert?

Treffend E. schrieb:
> SerialWriteBuf(Anemometer_request, sizeof(Anemometer_request));

Ich frage mich: Wofür ist diese Funktion?

Tut nicht ...
1
Serial1.write(Anemometer_request, sizeof(Anemometer_request));
... genau das gleiche?


Ok, ich kenne deinen Z-Uno und seine Libs nicht.
Aber da der Arduino Welt zugehörig, würde ich das erwarten.

von Zeno (Gast)


Lesenswert?

Treffend-e schrieb:
> Ich frage ja das Signal an und lese dann aus. Sollte ich dann länger
> warten bis ich auslese ?

Naja einen kleinen Moment braucht das Teil ja auch, um auf Deine Anfrage 
zu antworten. Wie lange das dauert sollte im Datenblatt stehen.
Irgendwie liest Du da blind, soll heißen Du weist ja gar nicht ob Daten 
empfangen wurden.
Dafür gibt es bei Arduino die Funktion "Serial.available()"
Das könnte z.B. dann so aussehen.
1
if (Serial.available()) {
2
    Serial1.readBytes(Anemometer_buf, 8);
3
  }

von Veit D. (devil-elec)


Lesenswert?

EAF schrieb:
> Veit D. schrieb:
>> Das
>> Signal  bzw. die Umschaltung muss man doch aktiv steuern. Oder nicht?
>
> U4 tut das.

Hallo,

das erklärt alles, Danke. Hatte RE im Plan gesucht aber gestern nicht 
mehr gefunden.

von Treffend-e (Gast)


Lesenswert?

EAF schrieb:
> Tut nicht ...1Serial1.write(Anemometer_request,
> sizeof(Anemometer_request));
> ... genau das gleiche?

Ja, das stimmt, aber der Z-Uno unterstützt das nicht. Deshalb der 
Workaround.

Serial1.flush(); hab ich auch schon weggelassen, kommt auf Gleiche 
heraus.


 * Falsche UART-Parameter im uC (z.B. 2 Stoppbits statt einem, falscher
Baudteiler)
Wie kann ich das denn ändern/kontrollieren?

von Treffend-e (Gast)


Lesenswert?

Zeno schrieb:
> Dafür gibt es bei Arduino die Funktion "Serial.available()"

Tatsächlich wird dann gar nichts empfangen.

1
if (Serial1.available()) {
2
    Serial1.readBytes(Anemometer_buf, 8);
3
  }

von Forist (Gast)


Lesenswert?

A. S. schrieb:
> A) Verkabelung/Verdrahtung/Uart-Parameter: Wenn der Empfang bei 2 oder
> 10m gestört ist, ist ein Bauteil defekt oder Du hast einen Fehler
> gemacht.
> ...
> Falsche UART-Parameter im uC (z.B. 2 Stoppbits statt einem, falscher
> Baudteiler)

Es besteht auch die Möglichkeit, dass trotz richtig eingestelltem 
"Baudteiler" die Baudrate wegen Toleranzen der Taktfrequenz nicht 
richtig passt und Signalverschleifung durch die Kabelkapazität das Fass 
zum überlaufen bringt, so dass der Empfänger Pegel fehlerhaft erkennt.
So etwas mit einem LA zu erkennen, setzt schon etwas Detailwissen 
voraus.

von EAF (Gast)


Lesenswert?

Treffend-e schrieb:
> Zeno schrieb:
>> Dafür gibt es bei Arduino die Funktion "Serial.available()"
>
> Tatsächlich wird dann gar nichts empfangen.
>
> if (Serial1.available()) {
>     Serial1.readBytes(Anemometer_buf, 8);
>   }

Wenn man 8 Bytes lesen will, sollte man auch warten bis 8 im Buffer 
sind.
 if (Serial1.available()>=8)

Treffend-e schrieb:
> EAF schrieb:
>> Tut nicht ...1Serial1.write(Anemometer_request,
>> sizeof(Anemometer_request));
>> ... genau das gleiche?
>
> Ja, das stimmt, aber der Z-Uno unterstützt das nicht. Deshalb der
> Workaround.

Doch tut er!
Serial1 erbt von Stream und damit auch Print.
Und in Print findet sich
size_t Print::write(const uint8_t *buffer, size_t size)

Wird also unterstützt.

von Treffend-e (Gast)


Lesenswert?

Es kann aber keine Buffer schreiben.

von Treffend-e (Gast)


Lesenswert?

EAF schrieb:
> Treffend-e schrieb:
>> Zeno schrieb:
>>> Dafür gibt es bei Arduino die Funktion "Serial.available()"
>>
>> Tatsächlich wird dann gar nichts empfangen.
>>
>> if (Serial1.available()) {
>>     Serial1.readBytes(Anemometer_buf, 8);
>>   }
>
> Wenn man 8 Bytes lesen will, sollte man auch warten bis 8 im Buffer
> sind.
>  if (Serial1.available()>=8)
>

Dann müsste ich eine While-Schleife machen, sonst wartet er nicht, oder 
doch?

von EAF (Gast)


Lesenswert?

Treffend-e schrieb:
> Es kann aber keine Buffer schreiben.

Naja...
Keine Ahnung, was du da falsch machst....

In Print ist es implementiert.
Es ist offensichtlich auch funktionsfähig implementiert.
Es kompiliert fehlerfrei.

Testen kann ich es leider nicht. Die Hardware fehlt mir.

Ein Test
Serial.print(Serial1.write(Anemometer_request,sizeof(Anemometer_request) 
));
Würde dir auch beweisen, das genau dir richtige Anzahl Byte geschrieben 
werden.

von EAF (Gast)


Lesenswert?

Treffend-e schrieb:
> Dann müsste ich eine While-Schleife machen, sonst wartet er nicht, oder
> doch?

loop() wird doch dauernd aufgerufen.

von Treffend-e (Gast)


Lesenswert?

Da stimmt, aber ich mache ja einen request und prüfe dann, ob die 
Antwort da ist. Wenn das zu lange dauert, wird nie etwas gelesen und der 
Loop beginnt von Neuem.

Bin nicht sicher wegen dem SerialWrite, aber ich habe das hier gefunden:

https://forum.z-wave.me/viewtopic.php?f=3427&t=25584

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Treffend E. schrieb:
> Können wir uns endlich wieder dem eigentlichen Thema zuwenden?
Beschaff dir einfach ein Osilloskop und stelle sicher, dass der Bus auf 
der untersten physikalischen Ebene funktioniert. Es ist mir ein Rätsel, 
man Probleme auf seriellen Schnittstellen ohne Oszilloskop und 
Logikanalyzer finden und zuverlässig beheben will.

Schon das billigste Picoscope für unter 150€ wird dir bei derartigen 
Problemen noch oft helfen.

Treffend E. schrieb:
> Glaubst du ernsthaft ich löte das alles zusammen, solange ich es noch
> testen muss.
Richtig dumm gelaufen ist es, wenn sich der Test wegen einer lausigen 
Schraub- oder Steckverbindung endlos in die Länge zieht.

Oder andersrum: ob etwas funktioniert, das steht für mich schon beim 
Schaltplan fest. Der Testaufbau ist dann nur dafür da, nachzuweisen, 
dass es funktioniert.

: Bearbeitet durch Moderator
von EAF (Gast)


Lesenswert?

Treffend-e schrieb:
> aber ich habe das hier gefunden:

Die schreiben eindeutig von der Meldung
> no matching member function for call to 'write'
Zudem ist das ca 7 Jahre her.
Hatten als "etwas" Zeit zum nacharbeiten.

Die kommt bei mir nicht.

von Treffend-e (Gast)


Lesenswert?

Kann ich nochmals versuchen. Wobei die kompliziertere Version ja auch 
funktioniert.

von Zeno (Gast)


Lesenswert?

Treffend-e schrieb:
> Dann müsste ich eine While-Schleife machen, sonst wartet er nicht, oder
> doch?
Die käme dann mit einer Abbruchbedingung (Timeout) vor das if.

von Jobst M. (jobstens-de)


Lesenswert?

Treffend E. schrieb:
> Warum muss eigentlich immer beleidigend geantwortet werden?

Weil Du Dir keine erkennbare Mühe bei der Aufbereitung der Informationen 
für uns gibst.

Schau Dir Deine Bilder an. Wir bekommen ein Kabelkneul zu sehen und 
dürfen das selbst im Kopf auseinander pflücken. ... Wenigstens sind sie 
scharf.

Wo gehen die Leitungen hin, die das Bild verlassen?

Wieso benutzt Du Koax-Leitung zur Spannungsversorgung?

Das kleine Modul ist ein Spannungswandler?


Du hast am Anfang geschrieben

Treffend E. schrieb:
> Ich habe keinen Oszillator.

Meinst Du tatsächlich evtl. keinen Quarz? Das wäre bei serieller, 
asynchroner Datenübertragung aber schon wichtig. Was ist Deine 
Taktquelle?

Oder meintest Du, wie von einigen hier vermutet, ein Oszilloskop?
Das wäre eigentlich nicht ganz so dramatisch.

Skizziere Deinen Aufbau mit allen wichtigen Infos. Wo sitzen welche 
Widerstände. Spannungsquellen. Komplett alles was da irgendwie 
angeschlossen ist. Mit Bezeichnungen und Werten.


Gruß
Jobst

von Klaus S. (kseege)


Lesenswert?

An Alle:

Ich denke, es hat wenig Sinn, dem TO zu sagen, was er machen soll.

Er hat selbst gesagt, dass er von Elektronik wenig Ahnung hat und dass 
er von non-blocking I/O auf Mikrocontrollern genausoviel versteht wie 
von Kisuaheli ist deutlich aus seinen Programmierbeispielen zu 
entnehmen.
Vermutlich (!) hat er C auf einem Rechner mit Betriebssystem und dem 
dazugehörigen blocking-I/O gelernt und wendet das auch hier brav an, 
aber das geht natürlich (!) granatenmäßig in die Hose.

Er ist (für mich) offensichtlich ziemlich halsstarrig, was nicht negativ 
gemeint ist, er muß einfach überzeugt werden. Und da er nicht 2 Sachen 
gleichzeitig machen kann, sollte irgendjemand, vorzugsweise der TO, 
entscheiden, welchen Pfad er zuerst einschlagen soll und kann.

Die Hardware ist die eine Baustelle, die Software die andere. Da heute 
Sonntag ist, ein Oszi nicht hergezaubert werden kann und ein korrekter 
Schaltplan den TO vermutlich (!) 3 Tage beschäftigen würde, bin ich der 
Auffassung, dass die Probleme der Software innerhal dreier Stunden zu 
lösen seien und daher als Erstes angegangen werden sollte.

Was meint Ihr dazu?

Gruß Klaus (der soundsovielte)

von Treffend-e (Gast)


Lesenswert?

Puh, also ich kürze das hier mal ab.

Der Code funktioniert.
Die Elektronik funktioniert.
Die Verdrahtung funktioniert.
Leider war tatsächlich ein Kabelbruch das Problem.

Danke allen, die geholfen haben. Habt bitte etwas Geduld mit Anfängern. 
Ich werde das Forum auf jeden Fall wieder verlassen.

von Rudi (Gast)


Lesenswert?

Treffend-e schrieb:

> Der Code funktioniert.
> Die Elektronik funktioniert.
> Die Verdrahtung funktioniert.
> Leider war tatsächlich ein Kabelbruch das Problem.

Wenn der Code den Fehler nicht bemerkt und behandelt dann funktioniert 
der Code nicht!

von Stefan F. (Gast)


Lesenswert?

Treffend-e schrieb:
> Leider war tatsächlich ein Kabelbruch das Problem.

war es eins dieser Dupont Kabel aus Eisen?

von M. K. (sylaina)


Lesenswert?

Treffend-e schrieb:
> Leider war tatsächlich ein Kabelbruch das Problem.

Und jetzt siehst du, wie wichtig nachschaun ist. Jede Maßnahme zum Thema 
Entstören hätte nichts gebracht, es geht halt nichts über messen, 
schätzen ist selten gut wenn gleich  uns das u.a. von öffentlicher Seite 
das als bewährtes Mittel zum Zweck näher gebracht wurde.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Treffend-e schrieb:
> Leider war tatsächlich ein Kabelbruch das Problem.
Ich melde gleich morgen ein Kleingewerbe zur "Hellseherei in 
elektronischen Fragen" an... ;-)

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
Noch kein Account? Hier anmelden.