RS485 Datenübertragung mit VB 2005

"Artur" schrieb im Newsbeitrag news: snipped-for-privacy@22g2000hsm.googlegroups.com...

Ich kann dir zwar auch nicht wirklich helfen , aber der Fehler liegt eindeutig bei VB 2005. Mein Arbeitskollege hatte vor Kurzem das gleiche Problem. Er konnte auf der Seriellen (RS232) nur 7 Bit senden.

Er hat dann eine ältere Version probiert, welche richtig funkioniert hat.

Gruß

Werner

er

t=2E

Na das ist ja schon mal eine Aussage. Dann wird es doch wohl darauf hinaus laufen das ich direkt die Treiber in der DLL nutzen muss (FT2xx.DLL)

Vielen Dank,

Artur

Hallo Werner,

Scheint nicht nur bei VB ein Problem zu sein. Ich bin gerade an der Installation einer Oszilloskop Software gescheitert. Dieser leidige .NET Kram. Offenbar funktioniert die nur mit Version 1.1.4322, aber Microsoft hat nur noch ab 2.0. Ganz wunderbar.

--
Gruesse, Joerg

http://www.analogconsultants.com

Joerg schrieb:

.NET Redistributable Version 1.1:

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA

Hallo Christian,

Danke, die hatte ich allerdings auch schon probiert. Same thing :-(

Es gibt offenbar ziemlich harte Patzer in .NET in Sachen Backward Compatibility. Naja, ist auch gut zu wissen, wieder was (nicht so gutes) gelernt. Wenn der naechste Programmierer darauf aufsetzen will, kann ich nun rechtzeitig bremsen und abbiegen ;-)

--
Gruesse, Joerg

http://www.analogconsultants.com

Hmm, ich gehe mal davon aus "RS485" ist vom Typ System.IO.Ports.SerialPort?

Welche Überladung von SerialPort.Write meinst Du denn mit RS485.Write()?

Es scheint drei zu geben:

#1 (neu in .NET 2.0) Public Sub Write ( _ text As String _ )

#2 Public Sub Write ( _ buffer As Byte(), _ offset As Integer, _ count As Integer _ )

#3 Public Sub Write ( _ buffer As Char(), _ offset As Integer, _ count As Integer _ )

Ich könnte mir Folgendes vorstellen: Du willst eigentlich Bytes an die Schnittstelle schicken, brauchst also die Überladung #2.

