VB Problem

Hi,
Ich versuche mit VB6 und dem Comm Control Daten von einem an den COM1 Port angeschlossenen Micoprozessor zu empfangen und in einer Listbox zu speichern.

Der VB-Code:

Code:

---

Private Sub Form_Load()
MSComm1.CommPort = 1
MSComm1.Settings = "9600,N,8,1"
MSComm1.PortOpen = True
MSComm1.RThreshold = 1
MSComm1.SThreshold = 1
MSComm1.InputLen = 0
End Sub

Private Sub Form_Unload(Cancel As Integer)
MSComm1.PortOpen = False
End Sub

Private Sub MSComm1_OnComm()
Dim Eingang As String
  Select Case MSComm1.CommEvent
  Case comOverrun:  MsgBox "Datenverlust!"
  Case comRxOver:    MsgBox "Datenverlust!"
  Case comEvReceive: List1.AddItem MSComm1.Input
  End Select
End Sub

---

Der Code im Prozessor ist das Testprogram2:

Code:

---

I = 0
Do
  Incr I
  Wait 1
  Print "Hallo" ; I
Loop

---

Als Ergebnis bekomme ich folgendes in der List-Box:
( || bedeutet, dass da 2 seltsame schwarze balken kommen)
Hallo1||
Hallo2||
Hallo3||
Hallo4||
Hallo5||
Hallo6||
Hallo7||
Hallo8||
Hallo9||
Hallo10|
|
Hallo11|
|
Hallo12|
|


Meine Frage ist also: Warum kommen da so komische Balken nach dem empfangenen Wert? UND: Warum gibts immer nen neuen Eintrag in dem immer nur ein solcher Balken vorkommt. Schaut irgendwie wie ein Zeilenumbruch aber da es ne Liste ist geht das wohl nicht.

Bitte um Hilfe !!
mfg
jagdfalke

Soweit ich das in Erinnerung habe sind das Zeilenumbrüche, die in einer Listbox nicht als solche behandelt werden können, weil es da nur Einträge und keine Umbrüche gibt.
Es scheint das ganze nicht sorichtig synchron zu sein. Ansonsten musst du empfangene Zeilenumbrüche rausfiltern.
Die VB-Umgabungskonstante für einen Zeilenumbruch ist "vbCrLf"

Es scheinen wirklich Zeilenumbrüche zu sein. Ich hab das ganza mal in ne Textbox schreiben lassen.
Wenn multiline auf false ist, sind die Balken da. Wenn es auf false gestellt ist, sind sie weg: wahrscheinlich in echte Zeilenümbrüche umgewandelt.

Wie krieg ich das ganz denn dann synchron? Bzw. Wie kann ich die Zeilenübrüche rausfiltern?

Speicher den Input von der Comm-Schnittstelle vorher einmal in eine Variable und gehe die dann durch. Wenn du einen Text hast, der "Text" heißt filterst du wie folgt alle Zeilenumbrüche raus:

Code:

---

do
  Text = Left(Text, instr(Text,vbcrlf)-1) & right(Text, len(Text)-instr(Text,vbcrlf))
until instr(Text, vbCrLf) = 0

---

Hi, ich hab das etz ein wenig anders gelöst, nachdem ich nen alten VB Schmöker gewälzt hab:

Code:

---

Private Sub Form_Load()
MSComm1.CommPort = 1
MSComm1.Settings = "9600,N,8,1"
MSComm1.PortOpen = True
MSComm1.RThreshold = 1
MSComm1.SThreshold = 1
MSComm1.InputLen = 0
End Sub

Private Sub MSComm1_OnComm()
Dim Eingang As String
Dim Eingang_replaced As String

Select Case MSComm1.CommEvent
 Case comOverrun:  MsgBox "Datenverlust!"
 Case comRxOver:    MsgBox "Datenverlust!"
 Case comEvReceive: Eingang = MSComm1.Input
End Select
Text1.Text = Replace(Eingang, vbCrLf, "")
VScroll1.Value = 255 - CInt(Replace(Eingang, vbCrLf, ""))
End Sub

---

Das komische ist: Es funktioniert alles wunderbar, bis ich das Fenster (während das proggy läuft) verschiebe. Dann steht in der textbox plötzlich ne ellenlange (nicht immer die gleiche) Zahl und die Fehlermessage lautet:
"overflow"
Was zum geier ist da los? liegt es am replace-Befehl?

