Da ich vernetzte Labore mehr in Europa gesehen haben, frage ich mal in diesem erlauchten Kreis.
Ich habe oefter gehoert, dass man ueber den Macro-Editor (oder VBA?) Interfaces schreiben kann, welche die Anbindung von Scopes, Analyzern und so weiter ermoeglichen und damit eine gaengige und so gut wie immer vorhandene Umgebung (Office) nutzen. Mit Labview und dergleichen ist das kein Akt, ist aber teuer und haben viele Kunden nicht. Einlesen der Messergebnisse in Excel ist auch einfach, das funktionierte hier auf Anhieb sehr schoen.
Falls so etwas geht, gibt es modifizierbare Beispiele, mit denen ein Steuerblock z.B. als Macro auf Excel gelegt werden kann? Google half mir diesmal nicht weiter.
Ok, jetzt werden sicher einige sagen "Das macht man doch mal eben schnell in C". Bin aber kein SW-Spezi und C laesst sich auch mit der ETS Spitze im Kolben nicht zusammenloeten ;-)
Ein einfacher Weg dürfte SICL von Agilent sein, dort gibt es eine Visual Basic Schnittstelle. Und Visual Basic for Applications ist exakt die "Makro" Sprache der Microsoft Office Anwendungen und damit auch von Excel. Das SICL gehört zu den GPIB Adaptern von Agilent, z.B. GPIB nach USB, und wird kostenlos für diese lizensiert.
Zu SICL schaust Du hier:
formatting link
formatting link
In der Users Guide sind auch Visual Basic (VBA) Beispiele drin.
IMHO haben die auch soetwas wie Benchlink als Goodie, aber nur für die eigenen Oszis.
Danke, das sieht handfest aus. Mit $394 auch nicht teuer. Ausser, dass es am anderen Ende eventuell nicht vorhanden sein wird und eine Anschaffung bei grossen Firmen oft ein buerokratischer Akt ist.
Der Hinweis "Works with the most popular T&M software applications including Agilent VEE Pro, NI LabVIEW, Visual Studio®" zeigt zwar keinen MS-Office Support, aber evtl geht das ueber Visual Studio.
Aha! Danke fuer den Tip, da muesste ich hier mal sehen, ob es aehnliches in Englisch gibt. Oder meine Schwester in Germany bitten.
Allerdings scheint es noch in der guten alten RS232 Zeit zu handeln. Hat hier sowohl Messgeraet als auch PC, ist aber i.d.R. nicht mehr der Fall. In den meisten Labors ist heute alles USB.
Diese Begründung ist unverständlich. Was hat die Vernetzung von Laboren (wo auch immer gelegen) mit dem Einsatz von Excel zu tuen? Und warum sollte die vermeintlich höhere Häufigkeit vernetzter Labore in Europa eine Anfrage zum Thema Excel in einer NG rechtfertigen, in der Excel wirklich komplett OT ist?
Erstens ist (MS)Office nicht wirklich "so gut wie immer" vorhanden und zweitens kann man mit VBA keine "Interfaces" schreiben, sondern allenfalls vorhandene benutzen, um Daten irgendwie in dieses schrottige Office zu bekommen.
VBA ist arg beschränkt. Man kann damit nur "Interfaces" zweier Arten verwenden und davon noch nichtmal wirklich alle.
Die grundsätzlich unterstützen Sachen sind COM-Objekte und klassische Funktionssammlungs-DLLs, die mit dem Aufrufmodell "STDCALL" arbeiten. Wirklich sicher und vollständig benutzbar sind aber nur die bezüglich der zulässigen Parameter erheblich eingeschränkte Sonderfälle dieser beiden "Interfaces", nämlich bei COM-Objekten die Sonderform "ActiveX" und bei den STDCALL-DLLs die Variante mit "WINAPI"-Konventionen.
Was ist ein "Steuerblock"? Vermutlich irgendwas von Labview, da du ja LabView explizit erwähnt hast. Nun, wenn das Teil die o.g. Bedingungen unterstützt, kann man es auch direkt in Excel oder ein sonstiges MS-Schrott-Office-Programm einbinden. Wie das prinzipiell geht, steht für beide unterstützten Varianten sogar in der bei Office mitgelieferten VBA-Dokumentation. Also: RTFM. Ob dieser "Steuerblock" den genannten Interfacemodellen entspricht, sollte sich wiederum beim Hersteller von LabView ermitteln lassen. Irgendwo in deren Dokumentation wird das sehr wahrscheinlich erwähnt sein. Und wenn er nicht diesen Bedingungen entspricht, braucht man eine Wrapperschicht, die man dann allerdings in einer richtigen Programmiersprache verfassen muß...
...das muß nicht notwendigerweise C sein. C erlaubt nur besonders unsaubere Schweinereien, die es besonders einfach(*) machen, Wrapper damit zu schreiben.
(*) "Einfach" ist hier nicht im logisch-technischen Sinne gemeint, sondern ausschließlich im Sinne eines vergleichweise geringen Tippaufwands.
Burkhard Kainka scheint aber auch fuer alle Lebenslagen ein Buch in petto zu haben. Allerdings bezieht sich dieses offenbar auf USB Interfacing, nicht Geraetesteuerung.
Manche USB Geraete hier arbeiten ueber einen Pseudo COM Port, womit man das dann so wie RS232 ansehen kann. Das Scope allerdings nicht, es tut dies m.W. nur fuer die Kommandos.
Wenn du es genauer wissen willst kannst du auch einfach seine Homepage besuchen und ihn mal eine email schreiben. Ausserdem sprecht ihr eh dieselbe Sprache. (Burkhard ist auch eher alter Analogentwickler, als C-programmier)
Es gibt da IMHO nur zwei Moeglichkeiten. Entweder ein Geraet meldet sich als Comport an, dann kann man es beim programmieren auch als ein solches ansprechen, oder nicht. Im letzeren Fall brauchst du einen speziellen USB-Treiber und eine Dokumentation wie du dann diesem Treiber die Daten entlockst.
Den gibt es auch, mit seitenweise Dokumentation. Nur ist das fuer Nicht-Programmierer harte Kost, gewuerzt mit kernigen grammatischen Patzern. Nehme ich ihnen aber nicht uebel, Englisch zu lernen ist fuer Asiaten viel schwerer als fuer uns.
Ich wollte Labview für sowas verwenden, aber der Einstieg war mir für meinen Zweck etwas zu aufwändig und es erschien mir auch etwas zu aufgeblasen.
Ich hab es dann mit VBA für Excel gemacht, als Basis für GPIB dienten Beispiele die bei einer alten NI-AT-Bus GPIB Karte dabei waren, für RS232-Ansteuerung dient eine frei erhältliche DLL die es etwas einfacher macht.
Das Ganze steuert eine Art halbautomatisches ATE welches aus älteren Geräten günstig zusammengestellt wurde. Über GPIB wird eine 8-Kanal Spannungsquelle und ein HP3455A gesteuert, über RS232/485 wird noch ein selbstgebauter Mux und das DUT gesteuert.
Für kleine Stückzahlen ist das recht brauchbar.
Für die 8-Kanal Spannungsquelle hab ich mir so auch eine Art virtuelles Bedienpanel zusammengebastelt, das gab es nicht fertig für LabView.
Da müsste es aber zig Seiten geben die sich damit beschäftigen. Der einfachste Weg dürfte folgender sein: Ein Makro mit irgendeiner primitiven Aktion in Ecxel aufnehmem, über "Extras"->"Makro" den "Visual Basic Editor" aufrufen und schauen wo der zugehörige Code liegt. Diesen Rumpf kannst Du dann mit sinvollem Code füllen. Ich baue meist noch eine Schaltfläche ins Arbeitsblatt ein, die bestimmte Aktionen auslöst. Benutzereingaben werden im Code einfach aus bestimmten Zellen geholt, die man vorher manuell gefüllt hat.
Nachteil: VBA ist manchmal wirklich ein PITA, vielleicht wäre LabView dafür doch besser gewesen. Ich könnte mir Vorstellen das es bei Steurung von komplexeren Geräten schnell ausufert.
Andererseits hab ich so für jedes DUT eine komplette Dokumentation der Testergebnisse und des verwendeten Codes in einer Datei, für Selektionszwecke und Statistik kann man dann auch noch (über SQL oder so) relativ einfach Daten aus verschiedenen Dateien zusammenfassen und auswerten.
Aufgeblasen ist gut. Die Verwandten meiner Frau haetten "uffjeplustert" gesagt.
Danke! Das ist doch mal eine Sache und geht in die Richtung, wohin ich moechte. Zumal meist gar kein GPIB mehr anfaellt, weil heutzutage alles mit USB oder Pseudo-RS232 ueber USB laeuft.
Wichtig ist, dass auch andere weit entfernt so etwas in Gang setzen koennen, ohne eine komplette Umgebung zu kaufen und zu installieren. Einfach mit dem, was auf normalen PCs schon drauf ist. Ich denke dabei auch an Schulen und so, denen man auf Non-Profit Basis (ohne Bezahlung und ohne Kosten) hilft.
Das hatte ich gestern schon mal ein wenig probiert. Mein persoenliches Problem ist aber, dass ich nicht so der Programmierer vor dem Herrn bin.
Interessant. Nach dem, was Du schreibst, scheint sich eine Einarbeitung in VBA ja doch zu lohnen. Mit C ist in diesem Metier vermutlich nichts gebacken, weil nicht in MS-Office vorgesehen. C haette ich wenigstens noch ein bisschen gekannt.
Ich kann Dir nur dazu raten. VBA in Excel ist fuer kleine Sachen durchaus brauchbar und fuehrt nach ein bisschen Einarbeitung wirklich zu einem "Mach ich doch mal eben in Excel/VBA..." und macht dabei durchaus Spass. Bei grossen Sachen faengt man allerdings an es weniger zu moegen
Das kann auch Wartezeiten vermeiden, denn man muss dann nicht ausharren, bis der LabView-Spezi Zeit hat, die noetigen Routinen zu schreiben. Ausserdem haben, wenn ich das jetzt alles richtig verstehe, alle PCs mit ausgeliefertem MS-Office diese VBA Extension. Gestern konnte ich es nicht lassen und habe mal bei OpenOffice nachgesehen. Und siehe da, Tools -> Macros -> Organize Macros -> OpenOffice.org_Basic.
Da muss ich jetzt wohl ein Buch besorgen, zum Nachschlagen der Syntax und so.
ich habe heute den USB-Anschluss einer externen Festplatte über ein Silex SX-2000U2 "verlängert". Funktioniert einwandfrei, die Festplatte verhält sich wie am lokalen Anschluss, auch wenn sie irgendwo im Netz angeschlossen ist (natürlich etwas langsamer).
Hat das schon einmal jemand mit Messgeräten versucht? Wär' doch eine nette Idee, ein USB-Messgerät über das Internet/VPN zu betreiben.
Zumindest früher war es nicht möglich, von VBA aus direkt z.B. auf die RS-232 Schnittstelle zuzugreifen. Es gibt aber die Möglichkeit, externe Bibliotheken, d.h. DLLs, die z.B. in Delphi oder C geschrieben wurden, in VBA einzubinden und die entsprechenden Funktionen dann zu nutzen.
VBA selber verwenden wir nicht, aber wir schreiben gelegentlich DLLs, die in VBA eingebunden werden und Delphi Programm, die mit Meßgeräten kommunizieren. Wir übergeben dann aber normalerweise lediglich die Daten an Excel und machen die komplette Kommunikation in Delphi. Ist auch nicht schwerer zu lernen, als VBA und irgendwie "ordentlicher" und nicht so chaotisch, wie manche Pfuschertools.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.