Calc: Zeiten vereinfacht eingeben

Nino_1952 · December 29, 2019, 11:43am

Hi Admin04,

Hallo Marino,

Wenn das, was Du hier sagst richtig ist; das die Zeiten in Calc in
Fliesskomma-Werten hinterlegt sind; dann werden bei gewissen
Rechenoperationen unweigerlich Fehler auftrete.
Nicht gerade das Gesuchte. In INT würde solches nie auftreten. Auf
Leitsystemen mit Echtzeiteinträgen ist es Bedingung, dass die
Zeitstempel kohärent sind!
Gerade beim Abgleich von Letzt-wert, was in Leitebene als Bedingung
für die Neuwert-Gültigkeit steht (DCP/IP Daten-Überholungen), eine
absolute Bedingung.
Somit kommt Calc als Tabelle für Datenhinterlegung für diesen Zweck
nicht in Frage!

In solchen Fällen müsstest du Zeitangaben in INT _codieren_. Es hält
dich ja niemand davon ab, Zeiträume oder Zeitpunkte z.B. in Sekunden
oder Millisekunden zu speichern. Im Falle eines Zeitpunktes müsstest du
allerdings einen passenden Zeitpunkt als Nullpunkt festlegen. Du
könntest den Zeitpunkt des Messbeginns (möglicherweise als String) in
die Tabelle schreiben und diesem den Wert 0 (Millit-)Sekunden zuweisen.
Alle weiteren Zeitwerte werden dann als INT-Wert bezüglich dieses
Startwertes abgelegt.

Das ist schon richtig und durchaus ausführbar und Zielführend.
Nur möchte ich dazu bemerken, dass solches bekannt sein muss.
Ich denke, dass die Wenigsten sich mit solchen Dingen beschäftigen und
hinterfragen wie die Daten im Hintergrund tatsächlich manipuliert werden.
Ich jedenfalls habe das bisher nie hinterfragt. So war mir auch gar
nicht bewusst, dass die Zeit in Calc durch anwendung von FLOAT für
hochdynamische Prozesse, oder für höhere Mathematik ungeeignet ist.

Was mich wundert ist daher, warum man auf solch eine Idee überhaupt
gekommen ist.

Auf CPUs die Echtzeitverhalten mit Zeitstempel nutzen wird die Zeit von
einem Zeitserver auf alle Teilnehmer übertragen und in den lokalen
Rechnern wird immer in DINT bez. LINT hinterlegt! Jeder Datenpunkt
welcher aus der Zukunft stammt wird direkt als falsch verworfen ist er
älter als der Letzt-gültige Eintrag bleibt er unberücksichtigt!

Das hat sich durchgängig als die sicherste Methode erwiesen. Mann stelle
sich einmal das CERN vor, wenn deren Zeiten nicht sicher verifizierbar
wären...

GerhardW · December 29, 2019, 3:26pm

hallo Marino,

Hi Admin04,

Hallo Marino,

Wenn das, was Du hier sagst richtig ist; das die Zeiten in Calc in
Fliesskomma-Werten hinterlegt sind; dann werden bei gewissen
Rechenoperationen unweigerlich Fehler auftrete.
Nicht gerade das Gesuchte. In INT würde solches nie auftreten. Auf
Leitsystemen mit Echtzeiteinträgen ist es Bedingung, dass die
Zeitstempel kohärent sind!
Gerade beim Abgleich von Letzt-wert, was in Leitebene als Bedingung
für die Neuwert-Gültigkeit steht (DCP/IP Daten-Überholungen), eine
absolute Bedingung.
Somit kommt Calc als Tabelle für Datenhinterlegung für diesen Zweck
nicht in Frage!

In solchen Fällen müsstest du Zeitangaben in INT _codieren_. Es hält
dich ja niemand davon ab, Zeiträume oder Zeitpunkte z.B. in Sekunden
oder Millisekunden zu speichern. Im Falle eines Zeitpunktes müsstest du
allerdings einen passenden Zeitpunkt als Nullpunkt festlegen. Du
könntest den Zeitpunkt des Messbeginns (möglicherweise als String) in
die Tabelle schreiben und diesem den Wert 0 (Millit-)Sekunden zuweisen.
Alle weiteren Zeitwerte werden dann als INT-Wert bezüglich dieses
Startwertes abgelegt.

Das ist schon richtig und durchaus ausführbar und Zielführend.
Nur möchte ich dazu bemerken, dass solches bekannt sein muss.
Ich denke, dass die Wenigsten sich mit solchen Dingen beschäftigen und
hinterfragen wie die Daten im Hintergrund tatsächlich manipuliert werden.
Ich jedenfalls habe das bisher nie hinterfragt. So war mir auch gar
nicht bewusst, dass die Zeit in Calc durch anwendung von FLOAT für
hochdynamische Prozesse, oder für höhere Mathematik ungeeignet ist.