Am replace-Befehl liegt es nicht. Ich hab auch deine Methode probiert.

Mist ich hab vergessen, dass sich der Aufbau mittlerweile geändert hat:
Ich bewege im Moment mit dem Prozessor einen Servo und übermittle immer die aktuelle Position an den COM1.

Hier die Subrouting im Prozessor, die den Servo bewegt und die Daten sendet:

Code:

---

Sub Rnb_servo(byval Servonummer As Byte , Byval Go_to_pos As Byte)
  Local Schritt As Integer
  If Curr_pos < Go_to_pos Then
      Schritt = 1
  Else
      Schritt = -1
  End If

  For Curr_pos = Curr_pos To Go_to_pos Step Schritt
        Open "comd.7:9600,8,n,1" For Output As #2
            Print #2 , "#s" ; Chr(servonummer) ; Chr(curr_pos)
        Close #2
        Print Curr_pos
        Waitms 10
  Next

End Sub

---

Hm, also wenn das wirklich nur auftaucht, wenn man das Formular verschiebt dann solltest du mal folgendest testen:


- tritt gleicher Fehler auch bei der compilierten (.exe) Datei auf ?

- ist das Programm vllt. auch vor dem Verschieben nicht mehr stabil und hängt, der Fehler wird erst bei Aktion sichtbar ?

- wird das ganze somit wirklich unmittelbar mit dem Verschieben zusammenhängen ?

- Mir ist nur ein Fehler in dem Zusammenhang bekannt, dessen Lösung lautet Auto-Redraw Eigenschaft des Formulars auf true setzen.

Mir fällt sonst grad noch ein, dass es vllt. nicht unmittelbar an dem Programm liegen könnte sondern unmittelbar an den kommenden Daten oder an der Schnittstelle ???
Evt. anderen Rechner prüfen...

Ich hätte nie daran gedacht, dass es daran liegen könnte:
Ich hab eine VScroll-Bar mit reingebaut und den Wert der übergeben wurde durch die Scroll-Bar dargestellt. Mit Scroll-Bar freckt mir das Proggy ständig ab, aber ohne machter des ohne mit der Wimper zu zucken. Warum ist das so? ist die Übertragungsgeschwindigkeit zu schnell für die Scroll-Bar? (auch die ProgressBar funktioniert nicht.)
mfg
jagdfalke

Das könnte man ausprobieren, indem man Pausen einbaut. Ist denn die ober und Untegrenze der Scroll-Bar passende eingestellt ?

Also die min und max Werte sind richtig (min = 0; max = 255).
hier mal die kompletten Eigenschaften der Scroll-Bar:

Code:

---

Name = HScroll1
CausesValidation = True
DragIcon = none
DragMode = 1
Enable = True
Height = 255
HelpContextID = 0
Index = [leer]
LargeChange = 1
Left = 120
Max = 255
Min = 0
MouseIcon = none
RightToLeft = False
SmallChange = 1
TabIndex = 5
TabStop = True
Tag = [leer]
Top = 960
Value = 0
Visible = True
WhatsThisHelpID = 0
Width = 4575

---

Wie stellst du dir das mit den Pausen vor? Das ganze FUnktioniert ja über das OnComm-Event, oder geht das auch anders? Naja lassen wird das, es gibt schon wieder neue Probleme:

hier der kompette code:

Code:

---

Private Sub Form_Load()
    MSComm1.CommPort = 1
    MSComm1.RTSEnable = True
    MSComm1.Settings = "9600,N,8,1"
    MSComm1.PortOpen = True
    MSComm1.RThreshold = 1
    MSComm1.SThreshold = 1
    MSComm1.InputLen = 0
End Sub

Private Sub Form_Unload(Cancel As Integer)
    MSComm1.PortOpen = False
End Sub

Private Sub MSComm1_OnComm()
        Dim InBuff As String

        Select Case MSComm1.CommEvent
        ' Errors
            Case comEventBreak  ' A Break was received.
            Case comEventCDTO    ' CD (RLSD) Timeout.
            Case comEventCTSTO  ' CTS Timeout.
            Case comEventDSRTO  ' DSR Timeout.
            Case comEventFrame  ' Framing Error.
            Case comEventOverrun ' Data Lost.
            Case comEventRxOver  ' Receive buffer overflow.
            Case comEventRxParity  ' Parity Error.
            Case comEventTxFull  ' Transmit buffer full.
            Case comEventDCB    ' Unexpected error retrieving DCB]

        ' Events
            Case comEvCD  ' Change in the CD line.
            Case comEvCTS  ' Change in the CTS line.
            Case comEvDSR  ' Change in the DSR line.
            Case comEvRing ' Change in the Ring Indicator.
            Case comEvReceive ' Received RThreshold # of chars.
              InBuff = MSComm1.Input
              Call HandleInput(InBuff)
            Case comEvSend ' There are SThreshold number of
                          ' characters in the transmit buffer.
            Case comEvEOF  ' An EOF character was found in the
                          ' input stream.
        End Select
