Hallo zusammen, ich mache zurzeit mein Praktikum für mein Studium, und ich beschäftige mich mit dem Thema Automatisierung. Es sollen Instrumente (Messgerät, Oszilloskop, Netzteil etc.) an eine Testmanagementsoftware angeschlossen werden. Das Problem ist, der Prüfplan, womit die Software des Prüflings getestet wird, ist sehr lang. Wenn später ein Instrument mit GPIB-Schnittstelle ausgetauscht werden soll(neues Gerät ebenfalls GPIB-Schnittstelle), ist es möglich das Gerät auszutauschen ohne in den Programmcode einzugreifen? Gibt es auch eine Möglichkeit USB-Instrumente auszuwechseln? Ich will später nämlich ein Prüfplatz haben, wo man Instrumente auswechseln kann, ohne im Programmcode Änderungen vornehmen zu müssen. Ist eine Lösung ohne LabVIEW möglich? Gruß Daniel
Das kommt ganz darauf an. Wenn es sich um das selbe Gerät handelt, klar. Dann musst du nur die GPIB Adresse am Gerät anpassen. Ansonsten wirst du immer den Code ändern müssen da die Befehle von dem Gerät abhängig sind.
blablub schrieb: > Ansonsten wirst du immer den Code ändern müssen da die Befehle von dem > Gerät abhängig sind. Naja, bei Instrumenten, die dem SCPI-Standard folgen, sind für die gleiche Geräteklasse (also bspw. Multimeter) zumindest die Grundfunktionen oft gleich. Bei unterschiedlichen Modellen eines Herstellers gleichen sich die Befehlssätze oft sehr weitreichend, sodass man meist ohne Codeänderungen wenigstens das Nachfolgemodell benutzen kann. Daniel T. schrieb: > Ist eine Lösung ohne LabVIEW möglich? Selbstverständlich. Wir benutzen in der Firma eine Python-basierte Scripting-Umgebung. GPIB-Tcl ist auch schon lange da. Das ist zwar im Umfeld der Opensource-Reimplementierung des GPIB-APIs entstanden, aber da die Basis-APIs identisch mit dem der NI-Variante gehalten worden sind, sollte es ziemlich egal sein, ob man nun die Bibliothek von NI oder die Opensource-Variante da drunter legt.
Es soll nicht durch das gleiche Instrument ausgetauscht werden, sondern durch ein Instrument mit der gleichen Schnittstelle. Gibt es da echt keine Möglichkeit?
Ein Netzteil mit GPIB und ein Scope mit GPIB haben die gleiche Schnittstelle. Wenn du die gegeneinander austauschen willst und die Software nicht ändern willst... was macht das für einen Sinn. Tauschen kannst du z.Bsp. Multimeter gegen Multimeter. Da gibt es auch 'höhere' Gerätetreiber z.Bsp. DMM Treiber der mit (fast) allen Multimetern spricht. Sowas ist aber kein Job für einen Praktikanten, dafür werden Ing's mit richtigem Geld bezahlt. Sag das mal deinem Chef...
Rene Schube schrieb: > Sowas ist aber kein Job für einen Praktikanten, dafür werden Ing's mit > richtigem Geld bezahlt. Naja, man kann's doch mal probieren, ob der Praktikant das Problem auch lösen würde, nicht wahr? ;-)
Versuchen kann man das, aber dann jammern die Ings wieder wie wenig sie verdienen... und keiner braucht einen und das leben ist so schlecht...
Daniel T. schrieb: > Wenn später ein Instrument mit GPIB-Schnittstelle ausgetauscht werden > soll(neues Gerät ebenfalls GPIB-Schnittstelle), ist es möglich das Gerät > auszutauschen ohne in den Programmcode einzugreifen? Grundsätzliche Frage, grundsätzliche Antwort: Nein. GPIB ist eine Norm der Schnittstelle und des Hardwareprotokolls. Mehr ist da nicht. Wenn du dich als Praktikant mit der Austauschbarkeit der Geräte beschäftigst verzettelst du dich nur. Wenn allerdings deine Aufgabenstellung die Austauschbarkeit auf GPIB Level war so ist Sie hiermit beendet ;-). Es macht auch wenig Sinn da die Testaufbauten alles Unikate sind und der Austausch eines Gerätes gegen ein anderes das Verhalten diese Aufbaus ändert (bzw die Wiederholbarkeit nicht mehr gewährleistet ist). Es gibt alles mögliche um mit Treibern und Anwendungssoftware (Labview, Profilab, HT-Basic) dieses Problem anders abzubilden. Ist aber nur eine Problemverschiebung. Die Austauschbarkeit kannst du jenseits von Spannungsmessung (bei der man GPIB gar nicht braucht) imho vergessen.
Danke schon mal für eure Unterstützung Meine Aufgabe ist es als Praktikant nicht das Gesamte Konzept zu entwickeln, sondern sich die Anforderungen anzugucken, und sich dann mit den Realisierungsmöglichkeiten zu beschäftigen. Entschuldigung, wenn es falsch rüber kam. Als Testmanagementsoftware stehen TestStand und EDTest gegenüber. Hat jemand schon Erfahrungen mit diesen Programmen gesammelt?
Noch zur Ergänzung. Es soll später ein anwenderfreundlicher Prüfplan erstellt werden, d.h. wenn man hardwaremäßige Modifikationen vornimmt, sollte kein großer Aufwand im Programmcode entstehen. Es soll keine Senke durch ein Messgerät ausgetauscht werden, sondern eher eine Senke mit einer leistungsstärkeren Senke. Die Kriterien, mit denen ich mich beschäftige sollen evtl. eine Vorlage für eine Bachelorarbeit sein.
Die Hersteller von Messgeräten achten schon sehr deutlich darauf, dass Geräte ähnlicher Kategorien zueinander kompatibel sind. Auf der einen Seite gibt es hierfür den SCPI-Standard, auf der anderen Seite "Pseudo-Industriestandards" wie z.B. Multimeter der Typen Fluke 88xx, HP/Agilent 34xx oder 34401A. Wenn ein Hersteller ein neues Systemmultimeter herausbringt, kann er nur dann überhaupt einen Blumentopf gewinnen, wenn er zu den obigen "Industriestandards" kompatibel ist. Dennoch ist nicht zwingend eine hundertprozentige Kompatibilität gegeben, insbesondere bei den zeitlichen Eigenschaften. Da hilft einfach nur ein Blick in die Dokumentation des konkreten Austauschgerätes, welche Kommandos wie emuliert werden und wo es Abweichungen gibt. Ich weiß z.B., dass Rohde&Schwarz sehr viel Aufwand in der Entwicklung betreibt, damit deren Geräte auch über etliche Produktgenerationen per SCPI kompatibel sind. Aber auch hier muss man schauen, welche konkreten Befehle in der Prüfsoftware angesteuert werden und ob es kleine, aber feine Unterschiede gibt.
Daniel T. schrieb: > Noch zur Ergänzung. > Es soll später ein anwenderfreundlicher Prüfplan erstellt werden, d.h. > wenn man hardwaremäßige Modifikationen vornimmt, sollte kein großer > Aufwand im Programmcode entstehen. Wir bauen eine Mondrakete, die Komponenten sollen aber wie eine Glühbirne austauschbar sein ;-). Wer dich mit so einer Spezifikation ins Praktikum leitet stürzt dich ins Nirwana. So eine Anforderung ist viel zu unspezifisch. Minimum wäre auf welchem Level mit Aufwand durch welche Abteilung/Fremdfirma/Budget was erreicht werden soll. Dann kannst du Messungen normalisieren und parametrisch definieren. Wenn das ganze aber auf dem 70er Jahre retro GPIB/NI OSI 1-2 Level definiert wird ist der Systemfehler "vorprogrammiert". > > Es soll keine Senke durch ein Messgerät ausgetauscht werden, sondern > eher eine Senke mit einer leistungsstärkeren Senke. Auch hier ist die Definition unbrauchbar. Ein Testsystem hat ein Ziel. Die und die Tests mit der und der Qualität und dem und dem Aufwand zu erreichen. > > Die Kriterien, mit denen ich mich beschäftige sollen evtl. eine Vorlage > für eine Bachelorarbeit sein. Bei dem ollen Kram wäre ne Anbindung an eine Zuse Z3 dann die richtige Praktikumsaufgabe für eine Bewerbung im Technischen Museum :-). Hab übrigens selbst GPIB/HPIB Gerät entwickelt, aber Stand der Technik Konzepte und Standards sind nun mal weit vorangeschritten.
Daniel T. schrieb: > Es soll keine Senke durch ein Messgerät ausgetauscht werden, sondern > eher eine Senke mit einer leistungsstärkeren Senke. Das würde ja nur was nützen, wenn die geänderten Eigenschaften des Geräts in der jetzigen Software bereits berücksichtigt sind. Dafür brauchst du aber keinen Techniker, sondern einen Hellseher. Gruss Reinhard
Daniel T. schrieb: > Wenn später ein Instrument mit GPIB-Schnittstelle ausgetauscht werden > soll(neues Gerät ebenfalls GPIB-Schnittstelle), ist es möglich das Gerät > auszutauschen ohne in den Programmcode einzugreifen? Grundsätzliche Frage, grundsätzliche Antwort: JA!!! Hallo Daniel, hier wurde schon eine Menge zu diesem Thema geschrieben, aber nicht alle Kommentare entsprechen so ganz der Wirklichkeit. Wenn Du einen automatisierten Messplatz besitzt, der hochverfügbar sein muß, dann ist einer der Ansprüche die hohe Flexibilität im Austausch der Geräte, sowie in der Verwendung der Schnittstellen. Es wäre doch fein, wenn man ein defektes Gerät gegen ein anderes der gleichen Funktion, aber zum Beispiel gegen ein Gerät anderer Hersteller, gegen ein moderneres, gegen eines mit mehr Leistung oder was auch immer austauschen könnte, OHNE in die Software eingreifen zu müssen. Und genau dieses ist auch möglich, vorausgesetzt 1) man bleibt in der gelichen Geräteklasse, also Oszi gegen Oszi tauschen, Power Supply gegen Power Supply tauschen 2) die einzelnen Geräte bringen vom Hersteller einen geeigneten Treiber mit und 3) bei der Erstellung des Automatisierungsprogrammes arbeitet man sehr diszipliniert. Die Firmen haben seit vielen Jahren die Austauschbarkeit der Hardware in der sogenannten IVI Foundation vorangetrieben: http://www.ivifoundation.org/ Hierzu wurden die wichtigsten Messgeräte in Klassen mit gemeinsamen Treiber zusammngefasst, soll heissen: Wenn ein Hersteller zu seinem Gerät ein IVI-Treiber anbietet, dann garantiert er, sich an die IVI Standardisierung gehalten zu haben und jeder Treiber enthält Funktionen, die das gleiche unter dem GLEICHEN Namen tun. Die unterschiedlichen Geräteklassen und ihre IVI Treiber heissen: Class IVI Driver Digital multimeter (DMM) IviDmm Oscilloscope IviScope Arbitrary waveform/function generator IviFgen DC power supply IviDCPwr AC power supply IviACPwr Switch IviSwtch Power meter IviPwrMeter Spectrum analyzer IviSpecAn RF signal generator IviRFSigGen Upconverter IviUpconverter Downconverter IviDownconverter Digitizer IviDigitizer Counter/timer IviCounter Wenn Du genaueres dazu wissen möchtest, dann schaue mal in "Getting Started" der Foundation. Im allgemeinen sind IVI Treiber auch VISA kompatibel. Dann interessiert Dich auch die Schnittstelle IEEE488, USB, RS232 oder Ethernet nicht mehr wirklich. Ein Power Meter der Firma ABC am USB kann dann durch ein Power Meter der Firma XYZ mit Ethernetschnittstelle ohne Problem ausgetauscht werden. Das Automatisierungsprogramm kann automatisch nach den Geräteklassen suchen und verwendet, was passt. NI Teststand unterstützt IVI im vollen Umfang, aber auch mit anderen Programmiersprachen wie den Visual's ist das kein Problem. Zum Schluß noch ein paar Anmerkungen ... 1) Die hohe Austauschbarkeit wird bezahlt durch eine saubere Programmierung, die mitunter mehr Zeit kostet, als wenn man direkt mit LowLevel SCPI Befehlen arbeitet und Geräte direkt anspricht. 2) Wenn man keinen IVI Treiber findet, muß man selber ran. Ist nicht so schwierig, aber man sollte sein Gerät schon gut kennen, für das man den Treiber schreiben muss. 3) Besonderheiten von Geräten werden in den IVI Treibern nicht berücksichtigt, sondern nur die nackten Funktionen werden im IVI Treiber abgebildet. Nur so lassen sich die Geräte austauschen. In der Regle reicht das aber bestens aus. Ich habe schon mehrere Systeme mit IVI Treibern realisiert und sie laufen und laufen und laufen. Wenn ein Gerät den Geist aufgiebt, wird es durch ein anderes, oft durch ein neueres ersetzt. Ich hoffe, ich konnte helfen .... Gruß kokisan PS: Die Firma National Instruments hält sehr viel Informationsmaterial hierzu bereit, ansonsten mal nach IVI Treiber im Netz suchen ...
Lieben Dank für die zahlreichen Antworten. Ich habe mir bereits schon sehr viele Informationen auf der Seite von National Instruments besorgt, doch NI hat oftmals ihre Open Source Produkte im Zusammenhang mit LabVIEW, LabWindows/CVI etc. beschrieben(weil sie diese verständlicherweise auch verkaufen wollen). Mir fiel es demnach schwer zu Differenzieren, welche kostenpflichtige Produkte ich von NI benötige und welche nicht. Ich hätte mir gewünscht, so eine allgemeine Aussage über Treiber wie von Kokisan, auf der NI-HP zu bekommen. Deswegen nochmal vielen Dank Kokisan!
Die Gerätetreiber und die 488 Abstraktionsschickt sind bei NI kostenlos. http://joule.ni.com/nidu/cds/view/p/id/2922/lang/de Die nutzen wir auch um unsere Geräte von Tek, LeCroy und R&S in unser Testprogramm einzubinden. Das Programm selber ist in C# geschrieben und kommuniziert über die VISA Treiber mit den Geräten.
Christian R. schrieb: > Die Gerätetreiber und die 488 Abstraktionsschickt sind bei NI kostenlos. Allerdings Windows-lastig. (Es gibt m. W. auch eine Linux-Variante, aber zumindest lange Zeit war x86_64 nicht mit dabei.) Die Lücke zu den nicht-Windows-Systemen füllt dann Linux-GPIB (welches auch auf nicht-Linux unixoiden Systemen läuft). Da das API das gleiche wie das von NI ist, kann man auf diese Weise auch plattformübergreifende Steuerungssoftware bauen.
Hat jemand Erfahrung mit einer alternativen Testmanagementsoftware neben TestStand und EDTest gemacht?
Ja, siehe oben: selbst geschriebene. Nein, nicht verkäuflich. ;-) Bei Chris scheint es ja genauso zu sein, das ist also durchaus nicht so unüblich, wie es auf den ersten Blick aussehen mag.
Jörg Wunsch schrieb: > Nein, nicht verkäuflich. ;-) Also doch verkäuflich :D Nein, Spaß! Selbstgeschriebene Testsoftware ist bei uns leider keine Alternative. Vielleicht gibt es hier noch Anwender, die eine weitere Testmanagementsoftware empfehlen können?!
Bei uns wird die Software hauptsächlich zur Kalibrierung der Hardware eingesetzt. Zum Testen der Hardwere gegen die entsprechende Norm reicht uns eine LabView Software die die Geräte bedient. Müssen wir aber demnächst mal neu machen, schei** LabView ist immer kaum erweiterbar und wartbar. Vielleicht machen wir das dann gleich in Python oder so.
Christian R. schrieb: >LabView ist immer kaum erweiterbar und wartbar. Inwiefern meinst du kaum erweiterbar? Ich dachte immer, dass man LabVIEW, durch die graphische Programmierung, leicht erweitern kann.
Christian R. schrieb: > demnächst mal neu machen, schei** LabView ist immer kaum erweiterbar und > wartbar. Vielleicht machen wir das dann gleich in Python oder so. ...am besten sowas immer vom Praktikanten machen lassen. Da ist die Programmiersprache auch egal... ;) Man kann in jeder Programmiersprache unwartbaren Code produzieren...das liegt dann aber nicht an der Sprache. Ich habe hier einige LabView Programme, die in der Version 5 erstellt wurden. Der Code ist wartbar und Erweiterungen können auch ohne Probleme eingepflegt werden. Man muss eben nur etwas selbstdiszipliniert sein. Daniel T. schrieb: > Inwiefern meinst du kaum erweiterbar? Ich dachte immer, dass man > LabVIEW, durch die graphische Programmierung, leicht erweitern kann. Jain... Wenn die Erweiterung darin besteht, einfach auf einen freien Platz 12 VIs zu klatschen und die Verbindungen quer übers Blatt ziehe, wirds irgendwann Grütze. Wenn man dann nach 37 weiteren VIs anfängt aufzuräumen, wirds ätzend... Ist einfach gesagt wie Leiterplatten routen... ;) Ich arbeite viel mit SUB-VIs. Dadurch ist der Programmcode gut aufgeräumt und übersichtlich. Beim warten bzw. erweitern muss ich nur das entsprechende SUB-VI (und/oder die SUB-SUB-VIs) anfassen. Der Rest bleibt so wie er ist. Mirko
MirkoB schrieb: > ...am besten sowas immer vom Praktikanten machen lassen. Da ist die > Programmiersprache auch egal... ;) So wars leider auch. Praktikant hat da was fabriziert, was er selber sicher hätte auch noch erweitern verbessern können. Aber Praktikant weg und sonst in der Abteilung kann niemand diesen Drahtverhau durschauen. Dann lieber eine schlecht programmierte Lösung die wenigstens in einer Strukturierten Programmiersprache ist. Klar kann man LabView auch sinnvoll machen, aber da muss man viel Erfahrung und vor allem Selbstdisziplin haben. Und das haben Praktikanten nun mal nicht. Die nächste Lösung wollen wir Ingenieure uns selber machen und Pythos deshalb weil dann jeder von uns mal schnell was ändern kann. Mal sehen, ob es diesmal nicht wieder für die Tonne ist.
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.