RS485-Netzwerk - Welche Widerstaende?

Ja hab auch noch viel von dem alten zeugs rumliegen aber naja .. bleibt in der Schublade ev. kann man es irgendwann mal brauchen (wobei ich zurzeit nur mit ARM und AVR32 rumspiel hmmz) ...

Zum Oscal .. wert mir das nicht so ab .. so schlecht ist das garnicht ^^, vorallem kannst wenn ne gute Ref. hast über das Oscal dein Proz richtig Kalibrieren .. (wenn nicht die Atmel Grundeinstellung nimmst ..)


back to topic ^^
Naja aber nen Externen 8MHz Resonator um dann intern wieder Div 8 zu machen ? *ggg* naaa okey ;)
 
Männer, ich krieg ne Krise! Hab nen 16MHz angebaut mit zweimal 22pF nach Masse links und rechts. Anschliessend hab ich dem 8er ne Variable zum hochzählen und versenden gegeben, beide Prozessoren wie gestern direkt miteinander gekoppelt (ohne MAX) und siehe da: Jetzt ists noch schlimmer wie vorher. Meine Empfängervariable variiert zwischen 65000 und 65535 wo eigentlich von 1 hochgezählt werden sollte.

Jetzt hab ich als festen Wert einfach mal die Zahl 333 in den 8er gegeben, die er übermitteln soll. Jedes Mal ist das Ergebniss anders und 5-stellig.
 
Hi Uwe,

Jetzt hab ich als festen Wert einfach mal die Zahl 333 in den 8er gegeben, die er übermitteln soll. Jedes Mal ist das Ergebniss anders und 5-stellig.
könnte es sein das du ein grundlegendes Problem im Programm oder im Timing des Programms hast ??

Gruß
Dino
 
Das Programm ist idiotisch einfach. Hier ist es:

$regfile = "m8def.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 Datavalue As Word

Datavalue = 333

Wait 1

Print Datavalue

end


Hier das des Empfängers:


$regfile = "m644pdef.dat"
$crystal = 2000000 <--- Sind 16MHz, Wert wird vom Atmega intern durch 8 geteilt
$hwstack = 100
$swstack = 100
$framesize = 100



Config Lcdpin = Pin , Db4 = Portc.4 , Db5 = Portc.5 , Db6 = Portc.6 , _
Db7 = Portc.7 , E = Portc.3 , Rs = Portc.2

Config Lcd = 16 * 4
Cls
Cursor Off


$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 Datavalue As Word


Lcd "Warte"

Input Datavalue

Cls
Locate 1 , 1
Lcd Datavalue

End
 
Ok, ich hab den einen Fehler gefunden. Ein Kabel hatte nen wackligen *grunz!* Jetzt läuft der Mist bei Direktverbindung wieder flüssig. Wenn ich aber jetzt den MAX anklemme, empfängt die Gegenseite nur Null... sprich nix. Hier ein Auszug aus der Senderoutine. Empfangsroutine ist die Gleich wie oben.

Do

Set Portd.2
Waitus 10
Printbin Dataword
Waitus 10
Reset Portd.2

Wait 1
Loop
 
Guten Morgen zusammen :)
Nach einer fast schlaflosen Nacht hab ich es glaub ich hinbekommen. Das Mistding sendet jetzt zumindest das, was es sollte. Hab eine Interruptroutine eingebaut, die den RE/DE Port auf Null setzt, sobald der Sendepuffer leer ist. Soweit ich mich reinlesen konnte, sendet der Max nach "Printbin" oder "Print" noch ne ganze Weile weiter und entsprechende Wartezeiten sind dort nötig. Das einzige Problem ist jetzt noch, dass er zusätzlich irgendwelchen Mist empfängt, was ungefähr so aussieht:

Das Programm stoppt bei Inputbin, empfängt die korrekten Daten, zeigt sie an und plötzlich kommen ein paar mal hintereinander in kurzer Frequenz irgendwelche 5-stelligen Zahlen rein, die aber sofort wieder verschwinden, sobald Inputbin wieder erreicht ist und das korrekte Ergebnis ankommt. Das Problem verschlimmert sich, wenn ich den 120Ohm Widerstand entferne. Teste das Ganze gleich mal in der Halle, da haben wir andere Kabel liegen. Vielleicht erledigt sich das Problem dort von selbst. Falls noch irgendjemand von euch ne Idee hat... immer her damit :)

