Guten Abend. Ich habe da ein komisches Problem beim Dateimport in Excel über VBA von einer Seriellen Schnittstelle (USB). Ich übertrage von einem ARDUINO MEGA über Serial3 bestimmte Werte über TTL-USB Wandler an einen USB-Port an einen PC 32-BIT, Windows 7, Excel 2013. Es sind nur kurze Sequenzen z.B. "W01:0","W01:1", SYS:1" etc. Dort lese ich die Daten über Excel mit einem VBA Makro von COM5 in eine Exceltabelle ein. Klappt soweit gut bis auf ein Problem. Das ist: Wenn ich die Exceldatei öffne und das Einlese-Makro starte, kann Excel (VBA) scheinbar die USB-Schnittstelle z.Z. COM5 nicht "öffnen", es werden keine Daten eingelesen, das Makro hängt sich auf und Excel stürzt ab (steht dann - Excel Fenster erste Zeile - keine Rückmeldung und das Fenster wird grau). Es kommt kein Datei oder Namensfehler, also ist COM5 ansprechbar. Das Makro hängt dann in der Input Anweisung fest, zeigt der Debugger. Mal die wichtigsten Codeteile Variabledeklaration ... Close #1 Open "COM5:9600,N,8,1" For Binary Access Read As #1 ' Open "COM5:9600,N,8,1" For INPUT As #1 ' da funktioniert gar nix, weder noch ... Do ... Egal welche der Inputvariante ich nehme ... => Input #1, Meldung oder => Line Input #1, Meldung oder ' einlesen der Daten solange kein ENTER Meldung = "" zeichen = "" While (zeichen <> Chr(13)) => zeichen = Input(1, #1) If (zeichen > Chr(31)) Then Meldung = Meldung + zeichen Wend ... Aufbereitung und abspeichern der Werte ... Loop Erst wenn ich die COM5 mit der ARDUNIO IDE und dem Seriellen Monitor "geöffnet" und einige Datensätze angeschaut habe, dann den Seriellen Monitor wieder schließe, jetzt die Exceldatei öffne, dann das Makro starte, => dann funktioniert das einlesen mit dem Makro aus der COM5 und die gesamte anschließende Datenverarbeitung. Hat jemand eine Idee woran das liegt, ich bin ratlos? Würde mir sehr helfen auch weil ich bei GOOGLE und co bisher nicht fündig geworden bin. Viele Grüße Fritz
Was haben diese Daten in Excel verloren? Die gehören da nicht hin.
IT-Abteilung schrieb: > Was haben diese Daten in Excel verloren? Die gehören da nicht hin. Warum nicht? Es kommt doch wohl auf die Daten an. Du weisst darüber nicht mehr als wir. Du erfrechst dich aber, zu entscheiden, dass sie nicht in Exel gehören würden. Das zeugt genau von Einem: du bist vollkommen inkompetent. Hast den Schuss nicht gehört. Hast keine Ahnung, was wirklich wichtig für so eine Entscheidung sein könnte. Fazit: bist ein Bläho.
Lass dir mal den Status der Steuerleitungen anzeigen.
Da ich das nur Hobbytechnisch mache weiß ich nicht wie. Kannst du mir sagen wie ich das unter VBA machen muss? Und für den Fall das diese inkorrekt stehen wie ich diese dann richtig setze? Gruss Fritz
Nein. VBA mache ich nicht sehr häufig. Aber es gab einige Programme, die unter Windows 7 noch mit der seriellen Schnittstelle liefen, unter Windows 10 (oder nach einem Update) nicht mehr. Eine Reduzierung auf 3 Leitungen (Rx, Tx, Gnd) hat da geholfen. Ist bei einer virtuellen Schnittstelle über USB etwas schwierig.
Könnte übrigens auch die Benamsung der Schnittstelle selbst sein, ich öffne COM Ports unter Windows immer als "\\.\COMx".
Jim M. schrieb: > Könnte übrigens auch die Benamsung der Schnittstelle selbst sein, ich > öffne COM Ports unter Windows immer als "\\.\COMx". Das macht erst ab x >= 10 Probleme
Da ist anfangs vermutlich der Hardware-Handshake aktiv, weswegen das Senden von Daten blockiert wird. Startest du vorher ein anderes Programm, das den Handshake deaktiviert, funktioniert das Ganze. Ich bin kein Windows- und erst recht kein VBA-Experte, aber du kannst mal versuchsweise dem "COM..."-String ein ",N" anhängen, das den Handshake deaktivieren sollte:
1 | Open "COM5:9600,N,8,1,N" For Binary Access Read As #1 |
Wenn das auch nicht funktioniert, kannst du die Schnittstelle auch mit entsprechenden Win32-Funktionen öffnen, so wie es wohl die meisten Programme tun, da das Öffnen mit Open und dem "COM..."-String schon immer (seit MS-DOS-Zeiten) etwas hakelig war. Das ist aber etwas komplizierter, aber im Netz findest du Beispiele dazu.
Hallo habe ich ausprobiert! Vorschlag 1: Open "\\.\COM5:9600,N,8,1" For Binary Access Read As #1 => Laufzeitfehler 53, Dateiname nicht gefunden Vorschlag 2: Open "COM5:9600,N,8,1,N" For Binary Access Read As #1 selbe Effekt wie bisher aber ohne Fehlermeldung! Dank bisher an alle die hier Ideen eingebracht haben! Ich habe jetzt gelesen das das so einfach wohl sowieso nicht geht. Mann muss über irgendwelche DLL da irgendwelche Zugriffe auf die PORTS freischalten usw. Wahrscheinlich macht der Seriell Monitor von der Arduino IDE das und ich habe bisher im Huckepack sozusagen dann diese Funktionalitäten nur nutzen können! Also Weitersuchen oder hat jemand ein funktionierendes Beispiel incl. aller Handlungschritte wenn dort zusätzliche DLL's installiert und angemeldet werden müssen. Bisher habe ich nur immer irgendwelche Teilfragmente gefunden die dann bei mir nicht liefen weil irgend etwas fehlte. Muss ich weiter suchen. Gruß Fritz
Hallo Dirkb2, eigentlich Nutze ich nur 2 Leitung. Arduino Serial-USB-Wandler PC Sender TX zu Rx TTL-USB-Wandler - steckt im USB-Anschluss des PC Sender GND zu GND TTL-USB-Wandler Sender Rx ist offen weil bisher ja keine Rückmeldung vom PC an den Sender erfolgt. Mehr ist da gar nicht verkabelt! Der Wandler ist ein CP2102 TTL zu USB Konverter HW-598. Der hat eingangseitig sowieso nur 5 Anschlüsse 1 x +5V 1 x GND 1 x Rx 1 x Tx 1 x 3,3V und auf der anderen Seite den USB-Stecker. Gruß Fritz
Ich vermute die initialisiert den Port nicht.
Hier mal ein Code mit VB 2010 der Funktioniert.
Der sollte in VBA fast das selbe sein. Kannst ihn ja mal testen.
Public Class hp
Dim S_Port As New IO.Ports.SerialPort ' das ini den Port
Sub einlesen
If S_Port.IsOpen Then ' schliest ein möglicherweise offnen Port
S_Port.Close()
End If
S_Port.PortName = "COM10"
S_Port.BaudRate = 9600
S_Port.Open()
lauf = true
do while lauf = true
S_Port.read(tx$)
if tx$ = "ende" then lauf = false' hier abbruchbedingung sonst
todesschleife
loop
S_Port.Close()
end sub
Fritz H. schrieb: > Ich habe jetzt gelesen das das so einfach wohl sowieso nicht geht. Mann > muss über irgendwelche DLL da irgendwelche Zugriffe auf die PORTS > freischalten usw. Unsinn. Unter VB reicht völlig. Imports System.IO Wenn du es mit VBA nicht hin bekommst machst du einfach folgendes. Sauge dir die VB-version runter bei MS. Dann das INTEROP Packet von Excel in dein Projekt einfügen. Imports Microsoft.Office.Interop.Excel.XlApplicationInternational am Anfang des Projekt Danach noch folgende Befehle in die lesende Sub : excel_pfad = hp_e_codierte_exceldatei_pfad.Text excel.Workbooks.Open(excel_pfad) ' das öffnet die Excel-Datei wo ein rein soll excel.visible = true ' dann hast du Excel in der Tastleiste. excel.Rows(zeile).cells(spalte).value = tx$ ' schreibt in die Excel Datei in die angebene Zelle. Ist nur eine Alternative Lösung. Ich mag kein VBA deshalb mach ich alles so. Das ist viel besser und flexibler. Einziger Nachtteil. Du darf NICHT während das Programm läuft in Excel eine Zelle anklicken. Das führt sonst zu sofortigen Absturz. Um das zu verhindern einfach excel.visible = false setzen, und am ende der Sub (oder mit einen Anzeige Routine und doevents im Programm) excel.visible = true setzen. Ich persönlich frage ein Checkbox-Teil ab nach seinen Status. Ach und nur so nebenbei. Du kannst JEDEN Excel-Befehl o. Eigenschaft über VB so steuern. Die befehle sind fast die selben, du musst sie nur an das EXCEL-Objekt (s.o.) übergeben. Wenn ich den VBA-Befehl nicht weiß, zeichne ich unter Excel ein Makro dafür auf, dann editiere ich das Makro und lese den Befehl aus, bzw. kopiere ihn nach VB. Ich benutze diese Technik allerdings meist um Excel-Daten in Datenbanken zu schreiben, also als Schnittstelle. Ihr würdet euch wundern welche Datenmengen manche Leute in Excel verarbeiten anstatt in einer Datenbank. Aber ich habe in der Firma auf diese Weise auch Daten aus einer AS-400 gelesen, mit VB vorbereitet und am Ende kam eine schöne Tabelle mit Diagramm aus Excel raus, Ohne das ich Excel auch nur angeklickt habe. ;)
Funktioniert so auch nicht, kommt gleich Fehler Option Explicit Public Class hp => erwatet Anweisungsende Dim S_Port As New IO.Ports.SerialPort ' das ini den Port ...
,,, Wenn du es mit VBA nicht hin bekommst machst du einfach folgendes. Sauge dir die VB-version runter bei MS ... Danke für den Vorschlag, aber ich will doch nur einige Daten über die USB-Schnittstelle in Excel einlesen ohne vorher immer irgendwelche Klimmzüge machen zu müssen. Die Weiterverarbeitung dieser Daten in Excel und die Visualisierung funktioniert doch schon alles. Meine VB-Kenntnisse sind = 0 und alles nochmal umbauen ... :-( ? Gruß Fritz
Fritz H. schrieb: > eigentlich Nutze ich nur 2 Leitung. Ach so, der PC sendet überhaupt nicht, sondern empfängt nur? Ok, dann kann das von mir oben erwähnte Handshake-Problem nicht die Ursache sein.
Fritz H. schrieb: > Public Class hp => erwatet Anweisungsende OK. Das ist VB. Die Zeile kannst du löschen. Es kommt nur auf den DIM-Befehl an. Der init die Serielle Schnittstelle.
Fritz H. schrieb: > Meine VB-Kenntnisse sind = 0 und alles nochmal umbauen ... :-( ? > Gruß Fritz Falsch. Deine VB Kenntnisse sind genau so gut/Schlecht wie deine VBA-Fähigkeiten. Weil das ist das selbe. Der einige Unterschied sind die intregierten Module der jeweiligen APP. was ich in meinen Beispiel mit INTEROP mache, machst du in VBA direkt. Der Vorteil von VB selbst ist, das es mächtiger ist, und 10000 x mehr Möglichkeiten bietet. Und man kann schönere Oberflächen bauen, als in VBA. VBA ist nur eine abspeckte Version von VB, oder anders gesagt eine total überdimensioniertes Makro-Sprache. Weshalb sie auch als Unsicher in Dateien (NICHT PROGRAMMEN) gilt. Wenn du die Sicherheitseinstellungen in Excel nicht verstellt hast, bekommst du kein Marko ans laufen was sich in einer nicht mit deiner Office-Version erstellten Datei befindet. MS ist da einfach wieder mal über das Ziel hinausgeschossen. Mit den Ergebnis das jedes Kiddy perfekte Viren coden kann die kaum ein Anti-Viren-Teil findet. Der berühmteste ist übrigens I-LOVE-YOU hast Millarden Euro an REALEN Schaden angerichtet. ;) Ergo hat MS die Blockade eingeführt und schiebe den Schwarzen-Peter den User zu. ;) Aber das nur so nebenbei.
Schlaumaier schrieb: > was ich in meinen Beispiel mit INTEROP mache, machst du in VBA direkt. > Der Vorteil von VB selbst ist, das es mächtiger ist, und 10000 x mehr > Möglichkeiten bietet. Nein, das ist Unsinn. Alles, was man mit VB.net machen kann, kann man auch mit VBA machen. Man muss es halt nur oft anders machen. Im Übrigen nähert sich beides immer weiter an. MS arbeitet daran, letztlich VBA vollständig durch VB.net zu ersetzen, ist aber noch nicht ganz so weit. Viel fehlt aber wohl nicht mehr. > Und man kann schönere Oberflächen bauen, als in VBA. Who cares? Bei VBA-Anwendungen geht es i.d.R. darum, die zusätzliche Funktionalität in der durch die Office-Anwendung vorgegebene Oberfläche zu integrieren. Nicht darum, irgendwas daran vorbei zu bauen. > VBA ist nur eine abspeckte Version von VB, oder anders gesagt eine total > überdimensioniertes Makro-Sprache. Unsinn. Du hast offensichtlich keine Ahnung. > Wenn du die Sicherheitseinstellungen in Excel nicht verstellt hast, > bekommst du kein Marko ans laufen was sich in einer nicht mit deiner > Office-Version erstellten Datei befindet. Unsinn. Aber klar: wenn man keine Ahnung hat, was man da tut, dann können solche "Beobachtungen" rauskommen...
Hallo an Alle,
ich finde es eigentlich schade das die Diskussion zu einem was ist
besser oder schlechter - VB oder VBA - entartet ist. Zur Lösung meines
Problems hat dies leider nicht beigetragen.
Aber egal, zwischenzeitlich habe ich die Lösung gefunden!
Wie bereits DirkB vermutete war die Leitung nicht richtig gesetzt.
Bevor ich die Exceldatei starte, setze ich jetzt mit
c:\windows\system32\mode com5: baud=9600 parity=n data=8 stop=1 to=off
xon=off dtr=on rts=on
meine USB-Schnittstelle.
Im Normalmodus ist dtr=off und rts=off.
Der serielle Monitor der Arduino-IDE hat wohl auch nur diese beiden
Parameter geändert.
Und es funktioniert!!!
Zwar verschluckt Excel das 1. Zeichen der Meldung - ist aber nicht
weiter schlimm. Ich setzte vor die Nutzdaten im Microcontroler einfach
noch ein Dummyzeichen und gut. Ich suche jetzt nicht weiter woran das
nun wieder liegt.
Zur Sicherheit habe ich am Ende der Schleife noch ein kleine Pause
eingefügt.
sub einlesen()
...
do
...
input #1, Meldung
...
Application.Wait (Now + 0.000001) '0.0001 = 10 s, 0,00001 1s,
0.000001 1/10
Loop
End Sub
Dank an alle für die Lösungshilfen.
Gruß
Fritz
c-hater schrieb: > nsinn. Aber klar: wenn man keine Ahnung hat, was man da tut, dann > können solche "Beobachtungen" rauskommen... Sicher hast du eine Erklärung dafür das ich bei JEDER Datei mit Makros eine Warnung bekomme und ich extra "Makros aktivieren" anklicken muss. c-hater schrieb: > Bei VBA-Anwendungen geht es i.d.R. darum, die zusätzliche > Funktionalität in der durch die Office-Anwendung vorgegebene Oberfläche > zu integrieren. VBA ist eine MAKRO-Sprache mit zu viel Funktionsumfang. Nicht mehr und auch nicht weniger. Davon abgesehen habe ich nur den TO eine Alternative Lösung angeboten, von der ich weiß das sie funktioniert weil ich sie selbst schon getestet habe. Das einzige was DU hier gesagt hast, ist die übliche Lästerei über mich und den TO.
Schlaumaier schrieb: > Sicher hast du eine Erklärung dafür das ich bei JEDER Datei mit Makros > eine Warnung bekomme und ich extra "Makros aktivieren" anklicken muss. Das liegt entweder daran, dass du zu blöd warst, deiner Office-Installation zu sagen, dass sie signierten Code ausführen darf, ohne rückzufragen oder aber daran, dass du zu blöd bist, deinen Code zu signieren (und dem Office zu ermöglichen, diese Signatur dann auch erfolgreich zu verifizieren). Ist alles kein Hexenwerk. Man muss halt nur wissen, wie's geht. Das kann man LERNEN.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.