Was mich wundert ist daher, warum man auf solch eine Idee überhaupt
gekommen ist.

Auf CPUs die Echtzeitverhalten mit Zeitstempel nutzen wird die Zeit von
einem Zeitserver auf alle Teilnehmer übertragen und in den lokalen
Rechnern wird immer in DINT bez. LINT hinterlegt! Jeder Datenpunkt
welcher aus der Zukunft stammt wird direkt als falsch verworfen ist er
älter als der Letzt-gültige Eintrag bleibt er unberücksichtigt!

Das hat sich durchgängig als die sicherste Methode erwiesen. Mann stelle
sich einmal das CERN vor, wenn deren Zeiten nicht sicher verifizierbar
wären...

Du redest aber doch von ganz anderen Aufgabenstellungen, das hat doch mit Calc nichts mehr zu tun. Und bei den Kürzeln für Variablentypen sollte man sich schon an die halten, die in LibO verwendet werden, und nicht an welche von anderswo.

Wolfgang_Jath · December 29, 2019, 4:28pm

*Alle* Daten, sogar Texte, werden intern binär abgelegt. Und Calc selbst
kennt überhaupt nur 3 Datentypen, nämlich String aka Text, Integer und
Gleitkomma aka Double.

Jep,
aber nur bedingt richtig "Wahrheitswert" (BOOL) hast Du unterschlagen...

Nein; bool ist genauso nur ein Integerwert (0=falsch, alles
andere=WAHR); probiers aus.

Wenn das, was Du hier sagst richtig ist; das die Zeiten in Calc in
Fliesskomma-Werten hinterlegt sind; dann werden bei gewissen
Rechenoperationen unweigerlich Fehler auftrete.

Tut es, ja. Allerdings so weit hinten, dass das nur sehr selten auf
fällt. Aber gelegentlich tut es das; such mal im Archiv (siehe Footer)
nach dem Thread "CALC: Uhrzeit wird beim Kopieren mit Maus falsch
berechnet" vom 3.12.2019.

Nicht gerade das Gesuchte. In INT würde solches nie auftreten. Auf
Leitsystemen mit Echtzeiteinträgen ist es Bedingung, dass die
Zeitstempel kohärent sind!

Ähm; dir ist aber schon bewusst, was das Wort "kohärent" wirklich
bedeutet, oder?

Meine Aussagen beruhen aber auf den Standard von den grundsätzlichen
ANY_INT Datentypen.

Und was bitte hat das mit Calc zu tun? In Calc *gibt* es das alles
nicht, bzw. nur als Abbildung in eine der 3 möglichen Datentypen.

Die Aufgliederung in BYTE ist darum zu berücksichtigen, weil die meisten
seriellen Transportmittel; CAN, PROFIBUS, MODBUS, Ethernet; Byte-weise
übertragen und die Speicher in Byte organisiert sind!

Schon lange nicht mehr; sowohl die Übertragnung als auch die
Speicherung. Die Speicherung innerhalb heutiger Hardware erfolgt fast
ausschließlich 32-bitig oder 64-bitig, teilweise sogar schon 128-bitig;
nur gaaaanz selten ist noch uralte 16-bit-Hardware in Gebrauch;
8-bit-Hardware gips bestenfalls noch im Museum. Und /serielle/
Transportprotokolle wie die oben von dir aufgeführten heißen "seriell",
weil sie die Bits einzeln, eines nach dem anderen, /hintereinander/
übertragen, und nicht byteweise aka 8 bit parallel. Ob diese Bits
anschließend wieder zu 8-, 16-, 32-, 64- oder 128-bit Ganz-, Festpunkt-
oder Fließkommazahlen oder Strings oder noch was anderes zusammen
gesetzt werden, ist dem Protokoll völlig wurscht.

Trotzdem muss ich mich wiederholen mit der Frage, was das alles mit Calc
zu tun hat. Hint: Cals ist ein Tabellenkalkulationsprogramm, kein
Transportprotokoll (und schon gar kein serielles).

Wolfgang

Bernd_Neumann · December 29, 2019, 7:05pm

Hallo Marino,

der Geizkragen sucht einen Pfennig und verbraucht dabei drei Lichte...
Wozu brauchst du die absolute Genauigkeit, die man mit viel Aufwand einprogrammieren müsste?

Nach der Uhr kann man sich sowieso nicht richten, die zeigt ständig unterschiedliche Zeiten! Besonders
jetzt, wo es auf den Jahreswechsel zugeht, wird das anschaulich vorgeführt. Das Jahr beginnt an unterschiedlichen Orten zu unterschiedlichen Zeiten. Was soll also der Nanosekundenbereich im Zeitraum von 50 Jahren. Ich für meine Person freue mich darauf den Jahreswechsel zu feiern und wünsche allen Listigen eine guten Rutsch!

