Welches Dateiformat vewenden für Messwert Ablage

mkRE · Beiträge: 98

Ok jfheins das ist dann auch verstanden danke dir.

Viele Grüße

icho2099 · Verfasst: So 28.02.16 12:33

Ein paar Erläuterungen zu Windows und Realtime finden sich auch hier
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

Ralf Jansen · Verfasst: 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 · Beiträge: 98

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

.
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 · Beiträge: 918 Erhaltene Danke: 158 Win 10 VS 2013, VS2015

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 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 ;-)

markieren

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 · Beiträge: 98

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.

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 · Verfasst: 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:

markieren

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 · Verfasst: 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 · Verfasst: Mi 09.03.16 17:27

Moin,

mkRE hat folgendes geschrieben :

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.

ich würde das mal von einem eher ingenieurwissenschaftlichen Standpunkt aufziehen. Die meisten Prozesse lassen sich durch ein Zustandsraummodell (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 schrieb seinerzeit Herr Shannon seine Masterarbeit) und dem ca. dreißigfachen 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 · Verfasst: 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 · Beiträge: 98

Hallo Palladin007

Palladin007 hat folgendes geschrieben :

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. .

Palladin007 hat folgendes geschrieben :

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 · Beiträge: 98

Hallo icho2099

icho2099 hat folgendes geschrieben :

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 · Beiträge: 98

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 · Beiträge: 98

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 · Verfasst: Fr 11.03.16 01:46

mkRE hat folgendes geschrieben :

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).

mkRE hat folgendes geschrieben :

Aber was meinst du genau mit Bau dir ein Interface?

Siehe oben

mkRE hat folgendes geschrieben :

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 · Beiträge: 98

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.)

Palladin007 hat folgendes geschrieben :

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 · Hält's aus hier Beiträge: 4

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 Th69: 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 Th69: Eigenzitat entfernt.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme