Effizienz/Performance RoboPro-Programmierung

Alles rund um TX(T) und RoboPro, mit ft-Hard- und Software
Computing using original ft hard- and software
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
Pinot
Beiträge: 55
Registriert: 23 Nov 2021, 15:24
Wohnort: Pfalz

Effizienz/Performance RoboPro-Programmierung

Beitrag von Pinot » 11 Mär 2022, 09:00

Folgende Fragestellung: ich brauch eine Betragsfunktion. Nun kann ich mir die auf zwei Wegen zusammenbauen:

Mit einer Ablaufsteuerung
Ablaufsteuerung.jpg
Ablaufsteuerung.jpg (48.27 KiB) 3738 mal betrachtet
Oder direkt auf dem Weg der Datenbearbeitung
Datensteuerung.jpg
Datensteuerung.jpg (7.51 KiB) 3738 mal betrachtet
Wenn man beim Funktionsaufruf vergisst, den Datentyp korrekt anzugeben (Integer oder FP), gibt's eine geniale Fehlermeldung ...
Fehler.jpg
Fehler.jpg (14.97 KiB) 3738 mal betrachtet
Wenn man den Datentyp auf Integer stellt, da man INT verarbeiten will, wird man hiermit ueberrascht:
Programmfehler.jpg
Programmfehler.jpg (7.91 KiB) 3693 mal betrachtet
Dann bleibt nur von hinten durch die Brust in's Auge mit einem Typecast:
Typecast.jpg
Typecast.jpg (9.71 KiB) 3693 mal betrachtet
Jetzt zu meiner eigentlichen Frage: was ist effizienter im Hinblick auf Performance? Die Programmierung moeglichst ueber Ablaufsteuerungen? Oder der Aufruf von Berechnungsfunktionen? Oder ist es egal?

Benutzeravatar
fishfriend
Beiträge: 1823
Registriert: 26 Nov 2010, 11:45

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von fishfriend » 11 Mär 2022, 20:15

Hallo...
Performance = Geschwindigkeit?

Ich bin mir nicht sicher...
Welche Version benutzt du?

Würde es helfen -in- der Funktion eine eigene Variable zu deffinieren?
Was würde passieren wenn diese als INT deffiniert ist, also ohne den Typecast? Um so den Typecast über die Variable zu machen.

Mit freundlichen Grüßen
fishfriend
Holger Howey
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

vleeuwen
Beiträge: 1567
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von vleeuwen » 11 Mär 2022, 23:32

test(abs).jpg
test(abs).jpg (74.65 KiB) 3595 mal betrachtet
It is not a type cast in the sense of an imperative programming language, it is a conversion.
software enigineer/teacher/advisor
Google translate
http://tescaweb.nl/Carel/?p=713

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von MasterOfGizmo » 12 Mär 2022, 08:52

What's the difference between a typecast and a conversion?
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Pinot
Beiträge: 55
Registriert: 23 Nov 2021, 15:24
Wohnort: Pfalz

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von Pinot » 12 Mär 2022, 09:52

Was ist mein prinzipielles Problem: ich baue eine Steuerung aus zwei TXT die mittlerweile fünf Motore (es werden noch mehr) und weitere Aktore antreibt. Dazu hat sie mehrer Schalter deren Informationen verarbeitet werden. Der Nutzer kontrolliert das ganze über eine IR-Steuerung, die nicht nur Ein/Aus sendet, sondern auch Integerwerte der Joysticks von -15 … 15. Was dann wieder zur dynamischen Ansteuerung von Motoren genutzt wird.

Mit dem Ausbau dieser Steuerung (keine Regelung!) beobachte ich, dass das Gesamtsystem immer instabiler wird. Motore laufen nicht an, setzen aus, das Ganze wird immer hakeliger.

Und da frag ich mich: liegt‘s womöglich an der Ineffizienz meiner Programmierung? Gibt es für RoboPro vielleicht ein paar good engineering practices, wie man Prozessorressourcen schont? Denn letztendlich muss die ganze grafische Kritzelei in OP-Code übersetzt werden. Und das mag je nach Quelle mal zu effizienterem oder weniger effizientem Code führen.

In der Hilfe bin ich mal über den Hinweis gestolpert, man soll nicht zu viele Funktionen aufrufen. Mehr war zu dem Thema aber auch nicht zu finden.

Grüße, Thomas

vleeuwen
Beiträge: 1567
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von vleeuwen » 12 Mär 2022, 12:44

@MasterOfGizmo
*) Type casting is treating a value (block of memory) referenced by a variable as being of a different type than the type the variable is declared as.

