RS485-Netzwerk - Welche Widerstaende?

[Uwe H.]

...und das naechste Problem in dieser verdammten Sporthalle

Hier ist ein RS485-Netwerk installiert worden, was nicht funktioniert. Da nicht ersichtlich ist, was diverse Platinen in diversen Verteilern bewirken und der fruehere Installateur auch nicht sehr auskunftsfreudig ist, was seine versaute Arbeit angeht, haben wir den ganzen Mist liquidiert und mit Atmegas und MAX485 neue Konverter gebaut. Jetzt ist folgendes Problem:

Ist der Konverter mit kurzem Kabel am Master angeschlossen, funktioniert der Empfang reibungslos. Im Moment laeuft auf dem Slave nur ein Testprogramm, was mir ein FFh sendet. Schliess ich den Slave an seinem Bestimmungsort an, empfange ich nur 00h, also keine Datenuebertragung. Der Master schliesst aber den "Inputbin" ab, also irgendein Signal kommt an. Hier ein paar Daten zu der Installation:

- FTP-Datenkabelschleife von ca. 70-90m
- Am Master 120 Ohm zwischen A und B
- Am Kabelende 120 Ohm zwischen A und B
Ausprobiert hab ich auch 100k von GND nach B und VCC nach A. Bringt aber auch nix und laut Info ist das beim Max485 auch nicht noetig. Wer weiss Rat, wie ich den Schrott hier ans Laufen bekomme?

Danke im vorab
Uwe

 

[Uwe H.]

Korrektur: Inputbin schliesst nicht ab. Hab Master und Slave auf Senden/Empfangen in Schleife gesetzt und es kommt nichts an.

 

[dino03]

Hi Uwe,

Korrektur: Inputbin schliesst nicht ab. Hab Master und Slave auf Senden/Empfangen in Schleife gesetzt und es kommt nichts an.

Hast du die Kabel schonmal durchgemessen ? Wenn es Cat-Kabel sind einfach mal nen Kabelmeßgerät dran (Fluke DSP100, DSP4300 oder was einfacheres). Nicht das du nur nen total versautes Kabel hast was um die Ecken gequält wurde und bei dem die Adernisolierung dadurch den Geist aufgegeben hat. Zell-PE bei LAN-Kabeln mag es nicht wenn man es mechanisch belastet.

Für RS485 würde ich mal Markus ansprechen. Der kennt sich da gut aus. Evtl hat er ja etwas Zeit wenn ihn die Italiener nicht so sehr ärgern

Gruß
Dino

 

[Uwe H.]

Gruess Dich Dino, ich hab den Fehler gefunden. Nach 6-stuendiger Suche hat sich ergeben, dass der Elektriker in einem Verteiler ein Kabel der Datenlinie auf Masse gelegt hat. Ich krieg ne Krise hier in dem Bau, echt....
Jetzt haben wir das naechste Problem. Die Daten kommen an, sind aber falsch. Mal kommen nur Nullen an, mal irgendwelche voellig danebengegriffenen Daten und ab und zu auch mal der echte Messwert. Konstruktion sieht so aus, dass der Slave von einem Sensor die Daten auswertet und die fertige Single-Datei via Printbin verschickt. Der Master nimmt mit Inputbin entgegen. Aber irgendwie passt da was nicht. Dasselbe hatten wir heute schonmal mit dem Testprogramm. Der Slave sollte 33h senden. Die kamen auch an aber bei jedem zweiten Inputbin wars 00h. Die Abfragetaktung lag bei ungefaehr 2 Sekunden. Kann das sein, dass der irgendwas mit den Stoppbits durcheinander wirft?

 

[dino03]

Hi,

Der Slave sollte 33h senden. Die kamen auch an aber bei jedem zweiten Inputbin wars 00h. Die Abfragetaktung lag bei ungefaehr 2 Sekunden. Kann das sein, dass der irgendwas mit den Stoppbits durcheinander wirft?

oder zusätzlich noch nen Wackelkontakt im Bus ? (schlecht angezogene Schraube?). Ist manchmal gerne gesehen. Wenn nen LKW vorbeirauscht hat man Datensalat

Gruß
Dino

 

[Uwe H.]