VG Bernd

Michael_Hohne · December 29, 2019, 7:23pm

Hallo Bernd,

Hallo Marino,

der Geizkragen sucht einen Pfennig und verbraucht dabei drei Lichte...
Wozu brauchst du die absolute Genauigkeit, die man mit viel Aufwand
einprogrammieren müsste?

Nach der Uhr kann man sich sowieso nicht richten, die zeigt ständig
unterschiedliche Zeiten! Besonders
jetzt, wo es auf den Jahreswechsel zugeht, wird das anschaulich
vorgeführt. Das Jahr beginnt an unterschiedlichen Orten zu
unterschiedlichen Zeiten. Was soll also der Nanosekundenbereich im
Zeitraum von 50 Jahren. Ich für meine Person freue mich darauf den
Jahreswechsel zu feiern und wünsche allen Listigen eine guten Rutsch!

VG Bernd

Boah! Jetzt wirds pfiliosofitsch!

Gruß,
Michael...

...der auf dem "Weihnachts"markt vielleicht doch einen Punsch zu viel
hatte...

Ernst_Hugli · December 30, 2019, 8:40am

Hallo Listige

Hei Boris, Wolfgang,

Hallo,

Hallo,

Im Menü Extras>Optionen>LibreOfficeCalc>Berechnen
ist der Stichtag (standardmäßig) als 30.12.1899 vorgegeben.

warum eigentlich der 30. und nicht der 31.?

Das ermöglicht, dass der interne Wert 1,0000 direkt den Zeitstempel
01.01.1900 00:00:00 repräsentieren kann.

genau das ist dann eben nicht der Fall, der 01.01.1900 entspräche dann
der 2 und nicht der 1 -das ist dann nämlich der 31.12.1899. Für mich
sieht im das ersten Anlauf nicht nach einer Erleichterung, Merkhilfe
o.ä. aus.

Es gibt da noch eine andere "Theorie". 1,0 sollte der 01.01.1900 sein, und das "Große" Excel-Programm eines Marktführers hat dies auch so intern bestimmt und festgelegt.

Leider hat man in der weiteren Berechnung das Schaltjahr 1904 "vergessen", so dass hier ein Tag fehlt. So stimmen die Zeitwerte zwischen LO/AOO und Excel in der Zeitspanne von 1900 bis 1904 nicht überein - erst ab dem 1. März 1904 passt das dann wieder. So erklärt sich der Stichtag 30.12.1899 als Starttag.

Stimmt nicht ganz! Excel hat nicht den Schalttag im Jahr 1904 vergessen, sondern fälschlicherweise einen Schalttag im Jahr 1900 eingeführt: den 29.02.1900 hat es nie gegeben. Die korrekte Schaltregel lautet nämlich: Schaltjahre sind alle Jahre, die ohne Rest durch 4 teilbar sind - es sei denn, es sind Hunderterjahre (wie z.B. 1900, 2000, usw.). Diese sind nur Schaltjahre, wenn sie ohne Rest durch 400 teilbar sind. Also sind die Jahre 1700, 1800, 1900 keine Schaltjahre - wohl aber 2000. Tatsächlich wollte man ursprünglich den 31.12.1899 als den Tag 0 setzen. In der Komputistik (Kalenderrechnung) ist es üblich, den letzten Tag einer Periode als den 0. Tag der neuen Periode zu setzen: der 31. Mai ist z.B. der 0. Juni. Das hat den unschätzbaren Vorteil, dass die Anzahl Tage dann einfach der Tagesnummer entspricht: der 1. Juni ist dann wirklich Tag 1 in dieser Zählung. Aber leider hat man sich eben mit dem 29.2.1900 "vertan", und so muss man auf den 30.12.1899 (was völlig unlogisch ist) kaprizieren als Tag 0, damit das Ganze dann wieder stimmt. Und ab 1904 stimmen "richtige" Zählweise und jene von Excel wiederum überein. A propos: Microsoft schwatzt sich raus: Man habe die korrekte Schaltregel sehr wohl gewusst, den Fehler aber vom Urahn aller Tabellenkalkulationsprogramme Lotus 1-2-3 übernommen ... (er war bereits im Excel-Vorgänger Multiplan von Microsoft enthalten und eben da habe man sich auf Lotus abgestützt). Na ja ... Übrigens: Versuchen Sie mal 29.2.1900 in Calc einzugeben... Da es dieses Datum für Calc nicht gibt, kann das Programm es auch nicht in eine Zahl umwandeln, sondern macht daraus einen String, erkennbar daran, dass es jetzt linksbündig und nicht rechtsbündig angezeigt wird.

Tja, Kalenderarithmetik ist nix für schwache Nerven und Leute ohne ein paar mathematische Kenntnisse 8-).