End Sub


Sub HandleInput(InBuff As String)
    Dim Eingang_STR  As String
    Dim Pos_Doppelpunkt As Integer
    Dim Data_identification_str As String
   
    Eingang_STR = Trim(Replace(InBuff, vbCrLf, ""))

    Pos_Doppelpunkt = InStr(Eingang_STR, ":")
    Data_identification_str = Left(Eingang_STR, Pos_Doppelpunkt)

    List1.AddItem Eingang_STR
End Sub

---

Das Prozessor sendet sowas wie "Servo1:232". Die Funktion HandleInput soll unterscheiden zwischen Daten, die den Servo oder den Schrittmotor betreffen. Das Problem liegt aber mal wieder beim empfangen:
Den interessiert es garnet, wann meine Daten (die gesendet werden) ankommen. Wenn ich im falschen Moment das Programm starte hab ich z.B. "vo1:232". Und dann hängt er ab und zu mal einfach was vom nächsten Paket dran: "vo1:232S". Es sind aber immer genau 8 Zeichen. Die hängt er einfach aneinander, auch wenn im richtigen Moment einschalte. Man des Zeug stresst mich.

Also hier im Anhang nochmal ein Bild zur Verdeutlichung. Was auf dem Bild zu sehen ist, ist das, was ich empfange. Ich mache nichts weiter, als den String zu empfangen und so wie er ist in die Listbox zu schreiben.

Bitte helft mir !!! Die seltsamen Zeichen hinten dran abzuschneiden ist ja nicht das Problem, aber warum werden die einzelnen Strings so zerrissen?
mfg
jagdfalke

Wenn dich die Zeilenumbrüche stören, könntest du sie einfach gar nicht erst versenden.

Wenn du in Bascom Print "Hallo" schreibst, schickt Bascom einen Zeilenumbruch mit.
Wenn du stattdessen Print "Hallo"; schreibst schickt Bascom das Hallo ohne Zeilenumbruch

Cool, danke für den Tip!! Dennoch sieht die Ausgabe so aus, wie auf dem Bild im Anhang. Die Zeichen sind zwar weg, aber das was geprinted wird wird immer noch zerstückelt. Kann man nur 8 Zeichen senden?

Bei mir gibt's bei folgendem Testcode keine Probleme mit mehr als 8 Zeichen:

Code:

---


'######### Bascom
Do
  Ts = Getadc(0)
  Print "Der Porta.1 hat den Wert: " ; : Print Ts
  Waitms 10
Loop



'####### VB

Private Sub Form_Load()
    With MSComm1
        .CommPort = 1
        .Settings = "19200,N,8,1"
        .PortOpen = True
        .RThreshold = 1
        .SThreshold = 1
        .InputLen = 0
    End With
End Sub

Private Sub Form_Terminate()
    End
End Sub

Private Sub MSComm1_OnComm()
    Select Case MSComm1.CommEvent
        Case comOverrun
        MsgBox "Datenverlust"
        Case comRxOver
        MsgBox "Datenverlust"
        Case comEvReceive
        data_in = MSComm1.Input
        Text1.Text = Text1.Text & data_in
    End Select
End Sub

---

habs mittlerweise in delphi umgeschrieben. ich benutze die Com Komponente aus dem Download Bereich. In VB hatte ich genau das selbe Problem.

Code:

---

unit ComMainForm;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  StdCtrls, ExtCtrls, CPort, CPortCtl;

type
  TForm1 = class(TForm)
    ComPort: TComPort;
    Button_Open: TButton;
    ListBox1: TListBox;
    procedure Button_OpenClick(Sender: TObject);
    procedure ComPortOpen(Sender: TObject);
    procedure ComPortClose(Sender: TObject);
    procedure ComPortRxChar(Sender: TObject; Count: Integer);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.DFM}

procedure TForm1.Button_OpenClick(Sender: TObject);
begin
  if ComPort.Connected then
    ComPort.Close
  else
    ComPort.Open;