Dino Ich hab gestern den kompletten Strang vorsorglich nochmal durchgeprüft Das Kabel ist wohl das Einzige, was hier ansatzweise qualitativ gekauft wurde. Trotz der Länge ist die Kapazität und der Leitungswiderstand fast Null. Schade nur, dass die Bautruppe das Kabel runterm Dach mit den Deckenverkleidungen beschädigt haben und nun die Abschirmung auf ca. 1/2m Länge weg ist. Natürlich direkt neben dem Hauptstromkabel für die Hallenbeleuchtung. Ich weiss nicht, was Du beruflich machst, aber diese Halle ist ein Eldorado für Elektronikliebhaber und Programmierer. Hier kann man sich so richtig austoben und alle möglichen Dinge ausprobieren, ohne Angst zu haben, was kaputtzumachen, weil ja eh nix funktioniert. Ich bin schon zufrieden, dass wir die Temperaturmessungen im Griff haben. Hier sind fast 100 Stk. DS18B20 eingemauert, um den Wärmeverlust zu analysieren. Der Depp, der das geplant hat, hat nur vergessen die Adressen der Sensoren vorher aufzuschreiben und ihren Messstellen zuzuteilen. Das war ne Arbeit, das alles anzuschliessen und dann erstmal den Standort zu bestimmen...

Wenn ich hier durch bin, geh ich mit dem Architekten einen heben Der hat auch die Nase voll von dem ganzen Pfusch hier, der in der Bauphase fabriziert wurde.

 

[bluelight_electronic]

Hi Uwe,

also mir fallen da nur ein paar Sachen noch ein es könnten die Abschlüsse des Netzwerkes sein

quelle : http://www.pci-card.com/

- Am Master 120 Ohm zwischen A und B
- Am Kabelende 120 Ohm zwischen A und B

das hört sich gut an die Brauchst du auf jeden fall (da RS485).