Liebe Grüsse aus der Schweiz

Ernst

Ernst_Hugli · December 30, 2019, 8:59am

Hallo Listige

Stimmt nicht ganz! Excel hat nicht den Schalttag im Jahr 1904 vergessen, sondern fälschlicherweise einen Schalttag im Jahr 1900 eingeführt: den 29.02.1900 hat es nie gegeben. Die korrekte Schaltregel lautet nämlich: Schaltjahre sind alle Jahre, die ohne Rest durch 4 teilbar sind - es sei denn, es sind Hunderterjahre (wie z.B. 1900, 2000, usw.). Diese sind nur Schaltjahre, wenn sie ohne Rest durch 400 teilbar sind. Also sind die Jahre 1700, 1800, 1900 keine Schaltjahre - wohl aber 2000. Tatsächlich wollte man ursprünglich den 31.12.1899 als den Tag 0 setzen. In der Komputistik (Kalenderrechnung) ist es üblich, den letzten Tag einer Periode als den 0. Tag der neuen Periode zu setzen: der 31. Mai ist z.B. der 0. Juni. Das hat den unschätzbaren Vorteil, dass die Anzahl Tage dann einfach der Tagesnummer entspricht: der 1. Juni ist dann wirklich Tag 1 in dieser Zählung. Aber leider hat man sich eben mit dem 29.2.1900 "vertan", und so muss man auf den 30.12.1899 (was völlig unlogisch ist) kaprizieren als Tag 0, damit das Ganze dann wieder stimmt. Und ab 1904 stimmen "richtige" Zählweise und jene von Excel wiederum überein. A propos: Microsoft schwatzt sich raus: Man habe die korrekte Schaltregel sehr wohl gewusst, den Fehler aber vom Urahn aller Tabellenkalkulationsprogramme Lotus 1-2-3 übernommen ... (er war bereits im Excel-Vorgänger Multiplan von Microsoft enthalten und eben da habe man sich auf Lotus abgestützt). Na ja ... Übrigens: Versuchen Sie mal 29.2.1900 in Calc einzugeben... Da es dieses Datum für Calc nicht gibt, kann das Programm es auch nicht in eine Zahl umwandeln, sondern macht daraus einen String, erkennbar daran, dass es jetzt linksbündig und nicht rechtsbündig angezeigt wird.

Tja, Kalenderarithmetik ist nix für schwache Nerven und Leute ohne ein paar mathematische Kenntnisse 8-).

Zwei Nachträge:

1. Bereits ab dem 1. März 1900 (und nicht erst ab 1904) stimmen Excel
    und Calc in ihrer Zählung wieder überein: Excel zählt ab dem
    31.12.1899, Calc ab dem 30.12.1899 ...
2. Die komplizierte Schaltregel hat natürlich einen tieferen Sinn. Das
    astronomische Jahr hat eine Länge von ungefähr 365.242 Tagen, also
    nicht ganz ¼ Tag mehr als 365 Tage. Würde man jetzt einfach die
    simple Schaltregel "alle 4 Jahre einen Schalttag einfügen" anwenden,
    dann wäre nach rund 128 Jahren die Differenz auf 1 Tag angewachsen.
    Für ein Menschenleben spielte das keine Rolle, im Laufe historischer
    Perioden aber schon. Tatsächlich galt diese Regel im Kalender des
    Julius Caesar, den er um 45 v.Chr. einführte und dessen endgültige,
    für die christliche Welt gültige Fassung der Mönch Dionysius Exiguus
    Ende des 5. Jahrhunderts (n.Chr. ;-)) festlegte. Bis ins 16. Jh. war
    dann die Differenz auf 10 Tage angewachsen. Das war nun in der Regel
    schon für Laien ersichtlich. Darum führte Papst Gregor XIII. im Jahr
    1582 den nach ihm benannten gregorianischen Kalender ein, der eben
    diese Schaltregel enthielt. Damit war "seine" Jahrlänge nicht mehr
    365.25 Tage, sondern 365.2425 Tage und weicht damit nur noch um
    0.0005 Tage von der wahren Jahreslänge ab. Diese Differenz wird sich
    erst in rund 3000 Jahren auf 1 Tag aufsummiert haben, was aber
    angesichts von Donald Trump und Konsorten kein Problem mehr
    darstellen dürfte, denn wenn diese Clique so weiterwurstelt, dann
    wird es bis dahin wohl kaum mehr Menschen geben bzw. nur noch
    solche, die andere Sorgen als einen korrekten Kalender haben ....
    Übrigens: um "seinen" Kalender wieder an die Geschehnisse am Himmel
    anzupassen, hat er den julianischen Kalender nicht einfach
    fortgeführt, sondern verfügt, dass ab dem 4. Oktober 1582 zehn Tage
    weggelassen werden, dh. also auf den Donnerstag 4. Oktober 1582
    folgte unmittelbar der Freitag 15. Oktober 1582. Die Kalenderdaten
    dazwischen, also z.B. den 8. Oktober 1582, hat es (offiziell) nie
    gegeben.