end;


procedure TForm1.ComPortOpen(Sender: TObject);
begin
  Button_Open.Caption := 'Close';
end;

procedure TForm1.ComPortClose(Sender: TObject);
begin
  if Button_Open <> nil then
    Button_Open.Caption := 'Open';
end;

procedure TForm1.ComPortRxChar(Sender: TObject; Count: Integer);
var
  Str: String;
begin
  ComPort.ReadStr(Str, Count);
  listbox1.Items.Add(Str);
end;


end.

---

Einstellungen von ComPort1:
Baudrate = br960
Buffer: InputSize = 1024 OutputSize = 1024
Connceted = False
DataBits = dbEight
DiscardNull = True
EventChar = #0
Events = alle true
ControlDTR = dtrEnable
ControlRTS = rtsEnable
DSRSensitivity = False
FlowControl = fcNone
OutCTSFlow = False
OutDSRFlow = False
TxContinueOnXoff = False
XoffChar = #19
XonChar = #17
XonXoffln = False
XonXoffOut = False
Parity:
Bits = prNone
Check = false
Replace = False
ReplaceChar = #0
Port = COM1
StopBits = sbOneStopBit
SyncMethod = smThreadSync
Tag = 0
Timeouts:
ReadInterval = -1
ReadTotalConstant = 0
ReadTotalMultiplier = 0
WriteTotalConstant = 1000
WriteTotalMultiplier = 100




Bascom Code:

Code:

---

Dim I As Byte

$crystal = 8000000                                       
$baud = 9600


Weiter:

I = 0
Do
  Incr I
  Waitms 500
  Print "HalloHallo" ; I;
Loop

End

---

Also für Baud = 19200 kommt bei mir nur Scheiß raus. Is glaub ich normal.

Zitat:

---

Also für Baud = 19200 kommt bei mir nur Scheiß raus. Is glaub ich normal.

---

Bei mir kommt bei Baud = 19200 aber doch genau das raus, was ich sende.
Hast du einen Quarz an deinem µC oder betreibst du den mit dem internen Oscilator? Mit letzterm kriege ich bei Baud = 19200 auch nur Schrott übertragen.

Ähm, naja, ich bin totaler Anfänger was das betrifft. Dh ich hab keine Ahnung. :-s

Ich hab das Fusebit A987 auf "1111:Ceramic resonator/Crystal, BOD enabled" eingestellt. Hat das was damit zu tun?


BTW: Es scheint kein Visual Basic Problem zu sein, da ich mit Delphi ja genau die selben Ergebnisse bekomme.

Öhm, hab' mir zwar nicht alles durchgelesen *schäm*, aber spontan würd mir einfallen, dass du bei deiner µC-Software - falls es Bascom ist - nach der Print-Anweisung noch ein Semikolon ";" dranhängst...

Gruß, Trabukh

@Trabukh:
Schau dir mal den letzten Bascom Code an den ich gepostet hab. Das mit dem Semikolon haben wir schon raus jetzt. Die Zeilenumbrüche sind weg.

Was jetzt noch stört, ist dass bei z.B.:
do
print "hallohallo";
wait 1
loop

in einer listbox das hier raus kommt:
hallohal
lo
hallohal
lo
hallohal
lo
usw...

Wei? niemand Rat?

Das Problem ist ja eigentlich nur, dass er einem Strings der länger ist als 8 zeichen zwei Strings draus macht. Ist das normal?

Zitat:

---

Das Problem ist ja eigentlich nur, dass er einem Strings der länger ist als 8 zeichen zwei Strings draus macht. Ist das normal?

---

Was heisst schon "normal". Mit dem Beispielcode den ich dir weiter oben gepostet habe, macht er bei mir jedenfalls auch bei Strings mit mehr Zeichen keinen Umbruch.

Hast du mal mit einem Terminal-Programm ausprobiert, ob der String schon zerstückelt von deinem µC ankommt, oder ob er erst in deinem VB, bzw. Delphi Programm zerhackt wird?

Der String wird definitiv erst im Programm zerhackt.

Ausgabe im Terminal:
hallohallo
hallohallo
hallohallo
hallohallo
usw

Ausgabe im Programm:
hallohal
lo
hallohal
lo
hallohal
lo

Um mal das Problem zu wechseln und ein bischen Abwechlung hier rein zu bringen: Warum zum Geier funktionert das hier schon wieder nicht:

Bascom-Code:

Code:

---

$regfile = "m32def.dat"
$baud = 9600
$crystal = 8000000

Dim Serial_in As Word

Mainloop:
Do
  Input Serial_in
  Waitms 100
  Print Serial_in;
  Waitms 100
Loop
Goto Mainloop


End

---

Delphi-Code:

Code:

---

procedure TForm1.Button1Click(Sender: TObject);
var
    send_str : String;
begin
    send_str := Edit1.text;
    ComPort.WriteStr(send_str);
end;

---

Was ich nach dem Write-Befehl über das Terminal emfange sind immer nur die ersten paar Stellen von dem was ich gesendet hab. Ist vielleicht der Typ Word nicht groß genug? Gibts was größeres? Und nachdem er die ersten paar Stellen über print rausgeschickt hat, geht garnix mehr. Ich muss das Programm im Controller neu starten, damit ich wieder einen String schicken kann. Is doch seltsam oder? Stimmt vielleicht mit dem Board was nicht?

mfg
jagdfalke

hi,

ich bin mir jetzt nicht sicher aber ich denke, dass des an dem "doppelgemoppel" liegt :) ...ich würd mal sagen ENTWEDER

Mainloop:

....
....

Goto Mainloop



ODER

Do

....
....

Loop

aber wie gesagt, ich bin mir nicht sicher und ich weiss auch nicht ob das das problem ist...

gruss hacker

Zitat:

---

ich bin mir jetzt nicht sicher aber ich denke, dass des an dem "doppelgemoppel" liegt

---

Glaube ich nicht.
Der Controller wird innerhalb der inneren do-loop Schleife seine Kreise ziehen. Dass da aussen nochmal eine Schleife drum ist, macht nicht viel Sinn, sollte aber eigentlich auch nicht schaden.

sehe ich auch so

@jagdfalke
hast du dir mal die Eigenschaften der verschiedenen Objekte (Textfelder, MSComm, usw.) die du in deinem Programm verwendest genau angesehen?

Vielleicht hast du da ja irgendwo die Feldlänge, Buffergrösse oder irgendwas ähnliches begrenzt.

Ich habe aus meinem Testcode mal eine exe compiliert. Kannst du dir ja HIER mal runterladen und ausprobieren. Bausrate ist 9600.

Beim Starten deiner .exe-Datei gibts nen Fehler: Invalid Portnumber. Mein COM-Port ist COM1.

Zitat:

---

Beim Starten deiner .exe-Datei gibts nen Fehler: Invalid Portnumber. Mein COM-Port ist COM1.

---

bekommst du nur eine Fehlermeldung, oder kannst du das Programm gar nicht starten? Eigentlich gibts in dem Programm extra einen Button mit dem du auf Com1 umstellen kannst, aber falls das Programm gar nicht startet, weil du keinen Com2 hast nutzt der Button wohl nix ;-)

Ich mach mal eine neue Version mit Com1.

@jagdfalke
HIER ist die .exe mit Com1 als Port.

Also: Deine .exe-Datei funktioniert. Liegt aber nicht daran, dass du irgendwas anders gemacht hast: Wenn ich alles in eine Memo-Box schreiben lasse:
memo1.text := memo1.text + Str;
dann funktionierts genauso wie mit deinem Program. Wenn ich aber
memo1.text := Str;
schreibe bekomme ich immer das, was er abschneidet.

Also nochmal verständlich:

Bascom-Code:

Code:

---

$crystal = 8000000                                          'Quarzfrequenz
$baud = 19200

Mainloop:
Print "hallohallo";
Wait 1
Goto Mainloop

end

---

Ausgabe, die immer in der Listbox kommt:

Zitat:

---

halloha
lo
halloha
lo
usw.

---

Ausgabe in Memo bei "memo1.text := memo1.text + Str;" :

Zitat:

---

hallohallohallohallohallohallohallohallo usw.

---

Ausgabe in Memo bei "memo1.text := Str;":

Zitat:

---

lo

---

Es kommt wirklich nur "lo" raus. Das heißt für mich, dass der String "hallohallo" wirklich in 2 Schritten übertragen wird: erst "halloha", dann "lo".

@recycle:
Schick mir doch mal dasselbe Program mit eine Listbox, also:
listbox1.additem Str
Mal schaun ob dann dasseble rauskommt wie bei mir

mfg jagdfalke

