Hallo Leute,
Ich bin nahezu mit meinem Projekt fertig, wäre da nicht immer dieser
blöde Runtime Error in VB6. Ich habe mir einen digitalen Signalgenerator
gebastelt der nach dem DDS-Prinzip arbeitet und möchte ihn mit einem
.exe-Programm das ich in VB6 geschrieben hab über USB auf dem Laptop
ansteuern.
Auf dem Laptop ist ein Virtual Com Port Driver für das USB-Modul auf der
Platine installiert und die Verbindung ist in Ordnung. Vorher habe ich
das Senden von Daten über ein Testprogramm in VB getestet. Mit nur 1
Byte klappt das wunderbar, kommt alles schön und gut bei meinem Atmega32
an.
Nun zum Signalgenerator, wenn ich dem uC nur die Signalform mit meinem
Hauptprogramm übermittle, zeigt das Oszilloskop auch das eingestellte
Signal an, ob Sinus, Rechteck, Dreieck oder Sägezahn, alles in Ordnung.
Aber bei der Frequenzeinstellung bekomme ich fast jedesmal einen
"Runtime Error 13" in VB. Die Daten die für die Frequenz an den uC
gesendet werden müssen betragen 32 Bit, diese habe ich allerdings in 4 x
8 Bit aufgeteilt, schön von LSB zu MSB und übertrage diese inkl. der
Signalform als ASCII-Zeichen. Bei 10 kHz, 10001 Hz und 75 kHz bekomme
ich diesen Laufzeitfehler jedoch nicht, jedoch sind "kleine"
Frequenzabweichungen auf dem Oszillo zu sehen.
Das versteh ich nicht, dauernd dieser runtime error und dann bei nur 3
verschiedenen Frequenzen klappts. Wenn ich allerdings die 32 Bit nicht
in eine Hex-Zahl und dann in ASCII-Zeichen umwandle, sondern sofort in
einen String dann gibt es gar keinen runtime error mehr, jedoch ist die
Frequenz dann völlig falsch.
Die Hardware meiner Schaltung funktioniert, das Programm auf dem uC
auch.
Ich dachte es würde vlt am USB-Kabel liegen, das ist ungefähr 2m lang
und nicht abgeschirmt, so dass Störungen von umliegenden Netzteilen etc
einen Einfluss haben können.
Ansonsten, hier ist der VB-code:
Davon bin ich ja auch nicht fest ausgegangen. Und doch, Laufzeitfehler
können auch extern auftreten, jedenfalls so dass die Übertragung nicht
sauber stattfindet. Ein paar uS Zeitverschiebung wärend des Sendens
genügt schon. Das muss also nicht direkt am Programm liegen.
Ausserdem war das noch keine Antwort auf mein Problem..
(VB6 ist schon so lange her bei mir)
Run Time Error 13 sagt (glaube ich) "type mismatch", dass heisst, bei
irgendeiner Zuweisung stimmen die Datentypen nicht.
Ich vermute hier:
ADDS = Hex(ADD)
(Sagt dir nicht der Debugger wo genau der Fehle auftritt?). Kan die
Hex-Funktion 1234.567 in Hex umwandeln?
Und noch 2 Anmerkungen:
>Private Sub MSComm1_OnComm()> MSComm1.Settings = "9600,n,8,1">End Sub
Die Settings gehören nicht ins OnComm Ereignis, sondern irgendwo zum
Programmstart.
>MSComm1.CommPort = 8
...und das auch.
>MSComm1.PortOpen = True>MSComm1.Output = Chr$(s1) & Chr$(s2) & Chr$(s3) & Chr$(s4) & Chr$(FREQF)>MSComm1.PortOpen = False
Und ob der Port hier schon wieder geschlossen werden kann? Ist den immer
Sichergestellt, dass alles zu Sendende auch schon gesendet wurde?
Eigentlich öffnet/schliesst man den Port nicht ständig vor/nach dem
Senden.
###
ahnungslos wrote:
> (VB6 ist schon so lange her bei mir)>> Run Time Error 13 sagt (glaube ich) "type mismatch", dass heisst, bei> irgendeiner Zuweisung stimmen die Datentypen nicht.>> Ich vermute hier:>> ADDS = Hex(ADD)>> (Sagt dir nicht der Debugger wo genau der Fehle auftritt?). Kan die> Hex-Funktion 1234.567 in Hex umwandeln?
Nein sagt er nicht, einfach nur Type Mismatch und das wars. Beim
Umwandeln rundet er automatisch auf oder ab. Das hab ich mit nem
separaten Label getestet welches mir die Hex-Zahl anzeigt.
> Und noch 2 Anmerkungen:>>>Private Sub MSComm1_OnComm()>> MSComm1.Settings = "9600,n,8,1">>End Sub>> Die Settings gehören nicht ins OnComm Ereignis, sondern irgendwo zum> Programmstart.
Hat nichts an der Sache geändert :S
>>MSComm1.CommPort = 8> ...und das auch.
Geht nicht, wenn ich den Port öffne kommt eine Meldung "Invalid Port
Number". Muss also beim Öffnen des Ports geschehen.
>>MSComm1.PortOpen = True>>MSComm1.Output = Chr$(s1) & Chr$(s2) & Chr$(s3) & Chr$(s4) & Chr$(FREQF)>>MSComm1.PortOpen = False>> Und ob der Port hier schon wieder geschlossen werden kann? Ist den immer> Sichergestellt, dass alles zu Sendende auch schon gesendet wurde?> Eigentlich öffnet/schliesst man den Port nicht ständig vor/nach dem> Senden.
Ich habe jetzt 2 Command Buttons eingefügt, mit dem einen öffne, mit dem
anderen schliesse ich den Port. Doch wenn ich nach dem Öffnen auf "Send"
klicke kommt immer noch derselbe runtime Fehler.
Aber der Debugger muss dir eigentlich die Stelle zeigen (-> natürlich
nicht die EXE starten, sondern das Programm in der IDE laufen lassen).
Es wird dann direkt die Zeile markiert, an der der Fehler auftritt.
Da kannst du dein Programm ja auch step-by-step durchlaufen und siehst
dann den Fehler.
Und btw: Runtime-Errors sind immer Programmierfehler. Und zur
Fehlervermeidung würde ich keine implizite Typwandlung machen, sondern
die Wandlung immer explizit angeben.
Z. B.:
>ADDS = Hex(ADD)
ADDS = Str(Hex(ADD))
(Ich glaube Str() ist die Syntax). So kann mann immer sehen, was gemacht
wird.
Nun der Fehler liegt immer in dieser Zeile:
MSComm1.Output = Chr$(s1) & Chr$(s2) & Chr$(s3) & Chr$(s4) & Chr$(FREQF)
Habe die Zeichen auch einzeln schon mal ausgegeben:
MSComm1.Output = Chr$(s1)
MSComm1.Output = Chr$(s2)
.
.
.
Hilft auch nix. Aber ich möchte wissen was genau der Fehler ist, in
welcher Zeile er liegt ist ja schon gut aber noch keine Lösung wert.
>ADDS = Str(Hex(ADD))
Gibt er komischerweise auch einen runtime error an, obwohl ADDS dann ja
noch immer ein string ist. Mit CStr() funzt es auch nicht.
Dann gib' dir doch mal direkt vor der Zeile
>MSComm1.Output = Chr$(s1) & Chr$(s2) & Chr$(s3) & Chr$(s4) & Chr$(FREQF)
den Inhalt der Variablen (s1,s2,s3,s4,FREQF) per MsgBox aus um zu sehen,
was drinnen steht.
MsgBox("s1 = " & s1)
MsgBox("s2 = " & s2)
MsgBox("s3 = " & s3)
MsgBox("s4 = " & s4)
MsgBox("FREQF = " & FREQF)
MSComm1.Output = Chr$(s1) & Chr$(s2) & Chr$(s3) & Chr$(s4) & Chr$(FREQF)
(Ich hoffe, die Syntax für MsgBox stimmt so...)
A.
>MSComm1.Output = Chr$(s1) & Chr$(s2) & Chr$(s3) & Chr$(s4) & Chr$(FREQF)
Du möchtest doch die Zeichen aneinanderketten und nicht logisch
verknüpfen, oder? In Basic werden Zeichenketten mit "+" verbunden, das
könnte die Ursache für deine Fehlermeldung sein.
Frank
Frank Esselbach wrote:
>>MSComm1.Output = Chr$(s1) & Chr$(s2) & Chr$(s3) & Chr$(s4) & Chr$(FREQF)>>> Du möchtest doch die Zeichen aneinanderketten und nicht logisch> verknüpfen, oder? In Basic werden Zeichenketten mit "+" verbunden, das> könnte die Ursache für deine Fehlermeldung sein.>> Frank
Nein, mit dem "&" möchte ich die Zeichen nur hintereinander schicken,
nicht verketten.
@ ahnungslos (Gast) ich habe s1-s4 und FREQF per msgbox ausgegeben, kein
Problem. Z.B. bei 1500 Hz und Rechteck: s1 = F6, s2 = 28, s3 = 5C, s4 =
00 und FREQF = 01. So wie VB das auch übertragen soll, was es aber nicht
tut.
ADD = (FREQ * (2 ^ 32) * 15) / 16000000
In Long geht maximal 2^31 rein. Wieso rechnet man das nicht mit Doubles
und konvertiert das ganze dann mit Grenzwertbetrachtung nach Long?
Gast
> Nein, mit dem "&" möchte ich die Zeichen nur hintereinander schicken,> nicht verketten.
Probier' es bitte trotzdem mal: ersetze die "&" durch "+" und schreibe
hier, was passiert.
Frank
Frank Esselbach wrote:
>> Nein, mit dem "&" möchte ich die Zeichen nur hintereinander schicken,>> nicht verketten.>> Probier' es bitte trotzdem mal: ersetze die "&" durch "+" und schreibe> hier, was passiert.>> Frank
Funzt auch nicht. Danke trotzdem.
Gast wrote:
> ADD = (FREQ * (2 ^ 32) * 15) / 16000000>> In Long geht maximal 2^31 rein. Wieso rechnet man das nicht mit Doubles> und konvertiert das ganze dann mit Grenzwertbetrachtung nach Long?>> Gast
Dann frag ich mich wieso es bei 10000 Hz klappt und bei z.B. 1 Hz nicht.
Der Formel nach erhält man bei 10000 einen grösseren Wert als bei 1.
ich verwende das Comm-control normalerweise auf dieser Art:
Private Sub Form_Load()
With MSComm1
.CommPort = 8
.Settings = "9600,n,8,1"
.RThreshold = 1
.SThreshold = 1
.PortOpen = True
End With
End Sub
Private Sub Form_Unload(Cancel As Integer)
MSComm1.PortOpen = False
End Sub
versuch mal
sTest As String
sTest = Chr$(s1) & Chr$(s2) & Chr$(s3) & Chr$(s4) & Chr$(FREQF)
MsgBox (sTest)
MSComm1.Output = sTest
Und schreib mal das Ergebnis (inhalt von sTest), bei demes funktioniert
und eines, bei dem es nicht funktioniert.
A
ahnungslos wrote:
> versuch mal>> sTest As String>>>> sTest = Chr$(s1) & Chr$(s2) & Chr$(s3) & Chr$(s4) & Chr$(FREQF)> MsgBox (sTest)> MSComm1.Output = sTest>>> Und schreib mal das Ergebnis (inhalt von sTest), bei demes funktioniert> und eines, bei dem es nicht funktioniert.>> A
BBB und dann ein Quadrat zum Schluss bei dem wo es geht. (10000 Hz)
Type Mismatch kommt sofort bei dem wo es nicht funktioniert ohne msgbox.
Hallo,
meiner Meinung ist der Type Mismatch in den Chr() aufrufen mit einem
String, Chr() erwartet eine Zahl! Ein String muss zuerst in eine Zahl
gewandelt werden, was mit einem Hexsting nicht geht!
Gast
Na, da haben wir doch den Fehler:
War es nicht so, dass bei Chr$(x) das 'x' ein Integer ist (ASCCI-Wert)?
Chr$(33) ergibt "!"
Chr$(65) ergibt "A"
s1="65"
Chr$(s1) ergibt "A"
s1="A0"
Chr$(s1) ergibt "Runtime Error 13"
Gast wrote:
> is1=(ADD AND &H0FF)> is2=((ADD/&H100) AND &H0FF)> is3=((ADD/&H10000) AND &H0FF)> is4=((ADD/&H1000000) AND &H0FF)
Wow danke! Signalgenerator funzt jetzt zu 100%. Ohne eure Hilfe würde
ich noch Wochen daran fummeln ohne dass sich was tut. Leider sind meine
Kenntnisse in VB ziemlich eingeschränkt da ich mich mehr mit Elektronik
beschäftige, ehrlich darauf wär ich jetzt nicht gekommen. Danke
nochmals! :-)
mfg Max
Wie ich es verstehe, willst du einen String senden. s1-s4 sind aber
schon strings. Also:
MSComm1.Output = s1 & s2 & s3 & s4 & CStr(FREQF)
Aber was genau erwartet der Empfänger?
s1 = "65"
Soll jetzt "65" (00000110 00000101) , oder 65 (01000001) gesendet
werden?
Route_66 wrote:
> Aber immer erst auf den niedlichen USB-Kabeln rumhacken!
Dies war ja nicht mein fester Verdacht sondern nur eine Vermutung ;-)
Heutzutage muss man schon aufpassen mit was man arbeitet.
Naja, bei einem "run time error" das USB-Kabel zu verdächtigen wäre etwa
so, als ob man bei beim Erwischtwerden mit überhöhter Geschwindigkeit
dem Reifen die Schuld gibt... ;-)
Ein "run time error" ist quasi das zur Laufzeit, was beim Programmieren
der "syntax error" ist - und damit liegt die Schuld immer beim
Programmierer. Das kann allerdings auch der Programmierer einer
unsauberen programierten Komponente sein, die du verwendest.
A