Liebe Grüsse

Ernst

Ernst_Hugli · December 30, 2019, 9:13am

Hallo Listige

Zwei Nachträge:

1. Bereits ab dem 1. März 1900 (und nicht erst ab 1904) stimmen Excel
und Calc in ihrer Zählung wieder überein: Excel zählt ab dem
31.12.1899, Calc ab dem 30.12.1899 ...

Ups, reingefallen ... Natürlich ist es umgekehrt: Excel muss ab dem 30.12.1899 (bzw. bei Excel-kompatibler Rechnung muss ab diesem Datum gezählt werden), Calc rechnet eigentlich schon mit dem korrekten Datum vom 31.12.1899 und nur wegen der Kompatibilität mit Excel mit dem Datum 30.12.1899, denn so kann man den Fehler ausbügeln. Ich nehme an, dass man das Startdatum 1.1.1904 gewählt hat, um all diese Probleme um das nicht existente Schaltjahr 1900 zu umgehen, aber ich kenne die Absichten der Entwickler von Calc nicht.

Liebe Grüsse

Ernst

Nino_1952 · December 30, 2019, 9:20am

Hallo Wolfgang,

als 1. möchte ich hierzu bemerken, dass ich in Zukunft nicht mehr weiter
zu diesem Thema schreiben werde; es sei denn, jemand hat eine direkte
Frage an mich. Derjenige darf mich dann direkt ansprechen. Der Rahmen
hier wird eindeutig gesprengt.

*Alle* Daten, sogar Texte, werden intern binär abgelegt. Und Calc selbst
kennt überhaupt nur 3 Datentypen, nämlich String aka Text, Integer und
Gleitkomma aka Double.

Jep,
aber nur bedingt richtig "Wahrheitswert" (BOOL) hast Du unterschlagen...

Nein; bool ist genauso nur ein Integerwert (0=falsch, alles
andere=WAHR); probiers aus.

Das ist dann in etwa das selbe, wie wenn ich für jeden einzelne Fahrgast
einen Bus mit 60 Sitzplätzen auf die Reise schicke - wirklich sehr
effizient!
Kein Wunder,dass die Prozessoren immer schneller werden und am Ende die
Berechnungswartezeit trotzdem nicht kürzer wird...

Wenn das, was Du hier sagst richtig ist; das die Zeiten in Calc in
Fliesskomma-Werten hinterlegt sind; dann werden bei gewissen
Rechenoperationen unweigerlich Fehler auftrete.

Tut es, ja. Allerdings so weit hinten, dass das nur sehr selten auf
fällt. Aber gelegentlich tut es das; such mal im Archiv (siehe Footer)
nach dem Thread "CALC: Uhrzeit wird beim Kopieren mit Maus falsch
berechnet" vom 3.12.2019.

Auch das ist nur bedingt richtig. Wenn man kurze Zeiten zuerst dividiert
und erst anschliessend multipliziert, kann es schon es erheblichen
Rundungsfehler führen...

Für eben solches aber benutze ich z.B. Calc, da ich unter Anderem in der
Netzfrequenzen die Abweich-Toleranz im Drehfeld in Winkel° berechnen muss...
(Synchronisation von Generatoren)

Nicht gerade das Gesuchte. In INT würde solches nie auftreten. Auf
Leitsystemen mit Echtzeiteinträgen ist es Bedingung, dass die
Zeitstempel kohärent sind!

Ähm; dir ist aber schon bewusst, was das Wort "kohärent" wirklich
bedeutet, oder?

Im Zusammenhang mit Zeit sicherlich ein passender Begriff, wenn man
Gleichtakt, Phasengleichheit darunter versteht...

Meine Aussagen beruhen aber auf den Standard von den grundsätzlichen
ANY_INT Datentypen.

Und was bitte hat das mit Calc zu tun? In Calc *gibt* es das alles
nicht, bzw. nur als Abbildung in eine der 3 möglichen Datentypen.

Die Aufgliederung in BYTE ist darum zu berücksichtigen, weil die meisten
seriellen Transportmittel; CAN, PROFIBUS, MODBUS, Ethernet; Byte-weise
übertragen und die Speicher in Byte organisiert sind!