Wisst ihr, was Mist ist? Das wir soweit auseinander wohnen. Wenn das hier hinhaut würde ich euch gern aufn Bier einladen zum Dank für die ganzen Bemühungen und eure Hilfe. Mailt mir eure Privatadressen, ich schick euch ne Flasche per Post aus Krakau :)
 
Das Problem verschlimmert sich, wenn ich den 120Ohm Widerstand entferne.
in Kürze ...

Der MAX485 reagiert auf differentielle Signale auf dem Bus. Der 120 Ohm zieht die beiden Leitungen auf beinahe gleichen Pegel. Wenn der Bus durch Abschalten eines sendenden Teilnehmers hochohmig wird fängt er sich natürlich Schmutz ein und eventuell noch vorhandende reflektierte Signale treiben auch ihr Unwesen. Versuch den Bus über hochohmige Widerstände (10k oder so ?) auf einen Pegel zu bringen der bei der seriellen Schnittstelle des Atmels einem Ruhezustand gleichkommt sonst wird er eventuell auf jedes Millivolt was um den Nullpunkt pendelt reagieren.

Gruß
Dino
 
Ich bin auch der Meinung, dass das Reflektionen sind. Ich haeng mal die Widerstaende von A nach + und B nach - rein. Mal sehen was passiert. 10kOhm sagst Du? Manuel sagte mal irgendwas von 1k...?
 
die Bias Widerstaende würde ich nicht über 1k machen ...

(auch wenn ich Wiki nicht viel traue aber selbst da sinds nur 680R)

bei mir sinds meist 470 R ...


Gruß,
 
Hey Jungs, wir habens hingekriegt. Der Mist läuft endlich :) Morgen muss ich noch die Fühler aufm Dach anschliessen und das wars dann hoffentlich. Hab 470er gesetzt, 1k war noch zu hoch. Im Ernst jetzt, schickt mir eure Adressen per Mail. Ich schicke ich was rüber aus Krakau als Dank für die kompetente und geduldige Hilfe. Ohne euch hätte ich das nicht in der Zeit hinbekommen.
 
