Entwickler-Ecke

IO, XML und Registry - Welches Dateiformat vewenden für Messwert Ablage


mkRE - So 10.01.16 00:02
Titel: Welches Dateiformat vewenden für Messwert Ablage
Hallo zusammen,

ich wende mich an euch um mich beraten zu lassen und hoffe ich habe den richtigen Forum bereich gefunden.

Eine Beispiel Anwendung:

Ich möchte in einem Zeitabstand einen Messwert erfassen für eine gewisse Arbeit, diese Arbeit hat ein Anfang und ein Ende, jedoch kann die Dauer immer unterschiedlich sein.

Hier meine Fragen wobei ich nicht weiß wie es am besten zu lösen wäre:

1: Wenn ich die Messwerte in eine Datenbank in bestimmten Intervallen ablege, wie bekomme ich diese Daten aus einer Datenbank noch zusätzlich in eine einzelne Datei.
2: Welcher Dateiformat wäre für die oben beschriebene Ablage zum Empfehlen bzw. was verwendet man für solche Anwendungsfälle generell?
3: Wie bekomme ich Messwerte anstatt in eine Datenbank direkt in eine Datei abgelegt, welche Methoden sind da zu empfehlen?
4: Wie bekomme ich diese Daten wieder zurück auf meinen Bildschirm meiner Anwendung bzw. wie kann ich solche Daten wieder anzeigen, welche Methoden sind da zu Empfehlen?

Ich arbeite mit Visual Studio 2012 - C#

Würde mich sehr freuen wenn ihr mich da beraten könnt.

Viele Grüße und vielen Dank im voraus.


Ralf Jansen - So 10.01.16 13:21

Für eine Empfehlung wären die Rahmenbedingungen entscheidend.

a.) Wie viele Messwerte werden dauerhaft gespeichert.
b.) Wie schnell müssen Messwerte angefügt werden können.
c.) Wie sollen die Daten weiterverwendet werden.

Je nach Antwort wäre dann noch wichtig ob die zusätzliche Datei ein sofort Ding ist (die muss gleichzeitig mitgeschrieben werden um auch sofort zur Verfügung zu stehen) oder ist es eher ein zu einen beliebigen Zeitpunkt erstellbar Export aus der Datenbank. Du deutest unter 3 zwar schon ersteres an. Es klingt aber merkwürdig gleichzeitig 2 Formate schreiben zu wollen. Oder ist die Überlegung eher eine Datei anstatt einer Datenbank zu verwenden und nicht zusätzlich? Wenn du darüber nachdenkst nur eine Datei zu verwenden ist es wichtig zu Wissen wie du gedenkst die Daten auszuwerten. Einen Datenbank bringt ja eine einfache Auswertemöglichkeit mit (im simpelsten Fall halt SQL) bei einer Datei fehlt dir jegliche Infrastruktur. Wenn deine Auswerte bedeutet man muss eh alle Daten in den Speicher laden wäre das aber möglicherweise irrelevant.


mkRE - Mo 11.01.16 00:48

Hallo Ralf danke für deine Antwort freue mich das du mich hier berätst.

a.) Es wären an die 120 (Max 240) Messwerte die ich mir vorstelle.
b.) Die Messwerte werden dann in einem Intervall von 500ms angefügt.
c.) Die Daten sollten schon kurz nach dem Vorgang wieder angezeigt werden können aber auch zu einem späteren Zeitpunkt zur Verfügung stehen.

Um es zu vereinfachen, ich würde gerne die Daten in einer Datenbank haben aber bei Bedarf als eine Datei abspeichern können.
Diese Datei würde ich dann gerne wieder öffnen können und den Inhalt Anzeigen z.B. an einer anderen Stelle an einem anderen Ort.

Danke und Viele Grüße


Ralf Jansen - Mo 11.01.16 21:06

Zitat:
a.) Es wären an die 120 (Max 240) Messwerte die ich mir vorstelle.
b.) Die Messwerte werden dann in einem Intervall von 500ms angefügt.


Die Frage hast du vermutlich missverstanden. Ich wollte bei a.) den ungefähren Gesamtumfang wissen als das was sich nach Monate/Jahren so anhäuft. Oder wie viel an Daten pro Zeiteinheit zusammenkommt.
1000 Datensätze/Tag oder 1Millionen Datensätze/Monat oder sowas. Was du schreibst bzw. ich so verstehe sind bei 240 Messwerte in 0.5 Sekunden Intervall die Anwendung nach 2 Minuten am Kapazitätsende. Das kannst du so nicht gemeint haben ;)


jfheins - Mo 11.01.16 22:22

Angesichts von "ich würde gerne die Daten in einer Datenbank haben aber bei Bedarf als eine Datei abspeichern können" würde ich jetzt mal SQLite empfehlen.

Das ist eine Dateibasierte Datenbank. Das heißt, du hast zwar eine ganz normale Datei (der Endbenutzer braucht keinen fetten Datenbankserver installieren) aber du kannst trotzdem mit einigen Datenbank-Features drauf zugreifen. Das lässt sich wohl auch einfach über ein nuget-Package installieren: https://www.nuget.org/packages/System.Data.SQLite/
Leider muss ich gestehen, dass ich noch nicht viel damit gemacht habe, aber was ich gesehen uns gelesen habe, sieht sehr vielversprechend aus ;-)


mkRE - Do 14.01.16 00:02

Hallo Ralf, tut mir leid das ich erst jetzt Antworte.

Ich habe mir die geplante Anwendung mal durch den Kopf gehen lassen folgendes ist entstanden :idea: :

Dauerhaft sollen pro Tag alles mal grob gerechnet 5,5MB bzw. 1440 Datensätze gespeichert werden, es wären in meinem Fall letztendlich 120 Messwerte pro Minute.

Allgemein möchte ich bei einem Prozess der eine Arbeit durchführt (Dauer eines Prozesses 60s) einen 32bit Wert z.B. eine Temperatur in 0,5s Schritten ablegen und als Datei abspeichern.
Diese Datei sollte dann nach dem Prozess in eine Datenbank abgelegt werden so das ich diese unter einer bestimmten ID wiederfinden kann.
Zusätzlich soll es möglich sein diese Messwerte nach dem Prozess direkt anzeigen zu können oder auch bei bedarf, weiterhin sollte diese Datei am besten bei bedarf exportierbar sein z.B. speichern auf einen USB Stick.

Um die Daten sicher speichern zu können, habe ich eher daran gedacht diese in eine Datei lokal in einem PC zu Speichern, falls der Intervall Anstatt 500ms dann irgendwann 10ms werden sollte, will ich Datenverluste vermeiden wenn die Datenbank im Extremfall weiter entfernt ist oder anderseits überlege ich die Datensätze auf einer kleinen lokalen Datenbank zu speichern und dann nach Prozessende ohne Stress in eine Datei abzulegen .... . Ist der Gedanken weg so richtig?

Viele Grüße und Danke.


mkRE - Do 14.01.16 00:09

Hallo jfheins,

danke für den Link gerne schaue ich mir das an.
Du sagtest du hast noch nicht viel damit gemacht, würde mich aber interessieren was dieses nicht viel war?
Welche Daten hast du da gespeichert und in welchem Umfang?

Würd mich freuen wenn du da was zu schreiben würdest.

Viele Grüße


Ralf Jansen - Do 14.01.16 00:20

Zitat:
Ist der Gedanken weg so richtig?


Weiß noch nicht ;) Ich habe den tatsächlichen Bedarf für eine Datenbank noch nicht rausgehört.