*) Type conversion is actually performing a conversion of that value.
In the case of RoboPro the Int16 value is rewritten into the Floating point format. It is not a reinterpretation of the memory block.
This is general the case with floating point < = > integers because the representation in the memory is different.
software enigineer/teacher/advisor
Google translate
http://tescaweb.nl/Carel/?p=713

Benutzeravatar
fishfriend
Beiträge: 1823
Registriert: 26 Nov 2010, 11:45

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von fishfriend » 12 Mär 2022, 14:01

Hallo...
OK es ist ein ein Bug :-(

Und den Wertebereich von 0-30 machen?

Du kannst den Interface-Test parallel aufmachen und sehn wie sich die Motoren verhalten, drehen, richtung...
Man kann auch mehrere z.B. für die Extensions aufmachen.

Mit freundlichen Grüßen
fishfriend
Holger Howey
PS Ich kämpfe gerade mit zwei TX und drei Schrittmotoren, wo es auch noch nichtoptimal läuft, weil die An-Abschaltzeiten sich beeinflussen.
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von MasterOfGizmo » 12 Mär 2022, 14:08

vleeuwen hat geschrieben:
12 Mär 2022, 12:44
@MasterOfGizmo
*) Type casting is treating a value (block of memory) referenced by a variable as being of a different type than the type the variable is declared as.

*) Type conversion is actually performing a conversion of that value.
In the case of RoboPro the Int16 value is rewritten into the Floating point format. It is not a reinterpretation of the memory block.
This is general the case with floating point < = > integers because the representation in the memory is different.
That's completely wrong. Here's a C example using a regular c typecast from float to int:

Code: Alles auswählen

#include <stdio.h>

int main(void) {
  float a = 12.5;
  printf("a is %f\n", a);
  printf("(int)a is %d\n", (int)a);

  return 0;
}
The resulting output is:

Code: Alles auswählen

a is 12.500000
(int)a is 12
If you cannot read C I can give you an example in a different language. Is there a computer language you understand?

So a was fully _converted_ from float to int.

Actually the german phrase for type cast is Typumwandlung which translates back to type conversion.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

vleeuwen
Beiträge: 1567
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von vleeuwen » 12 Mär 2022, 15:41

@MasterOfGizmo
http://www.mathcs.emory.edu/~cheung/Cou ... tConv.html

Mastery of programming language families and concepts is irrelevant to this discussion. I will not make you any wiser with regard to my knowledge in that area, It is about the substantive aspects and not about personal matters, but this is not the first time that you are targeting the person.
The given definition of "casting" versus "conversion" is programming language independent.
Attached is an explanation of how the image is put together in memory. On a microcomputer system, handling a float takes much longer than an integer of the length that matches the register length.
It's not about how a compiler of a particular language handles this, but it is done at the machine level.
======================================================================================
Die Beherrschung von Programmiersprachenfamilien und -konzepten ist für diese Diskussion irrelevant. Ich werde Sie in Bezug auf mein Wissen in diesem Bereich nicht klüger machen. Es geht um die inhaltlichen Aspekte und nicht um persönliche Angelegenheiten, aber Sie zielen nicht zum ersten Mal auf die Person ab.
Die gegebene Definition von "Casting" versus "Conversion" ist unabhängig von der Programmiersprache.
Im Anhang finden Sie eine Erklärung, wie das Bild im Speicher zusammengesetzt wird. Auf einem Mikrocomputersystem dauert die Handhabung eines Floats viel länger als eine Ganzzahl mit der Länge, die der Registerlänge entspricht.
software enigineer/teacher/advisor
Google translate
http://tescaweb.nl/Carel/?p=713

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von MasterOfGizmo » 12 Mär 2022, 16:28

vleeuwen hat geschrieben:
12 Mär 2022, 15:41
Mastery of programming language families and concepts is irrelevant to this discussion.
No, you definitely need to know the stuff you are talking about. What you wrote is simply wrong. I gave you an example that shows that you were wrong. Maybe Wikipedia can convince you: https://de.wikipedia.org/wiki/Typumwandlung uses "type conversion" and "type cast" as synonyms which means that they are different words for the same thing.

I have a request to the moderators.

Please cut this entire discussion starting with vleeuwen's first posting and move it to the off-topic section.

And please can some moderator explain how we are supposed to deal with such postings? vleeuwen's first reply in this topic was

- off-topic/unrelated to the initial question
- was given in english (without translation) while the original posting was german
- was technically wrong

I could have ignored that. But there are many beginners listening here and this is not a single posting that is spreading misleding or plain wrong information. Also giving examples showing that the statements made are trechnically wrong lead to even more misleading information.

I don't know how to deal with this. What do the moderators think?
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

vleeuwen
Beiträge: 1567
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von vleeuwen » 12 Mär 2022, 19:19