Schon lange nicht mehr; sowohl die Übertragnung als auch die
Speicherung. Die Speicherung innerhalb heutiger Hardware erfolgt fast
ausschließlich 32-bitig oder 64-bitig, teilweise sogar schon 128-bitig;
nur gaaaanz selten ist noch uralte 16-bit-Hardware in Gebrauch;
8-bit-Hardware gips bestenfalls noch im Museum. Und /serielle/
Transportprotokolle wie die oben von dir aufgeführten heißen "seriell",
weil sie die Bits einzeln, eines nach dem anderen, /hintereinander/
übertragen, und nicht byteweise aka 8 bit parallel. Ob diese Bits
anschließend wieder zu 8-, 16-, 32-, 64- oder 128-bit Ganz-, Festpunkt-
oder Fließkommazahlen oder Strings oder noch was anderes zusammen
gesetzt werden, ist dem Protokoll völlig wurscht.

Erzähl mir nun bitte über solche Protokolle keine Märchen...
=> C-Programm am Ende.
Wie willst Du den ohne Byte-Staffelung ein Transkript von seriell litle-
nach big-endian durchführen?

Trotzdem muss ich mich wiederholen mit der Frage, was das alles mit Calc
zu tun hat. Hint: Cals ist ein Tabellenkalkulationsprogramm, kein
Transportprotokoll (und schon gar kein serielles).
Die Frage ist immer noch die Selbe:

Warum wurde der Zeitstempel bei Calc in eine REAL hinterlegt?
Dar Programmiere muss doch einen triftigen Grund dafür gehabt haben...

Wolfgang

Das folgende hat nun tatsächlich gar nichts mit Calc zu tun, ausser dass
die daraus resultierende Daten via OPC in eine Tabelle auf dem Server
eingetragen und als Graphik ausgegeben werden.

Das was ich hier einkopiert habe ist ein Konvertierungs-Funktionsblock,
welcher in eine übergeordnete System-Programmierung eingebunden wird.
Leider gibt es drei Konventionen für die serielle Übertragung die auf
das im Empfänger genutzte Protokoll umgeschrieben werden muss; das Rad
wird halt immer wieder mal neu erfunden.

Ist leider nicht sehr gut lesbar, da der Code mit mehr Zeichen je Zeile
aufgesetzt war.

(*SOFTCONTROL:
   VERSION:4.00.21*)
FUNCTION_BLOCK Cnv_LitleBigMixed_Endian
(**)
(*GroupPath='POUs'*)
  VAR_INPUT
    xEn: BOOL:=FALSE;
      (*enable*)
    pModify: BOOL:=FALSE;
      (*start to modify*)
    siCnvTyp: SINT:=0;
      (*type of Convert
      0 = 1 /1 Dut Copy no convert
      1 = BigEnd <=> LtlEnd
      2 = BigEnd <=> MxlEnd
      3 = LtlEnd <=> MxEnd*)
    uiInitSrc: UINT:=0;
      (*first REAL to receive
      = uiStartAddr_read_INT*)
    uiInitDst: UINT:=0;
      (*first REAL to destination *)
    uiQntINT: UINT:=0;
      (*number of INT to modify *)
  END_VAR
  VAR_IN_OUT
    dwSrcStart: DWORD;
      (*Dut Start of recive*)
    dwDstStart: DWORD;
      (*DUT Start of destination*)
    bDstEnd: BYTE;
      (*Dut swaped *)
  END_VAR
  VAR_OUTPUT
    pErr: BOOL:=FALSE;
      (*Eror of Copy*)
    QiErr: INT:=0;
      (*Eror Code Copy
      = 0 Loop Ready => "pMdfy"= TRUE
      = >0 transfer is active
      = -1 transfer is ended / 1 cycle active
      = -2 transfer to break
      reset to =0 set "pMdfy"= FALSE*)
  END_VAR
'C-CODE'
BODY
C_CODE_OBJECT_BODY
int iSizeSrc, iSizeDst, /* size of source,/-destination */
  iOfstSrc, iOfstDst, /* offset source,/-destination */
  iNmbrOfR, iCntLoop; /* Number of REAL, loopcounter */
char *pSource, *pDstntn, /* addresspointer -source,/-destination */
  iToTrim, /* reduce modify */
  b0 , b1, b2, b3;
        /* Code of QiErr
        = 0 Loop Ready
        = >0 modifyed is run
        = -1 modify is ended / 1 cycle active
        = -2 modify is shorted
        = -3 modifyed to break
        = -4 INT-Source is odd =>
          REAL request even */

