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.
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.
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
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?
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.
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.
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.
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
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.
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)
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.
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
Ist das nett, sehe gerade im Fernsehprogramm heute kommt "42 - Die Antwort auf fast alles". 23:35 Uhr auf Arte.
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]); |
R42 schrieb: > Das ist mal wieder ein total geheimes Projekt. ... und Freitag war doch schon gestern.
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.
Werd ich nochmals versuchen. Was halt seltsam ist, es hat ja funktioniert.
Unter diesen, man kann schon sagen beinahe idealen Bedingungen funktioniert RS485 auch schon mal mit verpolten Leitungspaar.
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?
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?
Veit D. schrieb: > Das > Signal bzw. die Umschaltung muss man doch aktiv steuern. Oder nicht? U4 tut das.
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
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.
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
Das ist der Moment, wo man sich ein Oszilloskop ausleiht oder kauft. Keine Arme - keine Kekse.
Angehängte Dateien:
-
alles.jpeg
230 KB -
alles.png
9,4 MB
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 | }
|
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.
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...
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.
Können wir uns endlich wieder dem eigentlichen Thema zuwenden?
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.
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.
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.
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 ;)
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.
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.
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.
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 ?
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.
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?
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.
Ein Logic Analyzer für 10€ mit Sigrok an RX, TX usw. würde vermutlich auch schon Erkenntnisse bringen.
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.
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.
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 | }
|
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.
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?
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 | }
|
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.
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.
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?
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.
Treffend-e schrieb: > Dann müsste ich eine While-Schleife machen, sonst wartet er nicht, oder > doch? loop() wird doch dauernd aufgerufen.
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
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.
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.
Kann ich nochmals versuchen. Wobei die kompliziertere Version ja auch funktioniert.
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.
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
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)
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.
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!
Treffend-e schrieb: > Leider war tatsächlich ein Kabelbruch das Problem. war es eins dieser Dupont Kabel aus Eisen?
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.
Treffend-e schrieb: > Leider war tatsächlich ein Kabelbruch das Problem. Ich melde gleich morgen ein Kleingewerbe zur "Hellseherei in elektronischen Fragen" an... ;-)
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.