Sinnvolle Datenstruktur anlegen und der richtige Zugriff

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

Es gibt 40 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    jetzt hab ich deinen Edit gelesen, und dass die Datentypen ja doch im Param vercrypted sind - daraufhin kann ich jetzt meine ParamColumn-Tabelle glaub wieder weghauen.

    Bleibt noch die Frage, ob zu befürchten ist, dass noch weitere Spalten hinzukommen. Weil wies jetzt ist, ginge das nicht.
    Die Tabellenspalten im relationalen Datenmodell sind unveränderlich - stattdessen müsste man anders modellieren.
    Modelliert man anders, ergeben sich aber noch viel mehr Probleme, eine Kreuztabellen-Darstellung hinzukriegen.
    Anbei der derzeitige Stand - Ich hoffe, vb2013 ist ok.


    Kannst du mal feststellen, ob im PlcTag das ValueChanged in einem anneren Thread gefeuert wird, als der Thread, von wo aus gepollt wird?
    Weil wenn das derselbe Thread ist, dann kann man Threading evtl. komplett rauswerfen und die Funktionsweise erheblich einfacher, stabiler, resourcensparender machen.
    Für den Test kannst du etwa Thread.CurrentThread.ManagedThreadId abfragen.
    Dateien

    ErfinderDesRades schrieb:

    Ich hoffe, vb2013 ist ok.


    hab ich geschaut und macht er nicht... auch aufgrund des Tipps mit dem Timer hab ich auch bissl rumgespielt... das is gar nicht schlecht und funktioniert wirklich besser. Hab bei meiner Version also auch den Thread rausgehaun.

    Habs mal kurz laufen lassen und schaut erst mal nicht schlecht aus mit der Zellenmarkierung! Mach ich mich morgen nochmal drüber weil jetz dann Weihnachtsfeier is... :(

    Boch bezüglich VS 2013: mikrocontroller.net/topic/352272?goto=new#new
    Der Beitrag wurde aus 100% wiederverwendbaren Elektronen erstellt!
    Uups... Da ging beim Zitieren was schief.... Das Event feuert nur in diesem Thread. Deshalb hab ich den Thread mal rausgenommen und mit einem Timer realisiert. Geht genauso gut bzw. Sogar besser genau wie von Dir beschrieben.
    Das mit dem Cellhighlithing schaut auf jeden Fall gut aus. Muss aber noch lesen und vor allem verstehen wies genau funktioniert.
    Erstmal hab ich's so verstanden dass das DGV links der Verlauf is. Da mussich aber noch was ändern weil's sich nicht scrollen lässt.
    Der Beitrag wurde aus 100% wiederverwendbaren Elektronen erstellt!
    Wenn das Event im selben Thread wieder rauskommt, dann lässt sich der Daten-Abruf entscheidend vereinfachen:
    Da kann man eine Methode schreiben, die den geänderten Wert - falls geändert wurde - direkt zurückgibt.
    Sodann kann man wirklich alle Zeilen und spalten durchlaufen und pollen, und wenn man eine Änderung bekommt, die sofort eintragen, ohne Umstände machen zu müssen, in welche Zeile und Spalte der Wert denn nun muss.

    Das komische Verhalten vom DGV irritiert mich jetzt auch.
    Üblicherweise kenne ich DGV ja als Eingabe-Control für User, und nicht zum Loggen einlaufender Daten - daher war mir das ühaupt nicht bekannt.

    Edit: Problem gelöst.
    Die ValueBindingSource sollte nicht in Relation zur CurrentValuesBindingSource anzeigen, sondern sollte ans Dataset selbst angehängt werden. Um auf einen bestimmten Kanal zu filtern dann der BS einen entsprechenden Filter setzen.
    Dann loggt das Value-Datagridview ordentlich und ohne diese Mucken mit Cursor und Scrollbar.

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

    Du solltest auch mal untersuchen, was die
    PLCTag.OldValues-Property nach einem Read enthält.
    Ich könnte mir vorstellen, die enthält alle Änderungen seit dem letzten Read.
    Damit könntest du das Polling-Intervall locker auf > 500ms erweitern, ohne dass dir auch nur eine einzige Wert-Änderung dabei entgehen muss.
    Und das ohne Threading und sogar ohne das ganze Event-Geschiss.
    jo, verstehen ist auf jeden Fall gut.
    Aber nicht groß weiter entwickeln - denn post#28 - wenn sich das bestätigt, eröffnen sich ganz annere Möglichkeiten, man müsste ganz anneres mocken, und das Ergebnis sähe wieder ganz anners aus (viel besser).

    Also die Oberfläche wäre dieselbe, nur was darunter liegt wäre sowohl wesentlich simpler als auch performanter.
    Ach ja... es gibt

    VB.NET-Quellcode

    1. PLCTag.BackupValuesCount
    . Beim Initialisieren kann hier ein Wert gesetzt werden welcher die Anzahl der Items von

    VB.NET-Quellcode

    1. PLCTag.OldValues
    Festlegt. Somit vermute ich mal man könnte diese Liste irgendwie an die einzelnen Felder binden... !?

    Mein größeres Problem is vorerst aber noch das Datenbankzeugs. Ich hab Dataset schon öfters verwendet. Aber die Verknüpfungen untereinander hatte ich bisher noch nicht obwohl ich weiß was das macht. Ich muss nur durchsteigen wie und vor allem warum das Verhalten so is wie es is. Und ja... ich habe Deine 4Views usw. bereits mehrmals angeschaut. Aber is halt blöd wenn mans nicht braucht... Dann is es gleich wieder weg weil Übung macht den Meister... :)

    Gruß...
    Der Beitrag wurde aus 100% wiederverwendbaren Elektronen erstellt!

    wolfi_bayern schrieb:

    Somit vermute ich mal man könnte diese Liste irgendwie an die einzelnen Felder binden... !?
    Man kanns dann so hinzaubern, dass man direkt beim Read eine Liste zurückbekommt mit allen Wert-Änderungen seit dem letzten Read.
    So kann man - wenn man will - alle 500ms den neuesten Wert ins DGV stellen, und gleichzeitig aber auch alle zwischenzeitlichen Werte loggen, sodass nicht ein Wertchen verloren geht.
    Und das ohne Threading, glaub sogar ohne Event-Gewurstel!

    Jo, das Datenmodell ist in Teilen sehr unorthodox.
    Eigentlich und klassischerweise wären Kanal, CurrentValues und Param nur eine einzige Tabelle.
    Nun hält Param aber zusätzliche Informationen zu den Spalten von CurrentValue, deshalb ist das so aufgeteilt.
    Und diese Spalten-Zusatz-Informationen werden auch abgespeichert und bla, aber CurrentValues nicht - die ist eiglich nur eine Hilfs-Tabelle zum hübschen Anzeigen im DGV.
    Von daher ist das Datenmodell keine gut Übung für jemanden, der noch übt.
    Statusaktualisierung...

    Ich hab nicht immer dafür Zeit. Muss mir das aber nochmal überlegen wie mans besser machen kann. @Erfinder... Geiler Ansatz... Aber ich häng immer noch.... Hab ich noch einige Details aufzuarbeiten... Für Dich vermutlich einfach... Prinzipiell weiss ich was da passiert aber Du machst das offensichtlich öfters.
    Gruß
    Der Beitrag wurde aus 100% wiederverwendbaren Elektronen erstellt!
    mittm Dataset schon öfters, aber mit diese komische Steuerung ist mir auch neu.
    Wie gesagt: Kernfrage ist, ob in PLCTag.OldValues wirklich alle vergangenen Werte drinne sind, seit dem letzten Pollen.
    Und weiter gefragt, ob dort auch Werte aus dem vorletzten Pollen drin verbleiben (also ob einfach immer bis mw. 500 OldValues aufgefüllt wird) oder ob nach einem Pollen die OldValues wieder gelöscht werden.
    Und noch weiter gefragt: Mir erscheint am wahrscheinlichsten, dass man die OldValues selber iwie löschen kann.

    Mit diesen Infos könnte ich einen neuen Mock basteln, und dann eine ganz annere, viel einfachere, resourcenspar und glaub sogar leistungsfähigeren Ansatz entwickeln.
    Die Anzahl der PLCTag.OldValues lässt sich scheinbar über PLCTag.BackupValuesCount = 500 einstellen, da OldValues ja eine List(of ) is. Somit würden die letzten 500 Polls gespeichert.

    Und die Steuerung is eine ganz normale Steuerung wie sie in so ziemlich allen Produktionsmaschinen eingesetzt wird.
    Der Beitrag wurde aus 100% wiederverwendbaren Elektronen erstellt!

    wolfi_bayern schrieb:

    lässt sich scheinbar
    Das würde ich dich bitten, zu überprüfen.
    Ich mag nicht dolle was neues aufsetzen, und es basiert auf Annahmen.

    Du kannst etwa dir von einem PLCTag den Wert von OldValues.Count mit Debug.Print jeweils ausgeben lassen, da sollten sich während der Laufzeit - zumindest nach dem Start, Änderungen ergeben:
    ZB sollte man nachverfolgen können, wie es sich bis 500 auffüllt.