Announcement: there is an English version of this forum on Hallo Community, ich bin auf Eure Hilfe angewiesen, da ich mich jetzt leider kurzfristig auf unbekanntes Terrain begeben muss. Ich würde gerne über Excel mit VBA Befehle an einen COM-Port senden. Mir fehlt aktuell der Syntax zu Initialisierung und Verwendung des COM-Ports unter Windows 10 / VBA 7.1, hier hoffe ich stark auf Eure Unterstützung und wäre für ein Beispielprogramm oder ähnliches dankbar. Ich habe bereits im Forum und bei anderen Anlaufstellen erfolglos recherchiert und ausprobiert. Dies mag auch daran liegen, dass dies für mich Neuland ist und ich falsch gesucht habe, dies bitte ich dann zu entschuldigen :). Warum all dies jetzt so plötzlich passiert ist ein Bug in einer Bediensoftwäre für eine kürzlich erworbene AC-Quelle, so dass ich diese aktuell nicht vollumfänglich vom Rechner aus steuern kann und der Hersteller selbst sich schwer mit einer Timeline zur Lösungsfindung tut. Da dachte ich mir, den Befehlssatz hast du ja, jetzt baust du dir eine einfache grafische Oberfläche in Excel + VBA (das kann ich wenigstens :) ) und sendest die Befehle direkt von hier aus... und daran scheitert es derzeit. Wenn Ihr andere Vorschläge für Programme oder Herangehensweisen zur Erzeugung einer einfachen grafischen Oberfläche, mit Einlese Funktion von *.txt daten o.ä. und COM-Portkommunikation habt (freeware), nehme ich diese auch gerne an :) Vielen Dank im voraus! Grüße Hanseat.
Beim Lesen hatte ich überlegt wie man mit einem 40-Tonner im Wohngebiet eine Pizza ausliefert. Vielleicht ist Excel einfach nur das falsche Tool
Guizmo schrieb: > Beim Lesen hatte ich überlegt wie man mit einem 40-Tonner im Wohngebiet > eine Pizza ausliefert. > > Vielleicht ist Excel einfach nur das falsche Tool Danke für den überaus hilfreichen Kommentar.... Wie ich oben schrieb, kann das durchaus sein, daher wäre ich dankbar für eine aufgezeigte Alternative aber nicht für einen sinnlosen Kommentar der weder mir noch einem anderen user weiterhilft....
Guizmo schrieb: > Vielleicht ist Excel einfach nur das falsche Tool Nein. VBA ist das falsche Tool. Er muss VB nehmen und die INTEROP. Hab ich hier im Forum ca. 3 x geschrieben. VBA ist eine Script/Makrosprache. VB ist eine Entwicklersprache. Die kann ALLES und auch (das will der TO) Excel steuern. Ich bin ziemlich sicher es ist das selbe Problem wie immer. Daten aus der serial-Schnittstelle sollen abgefragt, an Excel übergeben und dort analysiert werden. Das mache ich in VB in 50 echten Zeilen.
Hanseat schrieb: > Hallo Community, > > ich bin auf Eure Hilfe angewiesen, da ich mich jetzt leider kurzfristig > auf unbekanntes Terrain begeben muss. > > Ich würde gerne über Excel mit VBA Befehle an einen COM-Port senden. > Mir fehlt aktuell der Syntax zu Initialisierung und Verwendung des > COM-Ports unter Windows 10 / VBA 7.1, hier hoffe ich stark auf Eure > Unterstützung und wäre für ein Beispielprogramm oder ähnliches dankbar. > Auf die Schnelle gefunden (aber nicht selber ausprobiert): https://people.uwplatt.edu/~evensenh/Hal_Evensens_Homepage/VBA_Communication.html
Schlaumaier schrieb: > > Das mache ich in VB in 50 echten Zeilen. Schwafel nicht, werf die paar Zeilen einfach mal hier rein - dann haben alle was von. Oder war das mal wieder nur der Wind aus vollen Backen?
Schlaumaier schrieb: > Er muss VB nehmen und die INTEROP. Hab ich hier im Forum ca. 3 x > geschrieben. Hi Schlaumaier, danke für deinen Kommentar, ich mache mich mal auf die Suche nach deinen älteren Antworten. Ganz so ist es mit dem Daten empfangen jedoch nicht. Ich habe vor das externe Gerät zu steuern, ich will keine Daten auslesen sondern ausschließlich senden. natürlich geht das auch über ein eine einfaches Schnittstellenfenster wie z.B. realterm etc., aber da ich der AC-Quelle doch auch gewisse Verläufe und Verhalten in einem zeitlichen Ablauf vorgeben will, muss ich halt zuvor erzeigte Datensätze (*.txt) einlesen und diese dann entsprechend "abarbeiten", dass alles kann ich in VBA und damit wohl auch in VB? gut realisieren, mir fehlt nur der Ansatz zum Daten an die RS232 zu schicken.
https://www.excelforum.com/excel-programming-vba-macros/331696-access-rs232-port-with-vba.html#post837979 Ist schon von 2005 und ich weiß nicht, ob das aktuell auch noch so ist, sieht aber komplett aus. Damals hatte ich ein Buch zum Thema, da hat das genau so funktioniert.
Freeware Processing IDE https://processing.org Python https://www.python.org Non Freeware LabView https://www.ni.com/de-de/shop/labview.html Drei Umgebungen mit denen man das Problem Quick & Dirty lösen könnte...
Die oben genannte Variante mit mscomm32.ocx scheint bei win10 64 noch zu funktionieren: https://github.com/davidanger/MSCOMM32
MeierKurt schrieb: > Schwafel nicht, werf die paar Zeilen einfach mal hier rein - dann haben > alle was von. > Oder war das mal wieder nur der Wind aus vollen Backen? **************************************************** Imports System.IO Imports System.Data.OleDb Imports System Imports System.Reflection Imports System.Runtime.InteropServices Public Class hp Dim S_Port As New IO.Ports.SerialPort Public excel As New Microsoft.Office.Interop.Excel.Application Private Sub hp_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load hp_l_com_port.SelectedIndex = 10 End Sub Private Sub hp_b_emfangen_Click(sender As System.Object, e As System.EventArgs) Handles hp_b_empfangen.Click 'sendet Daten excel.Workbooks.Open(grunddaten.prg_pfad) If S_Port.IsOpen Then S_Port.Close() End If S_Port.PortName = "COM10" S_Port.BaudRate = 9600 S_Port.Open() For i = 1 to 10 Zeile = i S_Port.Read(tx$) excel.Rows(zeile).cells(1).value = tx$ next i S_Port.Close() excel.visible = true End Sub ********************************************** Öffnet den COM-Port liest 10 Zeilen , schreibt sie untereinander in Excel schliesst den Com-Port und Zeigt excel an. Der Rest ist feintunig. Die Anzahl der Zeilen kannst du selber zählen.
> über Excel mit VBA Befehle an einen COM-Port senden. Nachdem man in Excel Win32-Calls machen kann, dürften Initialisierung und Senden machbar sein. > Einlese Funktion Empfangen ist vermutlich schwierig (Stichworte: Blocking, Call-Backs). Mit Bordmitteln geht es per Powershell-Script; z.B:
1 | $myport= new-Object System.IO.Ports.SerialPort "COM1",300,"Even",7,2 |
2 | $myport.DtrEnable = $true |
3 | $myport.RTSEnable = $false |
4 | $myport.Open() |
5 | $myport.Write "abc" |
6 | Write-Host $myport.ReadExisting() |
7 | $myport.Close() |
Das kann man von der Kommandozeile aus testen und könnte man von Excel aus aufrufen.
Thomas R. schrieb: >> über Excel mit VBA Befehle an einen COM-Port senden. > > Nachdem man in Excel Win32-Calls machen kann, dürften Initialisierung > und Senden machbar sein. Natürlich. > Empfangen ist vermutlich schwierig (Stichworte: Blocking, Call-Backs). Auch Callbacks und Multithreading sind in VBA machbar. Empfehlen würde ich es allerdings nicht. Dazu muss man mehr über VBA lernen, als man je darüber wissen wollte... Da ist Schlaumeiers Ansatz eindeutig vorzuziehen. Oder halt die Verwendung von mscomm.ocx, was schon immer der einfachste Weg war und immer noch der einfachste Weg ist... Blöd halt bloß, das dieses Control nicht im Excel-Lieferumfang ist...
c-hater schrieb: > Blöd halt bloß, das dieses Control nicht im Excel-Lieferumfang ist... Beitrag "Re: RS232 / COM-Port über VBA (Excel) ansprechen"
Guten Morgen, wow, vielen Dank für die zahlreichen Vorschläge und die sachliche Diskussion! Dass ist in der kurzen Zeit mehr Feedback als ich erwartet habe :) Ich werde mich in den folgenden Tagen mal durch die Vorschläge arbeiten und Euch auf Stand halten.
Hi Pegel, danke für deine Antwort: pegel schrieb: > https://www.excelforum.com/excel-programming-vba-macros/331696-access-rs232-port-with-vba.html#post837979 > > Ist schon von 2005 und ich weiß nicht, ob das aktuell auch noch so ist, > sieht aber komplett aus. > > Damals hatte ich ein Buch zum Thema, da hat das genau so funktioniert. Ich habe mir das mal angeschaut und bin den entsprechenden Link's gefolgt, hänge jetzt aber bereits bei dem MSCOMM32. In reg. einbinden etc. läuft auch soweit ich das beurteilen kann. Jetzt kommt das Aber, in VBA müsste ich nach Anleitung unter https://www.excelforum.com/excel-programming-vba-macros/331696-access-rs232-port-with-vba.html#post837979 die "MSCOMM32" bzw. "Microsoft Communications Control 6.0" als zusätzliches Steuerelement finden, was ich jedoch nicht tue. Muss ich hier zuvor noch eine Parametrierung oder der gleichen vornehmen?
Bitte lies diesen Thread und die Diskussion 32 Bit / 64 Bit. Deine DLL ist eine 32 Bit DLL. Ich rate deshalb jeden zu VB anstellen VBA. Da ist es kein Problem 32-Bit Anwendungen zu entwickeln.
Hanseat schrieb: > die "MSCOMM32" bzw. "Microsoft Communications Control 6.0" als > zusätzliches Steuerelement finden, was ich jedoch nicht tue. Du kannst !! die DLL auch von Hand hinzufügen. Dann ist sie ebenfalls in der Liste. Was aber nicht bedeutet das sie auch funktioniert. Nur das MS bereit ist die DLL zu linken.
Schlaumaier schrieb: > Bitte lies diesen Thread und die Diskussion 32 Bit / 64 Bit. > > Deine DLL ist eine 32 Bit DLL. > > Ich rate deshalb jeden zu VB anstellen VBA. Da ist es kein Problem > 32-Bit Anwendungen zu entwickeln. Oh mann ich werde alt ;) Beitrag "Bitte helfen Sie mir '' Datei nicht gefunden Rsapi.dll ''" <- den Link natürlich.
Schlaumaier schrieb: > Du kannst !! die DLL auch von Hand hinzufügen. Dann ist sie ebenfalls in > der Liste. Was aber nicht bedeutet das sie auch funktioniert. Nur das > MS bereit ist die DLL zu linken. Nach dem ich jetzt so einiges probiert habe und auch den angehängten Beitrag gelesen habe, vermute ich, dass das Problem eine Inkompatibilität dank der von mir verwendeten 64bit-Version ist. Ich hatte die *.OCX Datei hinzugefügt, auch das registrieren hatte per CMD der Rückmeldung nach funktioniert, nur in VBA habe ich den entsprechenden Eintrag nicht finden können. Selbes habe ich auch noch mit "Scomm32" probiert. Hier habe ich alles händisch ausgeführt, die *.OCX dann händisch verwiesen, aber auch das hat nichts im Bezug auf die Steuerelemente geholfen. Will ich hier weitere hinzufügen, tauchen die notwendigen Einträge nicht auf, nur kann ich hier eben keine eigenständig hinzufügen, woraus ich schließe, dass VBA mit denen nichts anfangen kann (dank 32bit Version der OCX).
Hanseat schrieb: > nur kann ich hier eben keine > eigenständig hinzufügen, woraus ich schließe, dass VBA mit denen nichts > anfangen kann (dank 32bit Version der OCX). Ja das ist sehr wahrscheinlich. Die einfachste Lösung ist, auf VBA zu verzichten und VB zu nehmen. Ein grundsätzlichen Code dazu siehst du oben von mir.
Hallo Hanseat, hier ist mal eine Beispieldatei mit Win API zum ausprobieren. Noch nicht mit Win 10 getestet. Musst du ggf. für deine Zwecke anpassen bzw. ändern. Viel Erfolg
Dr Bunsenbrenner schrieb: > Non Freeware > > LabView > https://www.ni.com/de-de/shop/labview.html > > Drei Umgebungen mit denen man das Problem Quick & Dirty lösen könnte... F: Ich möchte 3 Eimer Sand von A nach B bringen. A: Nimm einen Bulldozer, damit geht das in 5 Minuten. Hanseat schrieb: > Ich würde gerne über Excel mit VBA Befehle an einen COM-Port senden. > Mir fehlt aktuell der Syntax zu Initialisierung und Verwendung des > COM-Ports unter Windows 10 / VBA 7.1, hier hoffe ich stark auf Eure > Unterstützung und wäre für ein Beispielprogramm oder ähnliches dankbar. Das geht ist aber alles andere als schnell. Beispiele sind ja schon gennant worden. Würde ich heute über eine standalone Software machen und die über Excel steuern.
Beitrag "Re: RS232 / COM-Port über VBA (Excel) ansprechen" Das fürchte ich auch. Ich konnte keinen Ersatz für Excel64 und die Serielle Schnittstelle finden. Schwache Leistung von M$.
Hier habe ich mal vor Jahren ein Beispiel angehängt, mit Excel und RS232 Port. Falls dir das hilft, ganz letzter Post. Beitrag "excel vba com port auslesen problem"
pegel schrieb: > Ich konnte keinen Ersatz für Excel64 und die Serielle Schnittstelle > finden. > Schwache Leistung von M$. Eigentlich NICHT. VBA ist eine Markosprache. Die ist dafür da das man die Befehle zusammen klickt (Nennen die Makroaufzeichnung). Und man kann sie editieren. Was sehr von Vorteil ist, wenn man die erste Zeile des Makros ändern muss, weil man das Makro für alle Zeilen nutzen will, nicht nur für die Startzeile der Aufzeichnung. Was ihr macht, ist eine TabellenKALKULATION in eine Protokollaufzeichnung mit Auswertung zu verwandeln. Kleiner Tipp dazu neben bei. Wer sich die Excel-Ansteuerung nicht traut, lässt die Software einfach eine TEXT-Datei schreiben mit einen Trennzeichen (Ich mag dazu das @). Nun diese Textdatei mit Excel öffnen und Excel sagen das das @ das Trennzeichen ist. Einzig Wichtig ist, das die Textdatei jede Zeile mit einen Return beendet. Fertig.
Schlaumaier schrieb: > Eigentlich NICHT. ..... So kompliziert habe ich gar nicht gedacht. Ich finde es nur unschön, dass eine Funktion bei Excel 32bit existiert, und bei der moderneren 64bit Version nicht mehr. Vielleicht habe ich sie auch nur übersehen und es geht jetzt sogar einfacher!? Habe aber kein Excel zum testen da, bin auf LibreOffice. Da müsste ich mich aber auch erst zum Thema einlesen.
pegel schrieb: > Habe aber kein Excel zum testen da, bin auf LibreOffice. > Da müsste ich mich aber auch erst zum Thema einlesen. Wie schon geschrieben. Lies die Werte mit VB ein, und dann kannst du sie auch nach Libre importieren.
Hanseat schrieb: > Ich habe vor das > externe Gerät zu steuern, ich will keine Daten auslesen sondern > ausschließlich senden. Die Aufgabe sieht anders aus....
pegel schrieb: > Die Aufgabe sieht anders aus.... Ok dann muss halt doch VB ran. Ich hoffe das die die Daten nicht mit Hektik senden willst. Weil das kann Excel nicht. Excel ist langsam. Aber ich weiß das Libre eine Datenbankanbindung hat. Also die Daten in eine DB schreiben und die via VB auslesen und senden. Geht locker um den Faktor 10 schneller.
Nachtrag :
S_Port.Read(tx$)
excel.Rows(zeile).cells(1).value = tx$
gegen
tx$ = excel.Rows(zeile).cells(1).value
S_Port.write(tx$)
im Code ändern.
Dann sendet er.
Hallo zusammen, noch mal ein großes DANKE an Euch, für die Unterstützung, ich hoffe es hilft auch anderen :) Ich für meinen Teil habe bezüglich Excel und VBA aufgegeben, ich habe die letzten 2 Tage damit verbracht Python zu lernen und siehe da, das Programm zur Steuerung der AC-Quelle erfüllt alle Funktionen die ich aktuell benötige, von Messwerte einholen, über eine GUI, Alle möglichen Arten von Funktionen generieren und an die Quelle übergeben, konnte den Test heute erfolgreich mit meinem eigentlichen HW-Leistungselektronik-Entwicklungsprojekt abschließen. Was jetzt noch fehlt ist eine Datenbank anlegen und Messwerte ablegen und alles etwas "schöner" zu programmieren, aber die Zeit lässt das Projekt aktuell leider nicht zu.
Hanseat schrieb: > Was jetzt noch fehlt ist eine Datenbank anlegen und Messwerte ablegen Geht mit Sqlite RatziFatzi, Excel kann Sqlite per ODBC.
Toby P. schrieb: > Hanseat schrieb: >> Was jetzt noch fehlt ist eine Datenbank anlegen und Messwerte ablegen > > > Geht mit Sqlite RatziFatzi, Excel kann Sqlite per ODBC. toller Vorschlag wo er doch gerade schrieb sich von Excel abgewandt und die Sache mit Python gelöst zu haben. Aber für Python gibts sicher auch ein passendes Modul. Sascha
Bei dieser Anfrage erinnerte ich mich an die frühere Bücherreihe vom Franzis-Verlag. Da gab es ein Buch: "Messen, Steuern und Regeln mit Word und Excel". Damals konnte man die Office-Progamme noch "vernüftig" bedienen. Nicht so wie heute mit dem Ribbon-Kachel-Dicker-Finger-Scheixx. H.-J. Berndt und B. Kainka hatten damals eine DLL geschrieben,die RSAPI.DLL, mit Hilfe derer man ganz einfach unter Excel Daten von der Seriellen Schnittstelle einlesen konnte. Wie auf den Seiten von Berndt aktuell zu lesen, scheint die DLL auch unter 64bit Systemen und aktuellem Excel/Word weiterhin zu funktionieren. Vielleicht ist das ja eine Alternative. https://www.b-kainka.de/msrwin.htm http://www.hjberndt.de/book/msrfaq.html#mso2010 Webseiten nach altem Stil. Man sollte den alten Silberrücken dafür einen Ordern verleihen, dass Sie ihre Webseiten noch online halten. Heute würde mal wohl "voll retro" dazu sagen... /edit:/ Mein Beitrag bezog sich auf die Eingangsfrage. Dass der TO auf Phyton umgeschwenkt ist, habe ich überlesen. Aber das Problem mit Phyton zu erledigen, ist ganz sicher der bessere Weg gewesen.
:
Bearbeitet durch User
Ludwig K. schrieb: > Dass der TO auf Phyton umgeschwenkt ist, habe ich überlesen. > Aber das Problem mit Phyton zu erledigen, ist ganz sicher der bessere > Weg gewesen. Nicht wirklich. Damit hat er sich von den quasi unbegrenzten Möglichkeiten der Office-Libs weitestgehend abgekoppelt. Und das nur, um ein kleines, dummes Detailproblem zu lösen... Jedem, der denken kann, ist klar: Das kann zwar eine Lösung für dieses kleine Detailproblem sein, aber es ist sicher keine gute und zukunftsfähige Lösung... Überhaupt: schon die Wahl einer Sprache als Kriterium... Die Sprache selber sollte völlig Wurscht sein. Relevant ist sie nur insofern, als dass es Compiler/Runtimes für die Spache gibt, die den ganzen existierenden Binary-Kram mir möglichst geringer Hürde benutzen können. Die Frage ist also im Kern: kann Python in vollem Umfang das per COM-Komponenten bereitgestellte Featureset des MS-Office nutzen? Und: wie gut ist die Unterstützung dafür, genau das zu tun? Und ich lehne mich wohl nicht zu weit aus dem Fenster, um erklären zu können: Das ist Scheiße, in jeder Beziehung. Theoretisch machbar, praktisch aber völlig unbrauchbar. Ganz sicher jedenfalls für Leute, die so wenig wissen, was sie tun wie der TO...
Ludwig K. schrieb: > Wie auf den Seiten von Berndt aktuell zu lesen, scheint die DLL auch > unter 64bit Systemen und aktuellem Excel/Word weiterhin zu > funktionieren. Lt. ähnlichen (fast gleichalten) Threads hier, funktioniert sie NICHT. Jedenfalls haben diese User sie nicht ans laufen bekommen. Sorry.
c-hater schrieb: > Nicht wirklich. Damit hat er sich von den quasi unbegrenzten > Möglichkeiten der Office-Libs weitestgehend abgekoppelt. Und das nur, um > ein kleines, dummes Detailproblem zu lösen... Ja und nein. Eine Tabellenkalkulation zu einen Alleskönner zu vergewaltigen ist abartig. Ich bin ein klarer Vertreter der Profis. Eine Software macht EINE Sache und die Richtig. Für alles andere soll man eine Programmiersprache nutzen die "Übergreifende Komponenten" nutzt. Diese wäre MS-VC o. MS-VB. Mit diesen Programmiersprachen ERFASST man die Daten mit einen Extra-Programm und gibt sie zu Analyse an einen Profi (Excel) weiter. Und nur mal so nebenbei. Der Grund für die ganzen Office-Viren sind genau diese "Schnittstellen". Eine Makrosprache im "Sandkasten-Mode" wäre nämlich sicher, und ich müsste nicht bei jeder nicht bestätigen Excel-Datei Panikschieben das ein pöses Makro mir mein Rechner killt. Ich habe bis heute noch nicht verstanden wieso ein Makro Dateioperationen durchführen darf. Denkt mal drüber nach.
Sascha W. schrieb: > toller Vorschlag wo er doch gerade schrieb sich von Excel abgewandt und > die Sache mit Python gelöst zu haben. Das war auch mein Vorschlag. . Lesen/schreiben geht gleichzeitig Python und Excel sind unabhängig voneinander. Excel z.B. sieht neue Datensätze erst nach Transaktionsende. > Aber für Python gibts sicher auch ein passendes Modul. z.B. SQlite ;-) Python provides two popular interfaces for working with SQLite database library: PySQLite and APSW. Each interface targets a set of different needs. https://www.sqlitetutorial.net/sqlite-python/ Python <--> SQlite <--> ODBC <--> Excel
c-hater schrieb: > Nicht wirklich. Damit hat er sich von den quasi unbegrenzten > Möglichkeiten der Office-Libs weitestgehend abgekoppelt. Und das nur, um > ein kleines, dummes Detailproblem zu lösen... Das "Detailproblem" beinhaltet auch die Datenhaltung. SQlite kann Terabytes, Excel ... . Nach meiner Erfahrung sind Excel I/Os auf Schnittstellen sehr instabil und auch langsam. Je mehr Daten desto langsamer. Das Problem tritt bei SQlite (als Beispiel für eine Datenbank) nicht auf. ODBC Abfragen laufen in Excel dann sehr schnell.
Toby P. schrieb: > Je mehr Daten desto langsamer. Das gilt auch ohne Schnittstellen. Ich habe eine Batch-Datei auf meinen Desktop verlinkt. Mit folgenden Befehl (nur einen). taskkill /F /IM excel.exe /T Ratet mal warum. ;)
Manchmal hilft ja lesen... ;-) "Die RSAPI ist eine 32-Bit-DLL und funktioniert unter 64-Bit-Windows, wenn Office in einer 32-Bit-Version zum Einsatz kommt. In dieser Kombination konnten keinerlei neuen Problme unter Win7/8/8.1/10 festgstellt werden. Es ist nicht beabsichtigt eine reine 64-Bit-DLL zu erstellen, so dass es erforderlich sein kann, zu einer 32-Bit-Word/Excel-Version auf dem Messrechner zu wechseln."
:
Bearbeitet durch User
c-hater schrieb: > Nicht wirklich. Damit hat er sich von den quasi unbegrenzten > Möglichkeiten der Office-Libs weitestgehend abgekoppelt. Und das nur, um > ein kleines, dummes Detailproblem zu lösen... ... der Kommentar macht in meinem vorab skizzierten Fall nicht im entferntesten Ansatz Sinn, es ist einfach Besserwisserei. Danke für nichts! Hättest du meinen Beitrag aufmerksam und vollumfänglich gelesen, wüsstest du, dass es mir nicht darum geht ein Tool zu bauen, mit dem ich 30 Jahre glücklich werde oder wer weiß was erreichen will. Mir ging es um eine schnelle und effektive Lösung um meine AC-Quelle im Entwicklungslabor steuern zu können und ggf. auch Daten wegzuschreiben, da die aktuell bereitgestellte SW des Herstellers nicht tut was sie soll (Es also langfristig eine Lösung gibt). All das habe ich erfolgreich umgesetzt. Sicher könnte ich mich wochenlang hinsetzen und irgendwas "geiles" zusammenschreiben... aber das lässt weder mein Arbeitgeber, noch mein Projektzeitplan zu... manchmal darf es auch einfach "quick and dirty" sein.
DJ schrieb: > QUICK and dirty eher dirty ??? Thomas R. schrieb: > $myport= new-Object System.IO.Ports.SerialPort "COM1",300,"Even",7,2 > $myport.DtrEnable = $true > $myport.RTSEnable = $false > $myport.Open() > $myport.Write "abc" > Write-Host $myport.ReadExisting() > $myport.Close() Unerwartetes Token??
Hallo, im Anhang mal ein kleines lauffähiges Programm für die serielle Schnittstelle unter VBA. Die Version 2015 ist im Netzt frei verfügbar und läuft problemlos unter WinXP und Win7. Heißt jetzt Visual Studio! Der Quelltext ist im Programm enthalten. Mit einem etwas erweiterten Programm lese ich Daten mit VBA von einem ATMega aus und schreibe diese in eine Excel-Tabelle. Aber in dem Excel-Forum gibt es auch genügend Hinweise. Viel Spass Jürgen
VBs (funktioniert auch unter VBA) Einfach einen StreamObjekt auf einen COM-Port. Der Code ist ein Auszug, Quelle am Ende. Ungetestet. Lesen nach textfile
1 | Const ForReading = 1 |
2 | Const ForWriting = 2 |
3 | |
4 | Set fso = CreateObject("Scripting.FileSystemObject") |
5 | Set com = fso.OpenTextFile("COM6:9600,N,8,1", ForReading) |
6 | |
7 | Set objFSO = CreateObject("Scripting.FileSystemObject") |
8 | Set objFile = objFSO.OpenTextFile("C:\results.txt", ForWriting, True) |
9 | |
10 | MsgBox("Start to read data from COM") |
11 | |
12 | Do While com.AtEndOfStream <> True |
13 | s = com.ReadLine |
14 | objFile.WriteLine(s) |
15 | WScript.Sleep(200) |
16 | Loop
|
17 | |
18 | objFile.Close |
19 | com.Close() |
Schreiben aus Textfile
1 | Const ForReading = 1 |
2 | Const ForWriting = 2 |
3 | |
4 | Set fso = CreateObject("Scripting.FileSystemObject") |
5 | Set com = fso.OpenTextFile("COM7:9600,N,8,1", ForWriting) |
6 | |
7 | Set objFSO = CreateObject("Scripting.FileSystemObject") |
8 | Set objFile = objFSO.OpenTextFile("C:\docs\quotes.txt", ForReading) |
9 | |
10 | MsgBox("Ready to write file content to COM") |
11 | |
12 | Do While objFile.AtEndOfStream <> True |
13 | strChars = objFile.Read(10) |
14 | com.Write(strChars) |
15 | WScript.Sleep(200) |
16 | Loop
|
17 | |
18 | objFile.Close |
19 | com.Close() |
20 | |
21 | MsgBox("Finished writing to COM") |
*Quelle:* https://timewitharduino.blogspot.com/2009/05/getting-arduino-to-write-to-or-read.html?m=1
:
Bearbeitet durch User
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.