Was du einen Prozess nennst (das was 60 Sekunden dauert) würde in deiner Überlegung einer Datei entsprechen?`
Und diese Prozesse sind unabhängig voneinander? Es gibt also keine Prozessübergreifende Auswertung oder sowas in der Richtung?
Dann sehe ich keinen Bedarf für eine Datenbank und würde gleiche nur die Dateien erstellen.


mkRE - Do 14.01.16 01:27

In dem Prozess wird sagen wir mal in 60s ein Kuchen gebacken (Absoluter Schwachsinn :D aber gilt nur als Beispiel).

Der Kuchen wird dann eine eigene ID haben und unter der ID wird dann die Back Temperatur als Datei in eine Datenbank gelegt.
Vorerst wäre eine Datenbank nur dafür angedacht. Die aktuellen Messwerte im Prozess werden auf einem Trend angezeigt.

Wenn es zu dem Thema anscheinend nach einer Datei aussieht, würde mich sehr interessieren wie weit die Grenzen für eine Datei sind.
Könnte ich Problemlos 10 * 120 Messwerte pro Minute aufnehmen? Gibt es da Kapazität Grenzwerte?

Würde dort z.B. eine XML Datei in Frage kommen? Wichtig wäre für mich das ich die Messwerte aus der Datei heraus wieder anzeigen kann.

Ralf was meinst du genau mit:
Zitat:
Und diese Prozesse sind unabhängig voneinander? Es gibt also keine Prozessübergreifende Auswertung oder sowas in der Richtung?



Viele Grüße


Palladin007 - Do 14.01.16 02:21

user profile iconmkRE hat folgendes geschrieben Zum zitierten Posting springen:
Wenn es zu dem Thema anscheinend nach einer Datei aussieht, würde mich sehr interessieren wie weit die Grenzen für eine Datei sind.
Könnte ich Problemlos 10 * 120 Messwerte pro Minute aufnehmen? Gibt es da Kapazität Grenzwerte?


Also wenn es da Grenzwerte gibt, dann wohl die Performance des Speichermediums und die Maximalgröße einer Datei.

Hat NTFS eine Obergrenze? Ich glaube nicht :D
Bis Du da eine Grenze erreicht hast, gibt es die neue 3D XPoint-Technik (Spannende Sache, unbedingt mal danach suchen ^^) in jedem PC :D

Die Performance-Geschichte:
10 * 120 Messwerte pro Minute, das heißt, bei jedem Messwert bleiben etwa 50ms, das ganze zu schreiben.
Ob das knapp wird, kann ich nicht beurteilen. Wenn es pro Messung nur einzelne Integer-Werte sind und die Messung selber schnell genug ist, sollte das klappen.
Alternativ kannst Du die Werte sammeln und in einem seperaten Thread z.B. alle 30 Sekunden auf die Platte schreiben.
Ob das alles ist: Probiere es aus. Der Flaschenhals wird hier die HDD sein - denke ich

user profile iconmkRE hat folgendes geschrieben Zum zitierten Posting springen:
Würde dort z.B. eine XML Datei in Frage kommen? Wichtig wäre für mich das ich die Messwerte aus der Datei heraus wieder anzeigen kann.


XML würde ich bei sowas nicht nutzen. Besonders, wenn Du auch mal 1200 Werte pro Minute anpeilen willst, wird XML problematisch.
Der Grund ist, dass XML im Grunde immer komplett geladen und dann am Stück wieder geschrieben werden muss, das wäre ein riesiger Overhead, der nicht nötig ist.
Besser wäre ein einfaches Format (irgendwas simples, Trennzeichen getrennt zum Beispiel), wo ein Datensatz in einer Zeile liegt. Das lässt sich simpel schreiben und lesen, außerdem kannst Du einen Stream öffnen und ohne viel Zeitverlust den neuen Wert stumpf ans Ende anhängen.



Ich habs oben schon geschrieben, aber nochmal zusammen gefasst:
Ich würde die Messwerte sammeln und in einem bestimmten Zeitintervall auf die Festplatte schreiben. Wann, das solltest Du daran fest machen, wie viel Verlust (zeitlich betrachtet) Du verschmerzen kannst.
Wenn es sich um einfache atomare Werte handelt, kann das ruhig in einer Datei zeilenweise z.B. mit Trennzeichen getrennt geschrieben werden. Lesen und Schreiben ist schnell und einfach möglich. Allerdings können komplexere Daten schnell Probleme machen. XML - finger weg ^^
Eine Datenbank wie SQLite ist vielleicht auch ganz brauchbar. Pro Tag eine neue Datenbank-Datei, das lässt sich leicht kopieren und einen besseren Mittelweg zwischen Flexibilität und Performance findest Du eigentlich nur noch bei NoSQL.
Auf Basis der einzelnen Datenbank-Dateien kannst Du dann arbeiten. Export in z.B. CSV ist simpel, anzeigen auch und Schreiben der Daten ist definitiv schneller, als XML. Gleichzeitig lässt es sich aber leichter bzw. komplexer ergänzen, also bei einem eigenen zeilenbasierten Format.


Christoph1972 - Do 14.01.16 07:50

Hallo zusammen,

ich denke ich würde der Einfachheit halber eine DataTable nehmen, die Messpunkte immer in .Rows.Add(neuer Messpunkt) mitführen und wenn die Messung vorüber ist mit .WriteToXML(\..\DeineMessID.xml) weg schreiben. Für jede Messung wird eine Datei angelegt, die mit DataTable.ReadXML(DeineMessID.xml) wieder eingelesen werden kann.

Mit einer serialisierbaren Klasse und einer Liste würde das natürlich auch gehen, da könnte man noch prima andere Werte mit speichern. Aber wie gesagt, mit einer DataTable und den WriteXML und ReadXML ist das sehr einfach und schnell gelöst.

Messen ist immer eine interessante Angelegenheit :-)


Palladin007 - Do 14.01.16 08:26

Ich bin ja so gar kein Freund von der DataTable :D
Untypisiert und es wirkt für mich wie eine Lösung, die Falheit und mangels besseren Wissens ausgewählt wurde.
Dann doch lieber die Klasse, deren Objekte in eine Liste kommen und das ganze wird dann mit dem XmlSerializer serialisiert.

Dann bleibt aber noch das Problem: Tritt irgendwo ein Fehler auf, kann es im schlimmsten Fall sein, dass die ganze Messung für'n Ar*** ist.
Wird direkt auf die Platte geschrieben, kann theoretisch alles passieren, solange die HDD noch in Takt ist, gibt es alle Messungen bis zu dem Punkt, wo abgebrochen wurde.


C# - Do 14.01.16 08:57

Also wenn ich das richig sehe, besteht dein Datensatz nur aus einem Integer Wert, korrekt? Wenn der Datensatz wirklich so primitiv ist würde ich einen BinaryWriter nehmen. Der ist schnell und erzeugt keinen unnötigen overhead wie XML Tags. Da braucht ein Integer tatsächlich nur 4 Byte.

Was die Performance der HDD angeht: ich meine, irgendwo gelesen zu haben, dass Windows alle HDD Zugriffe puffert. Solange du also die Datei offen lässt, solltest du dir keine Gedanken darüber machen.


Palladin007 - Do 14.01.16 09:26

user profile iconC# hat folgendes geschrieben Zum zitierten Posting springen:
Was die Performance der HDD angeht: ich meine, irgendwo gelesen zu haben, dass Windows alle HDD Zugriffe puffert. Solange du also die Datei offen lässt, solltest du dir keine Gedanken darüber machen.


Wie sieht das denn aus, wenn der Stream nicht geschlossen wird?
Behält Windows die Daten im Puffer und schreibt sie weiter in die Datei, oder gehen die verloren, wenn z.B. das Programm abschmiert?


tomte - Do 14.01.16 11:33

user profile iconPalladin007 hat folgendes geschrieben Zum zitierten Posting springen:
user profile iconC# hat folgendes geschrieben Zum zitierten Posting springen:
Was die Performance der HDD angeht: ich meine, irgendwo gelesen zu haben, dass Windows alle HDD Zugriffe puffert. Solange du also die Datei offen lässt, solltest du dir keine Gedanken darüber machen.


Wie sieht das denn aus, wenn der Stream nicht geschlossen wird?
Behält Windows die Daten im Puffer und schreibt sie weiter in die Datei, oder gehen die verloren, wenn z.B. das Programm abschmiert?


Wenn der Stream nicht geschlossen wird und auch kein flush durchgeführt wurde, dann sind die noch nicht geschriebenen Daten bei einem Absturz des Programms verloren.
Aber auch nach dem Schließen des Streams können die Daten noch verloren gehen, wenn Windows selbst abstürzt, oder der Strom ausfällt, bevor Windows die Daten aus seinem Buffer wirklich auf die HDD geschrieben hat.


C# - Do 14.01.16 12:01

Windows hat eine Caching Funktion, die kann an- und ausgeschaltet werden. Die Cache ist dann einfach nur ein Bereich im RAM. Wenn Daten auf die Platte geschrieben werden sollen, werden sie statt dessen in den RAM geschrieben und Windows wird benachrichtigt, dass noch offene Speicheroperationen anstehen. Sobald dann Kapazitäten frei sind, werden die Daten vom Cache auf die Platte geschrieben und aus dem Cache entfernt.


Ralf Jansen - Do 14.01.16 12:40

user profile iconmkRE hat folgendes geschrieben Zum zitierten Posting springen:
Ralf was meinst du genau mit:
Zitat:
Und diese Prozesse sind unabhängig voneinander? Es gibt also keine Prozessübergreifende Auswertung oder sowas in der Richtung?


Du beschreibst deine Prozesse so als hätten sie mit den anderen nix zu tun. Wenn die nix miteinander zu tun haben und es keine gemeinsame Auswertung gibt (z.B. erzeuge Statistiken über alle Prozesse), also etwas wo eine Datenbank stark drin wäre, sehe ich nicht warum man die in einer Datenbank zusammenwerfen sollte wenn das einzige was sie da tun zusammen rumzuliegen ist. Schon gar nicht wenn noch im Raum steht gleichzeitig Dateien mit den gleichen Daten erzeugen zu wollen.

Um zu entscheiden welches Fileformat (wenn man ohne DB arbeitet) das richtige wäre, überlage ob

a.) das File sofort bei Eingang des Messwerts geschrieben werden muß oder reicht ein Flush zu einem oder mehreren bestimmten Zeitpunkten (z.B. am Ende der Messreihe)
b.) Sollte das File auch ohne deine Anwendung einsehbar oder sinnvoll weiterverarbeitbar sein
c.) Das Format der Messwerte. ISt es wirklich einfach nur ein Wert oder doch mehr (z.B. Wert, Zeitpunkt, gemessene Resource etc.)


Christoph1972 - Do 14.01.16 18:45

user profile iconPalladin007 hat folgendes geschrieben Zum zitierten Posting springen:
Ich bin ja so gar kein Freund von der DataTable :D
Untypisiert und es wirkt für mich wie eine Lösung, die Falheit und mangels besseren Wissens ausgewählt wurde.
Dann doch lieber die Klasse, deren Objekte in eine Liste kommen und das ganze wird dann mit dem XmlSerializer serialisiert.

Dann bleibt aber noch das Problem: Tritt irgendwo ein Fehler auf, kann es im schlimmsten Fall sein, dass die ganze Messung für'n Ar*** ist.
Wird direkt auf die Platte geschrieben, kann theoretisch alles passieren, solange die HDD noch in Takt ist, gibt es alle Messungen bis zu dem Punkt, wo abgebrochen wurde.


Hi,

ich habe das auch nur der Einfachheit wegen vorgeschlagen. Für diesen Anwendungsfall würde das sehr gut funktionieren und wäre in ca. 5min realisiert.

Mit einem Fehler beim messen ist das eh so eine Sache. Bei mir ist das so, wenn ein Fehler auftritt, ist die Messung für den A.... und muss wiederholt werden. Gibt es Messungen die man wieder ab der Unterbrechung aufnehmen kann? Da wo ich herkomme nicht.


mkRE - Sa 16.01.16 22:21

Hallo Zusammen, tut mir leid das ich mich erst jetzt melde.

Allgemein gefallen mir wirklich alle Lösungsvorschläge am meisten wegen der Einfachheit halber von Christoph1972 jedoch bitte nimmt das nicht persönlich.
Es wird meine erste Anwendung in Hochsprache in dieser Form sein daher frage ich vorab nach Ideen von euch aber gerne möchte ich noch alle Frage beantworten und die Antwort abwarten :) .

Achso noch ein paar Fragen:

user profile iconPalladin007 hat folgendes geschrieben Zum zitierten Posting springen:

Dann doch lieber die Klasse, deren Objekte in eine Liste kommen und das ganze wird dann mit dem XmlSerializer serialisiert.


Wird mit listen z.B. eine TextDatei gemeint?

user profile iconPalladin007 hat folgendes geschrieben Zum zitierten Posting springen:

Wird direkt auf die Platte geschrieben, kann theoretisch alles passieren, solange die HDD noch in Takt ist, gibt es alle Messungen bis zu dem Punkt, wo abgebrochen wurde.


Was wird genau mit auf Platte schreiben gemeint und welche Datei kann ich mir da vorstellen?

Vielen Dank an alle.


mkRE - Sa 16.01.16 23:10

Hallo Ralf,

die Messwerte werden nur zu dem jeweiligen "Kuchen" ausgewertet, gemeinsame Auswertungen sind (noch) nicht eingeplant.

user profile iconRalf Jansen hat folgendes geschrieben Zum zitierten Posting springen:

a.) das File sofort bei Eingang des Messwerts geschrieben werden muß oder reicht ein Flush zu einem oder mehreren bestimmten Zeitpunkten (z.B. am Ende der Messreihe)
b.) Sollte das File auch ohne deine Anwendung einsehbar oder sinnvoll weiterverarbeitbar sein
c.) Das Format der Messwerte. ISt es wirklich einfach nur ein Wert oder doch mehr (z.B. Wert, Zeitpunkt, gemessene Resource etc.)


Zu a: Es reicht hier das die Messwerte zu einem bestimmten Zeitpunkt geschrieben werden aber zusätzlich noch auf dem Bildschirm bis zum beginn eines neuen Prozesses erhalten bleiben.
Zu b: Ja es sollte möglich sein auch ohne meiner Anwendung die Messwerte zu sehen ( z.b. Excel).
Zu c: Danke das du das angesprochen hast habe ich komplett vergessen, natürlich möchte ich auch den Zeitpunkt mit schreiben.

Danke

Viele Grüße


Christoph1972 - Sa 16.01.16 23:11

user profile iconmkRE hat folgendes geschrieben Zum zitierten Posting springen:
Wird mit listen z.B. eine TextDatei gemeint?


Nein damit ist ein Klasse mit einer generischen Liste gemeint.


C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
[Serializable]
public class Measurement
{
    public Measurement()
    {
    ListOfPoints = new List<PointValues>();
    }

    public string Name { get; set; }
    public DateTime Measurementdate { get; set; }

    public List<PointValues> ListOfPoints { get; set; }
}

[Serializable]
public class PointValues
{
    /// <summary>
    /// Time
    /// </summary>
    public int X { get; set; }
    /// <summary>
    /// Amplitude
    /// </summary>
    public int Y { get; set; }
}



Serialisieren kann man das dann so:

Klasse die die De-/Serialisierung übernimmt.

C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
public class MySerializer
{
    public static void Serialize(object myClass, string directory, string file)
    {
        if (!Directory.Exists(directory))
            Directory.CreateDirectory(directory);

        string fileabs = Path.Combine(directory, file);

        using (FileStream myFileStream = new FileStream(fileabs, FileMode.Create))
        {
            BinaryFormatter binFormatter = new BinaryFormatter();
            binFormatter.Serialize(myFileStream, myClass);
        }
    }

    public static object Deserialize(string file)
    {
        object oldObject = null;

        if (File.Exists(file))
        {
            using (FileStream myFileStream = new FileStream(file, FileMode.Open))
            {
                BinaryFormatter binFormatter = new BinaryFormatter();
                oldObject = binFormatter.Deserialize(myFileStream) as object;
            }
        }
        return oldObject;
    }
}



Speichern /laden:

C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
private void LoadSave()
{
    //Messung starten
    //================
    Measurement m = new Measurement() { Name = "Messung1", Measurementdate = DateTime.Now };

    for(int i = 0; i < 100; i++)
    {
        m.ListOfPoints.Add(new PointValues() { X = i, Y = i });
    }
    //================
    
    //Wegschreiben
    MySerializer.Serialize(m, @"c:\Test""Messung1.mes");

    //Wieder einlesen
    var oldMes = MySerializer.Deserialize(System.IO.Path.Combine(@"c:\Test""Messung1.mes"));
}


Alternativ gibt es auch einen XML Serializer.


user profile iconmkRE hat folgendes geschrieben Zum zitierten Posting springen:
Was wird genau mit auf Platte schreiben gemeint und welche Datei kann ich mir da vorstellen?


Damit ist gemeint, das man jeden oder jeden n Messpunkt gleich auf die Festplatte wegschreibt. Stellt sich nur die Frage, ob man mit einer unterbrochenen Messung was anfangen kann, oder wartet man mit dem speichern bis zum Ende vom Lauf? Das kannst nur Du wissen....


Für den Anfang kannst Du aber auch ruhig eine Tabelle verwenden, wenn dir das leichter fällt. Das wird auch sehr gut laufen. Ich verdiene mein Geld mit messen und spreche da aus Erfahrung :-) Aber mein Vorschlag ist auch nicht so schwer, oder?


Palladin007 - Sa 16.01.16 23:20

Bitte nimm keine DataTable (Sorry Christoph :D)
Ja, es ist einfach und Du kannst im Prinzip alles rein werfen, aber das ist auch der größte Nachteil.
Du kannst alles rein werfen, wie das am Ende aus sieht und ob das, was Du rein wirfst, aich so richtig ist, erfärst Du erst irgendwann zur Laufzeit.

Besser wäre sowas:


C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
public class Measurement
{
    public int Size { get; set; }
    public DateTime Timestamp { get; set; }

    // Weitere Eigenschaften:
    // public int MyProperty { get; set; }
}


Und die (beispielhafte) Nutzung:


C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
var measurements = new List<Measurement>();

// So lange neue Einträge der Liste hinzufügen, wie gemessen wird
while (Measuring)
{
    var measurement = new Measurement();

    measurement.Size = GetSize();
    measurement.Timestamp = DateTime.Now;

    // Weitere Eigenschaften:
    // measurement.MyProperty = GetMyProperty();

    measurements.Add(measurement);
}

Serialize(measurements);


Da hast Du eine feste Struktur (Die Klasse Measurement) und der Compiler sagt dir, was nicht passt.
Das Speichern muss aber ohne bereits implementierte Read- und Write-Methode nicht kompliziert sein.
Der XmlSerializer macht das fast genauso einfach. Das "fast", weil das erst einmal implementiert werden muss:


C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
public static void Serialize<T>(string xmlFile, T obj)
{
    var serializer = new XmlSerializer(typeof(T));

    // Erstellt einen neuen Datei-Stream, über den Du auf die Datei zugreifen kannst.
    // Das 'using' sorgt dafür, dass der Stream immer - auch bei einer Exception - geschlossen wird, sonst bleibt die Datei länger gesperrt als gewünscht
    using (var fileStream = File.Create(xmlFile))
    {
        // Das Objekt in die Datei serialisieren
        serializer.Serialize(file, obj);
    }
}
public static T Deserialize<T>(string xmlFile)
{
    var serializer = new XmlSerializer(typeof(T));

    using (var fileStream = File.OpenRead(xmlFile))
    {
        // Die Datei auslesen und die Daten deserialisieren
        return (T)serializer.Deserialize(file);
    }
}


Diese Methoden irgendwo hin legen und aufrufen.
Solange die Objekte serialisierbar sind, ist damit Lesen und Speichern geklärt.
Und keine Sorge: Die Meispielklasse oben ist serialisierbar, solange die Properties öffentlich gelesen und geschrieben werden können und ein public Konstruktor ohne Parameter existiert.
Sowas wie ein Dictionary nicht, allerdings gibt es online ohne Ende Beispiele, wie man das nachliefern kann.

Das hat den Vorteil, dass es sehr einfach ist und Du hast nicht die Nachteile einer DataTable.
Ist es aber unbedingt von Bedeutung, dass im schlimmsten Fall zumindest ein Teil der Messwerte erhalten bleiben, dann hast Du da ein Problem.
So kann ich mir z.B. vorstellen, dass eine sehr lang andauernde Messung irgendwann einen Fehler hat und Du die komplette Messung neu starten musst, da die Ergebnisse erst nach der Messung gespeichert werden.

Ob das von Bedeutung ist, das musst Du wissen.
Wenn es von Bedeutung ist, dann musst Du selber manuell schreiben und dir ein eigenes Vormat (z.B. durch Trennzeichen getrennt) ausdenken.


Zitat:
Wird mit listen z.B. eine TextDatei gemeint?


Damit meine ich eine Liste, in der ein Objekt pro Mess-Ergebnis rein kommt.
In meinem Beispiel oben wäre die Variable 'measurements' diese Liste.

Zitat:
Was wird genau mit auf Platte schreiben gemeint und welche Datei kann ich mir da vorstellen?


Damit meine ich den Vorgang, in dem eine Zeile in irgendeine Datei geschrieben wird.
Jede bereits ausprogrammierte Art, etwas in eine Datei zu speichern, wird früher oder später an dem Punkt angelangt sein, dass es einen Text in eine Datei schreiben.
Das heißt dann, es teilt dem Windows mit, es soll doch mal bitte den angegebenen Text in eine Datei schreiben und Windows sorgt dann dafür, dass dieser Text möglichst bald in die Datei - also auf die Festplatte - geschrieben wird.



PS:

Nun war ich doch ein bisschen zu langsam :D

Da ich aber gerade das lese:

Zitat:
Ja es sollte möglich sein auch ohne meiner Anwendung die Messwerte zu sehen ( z.b. Excel).


Dann fällt XML, binäres serialisieren (was Christoph zeigt), oder ähnliches raus.
Du könntest z.B. CSV nehmen, Excel kann das darstellen und es gibt online mehrere Möglichkeiten zu finden, die CSV schreiben oder Lesen können.
Oder Du schreibst das CSV selber, am Ende sind das ja nur durch Semikolon getrennte Werte.


Christoph1972 - So 17.01.16 09:47

Guten Morgen :-)

Also, wenn XML und Binary wegfallen, dann würde ich statt csv doch lieber die XML Variante vom DataTable nehmen. Beides ich ist untypisiert, beide Formate können mit Excel geöffnet werden. XML kann man sich zudem mit einem Internet Browser anschauen. Die CSV Reader die ich bisher verwendet habe, haben auch immer nur eine Tabelle ausgegeben.(Gut möglich das es mittlerweile neue im Netz gibt??) Bei der Variante mit DataTable fällt zudem das String-Gefrickel weg. CSV finde ich irgend wie Altbacken, das gibt es schon seit 1967 :-)


Palladin007 - So 17.01.16 13:27

Stimmt schon, dass CSV altbacken ist, aber es ist einfach und funktioniert überall.
Aber wie kann Excel XML anzeigen? So auf die Schnelle habe ich keine einfache Lösung gefunden, nur dass man ein Zuordnungsschema erstellen muss.

Ich persönlich finde CSV immer noch am besten geeignet. In Excel kann es sofort ohne Anpassungen geöffnet werden und ist kinderleicht zu schreiben.
Kurzes Googlen hat diese [http://www.codeproject.com/Articles/685310/Simple-and-fast-CSV-library-in-Csharp] CSV-Library ergeben.

Ein kleines Beispiel:


C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
public class Measurement
{
    public int Size { get; set; }
    public DateTime Timestamp { get; set; }
    // Weitere Eigenschaften:
    // ...
}

// Das soll die Quelle der Messungen simulieren:
public static class MeasurementSource
{
    private static readonly Random _rnd = new Random();

    public static int GetNextSize()
    {
        return _rnd.Next(01000);
    }

    // Weitere Werte:
    // ...
}

class Program
{
    static void Main(string[] args)
    {
        using (var csvFile = new CsvFile<Measurement>("measurements.csv"))
        {
            // Nur 10 Messungen, weil ich nicht so lange warten sollte :D
            for (int i = 0; i < 10; i++)
            {
                // Zwei Messungen pro Sekunde:
                Thread.Sleep(500);

                var measurement = new Measurement()
                {
                    Size = MeasurementSource.GetNextSize(),
                    Timestamp = DateTime.Now,
                    // Weitere Eigenschaften:
                    // ...
                };

                csvFile.Append(measurement);
            }
        }
    }
}


Das Ergebnis in CSV:

Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
Size;Timestamp
571;17.01.2016 12:17:59
159;17.01.2016 12:17:59
713;17.01.2016 12:18:00
872;17.01.2016 12:18:00
517;17.01.2016 12:18:01
135;17.01.2016 12:18:01
870;17.01.2016 12:18:02
761;17.01.2016 12:18:02
200;17.01.2016 12:18:03
591;17.01.2016 12:18:03


In Excel lässt sich das problemlos öffnen, zumindest bei mir ist Excel als Standart-Programm für CSV eingestellt und ich dann es direkt mit Doppelklick öffnen.



Und das Lesen im Programm:


C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
using (var measurements = new CsvFileReader<Measurement>("measurements.csv"))
{
    foreach (var measurement in measurements)
    {
        Console.WriteLine("Size: " + measurement.Size);
        Console.WriteLine("Timestamp: " + measurement.Timestamp);
        Console.WriteLine("==============================");
    }
}

Console.ReadKey();



Das sieht dann so aus:


Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
Size: 571
Timestamp: 17.01.2016 12:17:59
==============================
Size: 159
Timestamp: 17.01.2016 12:17:59
==============================
Size: 713
Timestamp: 17.01.2016 12:18:00
==============================
Size: 872
Timestamp: 17.01.2016 12:18:00
==============================
Size: 517
Timestamp: 17.01.2016 12:18:01
==============================
Size: 135
Timestamp: 17.01.2016 12:18:01
==============================
Size: 870
Timestamp: 17.01.2016 12:18:02
==============================
Size: 761
Timestamp: 17.01.2016 12:18:02
==============================
Size: 200
Timestamp: 17.01.2016 12:18:03
==============================
Size: 591
Timestamp: 17.01.2016 12:18:03
==============================



PS:
Das Ding ist wirklich schnell.
Wenn ich eine Million Einträge schreiben will, dauert (bei einer Messung) ca. 5,38 Sekunden.
Das Lesen der zuvor angelegten Datei dauert ca. 4,33 Sekunden. Excel braucht da schon deutlich länger


mkRE - So 17.01.16 17:07

Hallo Leute erstmal bin ich sehr sehr begeistert über euer Engagement und die Beispiele -> mehr als ich erwartet habe!!
Ich habe somit viel Stoff wo ich ansetzen kann :D .

Ich komme nochmal zu der Excel Datei bzw. jetzt aktuell CSV Format zurück.
Das war in erster Linie angedacht, das bei der Anwendung die Möglichkeit besteht auf Anfrage diese Datei bzw. Messwert Erfassung jederzeit herunter zu laden damit das auf jeden Haushalt PC angezeigt werden kann, ich glaube aber das habt ihr auch so verstanden.

Wenn jedoch direkt in CSV Format zu schreiben sinnvoll wäre für die angedachte Anwendung, dann interessiert mich wie die Performance bei CSV ist bzw. bin ich da ggf. Zeitlich ihrgendwann an der Grenze wenn es um die schreib Intervalle geht?

Viele wege führen nach Rom aber welcher weg ist der professionelle?
Christoph1972 und Palladin007 eure Ansätze vor dem CSV Thema ist für mich Professional angedacht kiene Frage, da Ihr das auch im Täglichen leben nutzt wie ich verstanden habe.
Aber wie sieht es da mit csv aus für z.B. Messanwendungen(Ich weiß das es verwendet wird aber was ich gesehen habe halt nur als gute Lösung um das Ergebnis Universell auf jedem PC anzeigen zu können via Excel usw. )?

Viele Grüße an alle!!


mkRE - So 17.01.16 17:32

Hallo C#, habe dich übersehen sorry :D

user profile iconC# hat folgendes geschrieben Zum zitierten Posting springen:

Also wenn ich das richig sehe, besteht dein Datensatz nur aus einem Integer Wert, korrekt?


Ich habe bei dem Messwert an ein Real bzw. Float Wert gedacht weil ich noch einige nach Kommastellen haben möchte.

Vielleicht ist das noch wichtig als Information.

Viele Grüße


Ralf Jansen - So 17.01.16 17:53

Zitat:
Wenn jedoch direkt in CSV Format zu schreiben sinnvoll wäre für die angedachte Anwendung, dann interessiert mich wie die Performance bei CSV ist bzw. bin ich da ggf. Zeitlich ihrgendwann an der Grenze wenn es um die schreib Intervalle geht?


File schreiben ist File schreiben da ist das interne Format relativ irrelevant. Wenn du dich zwischen Formaten entscheidest sind die der Faktor Lesbarkeit (soll der Inhalt ohne Zusatzinformation verstehbar sein), Kompaktheit (wieviel Redundanz bringt das Format mit um insbesondere ersteren Punkt zu erreichen) und Weiterverabeitbarkeit (können Fremdsysteme die nix von meiner Anwendung wissen was da was mit anfangen, das angesprochene Excel zum Beispiel) entscheidend. Ein wichtiger Faktor, der bei dir aber wohl nicht wichtig ist, ist ob Daten einfach Appendable sind. Xml, Json sind da eher schwierig zu handhaben und fertige System im Framework gehen eher von komplett lesen/schreiben aus. CSV Daten sind leicht anhängbar darum sind ja die meisten Log Fileformate csv oder zumindest csv ähnlich bzw. binär dann aber schwer von Fremdsystemen weiterverarbeitbar. Soweit ich dein anliegen verstehe ist ein csv Format den anderen Kandidaten vorzuziehen. Letztlich aber wenn du ein sauberes Klassensystem aufgesetzt hast ist der zu benutzende Serializer leicht auszutauschen. Ob es dann JSON, XML, binär, CSV oder was auch immer ist nur noch eine Frage von ein paar Handgriffen. Bei einer Lösung mit einer DataTable wärst du allerdings eher ein gefangener dieser Lösung. Das mal schnell zu ändern eher schwierig. Da du eine Lösung um die DataTable herum schreiben würdest ist die schwer wieder loszuwerden wenn sich die Anforderungen ändern. Ich würde davon, in einer lebenden Anwendung deren Anforderungen nicht festgemeißelt sind, abraten.

Zitat:
Aber wie sieht es da mit csv aus für z.B. Messanwendungen


Messen ist ein ziemlich allgemeiner Begriff. Teilbereiche haben vermutlich spezielle Formate die sich irgendwann als Quasistandard herausgebildet haben. Z.B. Network Sniffer (für mich auch eine Art Messanwendung) benutzen gern pcap (oder Abwandlungen davon). Wenn es sowas in deiner Teildisziplin gibt schau es dir an. Wenn nicht scheint csv erstmal eine gute Wahl.


Palladin007 - So 17.01.16 18:40

Zitat:
Wenn jedoch direkt in CSV Format zu schreiben sinnvoll wäre für die angedachte Anwendung, dann interessiert mich wie die Performance bei CSV ist bzw. bin ich da ggf. Zeitlich ihrgendwann an der Grenze wenn es um die schreib Intervalle geht?


Hast Du mein PS gelesen?
Um Performance mach dir mal keine Sorgen, nach meiner kurzen Messung hast Du in einer Sekunde Zeit für ca. 185000 Messungen.
In einer Sekunde, 185000 Messungen, meins Du, Du kommst da auch nur ansatzweise ran? :D
Da wird deine ganze Anwendung drum herum schon so stark ausbremsen, dass das nicht funktioniert.
Und ich habe keine SSD :D

Das Gleiche für das Lesen der Datei.

So viele Messdaten kannst Du gar nicht sammeln, dass Du bei dieser CSV-Library ein Performance-Problem bekommst.


mkRE - So 17.01.16 23:18

Hallo zusammen, also ich glaube ich habe alle Informationen die ich benötige und wirklich sinnvolle Lösungen erhalten.
Ich kann es nicht oft genug sagen aber ein Lob an die Forum Mitglieder!!!

Für diese Anwendung werde ich besonders aus den Weiterverarbeitungsgründen und der einfachen Handhabung die csv Version wählen.
Hat für meinen Anwendungsfall doch viele Vorteile.

Noch habe ich eine kleinigkeit an Palladin007:

Meinst du den PS zur Performance Geschichte? :) und was meinst du mit deiner kurzen Messung?

Wünsche euch einen schönen Abend.

Viele Grüße


Palladin007 - So 17.01.16 23:58

user profile iconmkRE hat folgendes geschrieben Zum zitierten Posting springen:
Meinst du den PS zur Performance Geschichte? :) und was meinst du mit deiner kurzen Messung?


Das PS unter der Nachricht mit meinem CSV-Beispiel, wo ich mal aufgeführt habe, wie lange es dauert, eine Million Objekte in eine CSV-Datei zu schreiben.
Das meine ich auch mit "meiner kurzen Messung": Die Messung, wo ich die Million Einträge in die Datei schreibe und messe, wie lange das dauert.

Ich wollte damit nur aufführen, dass die Library tatsächlich so schnell ist, wie sie verspricht und Du die Frage, ob es eine Performance-Grenze gibt, komplett ignorieren kannst. :D
Die Performance-Grenze kommt wenn dann von dir bzw. deiner Anwendung und da haben wir keinen Einfluss drauf.


mkRE - Mo 18.01.16 00:06

Ok habs jetzt verstanden danke dir!!
Habt mir echt weitergeholfen.

:D


mkRE - Sa 06.02.16 16:26

Hallo zusammen,

ich habe mich gestern an das Thema hier auch in der Praxis probiert.
Ich habe es soweit hinbekommen daten zu lesen und zu schreiben in und aus einer csv Datei.

Ich benutze jedoch den StreamReader und StreamWriter.
Lieber hätte ich das so wie Palladin007 es in seinen Beispielen gezeigt hat leider habe ich da noch einige Verständnis Probleme.

Ich bekomme hier immer SyntaxFehler Anzeige bei bzw. unter <Measurement> var csvFile = new CsvFile<Measurement>("measurements.csv") als hätte ich da keine Using Direktive.

Das wäre so mein erstes Problem.

Ein weiteres Problem ist, das ich gemerkt habe das csv eine Textdatei ist und die Daten sind dann immer schön in einer Spalte wenn ich es mit Excel Aufmache

Zelle A1
Zelle A2
""
""

So wie ich mich im Netz eingelesen habe kann ich die Daten nicht wie bei Excel in gezielte Zellen z.B. A1 B1 C1 usw schreiben.
Für meinen Anwendungsfall ist ist nicht so wichtig aber es würde mich interessieren ob ich es richtig verstanden habe, das es gar nicht möglich ist?
Ich bin mir nicht ganz sicher aber ich meine gesehen zu haben, das ich mal bei einem Datalogger eine csv. Datei generieren kann und die Daten dan in verschiedenen Zellen und Spalten hatte.
Jedoch bin ich mir da nicht ganz sicher.

Würde mich freuen wenn wir die Punkte noch etwas diskutieren könnten.

Vielen Dank


Ralf Jansen - Sa 06.02.16 16:36

Zitat:
So wie ich mich im Netz eingelesen habe kann ich die Daten nicht wie bei Excel in gezielte Zellen z.B. A1 B1 C1 usw schreiben.


Simple Antwort "Excel ist halt eine unappetitliche braune Masse". Auch wenn c in csv für character oder comma steht versteht Excel als Trennzeichen standardmäßig nur Semikolon.

Zitat:
Ich bekomme hier immer SyntaxFehler


Eine halbwegs aktuelle Visual Studio/Framework Version sollte das eigentlich kennen.


Palladin007 - Sa 06.02.16 17:01

Zitat:
Ich bekomme hier immer SyntaxFehler


Du musst die CSV-Library auch in dein Projekt mit auf nehmen ;)
Schau dir mal den Artikel an, wo ich das her habe, da wird alles erklärt.
Ganz unten steht dann der Source, den einfach in eine cs-Datei kopieren, passende using-Direktive hinzufügen und fertig.


mkRE - So 07.02.16 15:24

Hallo Ralf,

Zitat:
Simple Antwort "Excel ist halt eine unappetitliche braune Masse". Auch wenn c in csv für character oder comma steht versteht Excel als Trennzeichen standardmäßig nur Semikolon.


Ok die Trennzeichen wären also der Unterschied. Danke

Aber das mit der unappetitlichen braunen Masse musst du mir bitte mal erklären :?: :D (Ich vermute das du damit die Flexibilität in verschiedenen Spalten und Zeilen meinst)

Viele Grüße


mkRE - So 07.02.16 15:26

Hallo Palladin007,

danke vielmals ich hab den Link übersehen :oops:

Viele Grüße


mkRE - Sa 27.02.16 18:33

Hallo zusammen,

ich habe mal eine Frage welche im Zusammenhang mit der Beispielanwendung von Palladin007 zusammenhängt.
Dieses Beispiel funktioniert wunderbar ich habe diese in WinForms laufen.

Wenn ich nun wie im Code Thread.Sleep(500) verwende passt es ganz gut das jede Sekunde 2 Einträge gemacht werden.
Jetzt habe ich das Thema mal ausprobiert bei Thread.Sleep(250) komme ich auch auf 4 Einträge pro Sekunde wunderbar.
Wenn ich nun Thread.Sleep(20) eintrage sollte ich theoretisch auf 50 Einträge kommen jedoch sind es bei mir nur 32 Einträge pro Sekunde.
Gehe ich noch weiter Thread.Sleep(1) dann müsste ich ja 1000 Einträge pro Sekunde erwarten da komme ich nicht mal annähernd ran.

Nun zu der Frage warum verhält sich das ganze im höheren Taktbereich auf einmal so komisch das ich nicht mehr auf die erwarteten Einträge komme?
Mit Thread.Sleep sage ich dem System doch das ich in der angegebenen Zeit eine Ruhepause brauche und danach soll der Vorgang wieder fortgeführt werden.
Wenn ich das ganze ohne Thread Sleep ausführe habe ich in ca 3,..s 1.000.000 Einträge ich wollte das aber im höheren Taktbereich etwas kontrollieren jedoch passt das nicht mehr wie oben beschrieben.



C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
        using (var csvFile = new CsvFile<Measurement>("measurements.csv"))
        {
            for (int i = 0; i < 100; i++)
            {
                // Zwei Messungen pro Sekunde:
                Thread.Sleep(500);

                var measurement = new Measurement()
                {
                    Size = MeasurementSource.GetNextSize(),
                    Timestamp = DateTime.Now,
                    // Weitere Eigenschaften:
                    // ...
                };

                csvFile.Append(measurement);
            }
        }


Habt Ihr eine Idee woran das liegt?

Freue mich auf Ideen und Antworten.

Viele Grüße


Ralf Jansen - Sa 27.02.16 18:55

Zitat:
Mit Thread.Sleep sage ich dem System doch das ich in der angegebenen Zeit eine Ruhepause brauche und danach soll der Vorgang wieder fortgeführt werden.


Nicht ganz du sagst das du mindestens solange schlafen willst. In Windows bekommt jeder Thread mal Rechenzeit zugewiesen das steuert Windows und nicht irgendein User Prozess. Und mit Thread.Sleep sagt du "Ich brauche jetzt keine Rechenzeit mehr und bevor n Millisekunden abgelaufen sind brauchst du mir auch keine mehr zuzuweisen".
Und 2.tens es gibt ein Mindestauflösung wie oft Windows Taskwechsel versucht die Standardmäßig irgendwo bei 15,6ms liegt. Die Auflösung kann man zwar ändern sollte man aber nicht tun (Kostet richtig Performance und Strom wenn man Windows ganz oft dazu zwingt zu prüfen ob es einen Taskswitch machen muß und im schlimmsten Fall auch ganz oft Takswitches durchführen lässt).


mkRE - Sa 27.02.16 19:59

Hallo Ralf danke für die schnelle Anwort gut erklärt!

user profile iconRalf Jansen hat folgendes geschrieben Zum zitierten Posting springen:

"Ich brauche jetzt keine Rechenzeit mehr und bevor n Millisekunden abgelaufen sind brauchst du mir auch keine mehr zuzuweisen".


Den Schlußteil deines Satzes jedoch hoffe ich habe ich richtig verstanden das nach Ablauf der angegebenen Zeit noch keine Rechenzeit zugewiesen wurde?!
Aber erst wenn sich die Schleiße wie im oberen Code fortführt, bekomme ich wieder Rechenzeit reserviert bzw. zugewiesen? Funktioniert das so?
Ich muss zugestehen hier kenne ich mich nicht so gut aus.


Mit welcher möglichkeit würde ich den dann auf einen stabilen bzw. zuverlässigen Takt von z.B. 1 - 20ms unter windows kommen?
Der WinForms Timer liegt auch bei ca. 15ms an seinen Grenzen jetzt weiß ich nicht ob der Multimedia Timer das stabil hinbekommt.

Viele Grüße


jfheins - Sa 27.02.16 20:09

user profile iconmkRE hat folgendes geschrieben Zum zitierten Posting springen:
Mit welcher möglichkeit würde ich den dann auf einen stabilen bzw. zuverlässigen Takt von z.B. 1 - 20ms unter windows kommen?

Eigentlich gar nicht, am ehesten noch mit Windows-Embedded.

Grund ist, dass in Windows eigentlich jederzeit ein Prozess mit hoher Priorität Rechenzeit verlangen könnte. Die bekommt er in der Regel auch, und dein Programm guckt in die Röhre. Aber selbst wenn du dich hochpriorisiert und rechnest, wird Windows dein Programm ab und an unterbrechen damit andere auch mal rechnen dürfen. Und eventuell ist auch mal der RAM voll und die HDD schläft gerade ...

Wenn du wirklich einen zuverlässigen Takt brauchst, nimm einen Mikrocontroller den du bspw. an einen seriellen Port anschließt.


mkRE - Sa 27.02.16 20:35

Ok jfheins das ist dann auch verstanden danke dir.

Viele Grüße


icho2099 - So 28.02.16 12:33

Ein paar Erläuterungen zu Windows und Realtime finden sich auch hier [https://www.osr.com/nt-insider/2014-issue3/windows-real-time/]
Schon seit der alt ehrwürdigen Turbo Pascal Zeit gibt es real time Kernels von onTime
Die Einarbeitung dauert etwas, aber es lohnt sich.
onTime [http://www.on-time.com/]


Ralf Jansen - So 28.02.16 14:14

Zitat:
Mit welcher möglichkeit würde ich den dann auf einen stabilen bzw. zuverlässigen Takt von z.B. 1 - 20ms unter windows kommen?
Der WinForms Timer liegt auch bei ca. 15ms an seinen Grenzen jetzt weiß ich nicht ob der Multimedia Timer das stabil hinbekommt.


Nun ja der heißt ja schon ~Multimedia Timer~ ist also für Multimedia Zwecke ausreichend. Z.B. Soundwiedergabe ist eigentlich immer flüssig(Annahme vernünftige Programmierung) nur unter Extrembelastung bekommst du Ruckler. Du hast halt keine Garantie. Wenn du eine Machinensteuerung programmierst wo jetzt halten garantiert jetzt sein muss oder die einzige Alternative heißt Machine zerstört dann sollte man auf RealTime Systeme setzen und weniger auf Windows. Die 1ms sollte man eigentlich immer erreichen können (ist aber Abhängig von der Machine auf dem das läuft).


mkRE - Di 08.03.16 22:02

Hallo icho2099 und Ralf Jansen

ich danke euch für die Beiträge und für den Link ist sehr interessant super!!
Aber ich brauch da bestimmt paar stunden bis ich das Englische komplett verstanden habe :D .
Hast du icho2099 das den schon mal ausprobiert bzw. Erfahrung mit dem System onTime?

Ich habe mich noch nicht mit Echtzeit Systemen befasst jedoch interessiert mich das jetzt um so mehr
wenn wir hier über Echtzeit Aufzeichnungen sprechen.

So wie ich das sehe ist man hier sehr eingeschrenkt und komme mit C# gar nicht weiter jedoch aber mit C++ auf den ersten Blick?!


Zitat:

Wenn du eine Machinensteuerung programmierst wo jetzt halten garantiert jetzt sein muss oder die einzige Alternative heißt Machine zerstört dann sollte man auf RealTime Systeme setzen und weniger auf Windows.


Es gibt doch aber auch z.B. SPS Analyser Windows Anwendungen die unter Windows 7 Daten einer SPS mit 2ms oder 5ms auslesen können und in einem Grafen anzeigen.
Wie machen die das dann?

Kennt ihr den noch andere Systeme mir fallen da nur ein Industrie PC z.B. von Beckhoff ein dort kann man wie ich gehört habe unter verschiedenen Tasks Anwendungen
laufen lassen. Dort läuft Windows unter seinem anderen Task jedoch können andere Anwendungen unabhängig von Windows ablaufen.
Aber ich habe keinen Schimmer wie das funktionieren soll?

Mit C# Anwendungen kann ich da nichts mehr anfangen wie z.B. das schreiben von Daten in eine csv Datei da ich ja kein Net Framework installiert habe unter einem anderen Task in Echtzeit.
Wenn ich das nutzen müsste möchte ich ungern auf C# .NET verzichten.

Oder liege ich da ganz daneben?

Viele Grüße


jfheins - Di 08.03.16 23:25

Es ist tendenziell so: Je mehr du Richtung harte Echtzeitfähigkeit gehst, desto mehr low-level wird die Programmierumgebung bzw. die Sprache. Es gibt so Sachen wie den netduino [http://www.netduino.com] mit dem .net Micro-Framework, der kann tatsächlich Echtzeit und bietet die ein Interface an, welches an .net erinnert (aber deutlich weniger umfangreich)

Bei µC (Mikrocontrollern) verzichtet man auch gerne mal auf Speicherallozierung, d.h. es steht bereits beim Kompilieren fest, wie viel Speicher gebraucht wird. Damit erübrigen sich natürlich alle OutOfMemoryExceptions und so, aber man kann halt nur statische Arrays benutzen und keine Objekte instanziieren.


Im großen und ganzen läuft das meistens so ab, dass der µC die wichtigen Echtzeitaufgaben übernimmt und dann bspw. die Daten über eine serielle Schnittstelle an den PC weitergibt. Dort gibt es einen Puffer (vom Betriebssystem) der die Daten entgegennimmt und zwischenspeichert. Dann kann die Windows-Anwendung alle 10-100ms (relativ unkritisch) die Daten abrufen und darstellen. Und wenn der µC auch Zeitstempel bereitstellt, kann man die Daten auch mit sub-Millisekunden Präzision darstellen ohne sie mit dieser Präzision in Windows verarbeiten oder empfangen zu müssen.

Für viele Anwendungsfälle braucht man diesen Aufwand aber gar nicht treiben. Worum geht es denn bei deinem Projekt insgesamt?

Da ich noch einen netduio da habe: Hier ein einfaches Programm, welches die LED sanft blinken lässt ;-)

C#-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
    public class Program
    {
        public static void Main()
        {
            var LED = new OutputPort(Pins.ONBOARD_LED, false);            

            var period = 1024;
            var maxi = 1000;

            while (true)
            {
                for (int i = 1; i < maxi; i++)
                {
                    LED.Write(true);
                    Delay(i);
                    LED.Write(false);
                    Delay(period - i);
                }

                for (int i = maxi - 1; i > 0; i--)
                {
                    LED.Write(true);
                    Delay(i);
                    LED.Write(false);
                    Delay(period - i);
                }
                Delay(period * maxi / 2);
            }
        }

        private static void Delay(long ticks)
        {
            var due = DateTime.Now.AddTicks(ticks*128);
            while (DateTime.Now < due) ;
            return;
        }
    }


mkRE - Mi 09.03.16 00:57

Hallo jfheins

mein ziel ist eine Anwendung zu schreiben die einen beliebigen Prozessverlauf Grafisch darstellt (was nicht exakt in Echtzeit stattfinden muss) und zusätzlich am besten Echtzeitdaten
wie Position, Temperatur usw. vorerst nur als Datei abspeichert und dann darstellt aber zusätzlich noch als live daten in einem Grafen anzeigt.
Es kann auch ein Kuchen sein den ich am Anfang beschrieben habe der im Herd wächst. :D
Für mich sind jedoch erstmal die Aufzeichnungen in der Datei wichtig das diese so exakt wie möglich sein sollen.

Die Simulationen mit den mir bekannten Techniken funktionieren aber leider wie schon beschrieben mit Einschränkungen.

Das soll eine Universelle Anwendung sein (wobei die Grafik natürlich zur passenden Anwendung angepasst werden muss, das ist aber momentan nicht ganz wichtig).

Jedoch würde ich gerne bei der oben genannten Anwendung später ggf. noch regeln mit schnellen Reaktionszeiten und dazu habe ich gemerkt wird eine Anwendung unter Windows nicht ausreichen
den ein 1ms Takt oder kürzer wäre schon optimal.

Im Endeffekt benötige ich ja erstmal eine Hardware die mir schon reale daten liefert ohne ist mir bewusst das das ganze sinnlos wäre :) dein vorschlag mit dem netduino
ist einfach super!! Kannte diese Hardware bis jetzt noch nicht.
Daten liest du damit auch ein denke ich, wie weit hast du den netdruino schon eingesetzt (Analogwerte lesen, schreiben und regeln sowie daten über serielle SST senden)?

Ich habe was Hardware angeht zu Hause bis jetzt einen AVR-NET-IO Bausatz in einer Anwendung laufen für eine Zimmer Steuerung für das Thema reicht es allemal aber einen performance test
habe ich noch nicht ausprobiert.


Vermute leider jedoch das ich mit meine PC mehr als schnelles einlesen nicht mehr hinbekomme. :cry:


Viele Grüße


Palladin007 - Mi 09.03.16 01:20

Sicher, dass Du derartig exakte Werte brauchst?
So wie das klingt, würden leichte Ungenauigkeiten nicht wirklich auffallen, den Unterschied von ein paar ms nimmst Du als Mensch nicht war.
Ich sehe da aber keinen Grund, was wirklich in Echtzeit aufzuziehen.

Bau dir lieber ein Interface, was definiert, was Du von der Datenquelle brauchst.
Im ersten Schritt kannst Du das Messen dann in einem eigenen Thread auslagern (Windows legt das dann wahrscheinlich auf einen eigenen Kern, wenn gerade einer wartet)
Sollte es unbedingt notwendig sein, kannst Du das dann immer noch auf einen Netduino auslagern.

So ein Interface würde ich mir z.B. so vorstellen:


C#-Quelltext
1:
2:
3:
4:
5:
public interface IMeasurementSource : IEnumerator<Measurement>, IDiposible
{
    void StartMeasurement();
    void StopMeasurement();
}


Ob IEnumerator hier sinnvoll ist, darüber kann man diskutieren.
Mich stört hauptsächlich die Reset-Methode, da man die Quelle ja nicht einfach mal eben resetten kann.

Auf jeden Fall irgendwie so in der Art würde ich das aufbauen.
Ob die Daten dann in Echtzeit von einem Netduino in einen Puffer gelegt und dann von dort zurück gegeben werden, oder aus einem eigenen Thread in einen Puffer, ist dann ziemlich egal.


icho2099 - Mi 09.03.16 09:51

Hallo,
Den onTime Kernel setzen wir schon seit sehr langer Zeit ein. Die Erfahrungen sind durchweg positiv. Sehr stabil und zuverlässig.
Aber:
RTOS Anwendungen sind in Wahrheit Betriebssysteme, die deine Applikation starten. Es sind keine Windows Anwendungen die mal eben so nebenbei laufen und Realtime ermöglichen.
Du brauchst eine Zielmaschine, die deine Anwendung bootet.
Und mit managed code verträgt sich das auch nicht. Wie auch, es kann nur einen geben, der in Echtzeitumgebungen Das Sagen hat. Müllmänner stören da nur.
Und wenn du heute von deiner Anwendung verlangst in Zukunft echtzeitfähig zu sein, dann musst du heute die richtige Wahl treffen. Mindestens mal Standard code, kein. Net Gefrickel.
Willst du nur ein nettes, zügig arbeitenden GUI, und alle Realtime Funktionen an externe Controller delegieren, dann bleib bei Windows als OS.


FinnO - Mi 09.03.16 17:27

Moin,

user profile iconmkRE hat folgendes geschrieben Zum zitierten Posting springen:

mein ziel ist eine Anwendung zu schreiben die einen beliebigen Prozessverlauf Grafisch darstellt (was nicht exakt in Echtzeit stattfinden muss) und zusätzlich am besten Echtzeitdaten
wie Position, Temperatur usw. vorerst nur als Datei abspeichert und dann darstellt aber zusätzlich noch als live daten in einem Grafen anzeigt.
Es kann auch ein Kuchen sein den ich am Anfang beschrieben habe der im Herd wächst. :D


ich würde das mal von einem eher ingenieurwissenschaftlichen Standpunkt aufziehen. Die meisten Prozesse lassen sich durch ein Zustandsraummodell [https://de.wikipedia.org/wiki/Zustandsraumdarstellung] (exakt oder näherungsweise) beschreiben, welches ein lineares Differentialgleichungssystem mit Eingängen und Ausgängen ist. Wenn du einen Prozess beobachten möchtest, also anhand von Messwerten bestimmen möchtest, wie sich seine Zustandsgrößen verhalten, ist es möglich, die notwendige Messrate mathematisch zu bestimmen. Je nachdem, welche Ziele bzw. Möglichkeiten du hast, muss diese zwischen mindestens dem doppelten (hierzu [https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem] schrieb seinerzeit Herr Shannon seine Masterarbeit) und dem ca. dreißigfachen [https://de.wikipedia.org/wiki/Bilineare_Transformation_(Signalverarbeitung)] der Bandbreite des vorliegenden Systems liegen.

Damit wären wir wieder bei deinem Kuchen. Das Aufgehverhalten eines Kuchens ist ein Prozess mit geringer Bandbreite [citation needed] und erfordert daher sicherlich keine Samplingraten im Bereich von etlichen Hertz, sondern ich vermute, dass hier auch eine Abtastung von einigen Malen pro Minute ausreichend ist. Genau so verhält es sich bei der Raumtemperatur deines Zimmers oder vergleichbaren Systemen. Durch eine höhere Samplingrate gewinnst du hier, außer den in diesem Thread ausgiebig diskutierten Problemen mit der Echtzeitfähigkeit von Windows oder der Schreibrate deiner Festplatte (zumindest aus regelungstechnischer Sicht) nichts.

Dann wäre da noch ein Sonderfall. Wenn damit zu rechnen ist, dass dein System Störungen mit hoher Bandbreite ausgesetzt sein wird, die du nicht direkt messen kannst und du deinen State-Estimation-Fehler gering halten möchtest, musst du entsprechende Vorkehrungen durch höhere Abtastrate (oder robuste Regelung, was zumindest beim Kuchen schwierig sein wird) treffen. Dies könnte bei der Messung der Raumtemperatur zum Beispiel der Wegfall einer Hauswand sein, wenn in der Modellierung nur das Öffnen eines Fensters berücksichtigt wurde.


TL;DR
Worauf ich hinaus will, ist hoffentlich deutlich geworden: Ich glaube, dass du dir durch die hohe Abtastrate vor allem Probleme und keine wirklichen Vorteile bietet. Wenn deine Anwendung also für geringere Abtastraten gut funktioniert und sich dann herausstellen sollte, dass du plötzlich ein System mit hoher Bandbreite messen musst, wäre das eine Optimierung, die man später im Entwicklungsprozess gut anbringen kann. Zum Beispiel durch die Nutzung von externer Hardware und sehr schnellen Buffern. Das Ziel sollte also sein, die Architektur deiner Anwendung so zu gestalten, dass du nicht von vorne anfangen musst, wenn du mal eine neue Variante der Datenspeicherung nutzen möchtest.


icho2099 - Fr 11.03.16 00:12

Zitat:
Jedoch würde ich gerne bei der oben genannten Anwendung später ggf. noch regeln mit schnellen Reaktionszeiten und dazu habe ich gemerkt wird eine Anwendung unter Windows nicht ausreichen
den ein 1ms Takt oder kürzer wäre schon optimal.


Diese Forderung und die Tatsache, dass äquidistante Abtastung dem Ing. Das Leben schon erheblich vereinfachen können, lassen ein Echtzeitsystem als die bessere Wahl erscheinen.
Die Abtastrate selbst ist natürlich prozessabhängig, aber die Echtzeitforderung bleibt davon unberührt. Nun ist der Kuchen im Ofen vielleicht kein so glückliches Beispiel. Aber im Prinzip geht es wohl darum zunächst Messwerte zu erfassen und zu sammeln und in der weiteren Folge dann darum einen Regelkreis zu entwerfen und zu realisieren. Und genau da kommt dann die Echtzeitforderung wieder ins Spiel. Nur schade, wenn man dann feststellen muss, dass man zwar weit gekommen ist, aber in einer Sackgasse steckt.


mkRE - Fr 11.03.16 00:16

Hallo Palladin007

user profile iconPalladin007 hat folgendes geschrieben Zum zitierten Posting springen:

Sicher, dass Du derartig exakte Werte brauchst?


Direkt benötige ich das nicht aber ich würde gerne in Echtzeit messen können.
Wenn ich dann in Zukunft den Schritt gehe etwas zu Regeln z.B. Positionen, möchte ich einen Istwert so schnell wie möglich aufnehmen.
Es gäbe schon viele Gründe in Echtzeit Werte aufzunehmen z.B. Qualitätswerte die irgendwo genau wie möglich präsentiert werden müssen usw. .

user profile iconPalladin007 hat folgendes geschrieben Zum zitierten Posting springen:

Bau dir lieber ein Interface, was definiert, was Du von der Datenquelle brauchst.
Im ersten Schritt kannst Du das Messen dann in einem eigenen Thread auslagern (Windows legt das dann wahrscheinlich auf einen eigenen Kern, wenn gerade einer wartet)
Sollte es unbedingt notwendig sein, kannst Du das dann immer noch auf einen Netduino auslagern.


Die Idee gefällt mir gut.
Aber was meinst du genau mit Bau dir ein Interface?
Verstehe ich das richtig Messen in einem eigenen Thread und Auslagern in einem weiteren Thread?

Viele Grüße


mkRE - Fr 11.03.16 00:21

Hallo icho2099

user profile iconicho2099 hat folgendes geschrieben Zum zitierten Posting springen:

RTOS Anwendungen sind in Wahrheit Betriebssysteme, die deine Applikation starten. Es sind keine Windows Anwendungen die mal eben so nebenbei laufen und Realtime ermöglichen.
Du brauchst eine Zielmaschine, die deine Anwendung bootet.

Mindestens mal Standard code, kein. Net Gefrickel.


Was benutzt du den für eine Zielmaschine was setzt du den da ein wie kann ich das verstehen bitte?

Und mit Standard Code meinst du bestimmt C?!

Viele Grüße


mkRE - Fr 11.03.16 00:57

Hallo FinnO,

ich finde deine Betrachtungsweise ganz gut keine Frage und nehme es mir auch zu Herzen ich hoffe ich habs richtig verstanden was du damit sagen wolltest.
Kommt auf die Anwendung an so wie icho2099 sagte ist der Kuchen nicht gerade ein gutes Beispiel dort kann ich auch im Minuten Intervallen
erkennen ob der Kuchen mit seiner vorgegebenen Temperatur gebacken wurde :-).
Bei Aufzeichnung eines Prozesses der z.B. 20 Sekunden dauert bringt mir für konkrete aussagen über den Fort lauf des Prozesses eine Echtzeit Aufzeichnung 1 - 10ms
viel mehr als 500ms Intervalle. Wenn ich später noch Regelkreise ausprobiere dann keine Frage gehören noch andere Faktoren dazu Störungsgrößen, Auflösung der Messgeräte usw. ...

Ich möchte halt erstmal ausprobieren was möglich wäre mit dem Equipment das ich habe und das ist Windows 7 ich möchte aber auch verschiedene Lösungswege Kennenlernen.

Ich hoffe du verstehst was ich vor habe?


mkRE - Fr 11.03.16 01:15

Hallo icho2099

Zitat:

Und genau da kommt dann die Echtzeitforderung wieder ins Spiel. Nur schade, wenn man dann feststellen muss, dass man zwar weit gekommen ist, aber in einer Sackgasse steckt.


Wo siehst du hier eine Sackgasse?


Allgemein bevor wir langsam ganz in die Regelungstechnik steigen möchte ich doch lieber erstmal nur bei dem Datenerfassungsthema bleiben :-)
Versuche noch das beste unter Windows rauszuholen mit den Anworten die hier zwischendurch genannt wurden und dann sehe ich mal weiter.

Viele Grüße und vielen Dank.


Palladin007 - Fr 11.03.16 01:46

user profile iconmkRE hat folgendes geschrieben Zum zitierten Posting springen:
Direkt benötige ich das nicht aber ich würde gerne in Echtzeit messen können.


Genau, punkt. ;)
Es gibt die Regel KISS (Keep it simple, stupid), nimm dir das hier lieber zu Herzen ;)
Gehen tut das, aber der Aufwand, der damit zusammen hängt, ist enorm, während praktisch kein wirklicher Gewinn vorhanden ist.

Gleichzeitig solltest Du dir den Weg nicht verbauen, wenn das irgendwann mal doch relevant werden könnte. Daher das Interface, die Implementierung lässt sich sehr einfach tauschen (Im Bootstrapper, Config, User-Einstellungen, etc.). Sollte es mal nötig sein, dann kaufst Du dir einen Mikrocontroller und entwickelst eine Software dafür, die in Echtzeit deine Daten sammelt und deinem eigentlichen Programm sozusagen vor die Türe wirft. Sprich: Du hast irgendwo einen leistungsstarken Puffer, der schnell Daten entgegen nehmen und zwischen speichern kann, bis sie wieder abgefragt werden.
Dein Programm, bzw. die Implementierung von besagtem Interface, schaut dann regelmäßig (nicht echtzeit) nach, ob es weitere Daten zum Abholen gibt und bietet diese an. So kannst Du die in Echtzeit gelesenen Daten blockweise aufnehmen, speichern, analysieren, etc.

Wie Du das tust, bleibt dir überlassen. Aus Sicht des Programms muss das Interface vermutlich nicht mehr können, als über die Ergebnisse iterieren, also im Prinzip ein Enumerator.
Wo die Daten her kommen, ist dabei egal. Die können managed und nicht echtzeit im Windows gesammelt werden, oder sie kommen aus einem Buffer (der idealerweise auch in Echtzeit Daten entgegen nehmen kann).

user profile iconmkRE hat folgendes geschrieben Zum zitierten Posting springen:
Aber was meinst du genau mit Bau dir ein Interface?


Siehe oben

user profile iconmkRE hat folgendes geschrieben Zum zitierten Posting springen:
Verstehe ich das richtig Messen in einem eigenen Thread und Auslagern in einem weiteren Thread?


Das wäre meine Herangehensweise, das Maximum unter Windows heraus zu holen.
Wenn die Messungen möglichst Echtzeit sein sollen, dann wirst Du am ehesten daran kommen, wenn die Messungen einen ganzen Kern für sich haben, oder - je nach Komplexität - mehrere Kerne.
Windows verhaltet die Threads automatisch und wenn es einen Kern gibt, der gerade nichts zu tun hat, während ein Thread von einem Programm mit hoher Priorität groß am kämpfen ist, dann wird es den Thread vermutlich auf dem Kern arbeiten lassen. Zumindest solange es nichts Anderes auf dem System gibt, was Vorrang bekommen könnte.
Also haben wir einen Thread, der misst. Wenn dieser Thread auch noch die Daten verarbeitet/speichert, hast Du deinen Vorteil damit sehr effektiv wieder zu nichte gemacht. Das Verarbeiten/Speichern muss also möglichst effektiv entkoppelt werden. Der Messungs-Thread wirft seine Messwerte also simpel in einen (threadsafe) Stapel. Nun gibt es einen weiteren Thread, der alle halbe Sekunde in besagter Liste nach schaut, die Werte entfernt und selber weiter verarbeitet oder speichert. Damit hast Du eine "live" Verarbeitung der Messwerte und kannst sie theoretisch auch live darstellen. Effektiver wäre, wenn die Daten erst alle in der Liste gelagert und dann verarbeitet werden, wenn die Messung beendet ist. Damit sparst Du dir auch einen Thread.

So oder so brauchst Du mehrere Threads:
- Einen Thread zum Messen und in den Buffer legen
- Einen Thread, der die Messwerte entgegen nimmt und verarbeitet/speichert
Und dann noch die Threads, die Du sowieso immer hast (oder haben solltest):
- Einen UI-Thread
- Einen Thread, der deine übrigen Programm-Aktivitäten regelt

Das sind vier Threads. Bei 4 Kernen und 4 virtuellen Kernen sind das mehr oder weniger 8 Kerne. Solange nichts anderes auf dem System läuft, muss kein Prozess oder Thread um die Rechenzeit auf einem Kern bangen und für Windows bleibt auch noch etwas übrig.
Aber damit das funktioniert, muss alles sauber getrennt werden, da Du dich sonst selber ausbremst.


Aber auch hier steht nochmal die Frage im Raum: Brauchst Du das?
Ich würde es am Anfang ganz simpel so machen, dass die erste Implementierung von oben genannten Interface bei jeder Anfrage nach den Messwerten erst anfängt zu messen. Nicht vorher und auch nicht in einem eigenen Thread.
Das Messen findet also im Programm-Thread statt und ist damit alles andere als Echtzeit, aber der Umfang ist bedeutend geringer und durch das Interface lässt es sich leicht wieder austauschen.


mkRE - Sa 12.03.16 01:25

Hallo Palladin007,

danke sehr für deine Antworten und die Beschreibung der Lösungsweg über mehre Threads klingt absolut real.
(Jetzt verstehe ich auch wie z.B. Analyse Systeme z.B. SPS Analyzer (z.B. mit 5ms Abtastrate) funktionieren könnten ohne extra Hardware unter Windows.)

user profile iconPalladin007 hat folgendes geschrieben Zum zitierten Posting springen:

Aber auch hier steht nochmal die Frage im Raum: Brauchst Du das?


Die Frage ist so simpel das die doch sehr schwer zu beantworten ist :rofl:

Ich sags mal so wenn ich sich schnell veränderliche Messwerte genau wie möglich erfassen und repräsentieren möchte dann brauche ich das.
Momentan fällt mir nichts ein was ich mit dem PC direkt messen könnte ohne externer Hardware die eh die Echtzeit Messung vorher übernimmt, deshalb macht es kein Sinn den PC überhapt als direktes Messwerkzeug zu benutzen (außer für das lesen diverser Daten aus einer SPS über Ethernet).
Andere Anwendungen die ich mir gerade durch den Kopf gehen lassen habe, machen eh Sinn mit einem externen MC der Daten schnell puffert und ich diese am PC nur präsentiere.

ist doch so oder?!

Viele Grüße


Faramir - Mi 17.11.21 20:54

Ich speichere die Daten in Dateien im CSV-Format. Es ist einfach und Sie können es in einer txt-Datei speichern, es ist leicht in C# zu tun. Mit einem Rechtsklick können Sie Daten aus der Datenbank exportieren. Es ist möglich, in eine Excel-Datei zu exportieren. Ich habe früher mit Messgeräten gearbeitet und alles in einer txt-Datei im CSV-Format gespeichert.

Moderiert von user profile iconTh69: Beiträge zusammengefasst

Das Lesen von Daten in einem in C# geschriebenen Programm bedeutet das Lesen der gesamten Zeile und das Aufteilen der Daten mithilfe der Split-Funktion. Daten im CSV-Format werden normalerweise durch Semikolon ; getrennt.

Moderiert von user profile iconTh69: Eigenzitat entfernt.