In der benutzten Variante denkt VB es tut Dir einen Gefallen, wandelt die Zahl die Du angibst in einen String ("250" - damit passt Überladung #1) und sendet diese drei (!) Zeichen an die Schnittstelle.

Versuch's mal so:

Dim buffer(1) As Byte buffer(0) = &HFA RS485.Write(buffer, 0, 1)

Viele Grüße, Gilles.

Hallo Christian,

Ok, jetzt habe ich es endlich raus. Falls das noch jemandem anders passiert:

Ich musste zuerst die ganze .NET 2.0 Umgebung laden. Dann da drueber dotnetfx.exe fuer Version 1.1 (nicht umgekehrt).

Na ja, gut dass ich mich sonst nicht mit diesem .NET abplagen muss. Jedenfalls kann ich jetzt den grossen PC Bildschrim fuer das neue Scope benutzen, ist angenehmer fuer die Augen. Vor allem, wenn ich naechste Woche 0402 Kram mit der ganz starken Brille machen darf, seufz.

--
Gruesse, Joerg

http://www.analogconsultants.com

Hallo Gilles,

ich habe zwar schon die anderen =DCberladungen ausprobiert unter anderen ganz wilde Konstrukte wie

RS485.Write(char(&HFA))

aber bei 127 war immer Schluss. Das dekt sich ja auch mit den anderen Antworten zu diesem Posting.... leider!

Nicht desto trotz werde ich deinen Vorschlag heute Abden mal ausprobieren und das Ergebnis hier posten. Es kann ja auch sein das VB2005 denkt alles ist ein String und Zeichen gr=F6=DFer 127 werden ignoriert oder als Steuerzeichen behandelt. Da k=F6nnte es nat=FCrlich sein das dein Vorschlag mit dem Byte doch funktioniert....

Vielen Dank im Vorraus

Artur

Ich hab's mal geschwind getestet - mit HTerm auf COM4 horchend, diesem Progrämmle ...

' ---------------------------- Imports System.IO.Ports

Public Class Form1 Dim RS485 As New SerialPort("COM3")

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click Dim buffer(1) As Byte buffer(0) = &HFA RS485.Write(buffer, 0, 1) End Sub

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load RS485.BaudRate = 19200 RS485.DataBits = 8 RS485.StopBits = IO.Ports.StopBits.One RS485.Parity = IO.Ports.Parity.None RS485.Handshake = IO.Ports.Handshake.None

RS485.Open() End Sub

End Class ' ----------------------------

... auf COM3 sendend und GPSGate als Vermittler zwischen den beiden (schickt alles von COM3 nach COM4 und umgekehrt - ich hätte zwar einen ATMega bei Hand, aber da ist die serielle Schnittstelle z.Zt. nicht angeschlossen, und klicken ging schneller als Löten)

Resultat hier:

Viele Grüße, Gilles.

Gilles Kohl schrieb:

Hallo,

das war früher schon bei VB 5 das Problem, wenn man binäre Daten hatte und alle 8 Bits ausnutzen wollte durfte man wegen Unicode und 16 Bit Zeichen usw. nicht mehr Strings nehmen, es mussten Bytearrays sein. Bei der MSCOMM32.ocx gab es auch noch ein ModeBinary Flag, das war auch wichtig. Ich habe allerdings vor einigen Monaten mal einen selbsgeschriebenen Modus Treiber von VB 5 nach .Net 2.0 C# portiert, das klappte, es gab keine Probleme mit dem achten Bit. Allerdings benutzte ich da RS232 und nicht RS485 aber schon System.IO.Ports.SerialPort. Der Unterschied bei den physikalischen Treibern ist allerdings eigentlich unbedeutend, bis auf die Richtungssteuerung bei RS485. Benutzt Du einen Wandler von RS232 nach RS485? Wenn ja schau mal nach wie das die Richtungsumschaltung gemacht wird, da muß man Baudrate und evtl. auch Zeichenlänge einstellen damit erst nach dem ein komplettes Zeichen vom PC raus ist wieder auf Empfang für den PC geschaltet wird, nicht vorher. Ganz wichtig ist natürlich auch das beide Seiten auf die gleiche Baudrate, Datenlänge, Parity, Stopbits eingestellt sind. Die andere Seite darf erst antworten wenn ein Zeichen komplett draussen ist und kein weiteres Zeichen mehr kommen kann, sonst gibt es eine Kollision. Wichtig ist auch wenn aus z.B. einer Quarzfrequenz von 20 MHz in einem Mikroprozessor krumme Baudraten erzeugt werden das diese auf nur maximal

+- 2,5 % abweichen. Bei 2400 Baud ist das kein Problem, da gibt es genug Teilerwerte die genügend genau passende Baudraten erzeugen, aber bei 19200 und höher kann es Probleme geben.

Na denn viel Erfolg

Bye

Es schrieb einstmals Artur :

VB wird dann wohl bei Nicht-7Bit-ASCII-Zeichen Unicode benutzen. Evtl. kannst Du ihm das irgendwie abgewöhnen.

Ansgar

--
E-Mails an die angegebene Adresse errreichen mch - oder auch nicht.  
Nützliche Adresse gibt's bei Bedarf!
Mails to the given address may or may not rech me - useful address will be  
given when required!

Artur :

char() schreibt Unicode. versuchs mal mit: RS485.Write(byte(&HFA))

Natürlich sollte es in der Write() Routine nicht wieder in eine char() gecastet werden...

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.

Matthias Weingart schrieb:

Hallo,

ganz genau, man darf nirgendswo char benutzen, es muß alles byte sein!

Bye

[...]

Ist das Argument ein char? Ein signed char? Dann liegst du mit $fa=250 drüber. Sende mal -6, das liegt noch im Wertebereich, und schau, ob das dann geht.

Mit freundlichen Grüßen

Frank-Christian Krügel

Hallo Gilles,

ich habe heute fr=FCher Feierabend gemacht und deinen Vorschlag

direkt ausprobiert und es funktioniert!

Vielen, vilen Dank,

Artur

Hallo Matthias

funktioniert leider nicht. Ich habe es gerade ausprobiert. Anscheinend muss man wirklich ein Bytearray benutzen. Dann funktioniert es auch.

Dennoch vilen Dank f=FCr die Antwort,

Artur

Hallo Uwe,

Wie bereits weiter oben beschrieben funkltioniert es nur mit einem Bytarray.

Viele Gr=FC=DFe,

Artur

Das tut VB.net grundsätzlich, nicht nur für Nicht-7Bit-ASCII-Zeichen.

Nein. VB kennt keinen String-Datentyp mit 8Bit-Elementen, man muß zwingend Bytearrays verwenden, wenn man solches (z.B. für irgendwelche Übertragungen) braucht. Freundlicherweise gibt's im .net-Framework aber wenigstens Encoder, mit denen man die Wandlung auf einfache Art erledigen kann.

dim ansi as bytearray()=System.Text.Encoding.Default.GetBytes("Hällo Wörld")

Liefert auf einer deutschsprachigen Standard-Windows-Installation einen

8Bit-String in korrekter Windows-CP1252-Kodierung.

Mit der Klassenmethode System.Text.Encoding.GetEncoder() kann man sich aber auch problemlos Encoder für etliche andere Codepages verschaffen. Einige wichtige und weit verbreitete Codepages hat Microsoft dabei erstaunlicherweise sogar völlig fehlerfrei und standardgerecht implementiert. Also es geht doch...

Probleme gibt es aber natürlich aber immer dann, wenn im Unicode-String Zeichen enthalten sind, die sich in der jeweiligen Ziel-Codepage nicht abbilden lassen. Aber das liegt in der Natur der Sache und ist nicht MS anzulasten.

In beide Richtungen :( Wir haben unser device in der neueren Version von .net 1 auf 2 umgestellt, da mußten erst mal tausende Zeilen code angepaßt werden, weil sich da etwas geändert hatte. Unser Ali ist einpfiffiges Kerlchen, der hat erst mal ein Programm geschrieben, um das teilweise zu automatisieren. Das ist zu einem Zeitpunkt geschehen, wo ich gerade an der Entscheidungsfindung war, ob ich in Sachen Programmieren mich eher mit dem Visual Studio befasse, oder mit dem Code Composer Studio. Ich habe mich dann mit Grausen vom Wuschelstudio abgewandt :) DSPs sind ehrlichere Gesellen.