Hallo LVF-ler!
Ich habe ein großes Projekt in Auftrag bekommen. Unser komplettes Messraum muss zentral gesteuert werden. Wir haben mehrere Klimaschränke, Drehtische und Shaker im Messraum stehen. Jedes davon hat eigenes Schnittstellenprotokoll (es handelt sich um ca. 8 Equipmentgeräte) und unterschiedliche Kommunnikationsschnittstellen (analog, digital, RS232, CAN, TCP/IP, GPIB). Dazu hat unsere Firma eine große Produktpalette aus ca. 15 unterschidlichen Produktgruppen je nach Schnittstellenprotokoll.
Unsere Produkte müssen mit dem vorhandenem Meßequipment geprüft, kalibriert und verifiziert werden. Alles soll möglichst automatisch laufen (ausgenommen mechanische Tätigkeiten und Ein- Ausschalten).
Bis jetzt habe ich kleinere Bedienoberflächen für die einzelnen Geräte geschrieben, ab und zu in ein System auch zusammengefasste Geräte. Alle Protokolle sind mir gut bekannt, auch habe ich mit allen oben erwähnten Hardwareschnittstellen gearbeitet.
Nun kommt die Zentralisierung des ganzen. Bis jetzt war es zwar auch automatisch und halbzentralisiert (auch mein Projekt aus Praxissemester/Diplomarbeitszeiten). Nur es unterstützt nur die Hälfte der vorhandenen Geräten und hat Microkontroller als Hauptmodul. Die LV-Oberfläche steuert diesen µC an und kommuniziert mit Geräten mit kompexeren Protokollen. Die Berechnungen der Kalibrierdaten wurden bis jetzt mit Excelmakros erledigt, die Daten für die Berechnungen wurden vom LV-Programm in Excelsheets eingetragen.
Falls jemand anschauen will um welche Geräte es sich handelt:
http://www.imar-navigation.de
So, jetzt zum Projekt.
Ich habe vor für jedes einzelne Prüfling/Prüfgerät eine eigene Oberfläche zu programmieren. Dies soll die lokale Ansteuerung/Kommunikation/Konfiguration jedes einzelnen Gerätes ermöglichen. Diese einzelnen Programme werden eine TCP/IP-Schnittstelle nach außen haben. Es wird auch ein zentrales Programm geben, das mit den einzelnen lokalen Programmen kommuniziert. Die Befehle werden aus Skriptdateien genommen und die Ergebnisse werden in ein Meßbericht zusammengefügt. Danach wird dieses Bericht mit dem selben oder externem Programm ausgewertet.
Ich habe zwar keine großen Schwierigkeiten diesen Auftrag zu erledigen, aber vielleicht habt ihr irgendwelche Vorschläge, wie man es leichter/schneller/besser machen könnte.
Gruß, eg
Hallo Eugen,
ich haber hier auch Prüfstände entwickelt, mit denen ich Baugruppen und fertige Geräte teste. Da es davon viele unterschiedliche Möglichkeiten gibt und auch immer neue Baugruppen (Geräte) dazukommen, habe ich eine universelle Eingabemöglichkeit (per universellem Plugin) geschaffen, mit der unser Prüftechniker seine eigenen Prüfschritte (inkl. Unterschritte) erstellen kann. Diese Daten werden dann zentral in einer Datenbank gespeichert.
Der Aufbau ist im Prinzip dann so:
-> Prüfplan (kann aus mehreren Baustein bestehen)
-> Baustein (z.B. Name, Teilenummer,...) (kann aus mehreren Prüfschritten bestehen)
-> Prüfschritt (z.B. Messen einer Ausgangsspannung auf einer Platine oder Ansteuern eines Gerätes über eine Schnittstelle)(kann aus mehreren Unterschritten bestehen)
->Unterschritt (z.B. Generator einstellen, DIO ansteuern, Matrix schalten, Oszi ansteuern,....)
Also quasi hat der Bediener die Möglichkeit mit den Plugins seine eigene Prüfung für jede Komponente "zusammenzuklicken".
Dieser Prüfplan wird dann in der DB hinterlegt, so dass er ihn bei der nächsten Prüfung einfach laden und ablaufen lassen kann.
Die zugehörigen Toleranzen der Messwerte und Messwerte an sich werden auch gespeichert.
Gruß Markus
Hallo Markus, ja sowas in der Art will ich auch machen. Das was du Plugin nennst heisst bei mir Skript. Ein Skript ist eine einfache Textdatei, in der jede Zeile einen Befehl mit Parameter beinhaltet.
Zum Beispiel:
set_pos 1 45
set_temp 50
log_data 10
add_excel A5 E5
wait 600
und so weiter.
Diese Datei wird bei mir im Programm eingelesen und Zeile für Zeile ausgeführt. Während der Ausführung wird also ein Excelblatt mit Messdaten aufgefüllt.
Es ist sehr flexibel, denn jeder Mensch kann so eine Datei erstellen und ausführen.
Bei dir ist es eigentlich ähnlich, ausser dass du eine Datenbank benutzt.
Danke für die Antwort, Eugen
Keine Vorschäge mehr?
Wenn ich dich richtig verstanden habe, brauchst du ein Programm, das per se prüfstandsunabhängig ist. Was dann tatsächlich ausgeführt wird, soll z.B. per Skript (oder wie auch immer) konfiguriertbar sein. Ich kenne solche Programme.
Wir selbst fertigen nur Software, die speziell auf einen Prüfstand zugeschnitten ist. Der Ablauf wird durch ein Lastenfeft des Kunden vorgegeben, das wiederum durch den Prüfling vorgegeben wird. Der Ablauf - also set_pos, set_temp etc - ist also explizit festgelegt. Daher gibt es - nur - genau festgelegte Parameter, die immer alle mit Werten konfiguriert werden müssen. Diese Konfiguration - spricht: Datensatz festlegen - wird in einer speziellen Maske direkt im Prüfstandsprogramm gemacht. Der Kunde schreibt also (bisher) weder eine Textdatei, noch ein DB, noch ein Excel-File. Diese Daten werden als INI-File abgelegt.
Das könnte man hier auch so machen, nur das wären eine Unmenge an Dialogen und Eingabemasken. Ausserdem will ich auch die Möglichkeit geben sich wiederholende Vorgänge und Wartezeiten im Ablauf flexibel ändern zu können. Ja, dein Vorschlag nehme ich zur Kenntnis, danke dir.
Hallo Eugen,
in der Firma, in der ich arbeite, werden verschiedene Komplettgeräte mit unterschiedlichen Konfigurationen oder auch einzelne Baugruppen getestet. Die meisten Prüfstände sind für Dauertests mit bis zu 16 Prüflingen ausgelegt.
will mal kurz unser Prüfsystem vorstellen:
- jede prüfungsrelevante Aktion (Einschalten, Prüflingsinitialisierung, Messen usw.) wird in ein Sub-VI gesteckt, den sog. Prüfschritt. Diese Sub-VIs haben nach außen alle die gleiche Anschlußkonfiguration, mit der z.B. notwendige Übergabeparameter (Sollwerte, Toleranzen, Schnittstellennamen, Bedingungen, die bei der Messung prüfstandsseitig einzuhalten sind etc.) übergeben werden. Nur in diesen SubVIs erfolgt die Kommunikation mit den Prüflingen und angeschlossener Peripherie des Prüfstands.
- für jede Gerätekonfiguration wird eine sinnvolle Aneinanderreihung dieser Prüfschritte mit den dazu passenden Vorgaben, die zum Bestehen dieses Schritts einzuhalten sind, festgelegt. Das ist die Prüffolge.
- Beim Prüfungsstart wird entsprechend der Gerätekonfiguration auf den 16 Prüfplätzen aus den Prüffolgen ein zweidimensionales Feld, die Prüftabelle, erzeugt.
Die Prüffolgen bzw. Tabellen wurden in der Vergangenheit auch textbasiert angelegt, jedoch hatte teilweise das Bedienpersonal Probleme, die richtigen Folgen auszuwählen, bzw. wurden versehentliche falsche Auswahlen getroffen. Daher wird aktuell das ganze datenbankgestützt anhand von Serien- bzw. Artikelnummern der Prüflinge zusammengestellt.
Das Hauptprogramm ist eine Zustandsmaschine, die, nachdem die Prüfung gestartet wurde, solange läuft, bis alle Schritte für alle Geräte abgearbeitet, das Programm abgebrochen wurde oder alle Prüflinge als defekt befunden wurden.
Ein Algorithmus wählt nach einem Prüfschritt immer aus, welcher als nächstes mit welchem Prüfling durchzuführen ist. Anschließend werden die Übergabeparameter aus der Tabelle geholt, dem SubVI übergeben, der Prüfschritt ausgeführt, die Ergebnisse vom Prüfschritt zurückgeliefert, im Frontpanel und in Log-File bzw. Datenbank abgelegt.
Das hat für uns den Vorteil, daß man die Prüfabläufe anpassen kann, ohne das Programm neu kompilieren zu müssen, und man kann im nachhinein noch Prüfschritte neu erzeugen und in die Prüffolgen aufnehmen.
Gruß Andreas
Hallo Andreas,
dein Prüfsystem klingt sehr interessant. Könntest du bitte ein Beispiel einer Tabelle (oder einen Ausschnitt) zeigen?
Danke dir
Hallo Eugen,
hab eine ältere als Beispiel gepostet.
Ist eine reine Text-Datei.
Die ersten "JA JA JA..." (alles Tab-getrennt) bedeuten, daß dieser Prüfschritt für den betreffenden Prüfplatz ausgeführt werden soll. Da in diesem konkreten Falle alle 16 Geräte vom gleichen Typ waren, steht bei jedem Schritt auch "JA" für alle Geräte. Anders ist es bei Geräten verschiedener Konfiguration innerhalb eines Prüfdurchlaufs. Dort kommt es dann vor, daß da bei einem Mal "Nein" dastände weil ein Schritt nicht ausgeführt werden soll, weil z.B. dieses Gerät über die notwendige Peripherie, die getestet werden soll, nicht verfügt. Andernfalls kann es eben sein, daß gerade bei diesem Gerät z.B. eine gesonderte Spannung zugeschaltet werden muß, die die anderen Geräte nicht benötigen. Also ist der Schritt nur bei diesem Gerät "JA" und bei allen anderen "NEIN".
Außerdem können z.B. wegen Wartungsarbeiten auch mal Lücken zwischen den Prüflingen sein. Dann werden alle Prüfschritte für diesen Platz deaktiviert.
Dokumentation sagt aus, ob die Übergabeparameter und Ergebnisse dokumentiert werden sollen, z.B. in der Datenbank
Die Übergabeparameterwerte werden als String-Array an das betreffende VI übergeben und dort dann in das benötigte Format gewandelt.
Wenn dann die zweidimensionale Prüftabelle aus der Textdatei geparst wurde, kann man wählen, ob man sie zeilenweise (bei uns üblich) abarbeitet, d.h. jeder Prüfschritt wird nacheinander für jeden besetzten Prüfplatz ausgeführt. Erst danach wird der nächste Prüfschritt für alle Plätze aufgerufen. Oder man macht es spaltenweise, d.h. die Prüffolge wird hintereinander nur für ein Gerät abgearbeitet, danach beginnt man mit dem ersten Schritt für das zweite Gerät und so fort.
Gruß Andreas