Struktur für Prüfsystem mit X Prüfungen

Hallo zusammen,

aktuell stehe ich vor der Aufgabe die Struktur für ein Prüfsystem zu entwerfen, das diverse unterschiedliche Elektromotoren testen soll. Jeder Typ des Elektromotors hat eine eindeutige Sachnummer, über die der Typ identifiziert werden kann. Meine Idealvorstellung ist, das der Prüfer am Anfang der Prüfung einmal die Sachnummer und die Software dann die entsprechende Prüfung aufruft.
Bis hier hin ist das alles noch sehr einfach, wäre da nicht die Anzahl der Typen und die Vielfalt der Typen. Wer möchte, kann sich hier ein Bild machen: http://www.groschopp.de/produkte/ http://www.groschopp.de/de/produkte/moto...igliekiel/ (Dazu kommen noch Sonderwünsche von Kunden) Wie ihr seht also sehr viele Variationen.

Meine Idee ist es, das ganze Objekt orientiert aufzubauen. Der Grundaufbau einer Prüfung ist immer gleich und die Methoden "Initialisierung", "Prüfung+Protokollierung", "Ende" würden sich damit als Grundaufbau anbieten.
Ist das eine gute Idee? Andere Vorschläge sind willkommen.

Probleme die ich sehe, sind später in der Dateiverwaltung bzw. -versionierung. Ich hätte ungerne später einen großen Klumpen aus allen Prüfungen zusammen in einem Ordner/Repo. Könnte man das iwie trennen?

Wie schaffe ich es, dass die Klassen nach der Sachnummer durchsucht werden und die richtige Klasse gewählt wird?

Dazu kommt noch die Zeit beim kompilieren. Dauert das später nicht ewig, wenn man 100 oder mehr Prüfungen zusammen hat?

Vielen Dank im Voraus,

Gruß Max

Anzeige

Hallo Max,
ist es möglich in die Sachnummern schon einen Teil der Identifikation mit einzubauen?
Ich hatte ein ähnliches Problem, ein Prüfautomat für 10 unterschiedliche Modelle.
Ich habe es damit gelöst, dass in den Seriennummern bereits die Kennung des Moduls enthalten ist.
Über eine Datenbank wird die entsprechenden Prüfungen abgerufen.
Der Vorteil ist eine flexible Erweiterungsmöglichkeit.

Gruß
Freddy

Hallo Max,

Zitat:Meine Idee ist es, das ganze Objekt orientiert aufzubauen. Der Grundaufbau einer Prüfung ist immer gleich und die Methoden "Initialisierung", "Prüfung+Protokollierung", "Ende" würden sich damit als Grundaufbau anbieten.
Ist das eine gute Idee? Andere Vorschläge sind willkommen.

- Wenn deine Prüfungen aus vordefinierten Tests bestehen, bei denen vielleicht nur ein paar Parameter geändert werden (z.B. Test mit 12V vs. Test mit 24V), dann würde ich vielleicht eine Statemachine bauen für die verschiedenen Tests. (Ein State pro Test.)
- Diese Statemachine wird dann über eine Queue angesteuert. Die Queue übermittelt die zum Prüfling passenden Tests mitsamt ihrer Parameter. (queue driven design)
- Jetzt benötigst du nur eine "Datenbank" (kann eine echte Datenbank sein oder auch eine große Tabelle), die zu jedem Prüfling (Seriennummer, Modellnummer) die passenden Tests/Parameter enthält. (Ich hatte für so etwas auch mal eine einfache Skript-Sprache erstellt, mit der man die Testabläufe programmieren konnte…)

Zitat:Probleme die ich sehe, sind später in der Dateiverwaltung bzw. -versionierung. Ich hätte ungerne später einen großen Klumpen aus allen Prüfungen zusammen in einem Ordner/Repo. Könnte man das iwie trennen?

Die Messdaten/Testergebnisse gehören in eine Datenbank! Wie soll man sonst später effizient auf die Daten zugreifen???

Zitat:Dazu kommt noch die Zeit beim kompilieren. Dauert das später nicht ewig, wenn man 100 oder mehr Prüfungen zusammen hat?

Glaube ich nicht…
Ein "großes" Programm dauert halt etwas länger zum Kompilieren (bzw. beim Erstellen der EXE), aber nicht zwangsläufig "ewig".

