|
Anzeige
|
VB - msComm.ocx Bringt Fehler - Objekt erforderlichHallo Forengemeinde, möchte per VBA / mscomm32.ocx auf die RS232 zugreifen. Leider kommt hier bei meinem Minimal-Programm der Fehler "Objekt erforderlich" Es fehlt anscheinend das Setting zu: MSComm1. Und da weiß ich nicht, was da fehlt. Recherche habe ich unter mehreren VBA-Foren gemacht. Codes sind identisch. Im Objektkatalog ist es vorhanden. mein Code:
Danke vorab für Tips. grüße Tom Control registriert (regsrv32) und lizenziert? Das Teil will einen Lizenzschlüssel in der Registry, entsprechende Keys sind glücklicherweise im Internet leicht auffindbar. Solang du nur bei dir privat damit rummachst, wird da auch kein Hahn danach krähen. Die MsComm-Dll habe ich selber leider nicht. Es sieht so aus, als hättest Du das Objekt MsComm1 nicht deklariert bzw erzeugt. In meinem uralten Office 2000 gibt es im VBA-Editor (ALT F11) den Menüeintrag Extras mit der Auswahlmöglichkeit "Verweise". Da muss das Control vorhanden sein und das Häkchen zur Aktivierung gesetzt. In allen Beispielen, die ich bisher gesehen habe, bestand das Objekt aus einem Formular, das MsComm-Eigenschaften hatte, wie z.B. hier: https://www.ontrak.net/visual.htm Du siehst das an dem Bild, das unterhalb des Texts [... The MSComm properties allow the setting of communication parameters including port selection and port enabling functions. ...] steht. https://www.tek-tips.com/viewthread.cfm?qid=585370 Wenn man das Objekt nicht über VBA-Code zugänglich machen kann, müsstest Du Unter Office 2000 mit dem Menüeintrag "Einfügen", dann "Objekt" eine neue Instanz dieses Objekts erzeugen. Ich weiß nicht, wo sich das im aktuellen Excel-Menüs versteckt.
Das Objekt halt, steht doch ausdrücklich und sogar auf deutsch da.
Im Katalog stehen nur die COM-Klassen, die man (evtl.) instanziieren könnte. Du musst das Teil auf die Form oder das Tabellenblatt oder was auch immer ziehen. Erst dadurch entsteht eine Instanz, also das benutzbare Objekt.
Das habe ich mir angeschaut. Soweit komme ich aer nicht. Ich kann unter Visual Studio 6, das ich hier habe, das Telefon nirgends finden. in Access2000 / VB habe ich dieses gefunden. Verweis ist erstellt, mit MScomm32.ocx
Das finde ich eben nicht. Bitte erkläre mir dass.
Angehängte Dateien:
Hallo Thomas S.,
Du sprachst in Deinem Auftaktbeitrag von VBA ("Visual Studio for Applications"). Das ist ein abgespecktes VB, von dem ich ausgehe, dass Du es unter Microsoft Excel nutzt. Bitte stelle klar, wo Du "das Control" nutzen willst.
Gast
#7712129
Hast Du unter Projekt -> Komponenten -> Microsoft Comm 6.0 (SP6) die MSComm32.OCX zum Projekt hinzugefuegt? Dann kannst Du ein Objekt hinzufuegen. Es kann auch sein, dass Du mindestens die Professional-Version installiert haben solltest (Gedaechtnis ist etwas fuzzy, ist 25 Jahre her. MS hatte damals die "Business"-Funktionen nur gegen mehr Muenzen freigeschaltet. Aber, dass ist alle Fuzzy).
Mal auf Icon mit "OLE" klicken. Geht eine Liste der verfügbaren COM-Objekte auf. Eins davon müsste irgendwie nach MSCOMM aussehen. Ich kann mich leider nicht mehr erinnern, unter welchem Namen das genau auftaucht. Übrigens sieht sein Screenshot nicht wirklich nach Access2000-VBA aus. Das sieht eher nach VB5 oder VB6 aus.
Nein ich habe hier Visual Studio 6 Prof. Und möchte damit auf die Serielle Schnittstelle zugreifen.
Das geht nicht. Da kommt die Fehlermeldung : Name steht in Konflikt mit vorhandenem Modul, Projekt oder vorhandener Objektbibliothek. Die MSComm.Lib steht im Objektkatalog drin. Und darin sind die Funktionen für die Serielle.
Dach't ich's doch. Also hast du schonmal Müll erzählt. Es geht offensichtlich überhaupt nicht um VBA, sondern um VB. Falls du es nicht weißt: Das ist ein erheblicher Unterschied.
Ist also schon eingebunden (was bei einer standardmäßigen VB6-Installation ja auch der Normalfall wäre). Also: ist bloß noch nicht für dein Projekt instanziiert.
Nochmal zum Nachbeten: Da steht drinne, was die Klasse kann. Damit du diese Sachen verwenden kannst, musst du die Klasse instanziieren, also ein Objekt erzeugen.
Okay, danke für die Darstellung.
Bitte erkläre nun, wie das nun ansprechen kann. Zwischenzeitlich war ich in Access, und dort in VBA. Von dort aus konnte ich, nachdem das Telefon im Formular war, und ich noch etwas, wie den Namen, MSComm1 hier eingefügt hatte, die Serielle ansprechen. War meine PCMCIA Karte micht drin, hat VBA gemeckert, war sie gesteckt, ging die Routine ohne meckern durch. Aber nochmal. Ich bin hiermit nicht so routiniert, bitte um Erklärung, wie ich dies instanzieren kann, oder eben auch das Telefon auf das Formular bekomme. DANKE Hallo Thomas S.,
unter Excel 2000 musste ich im VBA-Editor (ALT F11) auf Menüleiste/Extras/Zusätzliche Steuerelemente gehen und dann aus der Liste aller verfügbarer Steuerelemente das MSComm-OCX auswählen. Dann erschien in der Steuerelemente-Toolbox ein Telefonsymbol. Dieses habe ich per "Drag-n-Drop" in das Formularfenster gezogen. Wenn ich das Telefonsymbol anklicke, erscheint im Eigenschaftenfenster der Name dieses MSComm-Objektes und seine Eigenschaften. "Visual Studio 6 Prof." ist eine Entwicklungsumgebung mit mehreren Sprachen. Du solltest vielleicht mal explizit sagen, welche Sprache Du benutzt. Ist es Visual Basic, dann solltest Du analog zur Vorgehensweise in VBA für Excel im VB-Editor das MSComm-Objekt auswählen, so dass sein Symbol in der Steuerelemente-Toolbox erscheint. Dann solltest Du es analog zur Vorgehensweise oben in Dein Benutzerformular "User form" ziehen können. Tust Du das nicht hilft der kopierte Code von ganz oben nicht weiter, weil keine Instanz ("Exemplar") Deines MSComm-Objektes vorhanden ist. Ich kann Dir leider nicht sagen, ob es möglich ist, auch ganz ohne "User form" dieses Objekt anzulegen.
Dort versuche ich es unter Visual Basic 6.0 Das Telefonsymbol schaffe ich ja unter VBA in Access zu installieren. Aber eben nicht in Basic unter dem Studio. Da benötige ich Hilfe. Habe das aber onen schon geschrieben. Ein Screenshoot ist oben in meinen Posts auch bereit sichtbar. Hallo Thomas S.,
was ist das Ergebnis? Ich habe Dir auch erklärt, wo Du suchen könntest. Ich hätte erwartest, dass Du jetzt berichtest, wo Du gesucht hast und was das Ergebnis war. Deine Bitte um Hilfe funktioniert nicht - ich habe kein VB6. Du musst jetzt selber suchen gehen.
Wenn Du das OLE links, unter Allgemein meinst? - Da geht dann ein Fenster auf, worin ich Adobe, oder sonstwas als OlE auf dem Formular plazieren könnte. Aber nicht das Telefon. Ich schrieb oben die Fehlermeldung. Hänge diese hier als Screenshoot dran.
Angehängte Dateien:
Es sieht so aus, als hättest Du das OCX durch Nachinstallation jetzt zweimal im System. Mach mal die beiden Häkchen weg, wann verschwindet die Fehlermeldung? Suche dann auf dem Reiter "Designer" und "einfügbare Objekte" nach dem Symbol. Falls nicht vorhanden, weitersuchen wie oben bei mir beschrieben.
Gast
#7712556
Comm Control <> Common Control! Was fuer ein Betruebssystem benutzt Du? Ich habe ein alten WindowsXP-Laptop, Windows XP mit ServicePack 2. Die IDE laesst sich nicht mehr unter Windows7 oder spaeter installieren. Noch ein kleiner Hinweis: Visual Studio 6 laeuft dann, und nur dann stabil, wenn Du Visual Studio 6 Service Pack 6(!) benutzt. Dein SP3 ist, in a Nutshell, schlecht.
Gast
#7712622
Ich habe noch mal meine Virtuelle Maschine gestartet (Windows XP SP 3, 2GB RAM, emulierter serieller Port, Visual Studio 6 (German) SP6, \Windows\system32\mscomm32.OXC ist vom 16-JUN-2010, Version 6.01.9816, 119616Bytes gross, kommt alles aus Visual Studio 6 SP6): Funktioniert wie geplant: Ich kann "Das Telefon" anklickern, in ein Form packen und habe dann das automatische generierte MSComm1-Objekt (auf- und zumachen geht, mehr kann ich nicht, dass Ding virtuell). Wenn Du jetzt das erste Mal mit Visual Studio arbeitest: Das Drag & Drop ist anderser: Du Clickst auf (z.b. command-Button) (Das Icon sinkt ein, es sieht "gedrueckt" aus). Du musst dann zu einem Form mausen und ein Recheck mit der Maus markieren: Dann bekommst Du ein Button in der gewuenschten Groesse. Solange Du kein Rechteck gewaehlt hast, bekommst Du das ausgegraute "No". Aber richtig Stabil laeuft das alles ab Service Pack 6.
Zugegeben. Meine Version ist älter. Ca. 98. Version:6.00.8169 vom 24. Juni 1998, Geht das nun trotzdem, zum laufen zu bringen?
Warum um alles in der Welt will man damit im Jahr 2024 noch etwas anfangen? Hallo Thomas S., mangels qualifizierter Rückmeldungen von Dir kann ich Dir nicht mehr weiterhelfen. Zwei Leute stellen Dir Fragen, die Du einfach ignorierst. Kauf Dir einfach die Adontec-Supercom-Bibliothek für schlappe €260. Viel Erfolg!
Gast
#7712980
Warum willst Du nicht updaten? Falls ich mich richtig erinnere war Visual Studio 6 SP3 richtig schlecht. Ich weiss nicht, ob Visual Studio 6 Service Pack 6 (German) noch frei verfuegbar ist (falls nicht, Muenzeinwurf bei MS hilft). Gruesse
A: Ich habe Feddback gegeben. Ivh habe gestern um 20:02 geschrieben. Euer Feddback kam um Thomas S. schrieb im Beitrag #7712863:
Darauf hin kam : 21:43 ein Post und um 21:48 ein Post Dann war nacht, und heute liege ich krank / flach - okay
Ich möchte nur ein paar kleine Sachen per RS232 erledigen, und da würde es mir reichen.
Ist dass die 'professionelle' Antwort in einem Forum? NEIN
Wo erkenne ich die SP-Version? - Unter Info sehe ich da nix. SP6, aber englisch habe ich hier als 7z. Gäbe es auch eine deutsche Version? Hallo Thomas S.,
Zu meinem Beitrag vom 1.8.2024 22:17 aber nicht. Was ich von Dir erwartet habe: Eine Antwort auf meine Frage und eine Ergebnismeldung zu meinen Suchvorschlägen.
Aber nicht zu meinem Beitrag.
Auf jeden Fall. Stocher' mal schön weiter unsystematisch im Nebel herum und stelle immer wieder neue Fragen und verprelle die, die Dir helfen wollen. Meine Kaufempfehlung ist passgenau zu Deinem Verhalten. Man kann Dir so nicht helfen. Deine unstrukturierte Vorgehensweise verhindert Dein und mein Erfolgsgefühl.
Das kann man aber auch auf andere Art und Weise anstellen. Dafür braucht man keinen über ein Vierteljahrhundert alten Compiler und den dazugehörenden OCX-/DLL-Krampf. Echt nicht. https://www.freebasic.net/wiki/KeyPgOpenCom Auf Deutsch gibts das auch: https://www.freebasic-portal.de/befehlsreferenz/open-com-235.html
Gast
#7713440
Frage nicht beantwortet. Betruebssystem, SP-Level?
? -> Info -> Microsoft Visual Basic 6.0 (SP6) Ich klinke mich jetzt aus. Kennst Du das Idom "like nailing jelly to a tree"?
Das hatte ich gesucht, aber wo sollte es noch sein? Da sind keine Häkelchen mehr. Habe 3 Screenshoots angefügt. In Verweise sind nur die oberen 4 angehakelt. Der Rest der Liste ist ohne. Auch an der zu erwartenden Stelle von MScomm32.ocx ist nichts. Dies musste ich erst per Suche hinzufügen, Aber dann kommt in Komponenten eben, dass es 2 mal da wäre.
Ich versuche hier wirklich die Teile zu liefern, um zur Lösung zu kommen. Kann sein, dass Du hier mehr drauf hast, aber deshalb gibt es das Forum, und deshalb frage ich hier.
Angehängte Dateien:
Ich habs gefunden. Jabadu. Folgendes war In meinem bereits bestehenden Minimal Progrämmchen ließ sich das nicht installieren, Inizieren. Habe nun ein neues leeres Projekt eröffnet. Und dort gleich unter 'Komponenten' das Microsoft Comm Control 6.0 angehakelt. Dann war das Telefon nun in der Galerie. Kannst Du mir bitte erklären, was in den anderen Projekten dann 'schräg' war, dass es nicht ging.
Angehängte Dateien:
Ich habe hier gar nichts "mehr drauf" und muss Dich daher fragen, an bestimmten Stellen zu gucken! Ich habe Dir am 1.8.2023 um 21:10 detailliert beschreiben, wie ich das MSComm-OCX unter Excel lauffähig gemacht habe, damit Du analog in Deiner VB6-Umgebung nachsuchst. Das habe ich Dir aber nicht explizit aufgegeben sondern erwartet. Du hast am 31.7.2024 ein Bild des Form-Editor aus VB6/Visual Basic gezeigt. Dort steht auch ein Menüeintrag "Extras". Hier hättest Du nach Lektüre meines Beitrags nachsuchen sollen - habe ich aber nicht gesagt. Ich vermute, dass VB6 ohne aktivierte Verweise nicht auskommt.
Wo ist Deine Rückmeldung zum Thema Nachinstallation? Auch "ich weiß nicht, ob" hätte ich akzeptiert. Such das vermaledei
Wo ist die Antwort auf meine Frage? Beide Häkchen löschen, melden, bei welchem Häkchensetzen der Fehler auftritt! Die Common-Dialogue-OCX brauchst Du für serielle Kommunikation nicht. Thomas W. hat Dich übrigens jetzt zum zweiten Mal gefragt, welches Betriebssystem Du nutzt. :( Au weia! Such Deine MSComm32.OCX auf Deinen Laufwerken. Ist die bei verschiedenen Softwareprodukten (in verschiedenen Ordnern vorhanden)?
Ich habe es doch nun gefunden.
Wusste nicht dass die von Relevanz ist. Ich bin hier auf XP unterwegs. Kann aber beim Booten auswählen : XP/ Win7 / Suse Linux
Findet sich im Windowsverzeichniss unter System32 Danke für Deine Mühe. Möchte Dich bestimmt nicht verärgern. Thomas, wenn Du mich schon nicht verärgern willst, dann tue mir einen Gefallen und beschreibe bitte nun final nachvollziehbar, wie Du das Problem gelöst hast, insbesondere ob und was Du tun musstest um das MsCOMM32-Symbol zur Anzeige zu bringen, damit Du es im zweiten Schritt in eine "Form" einbinden konntest. Zum Thema der Ansteuerung der seriellen Schnittstelle gibt es viele Beiträge in diesem Forum. Das mutmaßliche Alleinstellungsmerkmal der MSComm32.ocx ist, dass Du im Gegensatz zu anderen Lösungen kein "busy waiting" in Deiner Anwendung verursachen musst, um eingehenden Verkehr auf der Schnittstelle abzufangen. Harald K., danke für Deine Hinweise auf Freebasic! Unter VBA in Excel 2000 unter WinXP SP3 habe ich eine fast gleichlautende Syntax einmal ausprobiert. Die dabei enstehende Verbindung war aber nicht stabil, wenn ich die Daten eingelesen habe, per INPUT # oder GET#-Befehl.
Wenn Du mein Posting von 22:13 Uhr gelesen hättest, dann hättest Du gewust, wie ich es bewerkstelligt hätte, Hallo Thomas S., wir haben uns überschnitten, Deinen Beitrag habe ich deswegen nicht gesehen - sonst hätte ich ja nicht jetzt noch mal nachfragen müssen. Alles ist geklärt.
Keine Ahnung! Das musst Du herausfinden.
Ich hab' schon mal ein gelbes Buch gesehen, dessen Inhalt mir nicht gefallen hat. Also vermeide ich konsequenterweise alle gelben Bücher, denn das wird ja nicht von ungefähr gelb sein. -- Du verquirlst hier Dinge, die überhaupt nichts miteinander zu tun haben. Einerseits ist VBA nicht Visual Basic 6.0, andererseits ist FreeBasic etwas komplett anderes, das vollkommen anders funktioniert. Aus einer "Syntax" eines Systems darauf zu schließen, daß die eines vollkommen anderen Systems "nicht stabil" sein könnte, ist so wie mein Buchfarbenvergleich. Warum man heutzutage noch XP nutzt, und warum man einen über 25 Jahre alten Compiler nutzen will, kann ich mir nur mit Masochismus erklären.
Lebenslauf-Optimierung: Leute die das mit den aktuellen Hype-Programmiersprachen in 15 Minuten, KI-unterstützt, fertigcoden gibt es wie Sand am Meer. Jemand der sich da eine Woche Full-Time reinkniet, um es mit Ach und Krach sowie Foren-Hilfe, auf einer prähistorischen Plattform gerade so hinzukriegen ist ein Unikat. I mean: Banken suchen verzweifelt Cobol-Programmierer, und zahlen denen fette Gehälter. VisualBasic 6.0 ist genauso veraltet, müsste am Arbeitsmarkt also genauso gefragt sein, oder?
Hallo miteinander, Dass VisualBasic 6.0 veraltet ist, mag sein. Mir würde es für das bisschen immer noch reichen. Ich bin kein Profi-Proggi, aber ich baue mir das, was ich gerade so brauche. Ich bin mal mit C unterwegs, mal mit VBA unter Access und hier will ich was unter VB machen, da das Erstellen der Formulare hier soweit entfällt, nur code hinterlegen. Ich bin nicht drauf aus immer am Stand zu sein, Wenn es läuft, - never touch a running System. Und was schon mal gar nicht mag, sind die 365er Geschichten. Ein NoGo. Ich habe hier so nebenbei noch Atari MegaST2 mit SCSI-HDD, 'Mehrere Memotech MTX 512, Ein ZX81 (mit selbstgebauten 16KB, womit ich meine Buchhaltung mache. - smile.
Ich bin dran gescheitert, dass VB dieses OCX nicht haben wollte, und bislang nicht wusste an welcher 'versteckten' Schrauben man drehen muss, um dieses Telefon und damit die Com-Funktionalität zu bekommen. Habe in den 90er Jahren, wo das Internet so begann, Projekte unter Tools gebaut, die heute keiner mehr kennt, und auch welche, die nur für unsere Web-Firma damals konstruiert wurde. Es gab damals kein PHP, HTML5, CSS, und Consorten. Auch war ich lange Zeit dann unter Authorware Attain und Datenbankanknüpfung (DataGrip) unterwegs. So dumm bin ich nicht, nur liebe ich es mit der Umgebung zu arbeiten, die ich kenne. Die Welt will ich nicht mehr neu erschaffen, nachdem was heutzutage passiert, schaffen das nicht mal mehr die besten Gurus. Es endet in absehbarer Zeit eh da, was uns Wall-E zeigte. Ich hoffe, dass es die nächsten 50 Jahre noch so hält, wie gerad so ist. Aber 100 Jahre wird fraglich, wenn alle nicht dran arbeiten, es zu erhalten. Das ist der Punkt. Dieses hier ist ein Forum, wo man sich unter Gleichgesinnten austauschen kann, und sollte. Es ist keine Verkaufsplattform. Nachtrag: Was schafft Ihr denn bitte mit der KI??? - Nur Unbehagen. Wollt Ihr euch in 5-10 Jahren von Maschinen kommandieren lassen? Ich nicht - Die erste Maschine, die mir irgendetwas befiehlt, was mir gegen den Strich geht, hat die Axt im Kreuz. Grüße Thomas
Ich habe keine Hype-Programmiersprache als Alternative vorgeschlagen. Sondern nur ein anderes Basic.
Wofür könnte das "Free" in "FreeBasic" stehen?
Was hat ein anderes Basic als VB mit "KI" zu tun? Serielle Schnittstellen waren mit VB schon immer ein Krampf im Arsch, einfach, weil man dafür so ein OCX benötigte, das man auch immer irgendwie umständlich installieren musste - und, wie es sich zeigt, auch nicht so ohne weiteres mit VB selbst verwendet werden kann. Sich aus dieser Mühsal zu befreien und einfach ein anderes Basic zu verwenden, das a) noch gepflegt wird, b) kostenfrei verfügbar ist und c) sogar einem den Wechsel zu anderen Betriebssystemen ermöglicht (Linux), sollte doch eigentlich befreiend sein.
Das Argument könnte mich überzeugen. Sehe ich mir mal an. Ich habe dieses eben da, und wollte ohne TramTram zum Ziel kommen. Nun ist mir mit dieser Erklärung klar, dass VB evtl. nicht ganz der richtige Weg wäre. Aber nur um ein paar Bytes rüber zu schieben, dachte ich nicht an Strömungserzeugung.
Das stimmt so schlicht nicht. Selbst mit diesen inzwischen völlig veralteten Basic-Versionen war es durchaus möglich, das ganz normale Win32-API dafür zu verwenden, ganz sicher jedenfalls war dies mit VB6 möglich, das habe ich damals(tm) nämlich selber getan. Das war zwar nicht ganz einfach und ziemlich viel Schreibarbeit, aber durchaus machbar. Heute gibt es aber keinen Grund mehr, dies zu tun. Es gibt seit endlos langer Zeit VB.net (was inzwischen nach MS' Willen wieder nur VB heißen soll). Damit ist das alles eigentlich ganz einfach. Aber klar: Es gibt Leute, die kommen selbst damit nicht klar.
Nur ist VB.Net was völlig anderes als VB. Selbst die Profis haben damals rebeliert und wollten bei VB6 bleiben. Ich zähle mich bestimmt nicht zu den Profs. Und mein Geld verdiene ich woanders. Aber mich interssiert es einfach, und habs halt da. Und für das bisschen was ich produziere, reicht mir dies einfach. Punkt. Mal bin ich auf C unterwegs, mal eben mit VBA, und hier unter VB. Habe es oben geschrieben, war auch mit ganz firmenspezifischer Software unterwegs und habe im Team größere Software-Projekte erstellt. Jedem seins.
Das ist jetzt aber über ein Vierteljahrhundert her.
Das ist wahr. Nämlich: eine gut durchdachte, moderne Sprache. Nunja, anfangs gab es zur Unterstützung der Ewiggestrigen sogar noch einen Haufen Kombatibilitätskram. Zumindest Teile davon verfolgen uns sogar noch heute.
Das waren keine Profis, sondern Vertreter der "das haben wir doch immer schon so gemacht"-Fraktion. Die gibt es bei jeder Änderung von egal was.
Nunja, ein aktuelle VB ist auch nur einen kleinen kostenlosen Download entfernt. Und hätte dir z.B. den ganze Ärger mit diesem unsäglichen OCX erspart (welches es übrigens eigentlich nur gibt, weil die Realisierung von Callbacks aus dem Win32-API unter VB6 nur so überaus kitzlig umzusetzen war).
Und was spricht nun konkret gegen VB (in der modernen Inkarnation)? Da hast du alles, was du auch in VB6 hattest. Nur besser und einfacher. Aber halt an einigen Stellen auch etwas anders.
Danke Dir für Deine Ausführung. Ich werds mal überschlafen. Der Hintergrund ist folgender: Ich habe eine Isel-CNC (116). Diese ist bereits äußerst betagt. Das Programm zu dieser was mal dabei war ist nicht mehr existent. Auch über Isel bekomme ich das nicht mehr. Der andere Weg wäre, die Steuerkarte rauszuwerfen, und wie im anderen Forumm drüben auf Mach3 oder LinuxCNC, oder ... umzustricken. Dazu habe ich im Moment aber keine Lust. Ich habe mir nun soweit bislang beholfen, dass ich die CNC mit einen Terminal- Client (DockLight) angesteuert habe. Dazu habe ich ALLE Kommandos per Scriptzeilen angelegt, und diese dann jeweils gestartet. Klappte wunderbar soweit. Hat mir alles gefräst, was ich wollte, außer natürlich 3D. Nur ... der Maschiene fehlt die Intelligenz. Wenn ich nun falsche Parameter eingegen habe, ist diese halt dann über den zulässigen Bereich gefahren. Passierte mir hin und wieder , weil ich vergessen hatte den virtuellen Nullpunkt zuz setzen. Dann wusste die CNC halt nicht wo sie ist. Merkte ich aber immer beim Starten. Deshalb wollte ich nun eine einfache Oberfläche bauen, wo ich die Maschine steuern kann, und andererseits das Programm Fehler abfängt, um die CNC nicht zu zerstören. Dann der nächste Schritt würde sein, Zeichnungen per Corel Draw zu erstellen, und per DXF-Export an mein Programm weiterreichen. Es gibt fertige Sachen, klar. Aber wir sind hier in einem Forum, wo gebastelt wird, und dann ist das doch eine schöne Sache. Dass ich niemals an LinuxCNC rankomme klar, will ich auch nicht.
Dagegen spricht ja nichts. Nur muss man das nicht mit VB6 machen, da gibt es doch viele andere Möglichkeiten. Und wenn's Geld kosten darf, gibt es auch weitere Basic-Varianten: PureBasic https://www.purebasic.com/german/ xojo (ehemals RealBasic) https://www.xojo.com/ (Es gab auch mal PowerBasic, das aber wurde Anfang des Jahres vom Hersteller getötet https://web.archive.org/web/20231221060419/http://www.powerbasic.com/) Suche dir doch eine Sprache, die das (COM-Schnittstelle) von Haus aus kann und wo keine Verweise oder Abhängigkeiten für ein Modul bzw. Library oder sonst was benötigt werden. Wie Harald schon erwähnt hat, reicht da auch PureBasic oder auch mein Favorit XProfan (www.Profan.de) für kleine Sachen. Profan 10 als ältere Version gibt es auch kostenlos. Da braucht es auch keine große Installation. Und für ein paar Buttons und ein Editfeld braucht es auch nicht unbedingt einen Visual-Designer. Bis du bei den großen Bolliden ersten Erfolg mit der Einbindung der COM verbuchen kannst, hast du dich anderswo auch schon etwas eingearbeitet. Hallo Heinz B.,
Der Zugriff auf die COM-Schnittstelle funktioniert schon in Excel 2000 auch ohne externe Module.
Im Prinzip: ja. Aber asynchron aber nur mit recht erheblichen Anforderungen an die Qualität des Programierers. Das Problem ist es, die Callbacks des asynchronen Win32-API wieder "sauber" in die VB (oder auch: VBA-) Umgebung zu bekommen. Das ist leider alles andere als trivial. Weil das halt so kompliziert ist und eine serielle Schnittstalle sich eigentlich nur im asynchronen Betrieb wirklich sinnvoll verwenden läßt, hat MS halt lieber dieses MSCOMM.OCX geschaffen, was den ganzen Sackstand außerhalb der VB/VBA-Umgebung abhandelt.
Welche Callbacks? Aus VBA ruft man die API-Funktionen auf. Bitte erkläre mir, wo Callbacks auftreten, das verstehe ich nicht. Problematisch wird das erst, wenn die Schnittstelle gepollt werden muß, um keine Daten zu verlieren. Da kommt man um einen Thread meist nicht herum. Wenn er aber nur ein paar Konfigurationsdaten schicken bzw. empfangen will und die CNC antwortet entsprechend, sehe ich da kein Problem. Er hat ja schon geschrieben, daß er ein paar Buttons erstellen will, um mit diesen halt die Kommandos entsprechend senden will. Das geht auch mit einem kleinen BASIC, das Befehle zum Öffnen, Konfigurieren, Schreiben, Lesen und Schließen der Schnittstelle beherrscht. Nötigenfalls muß man nach dem Senden 200 - 300 ms warten und dann erst den Empfangspuffer auslesen. Das kommt dann auf die CNC selber an. Durch Ausprobieren kommt man da auch an eine gewisse ASynchronität heran. Sowas ähnliches hatte ich auch schon mit XProfan und einer 4-fach Relaiskarte vom großen C erfolgreich gemacht. Manche ziehen halt gerne den großen Werkstattwagen heraus, auch wenn im Vorraus bekannt ist, daß nur ein 10er Ring und einer 10er Maulschlüssel gebraucht wird. Hallo Heinz B.,
genauso ist es! Wenn es keine Hochfrequenzdaten sind, erzeugt die zyklisch Abfrage der Schnittstelle bzw. des Puffers auch kein "busy waiting" mit 100% Prozessorlast.
OMG. Zentral für das asynchrones File-API allgemein: BOOL ReadFile( [in] HANDLE hFile, [out] LPVOID lpBuffer, [in] DWORD nNumberOfBytesToRead, [out, optional] LPDWORD lpNumberOfBytesRead, [in, out, optional] LPOVERLAPPED lpOverlapped ); Man beachte hier den Verweis auf eine OVERLAPPED-Struktur. Da steht der Rest drinne, der für asynchrone Filezugriffe erforderlich ist. U.a. halt auch die Adresse des Callbacks, den das OS aufruft, wenn die angeforderte Aktion abgeschlossen oder (asynchron) gescheitert ist. Bezüglich der seriallen Schnittstellen kommt dazu aber noch was, was sich mit den diversen sonstigen Signalen der Schnittstelle asynchron auseinander setzt, die nicht direkt zum Filetransfer gehören: BOOL WaitCommEvent( [in] HANDLE hFile, [out] LPDWORD lpEvtMask, [in] LPOVERLAPPED lpOverlapped ); Auch hier wieder der Verweis auf die Overlapped-Struktur, die dann die Adresse des Callbacks enthält.
Wenn man es zyklisch haben will : Fast jede BASIC Sprache kennt auch einen Windows-Timer. Ab 300 ms aufwärts habe ich da gute Erfahrungen gemacht. Da friert auch die GUI so schnell nicht ein.
Dieses Stoppelhops-Polling ist das Mittel der Armen. Klar, es hält wenigstens die Anwendung benutzbar, erzeugt aber nach wie vor völlig unnütze CPU-Last. Bloß halt weniger. Also es freut mich, dass die Community hier doch mit eifrig dran ist. Sag ich erst mal danke und klasse. Die Isel CNC ist, wie ich bemerke nicht wirklich schnell im komzunizieren. Also auch kein Problem mit irgendwelchen Timings. Wenn ich einen Out-Port ansteuere, dauert das fast ne Sekunde, bis der Port sein Bitbimsel in der Isel ändert. Bin da grad dabei das Input, wie Output zur Isel zu verstehen. Was in VB z.B. nicht geht ist Bitmanipulation. Wenn ich im Port 1 bit 2 eine/aus schalten will, ohne die anderen zu verändern. Habe da aber was gefunden, da bin ich grad dran. Oder ich geh her, und addiere in Abhängigkeit, ob Checked oder nicht einfach 1, 2, 4, 8, 16, 32, 64 und 128. Die Summe übertrage ich dann zur Isel. Damit ist der Port entsprechend gesetzt. Wollte auch mal ein Lebenszeichen von mir hier zeigen.
Wen willst du hier verarschen? VB kennt dieselben Möglichkeiten zur Bitmanipulation wie jede andere ernstzunehmende Programmiersprache auch. Im Gengensatz zu solchen Klartext-Verschlüsselungs-Sprachen wie etwa C/C++ muß man die Operatoren dazu nicht mal erst aus irgendwelchen Sprach-Dokus extrahieren. Nö, man kann sie einfach im (englischen) Klartext hinschreiben. Das galt für die ollen VB-Inkarnationen und gilt auch noch für die aktuellen. Eines muß man sich immer vor Augen halten : Windows ist bis heute nicht multitasking - fähig. Es vergibt daher solche Zeitscheiben. Bloß unser träges, menschlische Auge erfaßt das nicht. Und die neueren Prozessoren tragen da auch etwas bei.
Die soll ja auch was anderes tun, als dir nur zuzuhören. Entweder springt die zyklisch, wenn sie eine Teilaufgabe fertig hat, in eine Lauscherstellung oder wird evtl. auch von einem Interrupt benachrichtigt. Außerdem muß das ja auch durch ein Kabel und 2 Ports. Da ist die Treiberschicht von der COM noch nicht berücksichtigt. Also nach dem Motto : wenns klingelt, machst du auch nicht innerhalb einer Sekunde die Tür auf. Aber um das mit den Interrupts zu verstehen, sollte man aus der guten alten MS-DOS - Zeit Erfahrung haben. Da wurde in ASM ein Buchtsabe in ein bestimmtes Register kopiert und ein INT 21 H (Bildschirm-Interrupt) erzeugt, der den Buchtstaben in den Bildschirmspeicher schrieb.
Wie kommst Du auf diese bizarre Idee? Und ob es das ist. Präemptiv seit 1993, kooperativ auch in den 16-Bit-Versionen seit Urschleim. Was für eine Definition von "Multitasking" siehst Du nicht erfüllt?
... hilft Dein Beispiel nicht, weil ein Softwareinterrupt nur der Aufruf einer BIOS- (oder Betriebssystem-) Funktion ist, aber nichts mit einem von Hardware (wie einer UART) ausgelösten Interrupt zu tun hat.
So ein Bullshit. Jeder normale Mensch hält gerade das Konzept der Vergabe von Zeitscheiben für den primären Angelpunkt einer (präemptiven) Multitasking-Struktur. Macht nicht nur Windows so, sondern ausnahmslos ALLE heute noch üblichen OS.
Ja, vor allem dadurch, dass sie über mehrere Kerne verfügen, deren Anwesenheit überhaupt erst mal die Grundvoraussetzung dafür ist, irgendwas tatsächlich parallel zu bearbeiten. Und mit mehreren Kernen kann Windows seit bald drei Jahrzehnten umgehen...
Auch mit Interrupts kann man mit nur einem einzelnen Kern nichts wirklich parallel bearbeiten. Solange die IRQ-Routine ausgeführt wird, ruht der Code in main() und macht garnix. Hallo Ob S.,
das ändert nichts daran, dass mein VBA-Code keine Callbacks enthält, sagt Dir ein "armer Stoppelhops-Poller"! :) Callback heißt, dass dem Betriebssystem eine VBA-Routine übergeben wird und das Betriebssystem die VBA-Routine aufruft. Callbacks gibt es offensichtlich nur innerhalb des Betriebssystems, ich muss auf keine Aufrufe von VBA-Funktionen oder -prozeduren durch das Betriebssystem antworten.
Bei mir wird alle 2 Sekunden ein Wert abgefragt. Dafür gibt es eine Timer-Funktion, busy waiting ist nicht erforderlich. Leider hat der VBA-Timer anscheinend nur Sekundenauflösung. Dannach heißt es >=80 ms Warten auf das Ergebnis. Das realisiere ich mit busy waiting in einer Schleife, die aber nach jeder Abfrage des Tick-Timers die Kontrolle an das Betriebssystem zurückgibt. Ja, das erzeugt Zusatzlast, die ich noch nicht gemessen habe, weil ich keine Bremswirkung gespürt habe. Technisch ist die Umsetzung wie MSComm32-OCX sicherlich die solideste Lösung. Mein Code läuft aber immer, egal ob das MSComm32-OCX installiert ist oder nicht. Ich brauche keinen Installer dafür zu schreiben, und muss auch nicht aus dem Code heraus abfragen, ob das OCX erfolgreich installiert wurde oder ist und auch keine Verweise mehr in VBA setzen. Ich brauche auch keine Admin-Rechte zur Installation des OCX. Ich brauche kein VB6 zu kaufen oder ominöse Netz-Downloads mit Seriennummerfunden in meinem System zu integrieren. Wie immer stellt sich die Frage nach dem besten Werkzeug für ein Problem. Und wenn ich nicht zufrieden bin, dann werde ich sicherlich die dicke Berta in Form von MSComm32 zum Einsatz bringen! :)
Schau' Dir mal im Visual-Basic-Sprachverzeichnis die Operatoren an: AND, OR, XOR, NOT. Damit kommst Du einfacher zum Ziel!
Multitasking auf einem Prozessor erfordert immer Zeitscheibenbetrieb, wenn nicht durch andere Methoden wie Hyperthreading Parallelbetrieb möglich gemacht wird. Der Task Manager zeigt dir ganz viele parallel laufende Tasks unter Windows, auch auf einem Ein-Prozessor-System. Die spannende Frage in der heutigen Hardware-Welt lautet nur noch, ob eine rechenintensive Anwendung Multitasking unterstützt.
Nein ich möchte hier niemanden verarschen. Habe ich so in einen VB Forum gefunden. Link:https://www.vbarchiv.net/tipps/tipp_1276-abfragen-setzen-und-loeschen-von-bits.html VB verfügt über bitweise arbeitende Operatoren (AND, EQV, IMP, OR). In Kombination mit dem NOT-Operator lassen sich die Bitmuster von zwei Variablen auf alle denkbaren Arten kombinieren. (Der XOR-Operator entspricht der Negation der EQV-Verknüpfung.) Was es in VB aber nicht gibt, sind Funktionen, durch die man direkt einzelne Bits in einer Variable abfragen, setzen oder löschen kann. Zum letzten Absatz. Genau das wollte ich erreichen. und dann hier diese Erklärung. Ich habe dies nun folgendermaßen gelöst. Es ist hier nur Port 1 - Bit1 und Port 2 - Bit 2 und die ausführende Routine gezeigt. Aufruf:
Die Portsteuer-routine:
Weiß nicht, ob man das 'eleganter' lösen kann? - So funktioniert es.
Wenn Du viele Ports hast, dann kannst Du den Code massiv eindampfen. Die ganzen Abfragen Deines Port-Arrays (die Du auch durch eine Schleife hättest ersetzen können) um das Portstatus-Byte zu konfigurieren, entfallen. Speichere den Portstatus pro Port in einem Byte: Global: Dim portA as byte Dim portB as byte Private Sub Check10_Click()
If Check10.Value = vbChecked Then
portA=bitSet(portA,2) Public function bitSet(portStatus as byte, bit as byte) as byte bitset= portStatus or 2^bit end sub Public function bitCleaer(portStatus as byte, bit as byte) as byte bitClear= portStatus and not(2^bit) end sub public sub PortUpdate(PortID as string, portStatus as byte) Dim szString MSComm1.PortOpen = True szString = PortID & "," & portStatus MSComm1.Output = szString & Chr(13) MSComm1.PortOpen = False end sub
Genau. Und das ist halt alles andere als einfach einfach, weil VB(A) ein Interpreter ist, der einen Kontext benötigt. Es enthält allerdings die nötigen Mechanismen, um Callbacks aus dem OS auszuführen, diese sind allerdings nicht dokumentiert. Bei VB (in der modernen Inkarnation als VB.net) hingegen sind sie es.
Das ist natürlich völliger Unsinn. Sagt schon die reine Logik: wieso sollte ein OS einer Anwendung ein API verfügbar machen, welches sie nicht nutzen kann? Also bitte: Wenigstens ein wenig Nachdenken vor dem Posten kann wirklich nicht schaden... Hallo Ob S.,
Das ist mir neu, danke!
Das war unpräzise von mir formuliert. In meinem VBA-Code gibt es Aufrufe à la Open, Close, Read und Write aber keinen Callback des Betriebssystems. Ein Callback würde aber sinnvoll bei einem Read-Aufruf sein. Der Read-Aufruf sollte ja nicht bis zum jüngsten Gericht warten, sondern am besten ergebnislos zurückkehren. Die Aufgabe des Callbacks bestünde dann darin, mitzuteilen, das im Puffer etwas liegt.
Da hast Du Recht!
Braucht man aber nicht, denn genau dafür kann man die Overlapped-IO-Mechanismen nutzen. https://learn.microsoft.com/en-us/windows/win32/sync/synchronization-and-overlapped-input-and-output Danke, Harald K.! Der Link ist lesenswert. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