Das laesst sich aber sehr leicht mit einem Oszi rausfinden (die PullUp/Down find ich mit 100k etwas arg hoch bei deinen Leitungslaengen ich würde allgemein nie über 1k nehmen. ? Bzw hast dir die Signale schon mal angeschaut ob die auch passen ?!? (Braucht der MAX 485 sicher keine ?).

Das Andere ist, dass mit den Adressen noch was nicht ganz passt, je nachdem wieviele Teilnehmer du hast (nicht, dass da 2 meinen gleichzeitig reden zu wollen (das war bei mir mal ein Arges Problem)).

Dann noch der DE & /RE Pin. Sicher dass die immer zum richtigen Zeitpunkt geschlaten werden ?

Das andere noch sind die ganzen Verbraucher Galvanisch getrennt ? Bei laengeren Reichweiten gibts oft Probleme mit der Masseverschleppung.

Das andere, wieviele Teilnehmer hast du den dran haengen ? Weil die RS485 Spec ja nur 32 Teilnehmer zulaesst.

Es ist ein reines Master / Slave System oder ist es ein Multimaster ?


Oehm ja mehr faellt mir gerade nicht ein.

Gruß,
Manuel

 

[Uwe H.]

Grüß Dich Manuel Das Problem mit den Widerständen ist gelöst, die Datenautobahn funktioniert. Das jetzige Problem ist das Senden/Empfangen. Wir haben eine einfache Master/Slave-Schaltung auf dem Tisch installiert, also 50cm Kabelstrecke, um zu sehen, wir wir die Daten am besten rüberbekommen. Dabei trat oben beschriebenes Problem bereits auf. Der Slave wurde nicht adressiert, er hat einfach nur den Befehl bekommen, zwei Bytes zu senden und der Master sollte zwei Bytes empfangen. Also eine absolute Grundschaltung, ohne Heckmeck. Leider hab ich (noch) kein Oszilloskop, deshalb muss ich manche Fragen analog lösen, sprich mit Raten, Denken und Dino im Forum bombadieren *lach* Ich wollte mir jetzt langsam ein Scopemeter zulegen, nur ist die Auswahl riesig, die Preise sehr unterschiedlich und ich hab keine Ahnung, welche wirklich halten, was sie versprechen. Wenn Du da einen Tipp hast, so wäre ich sehr dankbar. Hab mal hier geschaut: http://www.warensortiment.de/technische-daten-1a/oszilloskop-oc-1.htm Das gefällt mir ganz gut, nur hab ich keine Ahnung, wie es um die Qualität der Mühle steht. Ich kaufe lieber einmal teuer und für Jahre statt billig und Schrott. Aber zurück zum Thema. Hier ist ein Programmauszug der Sende/Empfangsroutine:

Slave:

$regfile = "m8def.dat"
$crystal = 1000000
$hwstack = 100
$swstack = 100
$framesize = 100
$baud = 9600

Dim Rhlintemp as word
Rhlintemp = &H3333

Wait 2
Set Portd.2 <---DE/RE zusammengeschaltet und auf Logik 1
Waitms 200
Printbin Rhlintemp
Waitms 200
Reset Portd.2

end



Master:

$regfile = "m32def.dat"
$crystal = 16000000
$hwstack = 100
$swstack = 100
$framesize = 100


$baud = 9600
Open "comd.0:9600,8,N,1" For Input As #2
Open "comd.1:9600,8,N,1" For Output As #1

Dim Rhlintemp As word

Config Portd.2 = Output

Reset Portd.2 <-----DE/RE zusammengeschaltet und auf Logik 0


Inputbin Rhlintemp

wait 1
End


So in etwa sieht das Testprogramm aus. Und dieses Programm empfängt mal richtig, mal falsch

 

[bluelight_electronic]

Hi,

also mit handgeraeten kann ich dir leider garnicht weiterhelfen, ich verwende halt ein TDS2024 (ist auch nichts weldbewegendes aber Tektronix hat super Trigger und reicht für mich super.

Ohweh Basecom da hab ich leider überhaupt kein plan das ist etwas arg kryptisch für mich aber mal schauen ob ich mit den Bezeichnungen klar komm ^^

Okey das was du gerade auf deinem Board machst ist schon irgendwie nen Multimaster ^^ weil dein Slave von sich aus einfach mal was senden soll und dein Master erst mal die klappe haelt ?!? ^^ ich bin etwaqs verwirrt .

Aber okey. Prinzipiell du machst den (Driver)Sende Enable vom Slave auf High um zu senden wollen. Das passt soweit "Printbin Rhlintemp" ist das Senden oder ? ich Interpretier das mal so ^^.

Laesst du das ganze aber schon in einer Schleife laufen oder nur einmal ?!? Also das Senden und das Empfangen ?!?

// Also du willst Senden Pin auf Senden schalten.
 Set Portd.2         <---DE/RE zusammengeschaltet und auf Logik 1
// kurz waren bis alles eingeschwungen ist ... (nicht zulange ...)
Waitms 10
// alles Senden was du Senden willst
     Printbin Rhlintemp
// warten bis alles raus ist dann wieder den Pin auf eingang und zuhören ob der Master was schickt...
 Reset Portd.2
// Jetzt warten solange bis vom Master was reinkommt und wieder beantwortet werden will

Wenn du das nur einmal machst (so sieht es für mich mal aus ev. Interpretier ich das auch falsch) und das Empfangen auch nur einmal machst, dann wirst du immer Zeitlich irgendwie durcheinander kommen weil dass das gerade Übereinstimmt beim hochlauf der Baugruppe ist eher Zufall ..

Oder hab ich das einfach nun falsch verstanden ?!?

Also Was ich damit Ausdrücken will ...

Den Rx immer Pollen und vom Sender immer wieder was Schicken ...


Sry ich bin einfach nicht Basic Fit ^^

Gruß,
Manuel

 

[Uwe H.]

Im Testprogramm schickt der Slave einmal die Daten raus (Printbin), während der Master bei "Inputbin" solange wartet, bis die Variable gefüllt wurde. Das ist kein Multimastering, das ist nur n Testlauf um zu sehen, ob die Daten auch ankommen und das Einlesen klappt. Später wird das dann mit Adressierung, etc ausgebaut aber im Moment reicht mir erstmal, das die Variable Rhlintemp sauber übertragen wird. Die Wartezeit zwischen Setzen von RE/DE und Senden könnten zu lang sein, ich hab sie auf 200ms. 10ms reichen? Dann teste ich das mal gleich. Hab den Versuchsaufbau hier aufm Tisch. Und die Abfrage/Senderoutine im Loop? Woher weiss dann der Controller, wann er den Loop verlassen soll? Mit Inputbin sollte eigentlich sowas wie ein Loop entstehen, indem der uC dort wartet, bis die Variable voll ist...

 

[bluelight_electronic]

Hi,

ja wie gesagt ich kenn die Basecom befehle nicht / weiß nicht was die funktionen machen..

naja dein Empfaenger (also in dem fall der Master) ist immer ein ? Wenn das Inputbin solange wartet bis auf der Uart was reinkam okey dann sollte es passen...


naja in nem C Programm mach ich dass meist mit Cases

//init
initialisieren von allem -> ab zu poll
//poll
ist was da ? falls ja verarbeiten falls nein weiter zu idle
//idle
hier kann man alles machen was man sonst will nur irgendwann sollte man halt wieder auf poll gehen ^^


Aber dein Test mit dem Warten bis was da ist sollte auch klappen ... (mal fürs erste).

Hat das Inputpin auch kein Timeout ?

Also ich denke einfach, dass sich da zeitlich etwas verhaspelt ...


Dass du 1MHz und 16 MHz verwendest ist gewollt ?


Hmmz sonst faellt mir da so per "Fernwartung" echt nichts mehr ein ^^

 

[Uwe H.]

Grüß Dich
Ich denke auch, dass das ein Timingproblem ist. Zumindest deutet viel daraufhin. Die 16 MHz und 1MHz resultieren aus zwei unterschiedlichen Prozessoren. Der eine ist ein Atmega8 und liest die Daten von den Messstellen ein. Dann wird das Ganze auf RS-485 verschickt an den Master, ein Atmega32, der immer auf "Empfang" steht und selber nix sendet. Der 32er hat nen externen Quarz mit 16MHz, die 8er laufen über den internen Oszillator. Könnte das ein Problem sein? Sollte eigentlich nicht, die Geschwindigkeit ist doch einheitlich in beiden Programmen mit 9600 baud definiert...? Ist das Tempo vielleicht zu langsam? Hatte schonmal das Problem, dass Daten sich verändern bei zu geringer Geschwindigkeit

 

[dino03]

Hi Uwe,

Der 32er hat nen externen Quarz mit 16MHz, die 8er laufen über den internen Oszillator. Könnte das ein Problem sein? Sollte eigentlich nicht, die Geschwindigkeit ist doch einheitlich in beiden Programmen mit 9600 baud definiert...? Ist das Tempo vielleicht zu langsam? Hatte schonmal das Problem, dass Daten sich verändern bei zu geringer Geschwindigkeit

wir hatten hier im Forum schon des öfteren das Problem das es selbst bei 9600Baud mit dem internen Oszillator wegen Ungenauigkeiten des Taktes Probleme gab. Der hat ne Abweichung von einigen Prozent. Auf die Schnelle hab ich im Datenblatt was von +/-3% gefunden. Ist aber glaube ich auch bei Vcc=5V und 25°C. Wenn sich die Temperatur oder die Betriebsspannung ändert dann läuft der noch weiter außer der Reihe.

Gruß
Dino

 

[bluelight_electronic]

Ahhh Ja okey, das würde eventuell auch erklaeren wieso es manchmal geht manchmal nicht ...

Wobei das sich bei 1 nem Byte noch nicht so auswirken sollte erst wenn 2..3..4..5 kommen wirds problematischer.

Was du mal Probieren könntest,

lass mal die Max485 komplett raus und verbind einfach mal die 2 Uarts ... wenn das geht -> ists kein Baudrate Problem sondern irgendwas mit dem Umschalten des Max485.

Aber leider ist es ohne Logic Analyser oder Oszi echt nur ins leere Raten.

Aber test mal das mit den normalen Uarts (denk an den Kross dann bei Rx & Tx), das sollte auf den halben meter auch ttl technisch noch laufen.


Gruß,
Manuel

 

[Uwe H.]

Hallo Manuel,

dein Tipp war goldrichtig Hab beide Controller ohne MAX485 verbunden und die Geschwindigkeit zusätzlich noch auf 19200 baud erhöht. Und siehe da, es klappt. Sprich mit der Schaltung des Chips passt was nicht. Werd nochmal ein bisschen im Datenblatt stöbern und ausprobieren. Hast Du noch einen Ratschlag bezüglich Umgang mit dem MAX oder ne Idee, wo der Fehler liegen könnte?

Grüße, Uwe

 

[dino03]

Hi Uwe,

Hallo Manuel,

dein Tipp war goldrichtig Hab beide Controller ohne MAX485 verbunden und die Geschwindigkeit zusätzlich noch auf 19200 baud erhöht. Und siehe da, es klappt. Sprich mit der Schaltung des Chips passt was nicht.

Ähhh ... Also das die Schnittstellentreiber bei 9600Baud Probleme bekommen ist sehr sehr unwahrscheinlich. Es kann sein das bei 19k2 das Timing zufällig wieder paßt. Ich wär da aber vorsichtig. Kannst du an die Mega8 nicht einfach noch nen kleinen Quarz und zwei Kondensatoren dransetzen oder wenigstens nen Keramikresonator (der hat die Kondensatoren in der 3Pin-Version schon drin) ??

Es gab hier schon oft genug Probleme mit Atmels über nen MAX232 an nem PC. Wie nen Quarz dran war waren die Probleme auf einmal auch weg. Es könnte im Moment nach dem MAX485 aussehen aber ich glaube nicht das er es wirklich ist. Eventuell verändert das Weglassen irgendwas an der Kurvenform des Signals (Flankensteilheit, Low/High-Zeiten, ...) die dann zufällig bei diesem einem Atmel das Problem beheben. Das heißt aber nicht das es dann mit allen anderen auch geht. Ich wäre da skeptisch. Aber naja ... probier es aus.

Voraussetzung für eine Fehlersuche ist natürlich immer der saubere Betrieb vom Bussystem. Also mit entsprechenden Abschlußwiderständen und ohne Signal-Reflexionen.

EDIT: Ich hab mir mal das Datenblatt angesehen ...
Der Treiber schafft 2,5MBit/s. Das ist weit oberhalb deiner 9600Bit/s.
Wenn ein LAN-Kabel verlegt ist dann besitzt das eine Impedanz von 100 Ohm.
Im Datenblatt sind zwar 120 Ohm angegeben aber damit werden auf dem Kabel wohl Reflexionen an den Enden auftreten.

Ich hatte es mal (vor zig Jahren) da meinte ein Kabelhersteller besonders klever zu sein. Er hat LAN-Kabel mit 110 Ohm hergestellt. Damit war er in den damaligen Spezifikationen von Ethernet (damals noch 10MBit) und von irgendwas anderem mit 120 Ohm drin, brauchte aber nur eine Fertigungsstraße. Wir haben dann aus Versehen mit Rücklaufdämpfung gemessen und dabei ist etwa 3/4tel der LAN-Kabel durchgefallen. Die Elektrofirma die das Kabel eingezogen hat wurde verdammt hektisch Zum Glück für die Elektrofirma mußte nicht mit Rücklaufdämpfung gemessen werden und dann hat die Abnahmemessung wieder gepaßt Bei etwa 2,5km verlegtem LAN-Kabel und bereits geschlossenen Brandschottungen hätten die echt nen Problem gehabt.

Gruß
Dino

 

[bluelight_electronic]

Ne mir gings allgemein nur erst mal darum ob die zwei Prozessoren voneinander was empfangen können.

So,

ich hab mich nochmal kurz in den Mega8 eingelsen *wer nutzt den noch sowas* *ggg*, okey spass bei seite , Nutzt du die Hardware Uart in den Atmels (wie gesagt ich hab ka was Basecom da macht ...) oder macht das eine SW Uart ?.

WEIL bei einer Config der Uart von:

U2X = 0
Baudrate | UBRR | Fehler
9600 6 -7.0% <- alles über 3,5 sind Problematisch ... Praxistauglich sollte man max 1% Fehler haben.

also bei 9600 eventuell auf U2X = 1 gehen denn ..

U2X = 1
Baudrate | UBRR | Fehler
9600 12 0.2%

dass es bei 19,2 besser geht .. find ich nun ganz wirr ^^

Weil

19.2k 2 8.5% 6 -7.0%

U2X = 0
Baudrate | UBRR | Fehler
19200 2 8,5% <- alles über 3,5 sind Problematisch ... Praxistauglich sollte man max 1% Fehler haben.

U2X = 1
Baudrate | UBRR | Fehler
19200 6 -7.0%

Also 1 MHz ist irgendwie einfach *würg* wenn dann bei 9600 und U2X = 1...
dann noch das Oscal Byte an ne Flashadresse / EEProm Adresse schreiben und bei Programmstart lesen und ins Register schreiben oder echt noch wie Dino meint nen Quarz / Resonator einbauen...


Jetzt wo ich die Fehler Quote seh wird mir das schon klar wieso du da mehr müll empfaengst als gutes ^^. Okey dass es dann als RS232 geht wundert mich dennoch ^^. Der Test war eigentlich nur um zu schauen ob die SW Sache soweit passt.

Woher ich die Zahlen oben hab (nicht aus meinem Hirn ^^) sondern
Datenblatt des MEGA8
Dort dann auf Tabelle 19-9 bzw Seite 161.


Also erst mal das ins reine bringen dann schauen wir weiter.

Gruß,
Manuel

 

[Uwe H.]

Gut, dass ich vorsorglich immer Quarze und Kondensatoren im Einmachglas eingelagert habe *gg* Ok, ich löte mal einen dran und werd sehen, was passiert. Gestern hatte ich die Geschichte soweit, dass es lief. Im Loop hat er dreimal hintereinander die richtigen Daten empfangen, beim vierten Mal und weiter war dann Feierabend. Es ist manchmal echt zum Kotzen mit diesen sch...ß Schnittstellen!

Manuel, ich setze die Atmegas in solchen Projekten noch ein, weil sie billig sind und bewährt. Für so nen dösigen Signalkonverter ist selbst ein 8er noch zuviel. Da würde selbst ein Tiny25 ausreichen, wenn der ne UART hätte

 

[bluelight_electronic]

hehe war auch eher als Scherz gedacht ^^ ich selbst hab sogar noch AT90S1200 ^^...

ja jaeger und Sammler .

Sagen wir so neue Sachen mach ich garnicht mehr unter nem Mega1280 (hab soviele hier rumliegen ...) Den Tiny25 nehm ich auch sehr oft =) (liegen auch einige hier rum *hmmz* ^^). Der Tiny261 und Tiny2313 sind auch ganz fein .. ach sind viele fein von denen dingern ^^...

ich brauch eindeutig mehr Zeit ^^.

Ja Probier das mal bitte mit dem Quarz ..
Gut wenn du da nun 100Geraete hast ... waere noch die Überlegung mit dem Oscal Byte ... ob dir das schon weiter hilft ..

Gruß,

 

[dino03]

Hi,

ich selbst hab sogar noch AT90S1200 ^^...

ich hab auch noch von vor Jahren AT90S1200, AT90S2313, AT90S4433, ... rumfliegen. Die hab ich mal ganz am Anfang besorgt und dann blieben die Teile dann liegen. Ein paar Jahre später hab ich dann wieder angefangen und nach den ersten Versuchen die dann erhältlichen ATmegas und ATtinys besorgt. Wirklich angefangen hab ich eigentlich erst mit den Megas/Tinys.

Ja Probier das mal bitte mit dem Quarz ..
Gut wenn du da nun 100Geraete hast ... waere noch die Überlegung mit dem Oscal Byte ... ob dir das schon weiter hilft ..

Wie gesagt ... nen Keramikresonator ist allemal besser wie der interne und die gibts auch in SMD als kleinen Platinenkrümel Den kann man da allemal noch irgendwie auf der Lötseite zwischen die Beinchen pressen.

CST 8,00 :: Keramik-Resonator 8,00 MHz
CSTCE 8,00 :: SMD-Resonator 8,00 MHz, Größe 3,2x1,3x0,9mm
=> => => => Frequenztoleranz: ± 0,5 % das ist doch wohl ein Unterschied.
und du brauchst nicht mal Keramikkondensatoren weil die schon drin sind.

Gruß
Dino