@Freddy: Dies ist leider nicht möglich. Die Sachnummern werden fortlaufend vergeben, ohne es nachzuschauen lässt diese Nummer also keinen Rückschluss auf das Produkt zu. Ein Weg über die Baugröße ist durch die verschiedensten Kundenanforderungen auch leider nicht möglich.

@GerdW: Sehr interessanter Ansatz, den werde ich mir mal genauer anschauen. Die Prüfungen so stark zu modularisieren, das dieser Ansatz möglich ist, ist sicher kein Problem.

Die Prüfdaten kommen natürlich später in eine DB! Ich meinte mit "Dateiverwaltung" die einzelnen Prüfungen. Wenn man aber alles nach deinem Vorschlag trennt, sollte es kein Problem mehr sein.

Vielen Dank schon mal für eure Hilfe .

Ich habe bei einem Projekt, das sehr viele verschiedene Messgeräte und DUTs unter einer Oberfläche ansprechen sollte, den Weg von dynamisch geladenen VIs gewählt.
Für Dich etwa so:
ID lesen , aus DB queued StateMC füttern, die die benötigte Testroutinen dynamisch läd, konfiguriert, ausführt und Ergebnisse in DB schreibt.

Neue Testroutinen könne dann eingepflegt werden, ohne das 'Hauptprogramm' neu zu compilieren /zu verteilen.
Die nachzuladenen VIs dann ebenfalls auf den Server ... .. nix nachinstallieren...

Und in den 'strickt type defs' Clustern immer noch ein Variant einbauen

Klingt auch sehr gut!
Wie machst du das mit dem dynamischen Laden? So? -> http://zone.ni.com/reference/de-XX/help/...dcall_vis/

Hallo MaxP,

ich habe das Testen von einem Gerät (DUT) das in 140 verschiedenen Varianten vorkam so umgesetzt:

- Geräteerkennung über Seriennummer (Handscanner)
- anhand der Seriennummer konnte die Konfiguration des DUT ermittelt werden (aus einer Konfigurationsdatei)
- erstellen eines Arrays mit den Testnamen/Statenamen
- eine Statemachine mit je einem State für alle vorkommenden Tests
- mit dem Array für die Testnamen die infragekommenden Tests/States ausführen

Also praktisch dynamisches Ausführen von States.

Grüße

kpa

(20.02.2018 15:23 )MaxP schrieb:  Klingt auch sehr gut!
Wie machst du das mit dem dynamischen Laden? So? -> http://zone.ni.com/reference/de-XX/help/...dcall_vis/

Jupp, genau so kann man anfangen.
Den Pfad und dessen Parametrierung holt man sich dann z.B. aus einer DB.
Das schöne ist, dass man diese VIs dann für eine neue Aufgabe (nach ausführlichem Testen und Freigabe) auf die Fläche (zu den Testmaschinen) schicken kann.. ohne Neustart

Bei mir liefen einige der VIs dann im Hintergrund (RS232 Kisten) da deren Zeitbasen nicht synchronisierbar waren .. aber das ist eine andere Baustelle .. gewesen...

@kpa: Vielen Dank für deine Antwort. Deine Idee klingt so, als würdest du die Qeue durch das Array ersetzen. Kommt das hin?

@HVo: Sehr schön, dann werde ich mich da mal genauer mit beschäftigen.

@all:

1. Wie legt ihr die Testabläufe + benötigte Daten in der Datenbank ab?
2. Wie stellt ihr die Kommunikation zwischen den States an? Also z.B. Referenz auf ein Messgerät? Gibt es die Möglichkeit eine Schieberegister während der Laufzeit zu verändern? Cluster zu entfernen/hinzuzufügen.

Gruß Max

PS: Wenn jemand Artikel/White Papers oder andere nützliche Quellen hat sind diese immer sehr willkommen.

(22.02.2018 15:28 )MaxP schrieb:  @kpa: Vielen Dank für deine Antwort. Deine Idee klingt so, als würdest du die Qeue durch das Array ersetzen. Kommt das hin?

Hallo MaxP,

nachdem ich die Antworten richtig gelesen habe muss ich sagen - Das kommt so hin.

Grüße
kpa