Problem mit Timer in einer Klasse

  • VB.NET

Es gibt 35 Antworten in diesem Thema. Der letzte Beitrag () ist von egon.

    >> Hmm - grade eine Prozessteuerung wäre evtl. mit Async doch sehr elegant. Weil das kann man programmieren wie einen sequentiellen Ablauf, also wenn du 10 Programmschritte abzuarbeiten hast, kannste das mit Async einfach in einer Schleife abhandeln, wo man mittm Timer ziemlich rumwerkeln müsste, um die Schleife in eine Art Status-Automaten zu übertragen.

    Da hat mich EdR auf einen interessanten Weg gebracht. Hier folgt nun meine Umsetzung die ganz gut funktioniert und mir sehr gut gefällt. Ich habe die Idee dafür in dem Buch "VB 2012" von Doberenz gefunden. Was da genau passiert habe ich noch nicht verstanden. Auch bekomme ich die Umsetzung nur für Function und nicht für Sub hin und der Aufruf musste in drei Teile aufgeteilt werden.

    Kann man eigentlich auch eine Abbruchmöglichkeit einbauen und vielleicht auch über ein Control den Stand der Bearbeitung irgendwie mitteilen?

    Spoiler anzeigen

    VB.NET-Quellcode

    1. Option Strict On
    2. Public Class Form1
    3. Dim test As New Testklasse
    4. Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
    5. test.start_queue()
    6. End Sub
    7. End Class

    VB.NET-Quellcode

    1. Public Class Testklasse
    2. Private WithEvents prc As Process
    3. Private Reihenfolge_index As New Queue(Of Integer)
    4. Private Reihenfolge_info As New Queue(Of String)
    5. Public Sub start_queue()
    6. 'Queue füllen
    7. For i = 0 To 3
    8. Reihenfolge_index.Enqueue(i)
    9. Next
    10. Reihenfolge_info.Enqueue("eins")
    11. Reihenfolge_info.Enqueue("zwei")
    12. Reihenfolge_info.Enqueue("drei")
    13. Reihenfolge_info.Enqueue("vier")
    14. lange_Messung_Async1()
    15. End Sub
    17. Public Async Sub lange_Messung_Async1()
    18. Dim Rueckmeldung As Integer = Await lange_Messung_Async2()
    19. End Sub
    21. Public Function lange_Messung_Async2() As Task(Of Integer)
    22. Return Task.Factory.StartNew(Of Integer)(Function() Messablaufsteuerung())
    23. End Function
    25. Public Function Messablaufsteuerung() As Integer
    26. While Reihenfolge_index.Count > 0
    27. Select Case Reihenfolge_index.Dequeue()
    28. Case 0
    29. Console.Beep(1500, 200)
    30. prc = New Process
    31. prc.StartInfo.FileName = "notepad.exe"
    32. prc.Start()
    33. prc.WaitForExit()
    34. Console.WriteLine(Reihenfolge_info.Dequeue())
    35. Case 1
    36. System.Threading.Thread.Sleep(5000) ' 5 Sekunden warten
    37. Console.WriteLine(Reihenfolge_info.Dequeue())
    38. Case 2
    39. prc = New Process
    40. prc.StartInfo.FileName = "notepad.exe"
    41. prc.Start()
    42. prc.WaitForExit()
    43. Console.WriteLine(Reihenfolge_info.Dequeue())
    44. Case 3
    45. prc = New Process
    46. prc.StartInfo.FileName = "notepad.exe"
    47. prc.Start()
    48. prc.WaitForExit()
    49. Console.WriteLine(Reihenfolge_info.Dequeue())
    50. Case Else
    51. Console.WriteLine("error")
    52. End Select
    53. End While
    54. Return 0
    55. End Function
    56. End Class

    Klar geht das - und zwar so einfach wie noch nie.
    (Das heisst nicht, dasses jetzt einfach wäre.)
    Threading ist immer! ein ganzes Paket an Problemen: 1) Nebenläufigkeit 2) den User davon abhalten, Mist zu machen, während der Thread läuft 3) Zwischen- und End-standsMeldungen 4) Canceln 5) Fehlerbehandlung.

    Ein alles erschlagendes Tut habich hier versucht:
    Async, Await und Task
    Aber wenn ich alles erschlage geht das immer leicht zu Lasten der Leichtverständlichkeit - also sieh mal zu.

    Dasselbe habich später nochmal auf englisch verzapft
    codeproject.com/Articles/10296…ithout-any-additional-Lin
    Ich glaube in Punkto Leichtverständlichkeit wesentlich besser.
    Aber immernoch ziemlich viel, weil ich auch einen Async-Bugfix eingetütet habe, und eben auch Visualisieren von Algorithmen mit rein - das ist genau dein Thema Prozesssteuerung.

    Auf VBP habich mich diesem SpezialFall (Algorithmen-Visualisierung) in eim eigenen Tut gewidmet
    Async: einfaches Visualisieren von Algorithmen
    Ist vergleichsweise leicht verdaulich, aber weiss nicht, ob nicht doch das Komplettpaket zu verstehen Vorraussetzung ist.

    Also ich empfehle dir die Tuts in umgekehrter Reihenfolge zu versuchen.


    Allerdings sollteste dir erstmal eine Programmschritt-Datenklasse ausdenken.
    Dieses Durcheinander da mit deinen bisherigen Tests mit den 2 Queues in der Test-Klasse - da blickt man nicht wirklich durch.


    Ach guckma - hier hab ich was, wo man mit Programmschritten umgeht: Ein Lauflicht-Creator - der geht mit Timer - ist eiglich auch kein Problem.
    Wie immer: A & O ist das Datenmodell.


    Und ich würde dir dringend raten, dein Datenmodell nicht mehr in Klassen zu formulieren, sondern zu erlernen, wie man sowas mit typisierten Datasets macht.
    Ich hatte ja glaub grosschnäuzig gesagt: Gib ma Datenmodell - mach ich Persistenz zu - aber das wurde unverhältnismässig umständlich.
    Mittm typDataset ist grundsätzlich nicht anders als mit Klassen - nur schreibste die nicht mehr selber, sondern bekommst sie generiert - aber nachwievor musste dabei mit Klassen umgehen.

    Und die generierten Klassen des Datasets bieten eine enorme Feature-Vielfalt - alle Basics, die man zur Datenverarbeitung braucht: Laden, Speichern, Sortieren, Suchen, Zufügen, Löschen, und das beste: Databinding.
    Aber Databinding wird dir nix sagen - nur soviel: es ist doller als du dir vorstellen kannst, ehrlich.

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

    egon schrieb:

    Wie wird ein FileSystemWatcher richtig eingesetzt? Welchen Vorteil hat dieser Weg?
    Er informiert Dich über begonnene und beendete Aktivitäten eines Dateisystems.
    Wenn das Messprogramm eine Datei abgelegt hat, kann der FSW Dich darüber per Event informieren. Kein Timer, kein Event.
    msdn.microsoft.com/de-de/libra…temwatcher(v=vs.110).aspx
    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!

    Ich habe jetzt auch eine Art Abbruchmöglichkeit geschaffen. Es wird nicht der Task gekillt, sondern nur der Ablaufsteuerung mitgeteilt, dass keine weiteren Schritte mehr ausgeführt werden sollen. Das ist für mich schnell genug und es wäre falsch an dieser Stelle ein neues Fass aufzumachen. Meine Programmierfähigkeitslücken sind an anderer Stelle größer und müssen zuerst dort gestopft werden ;) .
    Vielleicht sollten wir diesen Beitrag jetzt so langsam auslaufen lassen. Es ist eine Lösung die funktionieren wird, auch wenn es bessere und elegantere Lösungsmöglichkeiten gibt.

    Ich möchte noch auf einige Fragen und Anmerkungen von euch eingehen:

    >> "Und ich würde dir dringend raten, dein Datenmodell nicht mehr in Klassen zu formulieren, sondern zu erlernen, wie man sowas mit typisierten Datasets macht."
    Deinen Rat nehme ich gerne an. Es spricht für mich aber trotzdem sehr viel dafür es in Klassen zu formulieren. Den Umgang mit den Klassen muss ich auch erlernen. Wo komme ich her. Meine "Heimat" war die Programmierung von Atmel Mikrocontrollern wo man mit seinen Ressourcen haushalten musste. Dann habe ich mit der Windows-Programmierung angefangen, da mansche Projekte sich nur am PC bewältigen ließen. Mein Programmierstil hat sich aber nur teilweise geändert. Mein Spaghettiprogramm wurde in den letzten Wochen von anderen Teilprogramm befreit und von Müll entfernt und alles wurde sortiert. So ist es sehr viel übersichtlicher geworden. Dann habe mich versucht mit Klassen zu arbeiten. Das erlerne ich gerade und glaube, dass ich diesen Evolutionsschritt nicht überspringen darf um bei späteren Projekten nicht wieder in die Spaghetti-Programmiererei zu verfallen.
    Ein Datenmodell habe ich in Klassen schon erstellt und ein kleines Testprogramm läuft schon und wird in den nächsten Tagen immer vollständiger.

    - EdR hat gesagt "Gib ma Datenmodell - mach ich Persistenz zu - aber das wurde unverhältnismässig umständlich.":
    Mein Vorschlag um die typ. Datasets zu erlernen. Ich beende in der nächsten Zeit mein Messprogramm mit einem Datenmodell auf der Basis von Klassen. Dann denke ich mir ein kleineres Projekt aus, an welchen die typ. Datasets besser erlernt werden kann. Mein aktuelles Projekt ist als Lernprojekt eigentlich viel zu kompliziert. Daher ist es auch so unverhältnismäßig umständlich und zäh geworden.
    Ich habe mir deine Filme gestern intensiv angesehen und einiges dazu gelesen und sehe, dass ich diese Art der Datenverarbeitung lernen "muss". Ich habe aber auch gemerkt, dass dann in der Lernphase wieder neue Probleme hinzu kommen. Dafür ist mein Projekt nicht richtig geeignet - zu komplex.

    - Mein Vorschlag fürs das weitere Vorgehen um ermüdende seitenlange Beiträge zu vermeiden. Ich versuche jetzt mein Projekt auf der Basis von Klassen zu beenden und melde mich mit konkreten Fragen, die in kleinen Testprogramm einzeln geklärt werden können und eröffne dazu jeweils neue Beiträge. (Die dann auch nicht so lang sind...)
    Auf meiner Homepage lege ich ein Dokument an in dem ich den realen Messaufbau mit Blockschaltbildern beschreibe (Ein User hatte mich darum per Email gebeten). Auch beschreibe ich dort mein Datenmodell, ermüdende als Diagramm damit man es schneller überblicken kann. EdR wird mir dann bestimmt sagen "dann ist es doch mit dem typ. Dataset nicht mehr weit :D ". Wie beschrieben wäre dies aber erst der nächste Schritt (... auch wenn er ziemlich sicher damit Recht hat...).


    - >> FilesystemWatchers. ...wartet nicht eine Zeit, und hofft, das Messi-Prog ist fertig, sondern man wird informiert, wenns fertig ist.
    In meinem Fall geht es leider nicht. Wenn das Messgerät mit allen Parametern versorgt worden ist und die Messung startet, muss ich selbst wissen wann ich mit dem Abfragen der Messergebnisse starte, da ich vom dem Gerät keine Rückmeldung bekomme wenn es fertig ist. Beginne ich zu früh mir der Abfrage der Messergebnisse bekomme ich eben auch alte/ungültige Werte. Das lässt sich nicht umgehen.


    Hier meine aktuelle Version mit der Abbruchmögllichkeit:
    Spoiler anzeigen

    VB.NET-Quellcode

    1. Option Strict On
    2. Public Class Form1
    3. Dim test As New Testklasse
    4. Private Sub Button1_Click_Start(sender As Object, e As EventArgs) Handles Button1.Click
    5. test.start_queue()
    6. End Sub
    8. Private Sub Button2_Click_Stop(sender As Object, e As EventArgs) Handles Button2.Click
    9. test.kill()
    10. End Sub
    11. End Class

    VB.NET-Quellcode

    1. Public Class Testklasse
    2. Private WithEvents prc As Process
    3. Private Reihenfolge_index As New Queue(Of Integer)
    4. Private Reihenfolge_info As New Queue(Of String)
    5. Private abbruch As Boolean = False
    7. Public Sub start_queue()
    8. 'Queue füllen
    9. 'Reihenfolge_index: Steuert den Messablauf. Gibt an, an welcher Stelle vom Messablauf ich mich befinde
    10. 'Reihenfolge_info: Dient hier nur als Textausgabe. Später sollen hier Parameter gespeichert werden können,
    11. ' die für die jeweiligen Schritte im Messablauf notwendig sind.
    12. For i = 0 To 3
    13. Reihenfolge_index.Enqueue(i)
    14. Next
    15. Reihenfolge_info.Enqueue("eins")
    16. Reihenfolge_info.Enqueue("zwei")
    17. Reihenfolge_info.Enqueue("drei")
    18. Reihenfolge_info.Enqueue("vier")
    19. lange_Messung_Async1()
    20. End Sub
    22. Public Sub kill()
    23. abbruch = True
    24. End Sub
    26. Public Async Sub lange_Messung_Async1()
    27. abbruch = False
    28. Dim Rueckmeldung As Integer = Await lange_Messung_Async2()
    29. End Sub
    31. Public Function lange_Messung_Async2() As Task(Of Integer)
    32. Return Task.Factory.StartNew(Of Integer)(Function() Messablaufsteuerung())
    33. End Function
    35. Public Function Messablaufsteuerung() As Integer
    36. While Reihenfolge_index.Count > 0
    37. If abbruch = True Then
    38. Reihenfolge_index.Clear()
    39. Reihenfolge_info.Clear()
    40. Exit While
    41. End If
    43. Select Case Reihenfolge_index.Dequeue()
    44. Case 0
    45. Console.Beep(1500, 200)
    46. prc = New Process
    47. prc.StartInfo.FileName = "notepad.exe"
    48. prc.Start()
    49. prc.WaitForExit()
    50. Console.WriteLine(Reihenfolge_info.Dequeue())
    51. Case 1
    52. System.Threading.Thread.Sleep(5000) ' 5 Sekunden warten
    53. Console.WriteLine(Reihenfolge_info.Dequeue())
    54. Case 2
    55. prc = New Process
    56. prc.StartInfo.FileName = "notepad.exe"
    57. prc.Start()
    58. prc.WaitForExit()
    59. Console.WriteLine(Reihenfolge_info.Dequeue())
    60. Case 3
    61. prc = New Process
    62. prc.StartInfo.FileName = "notepad.exe"
    63. prc.Start()
    64. prc.WaitForExit()
    65. Console.WriteLine(Reihenfolge_info.Dequeue())
    66. Case Else
    67. Console.WriteLine("error")
    68. End Select
    69. End While
    70. Return 0
    71. End Function
    72. End Class

    egon schrieb:

    Es wird nicht der Task gekillt, sondern nur der Ablaufsteuerung mitgeteilt, dass keine weiteren Schritte mehr ausgeführt werden sollen.
    Jo - genau das ist eine sehr gängige Umsetzungen von Thread-Cancellation.

    egon schrieb:

    muss ich selbst wissen wann ich mit dem Abfragen der Messergebnisse starte, da ich vom dem Gerät keine Rückmeldung bekomme wenn es fertig ist.
    Echt? Ich hatte das so verstanden, dass das MessProggi eine Datei erstellt.
    Jo, und das kriegt der FSW mit, und kanner als "Messung fertig" auffassen.

    Aber vlt. gehts auch nicht, ich kenn mich mit FSW nicht gut aus. Evtl. kann er zwar detectieren, dass die Messdatei entsteht, aber nicht, wann der Entstehungs-Vorgang abgeschlossen ist.
    In dem Fall ist man denn doch wieder auf Timer oder sowas zurückgeworfen.


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

    egon schrieb:

    da ich vom dem Gerät keine Rückmeldung bekomme wenn es fertig ist.

    egon schrieb:

    Wenn Daten ausgelesen werden, schreibt das andere Programm die Daten in eine txt.Datei die ich dann anschließend auswerte.
    Du solltest Dich mal festlegen.
    =====
    Ich habe das so verstanden:
    Das Programm sagt Dir, wenn es fertig ist, indem die Datei mit den Messwerten auf der Festplatte abgelegt ist.
    Falls dem so ist, nimm einen FileSystemWatcher.
    Falls dem nicht so ist, erkläre präzise, wie es tatsächlich ist.
    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!

    Mit D:\Programme\KE5FX\GPIB\talk 18 "RL -52dB;RB 10KHZ;VB 10HZ;AT 0DB;CF 1MHZ;SP 0HZ;ST 1000MS" teile ich dem Messgerät mit, welche Einstellungen gewählt werden. So wird das Programm "talk" mit den angegebenen Parametern gesartet und erledigt die Kommunikatin mit dem Messgerät. Das ST 1000MS Bedeute "Sweep Time 1000ms", also interne Messdauer 1 Sekunde. In der kommenen Sekunde wandert der Strahl der Bildröhre vom Messgerät über seinen Bildschirm und ergibt die Messung aus dem Anhang (Bild einer Messung vom Messgerät). Erst nach einer Sekunde sind nur noch neue (gültige) Werte zu sehen. Dann dann macht es Sinn die Werte abzufragen mit: D:\Programme\KE5FX\GPIB\binquery.exe 18 "TDF P TRA?" messdaten.txt Dann werden die Werte in die Datei messdaten.txt geschrieben.
    Die Messdaten.txt ist formatiert in der Art -77.74,-77.76,-77.76,-77.72,-77.65,-77.74,-77.72,-77.65,-77.69,-77.74,-77.78,… (401 Werte) Aus diesen 401 Werten wird dann sofort der Median gebildet und der Median als neues Zwischenergebnis behandelt.
    Sind wir jetzt auf einer Wellenlänge? Vielleicht hätte ich es gleich mit einem Bild erklären sollen - sorry für die Verwirrung.

    [EDIT 1] Aus vier Teilmessung (mit unterschiedlichen Einstellen an der Messhardware (Relaisstellungen)) kann dann ein neuer Datenpunkt (gesuchter Messwert) berechnet werden Aus mehreren Datenpunkten ergibt sich dann eine Messkurve. Ein Bild einer solchen Messkurve (ältere Softwareversion) habe ich auch angehängt. (Kapitel 4 mit dem Datenmodell ist so nicht mehr aktuell.)

    [EDIT 2] Um es niemanden vorzuenhalten - auch wenn es für eine weitere Diskussion vermutlich nicht mehr notwendig ist - das PDF von mir mit weiteren Infos.
    Bilder

    • Rauschmessung.gif

      8,1 kB, 640×480, 92 mal angesehen

    • Mein Programm.png

      76,27 kB, 1.407×819, 61 mal angesehen
    Dateien

    Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von „egon“ ()

    egon schrieb:

    Dann dann macht es Sinn die Werte abzufragen mit:
    Offensichtlich ist in dieser Zeit von dem Messprogramm eine Datei auf der Festplatte abgelegt worden.
    Der Unterschied zur vorherigen Messdaten-Datei selben Namens besteht darin, dass die Datei geöffnet oder gelöscht wurde, danach beschrieben wurde und der Schreibvorgang vom System beendet wurde, indem die neue Datei geschlossen wurde.
    All dies meldetr Dir der FileSystemWatcher.

    egon schrieb:

    Sind wir jetzt auf einer Wellenlänge?
    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!

    Scheinbar immer noch nicht. ?(
    Erst nach der Wartezeit von einer Sekunde sieht man auf dem Bildschimt vom Messgerät vollständig korrekt Messwerte. Erst dann beginnt man mit D:\Programme\KE5FX\GPIB\binquery.exe 18 "TDF P TRA?" messdaten.txt abzufragen. Im Laufe dieser Abfrage schreibt Binquery.exe eine neue messdaten.txt und überschreibt die alte Datei ohne Nachfrage. Erst wenn sich binquery.exe selbst beendet hat, ist die Messung beendet. Das funktioniert eigentlich fehlerfrei mit proc.Start() und proc.WaitForExit(). Jetzt läuft der Messvorgang sowieso im Hintergrund und dann stölt doch ein Warten auf WaitForExit nicht ;-).
    Zu dem Paramtert von binquery.exe: 18 ist die Busadresse des Messgerätes; "TDF P TRA?" der Befehlt zum Starten eines Auslesevorgangs und messdaten.txt das Ziel. Der Auslesevorgang dauert rund 3 Sekunden.
    Müsste ich für den FileSystemWatcher nicht vor der Messung die Datei messdaten.txt löschen? Das Warten auf WaitForExit funktioniert fehlerfrei und sicher und dauert nicht länger.

    @egon Ist diese Kommunikation einseitig?
    Du schaust auf den von diesem Programm generierten Bildschirm,
    danach schickst Du einen Befehl an dieses Programm,
    danach schreibt dieses Programm Daten in eine Datei?
    Brrrrrrrrrrrrrr. :S
    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!

    Die Kommunikation ist recht einseitig. Nur schaue ich nicht auf den Bildschirm und warte auf das Ende der Messung, da mir bekannt ist, dass sie eine Sekunde dauert - ich habe es vorgegeben. Diese Zeit muss ich eben warten, also 1000ms plus 200ms zur Sicherheit = 1200ms.
    Ich gebe den Befehl zum Auslesen der Messwerte und das Gerät liest Messwerte aus - ob es sinnvoll oder nicht. Dass muss ich irgendwie anders herausbekommen. Bei anderen Messungen in anderen Situationen mag es sinnvoll zu sein die Werte zu einem beliebigen Zeitpunkt abzurufen - aber leider nicht bei mir. Mein Messgerät ist rund 20 Jahre alt und sehr flexibel in unterschiedlichen Situationen einsetzbar. Der Nutzer muss die Eigenheiten und Eigenschaften des Gerätes eben kennen und sie zu seinem Vorteil nutzen. Modernere Messgeräte dieser Art sind eigentlich nur von Firmen zu bezahlen und deren Befehlstsatz dann nicht unbedingt besser, wohl aber deren Genauigkeit und der Bildschirm ;-). Vor 20 Jahren war mein Gerät "absolut high end" ;-). Das ist sehr lange her und das verwendete Busprotokoll noch viel älter... Sehr gut ist aber, dass die Schaltpläne und Befehlssätze sehr gut beschrieben sind.

    Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von „egon“ ()

    egon schrieb:

    ich habe es vorgegeben.
    Das ist doch eine ideale Bedingung für einen FileSystemWatcher.
    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!

    Leider sind wir hier nicht auf einer Wellenlänge. Um ein aktive Warten (timer, sleep, wait,...) komme ich hier nicht herum. Wenn ich die Einstellungen an das Gerät sende und damit die Messung starte werden die Befehle dem Gerät übermittelt und es wird nicht gewartet bis die Messung beendet wird. Es wird nur die Messung angestoßen. Ich habe gerade mal die Messzeit auf 10 Sekunden erhöht und nochmals untersucht, ob es auch anders geht - leider nicht. Das Gerät sendet keine Rückmeldung ab wann es sinnvoll das Auslesen der Werte anzustoßen. Das alte Kommunikationaprotikoll lässt keinen anderen Weg zu. Das stört mich auch nicht wirklich, da ich mit Beitrag #25 eine gut funktionierende Variante gefunden habe.

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

    Kommen denn immer konstant viele Werte (401, richtig?) in der Geräteausgabedatei raus? Wenn ja, dann könntest Du das Programm mit kleinen Pausen dazwischen solange die Datei auswerten lassen, bis alle Werte vorhanden sind:
    PseudoCode:

    VB.NET-Quellcode

    1. Dim AuslesenWarVollständig = False
    2. SchickeParameterAnGerät()
    3. For i = 1 To 10 'oder ein anderer MaxWert
    4. WarteEineSekunde()
    5. If WerteInDatei.Count = 401 Then AuslesenWarVollständig = True: Exit For
    6. Next
    7. If Not AuslesenWarVollständig Then MessageBox.Show("Das Gerät ist anscheinend immer noch nicht fertig. Da stimmt doch was nicht."): Exit Sub
    8. 'und hier dann weitermachen
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

Facebook
Telefonspende