C_CODE_USER_AREA_BODY
if (#LD(xEn)&&(#LD(pModify)||(iCntLoop >0)))
{ if (iCntLoop >= 0)
  { iOfstSrc = #LD(uiInitSrc)*2;
    iOfstDst = #LD(uiInitDst)*2;
    iSizeSrc = #LD(uiQntINT)*2;
    iSizeDst = ((char*)& #LD(bDstEnd)-(char*)& #LD(dwDstStart))-4;
  pSource = ((char*)& #LD(dwSrcStart)+4 +iOfstSrc);
  pDstntn = ((char*)& #LD(dwDstStart)+4 +iOfstDst);
  if (iOfstSrc %4 == 0)
  { if (iSizeDst >= iSizeSrc)
    { iNmbrOfR = iSizeSrc /4;#ST(pErr, FALSE);
      iToTrim = 0;
    }
    else
    { iNmbrOfR = iSizeDst /4;
      iToTrim = 1;
    }
    iCntLoop = 0;
    while(iNmbrOfR > iCntLoop)
    { memcpy (pDstntn +(4* iCntLoop)+b0, pSource +(4* iCntLoop)+0, 1);
      memcpy (pDstntn +(4* iCntLoop)+b1, pSource +(4* iCntLoop)+1, 1);
      memcpy (pDstntn +(4* iCntLoop)+b2, pSource +(4* iCntLoop)+2, 1);
      memcpy (pDstntn +(4* iCntLoop)+b3, pSource +(4* iCntLoop)+3, 1);
      ++ iCntLoop;
        #ST(QiErr, iCntLoop);
       }
    if (iToTrim == 0)
    { iCntLoop = -1;
    }
    else
    { iCntLoop = -2;
      #ST(pErr, TRUE);
    }
    #ST(QiErr, iCntLoop);
       }
       else
    { #ST(QiErr, -4);
      #ST(pErr, TRUE);
       }
     }
}
else
{ iCntLoop = 0;
  #ST(QiErr, iCntLoop);
  #ST(pErr, FALSE);
  switch(#LD(siCnvTyp))
  { case 0 : b0 = 0;
        b1 = 1;
        b2 = 2;
        b3 = 3;
       case 1 : b0 = 3;
        b1 = 2;
        b2 = 1;
        b3 = 0;
       case 2 : b0 = 1;
        b1 = 0;
        b2 = 3;
        b3 = 2;
       case 3 : b0 = 2;
        b1 = 3;
        b2 = 0;
        b3 = 1;
  }
}

END_BODY
END_FUNCTION_BLOCK

Wolfgang_Jath · December 31, 2019, 1:28pm

Hallo Wolfgang,

als 1. möchte ich hierzu bemerken, dass ich in Zukunft nicht mehr weiter
zu diesem Thema schreiben werde; es sei denn, jemand hat eine direkte
Frage an mich.

Also /ich/ sicherlich nicht.

Derjenige darf mich dann direkt ansprechen.

Ohhh, wie gnädig. SCNR

Der Rahmen hier wird eindeutig gesprengt.

Warum hast du das Thema dann überhaupt angesprochen? Noch dazu, da es
dem OP eigentlich um etwas völlig /anderes/ ging, nämlich um ein
einfacheres /Handling/?

*Alle* Daten, sogar Texte, werden intern binär abgelegt. Und Calc selbst
kennt überhaupt nur 3 Datentypen, nämlich String aka Text, Integer und
Gleitkomma aka Double.

Jep,
aber nur bedingt richtig "Wahrheitswert" (BOOL) hast Du unterschlagen...

Nein; bool ist genauso nur ein Integerwert (0=falsch, alles
andere=WAHR); probiers aus.

Das ist dann in etwa das selbe, wie wenn ich für jeden einzelne Fahrgast
einen Bus mit 60 Sitzplätzen auf die Reise schicke - wirklich sehr
effizient!

Ja, es ist in der Tat sehr effizient, wenn er mit möglichst nur einem
einzigen Programm möglichst viele Bedürfnisse erfüllen kann. Das gilt
sowohl für den Softwareautor, der dann auch nur ein einziges Programm
warten und pflegen muss, als auch für den User, der sich dann lediglich
in die Bedienung eines einzigen Programms einarbeiten muss.

Kein Wunder,dass die Prozessoren immer schneller werden und am Ende die
Berechnungswartezeit trotzdem nicht kürzer wird...

Hint: Der Haupteffekt eines Rechners mit höherem Rechentakt und/oder
mehr Kernen stellt sich in der Regel so dar, dass er halt mit höherem
Rechentakt und/oder mehr Kernen auf die nächste Eingabe des Users
wartet. Die Auswirkungen auf die Rechenzeiten sind, von wenigen
Ausnahmen wie z. B. rechenintensivem Rendering o. ä. abgesehen, marginal.

Wenn das, was Du hier sagst richtig ist; das die Zeiten in Calc in
Fliesskomma-Werten hinterlegt sind; dann werden bei gewissen
Rechenoperationen unweigerlich Fehler auftrete.

Tut es, ja. Allerdings so weit hinten, dass das nur sehr selten auf
fällt. Aber gelegentlich tut es das; such mal im Archiv (siehe Footer)
nach dem Thread "CALC: Uhrzeit wird beim Kopieren mit Maus falsch
berechnet" vom 3.12.2019.

Auch das ist nur bedingt richtig. Wenn man kurze Zeiten zuerst dividiert
und erst anschliessend multipliziert, kann es schon es erheblichen
Rundungsfehler führen...

Sachichdoch; aber wie oft passiert das?

Für eben solches aber benutze ich z.B. Calc, da ich unter Anderem in der
Netzfrequenzen die Abweich-Toleranz im Drehfeld in Winkel° berechnen muss...
(Synchronisation von Generatoren)

Ja, man kann ein Tabellenkalkulationsprogramm eben zu vielem
miss^Wgebrauchen.

Nicht gerade das Gesuchte. In INT würde solches nie auftreten. Auf
Leitsystemen mit Echtzeiteinträgen ist es Bedingung, dass die
Zeitstempel kohärent sind!

Ähm; dir ist aber schon bewusst, was das Wort "kohärent" wirklich
bedeutet, oder?

Im Zusammenhang mit Zeit sicherlich ein passender Begriff, wenn man
Gleichtakt, Phasengleichheit darunter versteht...

Beschreibungen wie Gleichtakt, Phasengleichheit usw. sind aber nur
*Interpretationen* der Bedeutung von Zahlenwerten; Calc kennt nur die
Zahlenwerte an sich; wie der User diese interpretiert ist ihm wurscht.

Trotzdem muss ich mich wiederholen mit der Frage, was das alles mit Calc
zu tun hat. Hint: Cals ist ein Tabellenkalkulationsprogramm, kein
Transportprotokoll (und schon gar kein serielles).
Die Frage ist immer noch die Selbe:

Warum wurde der Zeitstempel bei Calc in eine REAL hinterlegt?

Nochmal ganz langsam zum Mitdenken: Es ist kein REAL sondern ein DOUBLE;
64-bit, nicht 32-bit.

Dar Programmiere muss doch einen triftigen Grund dafür gehabt haben...

Ja, hat es; sogar mehrere. Der erste ist, dann die heutigen, modernen
Rechnerprozessoren überrachenderweise bereits standardmäßig einen
Fließkommaprozessor eingebaut haben, der i.d.R. genauso schnell, oft
sogar schneller, Flißkommarechnungen durchführen kann als die Haupt-CPU
Integeroperationen ausführt. Der zweite ist, dass es vielleicht eine
geistige Anstrengung für manche Menschen darstellen mag, aber überhaupt
kein Probleme für die heutzuage üblichen Universalrechenkerne, Zeiten
repräsentierende Werte so zu interpretieren, dass der Vorkommaanteil
eben /ganze/ Tage, und der Nachkommanateil /Bruchteile/ von Tagen
darstellen; genau so wie Minuten nur Bruchteile von Stunden sind,
Sekunden nur Bruchteile von Minuten, Millisekunden nur Bruchteile von
Sekunden, usw.

Das folgende hat nun tatsächlich gar nichts mit Calc zu tun,

Ja.

ausser dass
die daraus resultierende Daten via OPC in eine Tabelle auf dem Server
eingetragen und als Graphik ausgegeben werden.

Nein, auch das hat nix mit Calc zu tun; was du da beschreibst ist ein,
ich möchte schon fast sagen, Missbrauch, eines
Tabellen*kalkulations*programms zum Zwecke der *grafischen* Darstellung.

Ja, klar, kann man machen, warum auch nicht? Schließlich *kann* es das
/auch/; als *ein* Feature unter *vielen*. Aber ihm deswegen vor zu
werfen, dass es sich bemüht, möglichst viele Bedürfnisse zu erfüllen,
anstatt sich optimal an ausschließlich die speziellen Bedürfnisse an zu
gepassen, die *du* für *deine* Anwendung als billiges /Frontend/
benötigst, ist schon sehr, hmmm ..., gewagt. Wenn dir Calc als Frontend
für deine Anwendung nicht passt, dann schreib dir dein eigenes; und lass
dir dein Geld für Calc zurück geben. Sorry.

Das was ich hier einkopiert habe ist ein Konvertierungs-Funktionsblock,
welcher in eine übergeordnete System-Programmierung eingebunden wird.
Leider gibt es drei Konventionen für die serielle Übertragung die auf
das im Empfänger genutzte Protokoll umgeschrieben werden muss; das Rad
wird halt immer wieder mal neu erfunden.

Und was bitte hat das mit Calc zu tun?

Die Konvertierung von Datenformaten ist in allererster (und auch
zweiter, dritter und vierter) Linie eine Sache des
Komunikationsprotokolls. Und das hat nix mit Rad neu erfinden zu tun,
sondern mit Kommunikation.

Und ich habe selber schon, neben 'normalen' Programmen, auch mehr als
nur eine Hand voll Gerätetreiber geschrieben; in Hochsprachen, und wo es
nötig war auch in Assembler (wenn ich auch, zugegeben, noch nix mit SPS
zu tun hatte). Also erzähl nem Affen nicht, dass die Banane krumm ist.

Wolfgang