Zu frueh gefreut :-( Jetzt taucht das naechste Problem auf. Wenn das System startet, laeuft die Uebertragung einwandfrei. Nach erfolgreicher Uebertragung schaltet der Master die Sensoren ab, da nur einmal pro Stunde gemessen wird und die Dinger nicht laufen brauchen. Jetzt der Haken: Schaltet der Master den Slave wieder ein, kommt nur noch Muell ueber die Leitung... Hab gestern mehrere Stunden versucht, das Problem zu finden aber ohne Oszilloskop ist das die beruehmte Nadel im Heuhaufen.
Abgeschaltet werden die Sensoren ueber die Masse mittels NPN-Transistor am Master. Laut Multimeter schaltet der Transistor auch sauber ein und aus. Stoert da etwa das Dauerplus?
 
Hi Uwe,

Zu frueh gefreut :-( Jetzt taucht das naechste Problem auf.
...
Jetzt der Haken: Schaltet der Master den Slave wieder ein, kommt nur noch Muell ueber die Leitung...
...
Abgeschaltet werden die Sensoren ueber die Masse mittels NPN-Transistor am Master. Laut Multimeter schaltet der Transistor auch sauber ein und aus. Stoert da etwa das Dauerplus?
ich tippe mal das sich durch das Schalten des GND die interne Logik des Sensors irgendwie verrennt und nicht sauber startet. Ist ja auch nur Digitaltechnik drin.

Ich würde den Vcc des Sensors schalten (über nen kleinen p-Kanal MOSFET ?) und zusätzlich die IO-Pins für die Datenübertragung vom Sensor auf GND legen damit da keine Phantomspeisung erfolgen kann.

Als Workaround damit man die Hardware nicht anpacken muß würde ich evtl zuerst die IO-Pins auf Eingang ohne PullUp schalten (also hochohmig) und erst nach dem Einschalten wieder auf die richtige Funktion setzen. Eventuell hilft das ja schon was. An den Datenleitungen zum Sensor liegen ja glaube ich externe PullUps. Dann wird er wenigstens halbwegs kontrolliert aus dem Schlaf geholt.

Gruß
Dino
 
Hey Uwe na wenigstens sind wir schon mal einen schritt weiter ^^,

bzw sry aber ich war die letzten Tage nicht zuhause deswegen erst jetzt wieder was =).


Dinge die ich mir vorstelen könnte sind :

- Wie diono sagt, der Power on Reset kommt nicht sauber (hast du die BurnOut fuse gesetzt ? Nutzt du 5V Versorgung ? Dann mal bitte die 4V7 Burn Out Aktivieren.

- Hast du eine schöne R/C Kombi am /Reset ?

- kann es sein, dass sich deine CPU noch irgendwie über den RS485 Bus ein GND holt und sich deshalb garnicht richtig Abschaltet sondern weiterlaeuft ?

- die andere Idee ist ev. noch, dass durch das Abschalten dein Master durcheinander kommt weil die Ruhepegel sich verziehen (ev. bekommst du deswegen irgendwie Interrupts ?)


öhm mehr faellt mir grad nicht ein ^^ bin gerade 450km auf der Autobahn geheizt mit öhm 2 Stunden stehen im Stau ^^

Gute Nacht ^^
 
Grüßt euch :) Sorry, für meine späte Antwort aber ich war letzte Woche auf ner Schulung am A...h der Welt und das ohne Internet. Zum Thema:
Ich hab zwischenzeitlich auch mal versucht, Plus und Minus zu trennen, da auch mein erster Gedanke dem Phantomstrom galt. Der Effekt war leider der Gleiche, nach der ersten Sendung, die noch gut rüberkam, kam anschliessend nur noch Schrott. Mittlerweile hab ich das Problem so gelöst, dass der Slave vor den Daten ein Byte mit ner bestimmten Ziffer sendet und direkt im Anschluss die Daten. Der Master nimmt erst die Daten auf, wenn die Nummer bei ihm ankommt und synchronisiert sich so mit dem Slave. Das klappt bis jetzt einwandfrei.
Die Burnouts sind übrigens alle auf 4,7 eingestellt und das ganze System ist mit 5V versorgt.

Mittlerweile hat sich noch eine neue Frage ergeben:
Mein Master schickt die aufbereiteten Daten weiter an einen PC mittels MAX232/USB. Und da gibts nen kleinen Haken. Er soll 22 Parameter (Single und Word) der Reihe nach verschicken und das tut er nicht wirklich. Er schickt nur 8-10 Parameter und überspringt den Rest. Beim nächsten Durchgang macht er dann da weiter, wo er aufgehört hat und schickt wieder nur ein "Päckchen". Bis alle 22 Parameter einmal übermittelt wurden, dauert es drei bis vier Durchläufe. Woran liegt das?


Liebe Grüße an alle

Uwe
 
Hi Uwe,

also das ist immer noch komisch dass du hier solche umwege gehen musst ... aber okey..

zu deiner anderen Frage ...

das ist genau das selbe in Grün .. das hört sich nach glaskugel an ^^

das kann Stack sein, das kann software sein ... mit was empfängst du das auf der pc seite ? Schon mal nur ein Terminal probiert ?...

Gruß,
Manuel
 
Naja welchen Buffer meinst du ?

Wie gesagt wenn du mir nicht sagst mit was du das Empfängst kann ich nur raten ^^ wenn es ne eigene Applikation ist, denke ich dass es der Applikations buffer ist ... hardware technisch denke ich nicht dass dir ein USB / RS232 Wandler da probleme macht, wenn dann der Treiber... kannst ja mal ausprobieren ... einmal all deine Bytes schicken und danach nur noch 'A' Schicken ... wenn dann dennoch noch der ganze Inhalt kommt liegts vermutlich an nem Buffer ... aber wie gesagt ... Glaskugel jucheeee =)
 
Hi,

Ist es auch möglich, dass der Buffer was damit zu tun hat? Ich werd morgen mal den Stack erhöhen.
der Serielle Buffer hat eigentlich nicht mit dem Stack zu tun weil der Stack eigentlich nur für Rücksprünge und sichern von Registern benutzt wird. Also zwei verschiedene Dinge. Ich tippe also mal das es dir nicht weiterhelfen wird. Sieht eher nach einem rumstochern im trüben nach dem Fehler aus.

Am besten mal wie "bluelight" es schon gesagt hat : Alle Infos auf den Tisch . Damit man mal das Gesamtkonstrukt sehen kann und eventuelle Stolperstellen erkennt.

Gruß
Dino
 
Hey Dino,

naja das das zwei komplett unterschiedliche dinge sind, ist glaub ich allen klar .. dennoch wenn der Stack nicht passt kannst du ganz wilde fehler bekommen ... (wo man zumteil garnicht mehr rafft was los ist ^^). Zum Buffer kann es sehr gut sein (gerade Treiberseitig)...


Aber wie ich schon sagte so ist das alles wie in ne große dicke Glaskugel zu schauen ...
Gruß,

Manuel
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)