PS: Schaut doch mal in meine Galerie. Ich hab schonmal was gebaut. Ich finde es ist mir sehr gut gelungen.

@jagdfalke

Zitat:

---

Schick mir doch mal dasselbe Program mit eine Listbox, also:
listbox1.additem Str
Mal schaun ob dann dasseble rauskommt wie bei mir

---

Ich habs mal mit der Listbox ausprobiert. Du hast Recht, die Daten kommen bei mir auch in Blöcken zu 8 Zeichen an.

Da die Daten in einem normalen Terminal-Programm unzerstückelt ankommen, ist das entweder normal für eine serielle Übertragung, oder es liegt am mscomm Objekt.

Wenn du die Daten unbedingt in einer Listbox ausgeben willst, kannst du sie ja erst solange bis ein Zeilenumbruch kommt in einem String cachen und den dann in die Listboc einfügen.

merkwürdig, warum schaust du dir den output nicht einach an, die darstellung in den boxen ist nicht ascii. du kannst daran auch nichts machen, ausser den output selber zu formatieren. einen zeilenumbruch brauchst du dann aber immernoch.

Ok, das ist natürlich auch ne Möglichkeit. Am MSComm liegts nicht, da die COM-Port Komponente für Delphi genau gleich reagiert. Na wenigstens haben wir das jetzt geklärt. Kannst du dir mal das Input-Problem anschaun. Wieder gilt hier, dass VB und Delphi die gleichen Reaktionen hervorrufen. Es scheint sich aber eher um ein Bascom-Problem zu handeln, da es ja um den INPUT-Befehl geht.

mfg
jagdfalke

Zitat:

---

Am MSComm liegts nicht, da die COM-Port Komponente für Delphi genau gleich reagiert. Na wenigstens haben wir das jetzt geklärt.

---

OK, dann ist es vermutlich ganz normal, denn in einem Terminal-Programm kommen die Strings ja unzerstückelt an.

Zitat:

---

Kannst du dir mal das Input-Problem anschaun. Wieder gilt hier, dass VB und Delphi die gleichen Reaktionen hervorrufen. Es scheint sich aber eher um ein Bascom-Problem zu handeln, da es ja um den INPUT-Befehl geht.

---

In deinem Beispiel liest du den String mit Input ein und gibst ihn sofort mit Print wieder aus. Wie unterscheidest du denn da, ob der String schon beim Einlesen in Bascom oder erst nach dem Print beim Einlesen durch das mscomm-Objekt zerstückelt wird?


Ausserdem hast du Serial_in als Word definiert und der Datentyp Word ist eine Zahl zwischen 0 und 65535.

Ich hab geschrieben, dass es sich hier um ein anderes Problem handelt. Das zuerstückeln ist also völlig wurscht. Das Problem liegt darin, dass der Controller nach 3 empfangenen Strings keine weiteren mehr annimmt. Es sieht so aus, als ob er sich aufgehängt hat. Kannst ja bei dir mal ausprobieren. Das passiert aber wieder nur dann, wenn der String über VB bzw. Delphi geschickt wurde. Im Terminal kann ich so oft Zeichenketten schicken wie ich will und sie kommen immer wieder zurück. Ohne Probleme.

mfg
jagdfalke

Zitat:

---

Das Problem liegt darin, dass der Controller nach 3 empfangenen Strings keine weiteren mehr annimmt. Es sieht so aus, als ob er sich aufgehängt hat. Kannst ja bei dir mal ausprobieren. Das passiert aber wieder nur dann, wenn der String über VB bzw. Delphi geschickt wurde.

---

Ist bei mir ähnlich.
Ich habe Serial_in als String deklariert und dabei muss man in Bascom angeben, wieviel Zeichen der String hat.

Ich kann dann genau soviele Zeichen senden wie der String aufnehmen kann.
Ob ich diese Anzahl auf einmal sende oder auf X Sendungen aufteile ist aber egal. Wenn ich den String 200 Zeichen gross mache kann ich auch 20 mal 10 Zeichen senden.

Sieht mir danach aus, als würde der Input-Befehl alle neuen Zeichen hinten an den String anhängen, anstatt den alten Inhalt zu überschreiben.

Da es mit einem nomalen Terminal-Programm funktioniert, liegt das aber vermutlich auch nicht an Controller und Bascom Programm.


Vielleicht muss man bei dem mscomm Objekt noch manuell irgendein Zeichen mitsenden, dass der Gegenseite sagt, wo eine einzelne Sendung zu ende ist.