In general, a "type cast" in a higher strong typed programming language is used to indicate that simple types can be seen as a different type.
The software engineer then takes responsibility for any loss of information (precision) for his own account and the compiler or interpreter decides how to implement the corresponding conversion.
When working with classes (object oriented) "type cast" in relation to inheritance has a somewhat different meaning.
In the case of RoboPro, this is not the case. This is also emphasized in the help of RoboPro (chapter 13 Working with decimals); only the term conversion is used there.
It is known from the world of microcontrollers that floating point mathematics usually requires many more steps at the level of the machine instructions and therefore usually runs slower. The presence of a floating point processor can reduce this slowness.
If such a conversion, actually part of a data flow, is placed in a separate RoboPro workflow, then the repetition rate is quite high. This while the need to calculate that value only depends on the main workflow. For this reason, it is not advisable to program calculation in this way (with his own work flow).
If the "abs" is replaced by a RoboPro SLI element, this effect will be clearly visible in the console logging.
===========================Google translate====================================================================
Im Allgemeinen wird eine "Typumwandlung" in einer stärker typisierten Programmiersprache verwendet, um anzuzeigen, dass einfache Typen als ein anderer Typ angesehen werden können.
Der Software-Ingenieur übernimmt dann die Verantwortung für etwaige Informationsverluste (Präzision) auf eigene Rechnung und der Compiler oder Interperter entscheidet, wie er die entsprechende Konvertierung durchführt.
Beim Arbeiten mit Klassen (objektorientiert) hat "Type Cast" in Bezug auf Vererbung eine etwas andere Bedeutung.
Bei RoboPro ist dies nicht der Fall. Dies wird auch in der Hilfe von RoboPro betont (chapter 13 Working with decimals); dort wird nur der Begriff Konversion verwendet.
Aus der Welt der Mikrocontroller ist bekannt, dass Gleitkomma-Mathematik meist viel mehr Schritte auf der Ebene der Maschinenbefehle benötigt und daher meist langsamer läuft.
Das Vorhandensein eines Gleitkommaprozessors kann diese Langsamkeit verringern.
Wenn eine solche Konvertierung, eigentlich Teil eines Datenflusses, in einen separaten RoboPro-Workflow gestellt wird, dann ist die Wiederholungsrate ziemlich hoch. Die Notwendigkeit, diesen Wert zu berechnen, hängt jedoch nur vom Hauptworkflow ab. Aus diesem Grund ist es nicht ratsam, die Berechnung auf diese Weise (mit eigenem Workflow) zu programmieren.
Wenn das „abs“ durch ein RoboPro SLI-Element ersetzt wird, wird dies im Konsolenprotokoll deutlich sichtbar.
software enigineer/teacher/advisor
Google translate
http://tescaweb.nl/Carel/?p=713

juh
Beiträge: 907
Registriert: 23 Jan 2012, 13:48

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von juh » 12 Mär 2022, 22:41

MasterOfGizmo hat geschrieben:
12 Mär 2022, 16:28
And please can some moderator explain how we are supposed to deal with such postings?
Till, lass doch das Moderationsteam da außen vor. Du bist es doch der sich auf vleeuwens Post gestürzt hat. Wenn Du den für off topic hältst, warum steigst Du dann so darauf ein? Für tatsächliche oder behauptete inhaltliche Fehler ist doch nicht die Moderation zuständig und Übersetzung ist nach meinem Verständnis eine Bitte, kein Zwang.

vg
Jan

(Eigentlich eine PN, die kann man dir hier aber nicht schicken.)

Benutzeravatar
steffalk
ft:pedia-Herausgeber
Beiträge: 1794
Registriert: 01 Nov 2010, 16:41
Wohnort: Karlsruhe
Kontaktdaten:

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von steffalk » 13 Mär 2022, 00:08

Tach auch!

Um mal wieder zur ursprünglichen Frage zurückzukehren: Wie wäre es denn mit einfach ausprobieren und beide Varianten in einem kleinen Benchmark zu vergleichen? 1000 mal oder so beides durchrechnen lassen und die Zeit stoppen? Dann wären wir von allen Dingen, die wir nicht wissen, wie irgendwelche Interna von RoboPro, entkoppelt.

Gruß,
Stefan

Pinot
Beiträge: 55
Registriert: 23 Nov 2021, 15:24
Wohnort: Pfalz

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von Pinot » 13 Mär 2022, 12:46

Ja, Benchmarking ist eine Moeglichkeit. Aber mir geht's gar nicht um die "ABS"-Funktion im Besonderen. sondern um geschwindigkeitseffiziente Programmierung im Allgmeinen. Bei vielen Steuerungen kann ich die Logik im Datenfluss (mit Arithmetik und Boolschen Verknuepfungen) implementieren, oder im Prozessablauf (mit Verzweigungen). Und ich hatte gehofft, dass in den vielen Jahren, in denen es den TXT und RoboPro jetzt gibt, sich eine Best Practice herauskristallisiert haette. Hat sich aber offensichtlich nicht.

