Eigenartiges Problem mit RS485

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Eigenartiges Problem mit RS485

      Hallo
      Ich habe da wieder einmal ein eigenartiges Problem.
      Dazu habe ich ein zusammengestrichenes Programm erstellt was den "Fehler" auch produziert.

      Und zwar ergibt sich folgendes Problem:
      Die Hardware ist über einen USB-RS485-Dongle mit dem PC verbunden auf dem ein Terminalprogramm läuft.
      Die rote LED blinkt dauernd im Sekundentakt (durch den IRQ.
      Es kommt zu einer Datenübertragung (der PC sendet die Zeichenkette BASCOMTEST gefolgt von einem CR.
      Die Hardware empfängt diese korrekt und erkennt die Datenübertragung mittels IsCharWaiting auch korrekt.
      Abhängig vom Zustand der Key_Defaulttaste KEY_Default-Taste wird entweder mittel grüner LED in Anzahl der empfangenen Zeichen geblinkt oder die Zeichenkette entsprechend zurückgegeben.


      Das Problem besteht allerdings darin, dass durch den Print-Befehl aus einem mir unbekannten Grund IsCharWaiting der Meinung ist, da sind neue Zeichen, welche aber nicht abgeholt werden können.

      Das Programm hängt dann sogar in einer Schleife wie man am abgebrochenen Ausgabeergebnis erkennen kann (IsCharWaiting wird wohl nach dem Print wieder 1 es sind aber keine (auch nicht druckbare) Zeichen vorhanden. Inkey liefert jedenfalls immer nur 0, Waitkey wartet an der Stelle übrigens ewig auf ein Zeichen also gehe ich mal davon aus, dass da auch nichts ist).
      Wird der Print-Befehl allerdings nicht verwendet und der Empfangsstatus nur durch die LED signalisiert wird der Bereich auch nur jeweils beim Datenempfang durchlaufen. Dies erkennt man am Signal welches dann tatsächlich nur nach jeder empfangenen Zeile signalisiert.

      Ich denke, dass da ein Problem mit dem RS485 (MAX485 im Halbdublex und dessen Umschaltung) vorliegen könnte, jedenfalls habe ich in der Vergangenheit nichts derartiges beobachtet
      Irgendwie stehe ich vor einem Rätsel, kann das eventuell wer lösen?

      Quellcode

      1. CMD:[BASCOMTEST]
      2. ERR:[]
      3. ERR:[]
      4. ERR:[]
      5. ERR:[]
      6. ERR:[]
      7. ERR:[]

      BASCOM-Quellcode

      1. $regfile = "m328pdef.dat"
      2. $crystal = 11059200
      3. $hwstack = 100
      4. $swstack = 100
      5. $framesize = 100
      6. Config Submode = New
      7. Config Base = 0
      8. Config Adc = Single , Prescaler = Auto , Reference = AVCC
      9. Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8
      10. Config Print0 = PortD.2 , Mode = Set
      11. Config Pind.2 = Output
      12. Config Input1 = Cr , Echo = Cr
      13. Config SERIALIN0 = BUFFERED , SIZE = 200
      14. Echo Off
      15. $baud = 9600
      16. '(
      17. ##############################################################################
      18. #
      19. # Timerkonfiguration und Konstanten für Timer-IRQ mit 10 ms
      20. #
      21. ##############################################################################
      22. ')
      23. Config TIMER0 = Timer , Prescale = 1024
      24. Const TimerPreload = 148
      25. On Timer0 Timer_IRQ
      26. Dim A As Byte
      27. Dim X As Byte
      28. Dim Y As Byte
      29. Dim Z As Byte
      30. Dim V As Word
      31. Dim W As Word
      32. Dim sAdresse As String * 1
      33. Dim sCMD As String * 16
      34. Dim sCommand As String * 2
      35. Dim sParameter As String * 16
      36. Dim ResultText As String * 128
      37. Dim iTimer As Word
      38. Dim iFlash As Byte
      39. Config PORTB.0 = Input ' MP3 Busy
      40. Config PORTC.3 = Input ' Adresse 1
      41. Config PORTC.4 = Input ' Adresse 0
      42. Config PORTD.3 = Input ' Key Quit
      43. Config PORTD.4 = Input ' Key Set
      44. Config PORTD.6 = Input ' Reserve
      45. Config PORTD.7 = Input ' Key_Default
      46. Config PORTC.0 = Output ' Output 1
      47. Config PORTC.1 = Output ' Output 2
      48. Config PORTC.2 = Output ' Output 3
      49. Config PORTD.5 = Output ' Signal
      50. Config PORTB.3 = Output ' Status RT
      51. Config PORTB.4 = Output ' Status GN
      52. Config PORTB.5 = Output ' Status BL
      53. ' Pollup aktivieren
      54. Set Portb.0
      55. Set PortC.3
      56. Set PortC.4
      57. Set PortD.3
      58. Set PortD.4
      59. Set PortD.6
      60. Set PortD.7
      61. Status_rt Alias PORTB.3
      62. Status_gn Alias PORTB.4
      63. Status_bl Alias PORTB.5
      64. Output1 Alias PORTC.0
      65. Output2 Alias PORTC.1
      66. Output3 Alias PORTC.2
      67. Signal Alias PORTD.5
      68. MP3busy Alias PINB.0
      69. BoxAdr0 Alias PINC.3
      70. BoxAdr1 Alias PINC.4
      71. Key_Reserve Alias PinD.6
      72. Key_Default Alias PinD.7
      73. Key_Quit Alias PIND.3
      74. Key_Set Alias PIND.4
      75. MP3IsOn Alias PIND.6
      76. Enable TIMER0
      77. Enable Interrupts
      78. TIMER0 = TimerPreload
      79. Do
      80. If IsCharWaiting() = 1 Then
      81. Set Signal ' Buzzer On
      82. X = 0
      83. sCMD = ""
      84. sAdresse = ""
      85. sCommand = ""
      86. sParameter = ""
      87. iTimer = 25
      88. Do
      89. A = Inkey()
      90. If A > 30 Then
      91. sCMD = sCMD + Chr(A)
      92. Incr X
      93. If X > 31 Then
      94. iTimer = 0
      95. End If
      96. ElseIf A > 0 Then
      97. If sCmd = "" And A = 13 Then
      98. sCMD = sCMD + ">13!"
      99. ElseIf A <> 13 Then
      100. sCMD = sCMD + ">" + Str(A)
      101. End If
      102. End If
      103. Loop Until iTimer = 0 Or A = 13
      104. sCMD = Ucase(sCMD)
      105. If iTimer <> 0 And A = 13 Then
      106. If Key_Default = 0 Then ' Default-Taste betätigt
      107. Reset Signal
      108. Y = Len(sCMD)
      109. If Y = 0 Then
      110. Set Status_bl
      111. Waitms 1000
      112. Reset Status_bl
      113. Else
      114. For X = 1 To Y
      115. Set Status_gn
      116. Waitms 200
      117. Reset Status_gn
      118. Waitms 200
      119. Next
      120. End If
      121. Else ' Default-Taste nicht betätigt
      122. Print "CMD:[" ; sCMD ; "]"
      123. End If
      124. Else
      125. Print "ERR:[" ; sCMD ; "]"
      126. End If
      127. Waitms 50
      128. Reset Signal ' Buzzer Off
      129. Waitms 50
      130. End If
      131. Loop
      132. End
      133. Timer_IRQ:
      134. TIMER0 = TimerPreload
      135. Select Case iFlash
      136. Case 0
      137. Set Status_rt
      138. Case 50
      139. Reset Status_rt
      140. Case Is > 99
      141. iFlash = 255
      142. End Select
      143. Incr iFlash
      144. If iTimer <> 0 Then
      145. Decr iTimer
      146. End If
      147. Return
      Alles anzeigen
    • Ja, der PC sendet nur ein CR.
      Und Signal ist ein Buzzer (so ein Minipiepser).
      Die Richtungsumschaltung sollt BasCom ja selbst lösen, das soll ja durch die beiden Zeilen
      Config Print0 = PortD.2 , Mode = Set
      Config Pind.2 = Output
      erfolgen, zumindest würde ich die Hilfe so verstehen.
      Und wenn es zu keiner Umschaltung käme, würde das doch IMHO gar nicht funktionieren.
    • ERR[] kommt immer, wenn iTimer = 0 ist, was nach dem ersten Empfang gegeben ist.

      Warum nutzt du nicht einfach den URXC Interrupt? Dort in ein Array sammeln und bei einem CR die empfangenen Daten umkopieren, damit sie im Hauptprogramm verwendet werden können.
      Hier hab ich 4 Bytes gesammelt und bei CR umkopiert:
      bascomforum.de/lexicon/index.p…2-teil-7-bascom-programm/
    • Aber das If Then IsChrWaiting() darf doch trotzdem nur einmal bei Datenempfang durchlaufen werden (und wird es auch solange Print nicht verwendet wird).
      Nachdem oben im Do-Loop die Daten abgeholt werden (bis zum CR), kommen ja keine neuen Daten mehr vom PC.
      Wird aber mit Print zurückgeschrieben, gibt IsCharWaiting offenbar eine 1 zurück obwohl da gar nichts mehr sein dürfte (Waikey statt Inkey wartet hier auch und blockiert dann das Programm, wie ich ausprobiert hatte), also ist da wohl auch nichts, ERR: zeigt es ja auch mit leerer Zeichenkette) obwohl IsCharWaiting das Gegenteil behauptet.
      Die Frage bleibt also warum Print da das IsCharWaiting beeinflusst, weil wenn Print nicht verwendet wird, wird das If-Then IsCharWaiting () ja nicht mehr betreten, wie auch der Summer beweist, der immer nur einmal piept wenn Daten vom PC gesendet werden, aber nach Print das If-Then plötzlich immer gültig ist, warum auch immer.

      Dennoch werde ich mir morgen das mit dem URXC-INTRRUPT auch noch ansehen, habe aber keine fixe Zeichenlänge sondern verschieden lange Strings in Verwendung.
      Auch habe ich da Zugriff auf den Master und werde sehen ob sich der auch so verhält.
    • Zitronenfalter schrieb:

      ERR: zeigt es ja auch mit leerer Zeichenkette) obwohl IsCharWaiting das Gegenteil behauptet.
      es könnte durchaus das besagte LF in der Pipeline klemmen.


      Zitronenfalter schrieb:

      Die Frage bleibt also warum Print da das IsCharWaiting beeinflusst,


      Vielleicht sendet der PC ein Echo? (du sendest mit deinem Echo = Cr ja auch gleich was zurück)


      Zitronenfalter schrieb:

      Dennoch werde ich mir morgen das mit dem URXC-INTRRUPT auch noch ansehen, habe aber keine fixe Zeichenlänge sondern verschieden lange Strings in Verwendung.
      das ist nicht von einer Zeichenlänge abhängig, es reicht ja, auf CR zu warten.
    • Michael schrieb:

      es könnte durchaus das besagte LF in der Pipeline klemmen.Vielleicht sendet der PC ein Echo? (du sendest mit deinem Echo = Cr ja auch gleich was zurück)
      Selbst wenn das alles zutreffen würde (der PC oder besser das Terminalprogramm, sendet aber in diesem Zusammenhang definitiv nichts was ich nicht auch "autorisiert" habe), müsste spätestens beim zweiten Durchlauf der IF_THEN-Bedingung jedes noch so undruckbare Zeichen (ausgenommen natürlich Chr(0), das kann ja INKEY() nicht) abgeholt und im ERR-String angezeigt werden, das kann ja dann nach meinem Verständnis nicht einfach verschwinden.

      In diesem Zusammenhang stellt sich mir immer noch die Frage, durch welchen Umstand kann ISCHARWAITING() ein Zeichen im Buffer anzeigen, dass dann dann aber wenige Millisekunden (oder eventuell sogar noch schneller) später von dort einfach verschwindet obwohl der Buffer (noch) nicht angefasst wurde?

      INKEY() liefert da immer nur 0, WAITKEY() wiederum wartet da in einem Deadlock, weil wohl doch kein Zeichen da ist und auch nichts weiter kommt.
      Was ich mit WAITKEY() inzwischen allerdings beobachtet hatte, ist, dass dann nach einlangen weiterer Zeichen, (zwar immer der gleiche) aber dennoch Unsinn empfangen (oder zumindest ausgegeben) wird.

      Die Hardware habe ich inzwischen auch durchgemessen, da ist auch nichts ungewöhnliches, alles so wie es sein soll.
      Als nächsten Schritt werde ich die betroffenen ICs austauschen und in einer bekannten anderen Schaltung testen.
      Ich werde das dann im laufe des Tages versuchen weiter zu beobachten und einzugrenzen.

      PS.
      Dieser Post ging mal wieder im Nirvana unter aber glücklicherweise werden die vom Server zwischengespeichert.
    • Irgendwie hab ich grad ein Problem mit deiner Programmstruktur:

      du schaust, ob was in der seriellen abzuholen ist (mit ischarwaiting)
      Dann machst du eine Do-Loop. die so lange läuft, bis ein CR kommt, oder 31 Zeichen voll sind.
      Wenn kein CR kommt, oder nicht mindestens 31 Zeichen, läuft die Loop bis iTimer nach etwa 0,3s auf null ist
      Da fehlt irgendwie die Synchronisation.
      Beim ersten mal ist A=13, deswegen wird die Bedingung in Zeile 105 wahr und der String ausgegeben.
      Bei jedem weitern mal ist das wohl nicht so, deswegen die ERR Ausgabe.

      Meiner Meinung nach müsste nach ischarwaiting das eine char abgeholt werden (mit inkey) und dann jedes mal neu ein ischarwaiting vor dem inkey ausgeführt werden. Sonst gibt inkey ja immer eine null zurück bis iTimer leer ist und zur ERR-Ausgabe springt.
    • Nein, aber ich versuche mal den Programmablauf darzustellen so wie meine dass das Programm abläuft.
      Angenommen wird, dass der folgende Text gesendet wird:
      Testtext
      welcher mit CR bzw. Chr(13) abgeschlossen ist.

      Innerhalb einer Hauptschleife (eben die äußerste Do-Loop) wird mittels IsCharWaiting() abgefragt ob sich Zeichen im seriellen Buffer befinden.
      Ist die der Fall, wird die Bedingung wahr und es wird der Buzzer (Signal) aktiviert.
      Es werden diverse Variablen in einen Grundzustand versetzt und ein Timer wird auf 250 mS gesetzt (iTimer wird im IRQ alle 10ms heruntergezählt)
      Jetzt wird eine Do-Loop-Schleife betreten die unter den folgenden Bedingungen verlassen wird:
      Der Timer ist 0 (250ms abgelaufen) oder das Zeichen CR (Chr(13) wurde empfangen.
      Innerhalb dieser Schleife wird kontinuierlich der serielle Buffer abgefragt.
      Zeichen die größer als Chr(30) sind werden in den String sCMD übernommen während
      andere Zeichen größer 0 als Zahlencode übernommen (das Zeichen 0 kann ja INKEY() nicht erkennen).
      Wurde das Zeichen CR bzw.Chr(13) empfangen, wird die Do-Loop Schleife noch vor Ablauf des Timers verlassen.
      Alle Zeichen werden dann noch in Großbuchstaben umgewandelt.
      Man sollte also auch annehmen können, dass der serielle Buffer an dieser Stelle komplett geleert ist und sich somit dort keine weiteren Zeichen befinden.

      Ist der Timer nicht abgelaufen und das letzte erkannte Zeichen ist CR oder Chr(13) wird der gesendete Text ohne Steuerzeichen aber mit CRLF zurückgesendet.
      Nach einer Pause von 50ms wird der Buzzer (Signal) abgeschaltet und nochmals 50ms gewartet.

      Durch den Printbefehl erkennt IsCharWaiting() aber aus irgend einem Grund einen nicht leeren Buffer und gibt daher 1 zurück.
      Es gibt für mich keinen erkennbaren Grund warum dadurch der serielle Empfangsbuffer irgend ein Zeichen empfangen könnte, da die Gegenstelle
      nun mal nichts zurücksendet.
      Erschwerend kommt ja noch hinzu, dass Inkey() dann innerhalb von 250ms kein Zeichen erkennt obwohl IsCharWaiting() dies mitteilt.
      WaitKey() läuft in einen Deadlock und würde ja auch den Chr(0) erkennen.
      Also wo ist das oder die Zeichen, die IsCharWaiting() zu erkennen meint?

      Ich bin inzwischen aber um einiges weiter.
      Ich kann das Verhalten auch auf einer anderen Platine (hier dann mit ATmega1284P) nachstellen.
      Darüber hinaus habe ich die MAX485 aus verschiedenen Produktionschargen verwendet um auszuschließen, dass das daher kommt.
      Ich habe auch die Richtungsumschaltung selbst in die Hand genommen (sogar Pausen vor und nach dem Umschalten und auch vor und nach dem Print-Befehl eingefügt) sowie den PC-Dongle getauscht und schließlich sogar den PC außen vor gelassen und zwei µCs direkt über RS485 kommunizieren lassen.
      Es macht einfach keinen Unterschied.
      Nach einem Print-Befehl geht IsCharWaiting auf 1 und es ist aber kein Zeichen da.
      Fakt ist, wird Print nicht verwendet bleibt IsCharWaiting auf 0.
      Auch das hat ein Versuch bestätigt.

      Weiters habe ich auch versucht nur dann den empfangenen String zurück zugeben wenn die Länge der zusammengesetzten Zeichenkette <>0 Ist.
      In diesem Fall wird die Zeichenkette mittels Print zurückgegeben und danach die Bedingung aber noch ein mal durchlaufen wo dann keine Zeichen erkannt werden. Dies erkenne ich daran, dass der Buzzer eben 250ms (eben weil mein Timer zuschlägt) ein Signal abgibt, da ja das notwendige Steuerzeichen nicht einlangt (woher auch?). Danach ist die Bedingung dann nicht mehr wahr. Also muss durch den Aufruf von Inkey() das imaginäre Zeichen, das aber weder Chr(0) (Waitkey hängt sich da ja auf) noch ein anderes sein kann der Buffercounter auf Null gesetzt werden so dass IsCharWaiting() nichts mehr erkennt.
      Ich denke inzwischen, dass sich BasCom an der Stelle zumindest in Verbindung mit RS485 "verschluckt", kann es aber, wie immer nicht direkt beweisen, ich finde solche Sachen leider immer ohne sie direkt zu suchen.

      Umgehen kann ich diesen Fehler aber inzwischen dadurch, dass ich im Ergebnis auch überprüfe ob auch tatsächlich Zeichen angekommen sind und mich nicht auf das IsCharWaiting() alleine verlasse.

      PS:
      Irgendwie hakt es heute, auch diesen Post konnte ich nur nach wiederherstellung und erweitertem senden übermitteln.
      Eventuell hat dieses Problem damit zu tun, dass man nur "kurze" Zeit hat einen Post im einfachen Editor zu bearbeiten.
    • Darf ich mal sachte fragen, woran ich am Programm erkenne, ob das RS485 ist, oder RS232? Hängt das nur an dem Stöpsel, wo die Daten raus bzw rein kommen/gehen? Was passiert, wenn du beide AVRs direkt verbindest?
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Zitronenfalter schrieb:

      Man sollte also auch annehmen können, dass der serielle Buffer an dieser Stelle komplett geleert ist und sich somit dort keine weiteren Zeichen befinden.
      oder dein Timer ist abgelaufen

      Zitronenfalter schrieb:

      Also muss durch den Aufruf von Inkey() das imaginäre Zeichen, das aber weder Chr(0)
      Wenn das Zeichen aber chr(0) wäre?

      Zitronenfalter schrieb:

      Ich denke inzwischen, dass sich BasCom an der Stelle zumindest in Verbindung mit RS485 "verschluckt", kann es aber, wie immer nicht direkt beweisen, ich finde solche Sachen leider immer ohne sie direkt zu suchen.
      Ich gehe immer davon aus, dass der Fehler bei mir liegt, bzw. dass ich etwas übersehen oder nicht verstanden habe.

      Beim RS485 Bus wird nach meinem Verständnis gesendet und empfangen auf der gleichen Leitung. Die Sende-Empfangseinheit hat quasi einen Daten-Kuzschluss und der Sender kann beim Empfangen abgeschaltet werden. So kommt es durch das Senden immer zu einem Datenempfang am eigenen Empfänger und das löst das Erkennen (ischarwaiting()=1) aus.
    • tschoeatsch schrieb:

      Darf ich mal sachte fragen, woran ich am Programm erkenne, ob das RS485 ist, oder RS232?
      Keine Ahnung a_56_df238249

      tschoeatsch schrieb:

      Was passiert, wenn du beide AVRs direkt verbindest?
      Hab's mal ausprobiert, da funktioniert das Programm erwartungsgemäß ;)

      Kaum sind wieder die MAX485 drinnen, kommt es zum beschriebenen Verhalten.
      Also irgend einen Einfluss müssen die Treiber haben, da der Code bei beiden Versuchen natürlich unverändert war, IsCharWaiting() meldet ein nicht vorhandenes Zeichen ?( .
    • Michael schrieb:

      So kommt es durch das Senden immer zu einem Datenempfang am eigenen Empfänger und das löst das Erkennen (ischarwaiting()=1) aus.
      Dann müsste ja auch was zu Lesen sein.
      In der Hilfe steht
      'Using the CONFIG SERIAL=BUFFERED, SIZE = 10 for example will
      'use some SRAM memory
      'The following internal variables will be generated :
      '_Rs_head_ptr0 BYTE , a pointer to the location of the start of the buffer
      '_Rs_tail_ptr0 BYTE , a pointer to the location of tail of the buffer
      '_RS232INBUF0 BYTE ARRAY , the actual buffer with the size of SIZE
      @Zitronenfalter du könntest nach dem print ja mal der pionter _Rs_tail... mit dem _Rs_head... gleich setzen. Das wäre doch so, als wie wenn nix im Puffer drin wäre.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Michael schrieb:

      Wenn das Zeichen aber chr(0) wäre?
      Dann müsste das doch das ersatzweise verwendete Waitkey() abholen können und dürfte das Programm nicht blockieren.
      Denn wenn ich Inkey() durch Waitkey() ersetze habe ich dann genau das Problem, dass das Programm hängt. Wäre da der Chr(0) würde es nach meinem Verständnis dann eben nicht zur Blockade kommen sonder eben der Chr(0) abgeholt.
      Man könnte zwar noch das TimeOut$ verwenden was ich aber vermeiden möchte, da ich in der Originalschaltung mehr als eine Schnittstelle verwende (die dann als Soft-RS232).

      Michael schrieb:

      So kommt es durch das Senden immer zu einem Datenempfang am eigenen Empfänger und das löst das Erkennen (ischarwaiting()=1) aus.
      Blöde Frage, aber ist dieser Datenempfang dann ein unsichtbares Zeichen?
      Weil ein Chr(0) ist es ja wohl nicht und andere werden auch nicht erkannt wie ich oben schon dargelegt hatte.
      Nach obigen Versuch komme ich auch immer mehr zur Überzeugung, dass das dem RS485 geschuldet ist und zumindest _MIR_ bisher nicht aufgefallen ist. Ich kann das ja inzwischen auch gut umschiffen, hatte nur ursprünglich damit einfach nicht gerechnet.

      Ich wundere mich nur darüber, dass das so erstellte Zeichen nicht abfragbar ist obwohl IsCharWaiting() das Gegenteil behauptet und weil WaitKey sich "aufhängt" ist nach meinem Verständnis auch kein Chr(0) da. Dennoch wird wohl nach Aufruf von Inkey() der Status für IsCharWaiting() verändert.
      Du musst aber schon zugeben, dass das ganze etwas eigenartig erscheint.

      Michael schrieb:

      Ich gehe immer davon aus, dass der Fehler bei mir liegt, bzw. dass ich etwas übersehen oder nicht verstanden habe.
      Glaub mir, aber ich habe lange überlegt und einige Versuche durchgeführt bis ich diesen Thread eröffnet habe und hatte gehofft, dass ich hier doch noch auf den richtigen Weg geführt werde.
      Ich bin ich ja eher(wiedereinmal) nur durch Zufall auf dieses Verhalten gestoßen.
    • Zitronenfalter schrieb:

      Michael schrieb:

      So kommt es durch das Senden immer zu einem Datenempfang am eigenen Empfänger und das löst das Erkennen (ischarwaiting()=1) aus.
      Blöde Frage, aber ist dieser Datenempfang dann ein unsichtbares Zeichen?Weil ein Chr(0) ist es ja wohl nicht und andere werden auch nicht erkannt wie ich oben schon dargelegt hatte.
      Nach obigen Versuch komme ich auch immer mehr zur Überzeugung, dass das dem RS485 geschuldet ist und zumindest _MIR_ bisher nicht aufgefallen ist. Ich kann das ja inzwischen auch gut umschiffen, hatte nur ursprünglich damit einfach nicht gerechnet.

      Ich wundere mich nur darüber, dass das so erstellte Zeichen nicht abfragbar ist obwohl IsCharWaiting() das Gegenteil behauptet und weil WaitKey sich "aufhängt" ist nach meinem Verständnis auch kein Chr(0) da. Dennoch wird wohl nach Aufruf von Inkey() der Status für IsCharWaiting() verändert.
      Du musst aber schon zugeben, dass das ganze etwas eigenartig erscheint.

      Michael schrieb:

      Ich gehe immer davon aus, dass der Fehler bei mir liegt, bzw. dass ich etwas übersehen oder nicht verstanden habe.
      Glaub mir, aber ich habe lange überlegt und einige Versuche durchgeführt bis ich diesen Thread eröffnet habe und hatte gehofft, dass ich hier doch noch auf den richtigen Weg geführt werde.Ich bin ich ja eher(wiedereinmal) nur durch Zufall auf dieses Verhalten gestoßen.

      Hallo,
      Den richtigen Weg hast Du doch schon erkannt. Es ist völlig Wurst welche UART_ Treiber genutzt werden.
      Der Befehl „Print“ wandelt grundsätzlich in Text und hängt die Steuerzeichen an. Egal was gesendet wird. Es sei denn ein [;] zum Abschluss oder gleich Printbin nutzen.
      Mit Printpin wird nichts in Text gewandelt und eine 1 kann auch als solche weiterbetrachtet werden ist eben keine „1“. Prima Lösung in Bascom.
      Nur mal so.
      Bin schon wieder im Untergrund Michael
    • Hallo Zitronenfalter,
      hast du auch die (niederohmigen) Abschlusswiderstände an beiden Leitungsenden angeschlossen? Auch wäre mal von Interresse statt der Halb-duplex MAX485 versuchsweise die Voll-duplex Max488 (z.B.) zu verwenden, dann allerdings mit 2 verdrillten Adern-Paaren . Da sind Sende- und Empfangsrichtungen getrennt und dürften sich nicht in die Quere kommen.
      Gruß
      Chris
    • oscar schrieb:

      hast du auch die (niederohmigen) Abschlusswiderstände an beiden Leitungsenden angeschlossen?
      Ja alle Kombinationen (120 Ohm mit Jumper zuschaltbar gelöst). Also bei beiden Geräten, nur bei jeweils einem und bei gar keinem (aktuell sind nur zwei Geräte beteiligt).
      Ändert aber nichts am Resultat.

      oscar schrieb:

      Auch wäre mal von Interresse statt der Halb-duplex MAX485 versuchsweise die Voll-duplex Max488 (z.B.) zu verwenden
      Die hab ich nicht hier, und im konkreten Anwendungsfall habe ich nur vier Adern inkl. Stromversorgung.