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
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.
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?
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
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.
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.
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.
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:> 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.
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?
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.
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.
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.
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... ;-)
