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.
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.
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:
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...
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.
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:> 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.
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.
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.
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.htmhttp://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.
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."
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.
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
