Info über Automated Measurement mit VB?

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 10 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    Info über Automated Measurement mit VB?

    Guten Abend an alle!

    Suche seit langem Info bezüglich "automatisierte Messsysteme" mit VB. Programmiere viele automatisierte Messungen in VB und würde gerne "professionelle bzw. fachliche" Information über die besten Techniken dafür und wie man am besten solche Programme strukturiert. Bis jetzt habe ich leider nur von Keysight und National Instruments was gefunden, aber leider beide orientieren sie sich an seinen Software und ist kein allgemeines Leitfaden....

    Bei den Messungen wird auch Excel (Interop) als Messdatenspeicher und von Datenbanken holt sich das Programm die Messungsinformation bzw - Parametern.

    Da ich leider nicht viel darüber in Inet gefunden habe, komme ich hier, evtl. kennt jemand eine Quelle, Web, Artikel, Buch o.ä. :)

    Danke im Voraus und schönen Abend noch! :)
    Life doesn't give you a datasheet. Sometimes the docs are wrong and you have to try it.
    ich hab auch keine Quelle oder sowas, arbeite trotzdem mit NationalInstruments-Kram, und der ist äusserst leistungsfähig.
    Bitte vergiss Excel als Messdatenspeicher - das ist grotten-lahm, und v.a. verändert Excel beim Einlesen gerne die eingelesenen Daten - es ist also schlicht unzuverlässig.

    Wir jdfs. schreiben die eingelesenen Dateien in simple TextFiles, und gänzlich getrennt davon lesen wir diese Data-Logs wieder aus, zur Präsentation und Analyse etc..
    Textfiles sind zwar noch immer nicht das NonplusUltra an Performance, aber immernoch wesentlich schneller als Datenbanken.

    ErfinderDesRades schrieb:

    Wir jdfs. schreiben die eingelesenen Dateien in simple TextFiles


    Legenden sterben nie :)

    @rgomez
    Excel ist was für Hausfrauen. Das eignet sich nicht als DB ersatz. Excel macht gerne was es will, da wird auch gern mal ne Zahl zum Datum - und andersrum ;)

    Generell wird für den Datenaustausch zwischen 2 Software Produkten gerne XML/CSV/Text verwendet. Der eine schreibt, der andere liest und so.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    @rgomez Üblicherweise kommt zu einer Hardware schnell eine weitere und dann noch eine usw.
    Dann kommt der Chef und sagt:
    Wir haben doch hier die Kamera der Firma X. Diese hier dser Firma Y ist schneller und billiger, aber völlig anders.
    An so was solltest Du von Anfabg an denken.
    Lagere alle HArdwaren in DLLs aus, damit sind sie sofort bereit, in andere Projekte eingebunden zu werden.
    Mach Dir für jede Sorte Hardware ein Interface (Kameras, Motoren usw.), dann kannst Du viele Arten Kameras/Motoren drüber implementieren und die sind universell einsetzbar und austauschbar. Für die, die Du nicht auf Anhieb implementieren kannst, musst Du das Interface erweitern. Dann ist es sinnvoll, eine Funktionalität mit einer Boolean-ReadOnly-Property zu koppeln: Farbkamera und IsColorAvailable.
    Mach Dir für jede Sorte Hardware ein Test-Projektmappe.
    GUI als WinForm/WPF, Interface und jede Kamera/Motor als je eine DLL.
    Da kannst Du alles ausgiebig testen und implementieren.
    Wenn dann eine solche Hardware eingebunden werden soll, ziehst Du Dir die Interface- und die Hardware-DLL in Deine Projektmappe und (fast) feddich. :D
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Genau so was brauche ich und vielen Dank erstmal.

    Ich mache mir viele Gedanken, wie am besten ich die Sache organisiere, aber da ich noch weit von Experte bin und immer wieder auf neue Alternativen stöße, die ich erstmal kennenlernen muss, bewege ich mich zur Zeit nur im Kreis und habe noch keinen "richtigen Leitfaden". Bis jetzt habe ich für jede HW eine Klasse, das zumindest :P

    Excel benutze ich aber nur zum Anzeigen der Daten, es wird nicht mehr damit gemacht. Mittlerweile habe ich auch die Raw-Daten in Log-Datei(en). Ich verstehe was ihr meint von Excel und Datenänderung usw., habe schon erlebt, aber denke dann dann so lange nur zur Anzeige, dass OK ist, da beim Einlesen einer CSV, XML o.ä. die selbe Problematik auftaucht oder nicht?

    Mit den Interfaces beschäftige ich mich zur Zeit und werde die Sachen so machen wie du es sagst, hatte es auch vor, nur bis ich nicht fest alles habe, kann ich das "Main-Programm" nicht ändern, da die Messungen weiter laufen müssen. (Denk nicht falsch über meine Firma:P, bin Werkstudent in ner Messtechnik Firma, also was ich mache ist nicht 100% offiziel.)

    Über RS232 Kommunikation und VB hättest du evtl. eine gute Info Quelle? Ich hab viel gelesen und viele verschiedene Meinungen gesehen. Soll es in einem separaten Thread erfolgen, etc etc, was soll was kontrollieren bzw. aufrufen , aber da habe wieder kein klares Überblick drüber...vor allem wenn man dazu noch eine nice GUI mit REAL-Live Messdata haben soll. xD
    Life doesn't give you a datasheet. Sometimes the docs are wrong and you have to try it.

    rgomez schrieb:

    Ich verstehe was ihr meint von Excel und Datenänderung usw., habe schon erlebt, aber denke dann dann so lange nur zur Anzeige, dass OK ist, da beim Einlesen einer CSV, XML o.ä. die selbe Problematik auftaucht oder nicht?
    Nein.
    Wenn Excel eine Csv einliest, wo zB. Zahlen drinne stehen, und speichert sie zurück - dann stehen da an manchen Stelle auf einmal Datumse drinne.
    Aber gut - du willst nur anzeigen, nicht zurückspeichern.
    Aber auch wenn du nur codeseitig aus Excel einen Wert ausliest, passiert das: Wo inne csv eine Fließkommazahl stand, da steht in der Excel-Zelle dann ein Datum, und zwar eines was partout nicht mehr in den korrekten Wert re-konvertierbar ist.
    Aber gut - du willst wirklich wirklich nur anzeigen - jo, dann richtet Excel zumindest keinen Daten-Schaden an - solange es nicht stört, dass in manchen Zellen Datumse stehen statt Fliesskommazahlen...


    Das mit den Interfaces würde ich nicht zu stark vorantreiben.
    Imo solltest du ühaupt mal was ans Laufen bringen - wenn dann die nächste Kamera kommt, dann ist der rechte Zeitpunkt, die Architektur entsprechend abzuwandeln.


    Ich sag nochmal meine Empfehlung:
    Es sind 2 komplett verschiedene Baustellen (im Grunde sogar 3 Baustellen):
    1. a) Aufnehmen und loggen der Messdaten - hier musst du ein Gui schreiben zum Messparameter eingeben / speichern / editieren / Aufnahme starten.
      b) Und eben die Aufnahme ausführen - das ist der Part der mit den Hersteller-Dlls hantiert, RS232, Threading etc.
    2. Einlesen, aufbereiten, präsentieren der LogDateien - das kann sogar als abgetrenntes eigenes Projekt entwickelt werden.
    Daraus ergibt sich auf jeden Fall eine Anwendungs-Architektur mit 3 Modulen - wie du das umsetzst deine Sache.
    In meim Fall habich nur ein Projekt, aber ich habe das AnwendungsFramework deaktiviert, sodass ich je nach KommandozeilenParameter die eine Oberfläche starte oder die andere.
    Das ist vlt. das erste was du lösen solltest: Dass bei dir auch die beiden Guis auswählbar sind.
    Kann man auch so machen, dass man ein klein 3.Form als MainForm startet, mit einfach 2 Buttons drauf: a) Messung aufnehmen starten b) Präsentation Messdaten starten

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Excel zum anzeigen? Warum der Umweg?

    Daten in ein DataGrid ballern und der Drops ist gelutscht :)
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    @rgomez
    Gar nichts mit Excel machen...
    Eigentlich kann Winforms mit Chartcontrol Daten präsentieren und Datatable kann sogar rechnen (berechnete Spalten) und das übers DGV anzeigen.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VB1963“ ()

    rgomez schrieb:

    kann ich das "Main-Programm" nicht ändern
    Du programmierst am Geräterechner? Der läuft 7 / 24?
    M.E. hast Du einen "eigenen" Rechner, an dem Du programmierst. Wenn Du eien laufende Variante hast, schiebst Du die auf ein Test-Verzeichnis des Geräterechners, und wenn Deinen Leuten das gefällt, was Du gemacht hast, wird das nach einer intensiven Testphase die aktuelle Variante.
    RS232 gibt es hier im Forum gefühlte 100 Threads mit 1000 Posts, wo das gut dokumentiert ist. Machst Du erweiterte Forum-Suche mit RS232 oder SerialPort.

    ErfinderDesRades schrieb:

    wenn dann die nächste Kamera kommt, dann ist der rechte Zeitpunkt, die Architektur entsprechend abzuwandeln.
    Das ist so ne Sache.
    Wenn die Architektur des Hauptprogramms darauf vorbereitet ist, geht das.
    Wenn die Architektur des Hauptprogramms nicht darauf vorbereitet ist, müsste diese aufs Blaue zunächst vorbereitet werden. Üblicherweise wird da die einne oder andere Hardware bereits im Spagetticode oder einer Klasse angesprochen, dies sollte dann über vollständige Kapselung und Separierung in eine DLL angegangen werden.
    Dann kann die nächste Kamera kommen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    hmm.
    Meiner Erfahrung nach, kann man mit Interfaces genauso viel Wirrsal schaffen wie ohne.
    Und ich hab schon Haufen Codes gesehen, grade durch ausschweifende Interfacerei ganz unerfreulich undurchsichtig gemacht.

    Aber ist langsam Abschweif-Nebendiskussion.
    IMO für rgomez sind erstmal die 3 Baustellen in eine Ordnung zu bringen:
    1. Gui für Eingabe von Messparametern und Start der Aufnahme
    2. Aufzeichnen der Mess-Logs
    3. Gui für Präsentation und Interpretation der Mess-Logs
    Ich finds immer wichtig, dass man bei der Entwicklung das Projekt zügig auf einen Stand bringt, wo es läuft, und erste Ergebnisse sichtbar werden.

    Mir fällt grad auf, diese Identifikation der Baustellen ist gleichzeitig recht gut was du meinst mit

    RodFromGermany schrieb:

    ...Wenn die Architektur des Hauptprogramms darauf vorbereitet ist, [...durch annere Hardware erweitert zu werden...]...



    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Jou.

    ErfinderDesRades schrieb:

    ausschweifende Interfacerei
    klar, das ist ein Kündigungsgrund. :thumbsup:
    Ganz wichtig ist meines Erachtens, das ganze vorher mit ein paar Kollegen durchzusprechen.
    Eine Woche reden und scheiben und erst dann loszuproggen spart einen Monat Zeit :!:
    Leider sehen das die Chefs nicht ein, weil

    ErfinderDesRades schrieb:

    erste Ergebnisse sichtbar werden.
    Die glauben dann nämlich, dass dieser Prä-Test-Code nächste Woche auf der Messe präsentiert werden kann.
    @rgomez Und da gibt es noch die 80 / 20-Regel: Nach 20% der veranschlagten Zeit sind 80% der geplanten Aufgaben erledigt.
    Bring das Deinem Chef bei.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!