Was sich fuer mich aber jetzt mehr und mehr zeigt: eine Steuerung mittels IR und der Abfrage der Joysticks zur Geschwindigkeitssteuerung von Motoren, mag der TXT ueberhaupt nicht. Je mehr Motore ich gleichzeitig steuere, und dabei auch noch im Datenfluss mit den Josystick-Werten Arithmetik betreibe, desto mehr geht die Gesamtanlage in die Knie. D.h. teilweise reagiert sie gar nicht mehr, teilweise bekommen die Motore keine Befehle mehr usw.

Als ich die Moeglichkeit gefunden hatte soetwas zu implementieren, dachte ich die Sonne geht auf ...
Motorsteuerung.jpg
Motorsteuerung.jpg (11.57 KiB) 3228 mal betrachtet
Seitdem ich das auf mehrere Achsen erweitert habe ist eher Daemmerung. Aber ich glaube das ist wohl einen eigenen Thread wert.

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von MasterOfGizmo » 13 Mär 2022, 18:43

Um die Möglichkeiten reiner Kombinatorik in RoboPro ging es entfernt auch in diesem Thread:

viewtopic.php?f=8&t=7163

Letztlich war das Fazit, dass hinter den einfach aussehenden Logiken in RoboPro ein Haufen Message-Passing stattfindet, dass also ständig Nachrichten hin- und hergeschickt werden.

Ich könnte mir gut vorstellen, dass das direkt auf die Performance durchschlägt. Und dann macht es ggf. leider gar keine Unterschied, wie man das umsetzt, im Hintergrund werden so oder so vielen Nachrichten verschickt. So hab ich's zumindest verstanden ...
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

ModeratorRalf
Moderator
Beiträge: 163
Registriert: 13 Sep 2019, 21:00

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von ModeratorRalf » 14 Mär 2022, 23:21

Hallo Till, hallo Carel,
ich werde keinem und auch keinem Beitrag von euch beiden den Vorzug geben und auch keinen Beitrag verschieben. Soweit ich das überblicken kann, gehört hier alles mehr oder weniger zum Thema.

Ich kenne und schätze euch beide sehr und weiß, dass ihr gestandene C-Entwickler seid.
Die Problematik der Typ-Konvertierungen in puncto float nach int und umgekehrt und im speziellen noch deren Performance ist wahrscheinlich so alt wie C selber.
Genauso wie eure Zwistigkeiten so alt sind wie dieses Forum.
Ich weiß gar nicht warum und auch nicht wer irgendwann mal damit angefangen hat?
Ich weiß nur - es dient wirklich niemandem.

Viele Grüße, Moderator Ralf

--- (Translation by deepl)

Hello Till, hello Carel,
I won't give preference to either of you, nor will I move any of your posts. As far as I can see, everything here is more or less on topic.

I know and appreciate you both very much and know that you are experienced C developers.
The problem of type conversions in terms of float to int and vice versa and especially their performance is probably as old as C itself.
Just as your quarrels are as old as this forum.
I don't know why and I don't know who started it at some point?
I only know - it really serves nobody.

Greetings, Moderator Ralf
Nordconvention am 20. April 2024 im Schulzentrum Mellendorf in 30900 Wedemark

thkais
Beiträge: 381
Registriert: 31 Okt 2010, 21:45

Re: Effizienz/Performance RoboPro-Programmierung

Beitrag von thkais » 06 Apr 2022, 06:54

Hallo Pinot,
das von Dir beschriebene Verhalten habe ich auch schon gesehen. Man muss mit dem "Timing" aufpassen, d.h. wann wird welche Information wo bereitgestellt. Wenn man einen linearen Programmablauf von Scriptsprachen gewohnt ist, kann man mit dieser Gleichzeitigkeit der Daten schon mal einen Knoten ins Hirn bekommen und ein Motor gleichzeitig zwei unterschiedliche Befehl bekommen. Das sieht dann manchmal so aus, als ob alles sehr langsam abläuft - je nachdem, welcher Zweig gerade gewinnt.

Ab und an kann es sinnvoll sein, nicht nur mit orangen Linien zu arbeiten sondern die Werte zeitlich in einer Reihenfolge zu definieren (mit "=" Zuordnungen im blauen Programmablauf). Evtl. kannst Du Dein Programm ja mal hochladen, dann könnte man gemeinsam drüber schauen.
Gruß
Thomas
Gruß
Thomas

Antworten