Show Posts
Pages: 1 ... 42 43 [44] 45 46 ... 193
646  International / Deutsch / Re: Indexinhalte eines Arrays nach deren Größe ordnen on: March 22, 2014, 04:51:42 am
Mit der zweiten Methode will es jedoch leider noch nicht wirklich funktionieren:

Zumindest der Aufruf der Funktion ist falsch, weil Du die Größe eines einzelnen zu sortierenden Elements falsch angibst. Wenn Du int-Werte sortieren möchtest, hat ein zu sortierendes Element die Größe "sizeof(int)".

Code:
qsort (Zielarray, 5, sizeof(int), compare);
647  International / Deutsch / Re: Poblem mit V-Plotter und GRBL on: March 21, 2014, 06:08:59 pm
Ich kann dir garnicht so viel Karma geben, wie ich es gerne würde.

Danke für die großartige Anerkennung!

Ich hab da aber noch eine frage: Hast du dir die GRBL Software runtergeladen und angesehen?
Hier nochmal der Link zu der Seite https://github.com/grbl/grbl
Kann man das da nicht irgendwie, Irgendwo einbauen?

Ich habe mir den Code mal angesehen. Und auch, was die G-Code Daten eigentlich sind.

Offenbar ganz etwas anderes als HPGL-Daten, d.h. da sind nicht nur die zu plottenden XY-Werte in den Daten enthalten, sondern auch höhere Geometriedaten wie z.B. Kreisbogenbeschreibungen, die dann erst noch interpretiert werden müssen. An den G-Code Daten, mit denen Dein Plotter gefüttert wird, kann man also nicht so einfach ansetzen. Die Kreisbögen würden sich einer Umrechnung entziehen.

Nachdem ich mal in den Code geschaut habe, kommt für eine Umrechnung der Koordinaten wohl die Datei "planner.c" in Frage und dort die Funktion "plan_buffer_line". Das scheint die Funktion zu sein, in der die Koordinaten in Steps für die Stepper-Motoren umgerechnet werden. Und dort könnte man am Anfang der Funktion, bevor die Umrechnung in Stepper-Schritte erfolgt, noch die Umrechnung der Koordinaten einfügen.

Statt Code in Datei planner.c:
Code:
void plan_buffer_line(float x, float y, float z, float feed_rate, uint8_t invert_feed_rate)
{
  // Prepare to set up new block
  block_t *block = &block_buffer[block_buffer_head];

  // Calculate target position in absolute steps
...

Da tue ich mal so als wenn die Funktion noch gar nicht die richtigen Koordinaten übergeben bekommt, sondern falsche Koordinaten, die ich mal xx und yy nenne und dann erst in X- und Y- umrechne (die hergeleiteten Werte für da und db), womit dann die Stepper-Schritte ermittelt werden:

Setze Code in Datei planner.c:
Code:
// V-Plotter calculations by 'jurs' for German Arduino Forum
// Details: http://forum.arduino.cc/index.php?topic=226277.0

#define XB 500.0
#define XA XB
#define YB 600.0
#define YA YB

void calc_ab(float x, float y, float &da, float &db)
{
  // db = b - b0
  db= sqrt((XA-x)*(XA-x) + (YA-y)*(YA-y)) - sqrt(YA*YA+XA*XA);
  // da = a - a0
  da= sqrt((XB+x)*(XB+x) + (YB-y)*(YB-y)) - sqrt(YB*YB+XB*XB);
}

void plan_buffer_line(float xx, float yy, float z, float feed_rate, uint8_t invert_feed_rate)
{
  // Prepare to set up new block
  block_t *block = &block_buffer[block_buffer_head];
  float x,y;
  calc_ab(xx, yy, x, y);
  // Calculate target position in absolute steps
...

Für die Geometriedaten Deines V-Plotters müßtest Du dann natürlich Deine tatsächlichen Werte für XA und XB direkt in die Library-Datei einsetzen, so dass die geänderte Library dann nur für Deine V-Plotter-Abmessungen verwendbar ist. Am besten sicherst Du Dir die Originaldatei, bevor Du sie für Dich veränderst.

Ob das die optimale Stelle zum Patchen der Library ist und ob das wirklich alles ist, was gemacht werden müßte und ob es überhaupt so funktioniert, müßtest Du mal ausprobieren. Ich kann es hier bei mir nicht testen, ich habe keinen V-Plotter.

Du kannst ja mal posten, wie es dann mit diesem Patch aussieht.
648  International / Deutsch / Re: Arduino Mega 2560 nach verwendung des Watchdog Timers nicht mehr beschreibbar on: March 21, 2014, 04:47:18 pm
Stimmt das so?

Funktioniert hat es jedenfalls nicht, aber ich hab natürlich auch keine Ahnung, ob das so generell nicht geht oder es immer noch am Watchdog liegt...

Generell müßte es wohl so funktionieren. Allerdings hast Du auf dem MEGA ja immer noch den fehlerhaften Sketch auf dem MEGA2560 drauf, und wenn der MEGA Strom bekommt, dann läuft erst sein Bootloader und danach aktiviert der fehlerhafte Sketch wieder den Watchdog-Reset, der ab dem Zeitpunkt aktiv ist und in einer Endlos-Reset-Schleife immer wieder zuschlägt und auch beim Reset nicht mehr deaktiviert wird.

Auf welche Tmeout-Zeit hast Du denn den Watchdog-Reset programmiert? Acht Sekunden? Oder weniger?

Wenn Du keinen richtigen ISP-Programmer hast und wenn ich es mir recht überlege, müßtest Du mit einem manuellen Reset eigentlich auch mit Hilfe des Bootloaders und des USB-Kabels in der Lage sein, einen neuen, fehlerfreien Sketch hochzuladen. Z.B. den Blink-Beispielsketch.

Hintergrund: Soweit mir bekannt ist, startet der Atmega beim Power-On ohne aktivierten Watchdog, und wenn danach der Watchdog-Reset programmiert ist, bleibt dieser bis zum Entfernen der Stromversorgung aktiv, übersteht also Resets.

Eigentlich müßtest Du jetzt nur folgende zwei Dinge machen:
1. das MEGA-Board mit Strom versorgen, OHNE dass der Controller startet
2. dafür sorgen, dass beim anschließenden ERSTEN START des Controllers sofort über den Bootloader ein neuer Sketch geladen wird

Das Handling dafür wäre wie folgt. Vorab würde ich unter Windows die Tonausgabe aktivieren, so dass man es akustisch hört, wenn Windows ein angestöpseltes USB-Gerät entfernt oder eingestöpselt bekommt.

1. USB-Kabel vom MEGA2560 Board entfernen (Board stromlos machen)
2. Reset-Taster auf dem MEGA-Board drücken und gedrückt halten
3. USB-Kabel einstöpseln und warten, bis die serielle Schnittstelle von Windows erkannt wird (Ton!)
   (Der gedrückte Reset-Button auf dem Board verhindert, dass der Controller startet)
4. Aus der Arduino-Software heraus den Sketch-Upload starten (z.B. Blink-Sketch)
5. Sobald die Arduino-Software "Uploaden..." anzeigt, blitzartig den Reset-Button loslassen

Falls es nicht auf Anhieb klappt, ggf. diese Schritte mehrmals wiederholen.

Funktioniert der Upload auf diese Art?
Wenn ja: Ist das Board danach normal benutzbar?
649  International / Deutsch / Re: Encoder gesucht on: March 21, 2014, 01:31:37 pm
Was muss ich machen, damit TCCR2, OCR2, OCIE2 richtig geladen werden. Bekomme die Meldung, dass die nicht deklariert sind.

Welches Board mit welchem Controller?

Auf dem Atmega328 gibt es beispielsweise TCCR2A und TCCR2B als Register.

Wenn Du hardwarenah direkt mit Registern programmieren willst, mußt Du auch genau die Register ansprechen, die die verwendete Hardware tatsächlich hat.
650  International / Deutsch / Re: Indexinhalte eines Arrays nach deren Größe ordnen on: March 21, 2014, 09:35:42 am
Da in meinem Fall im Hintergrund mit nem Timer höhe Frequenzen berechnet werden, würde mir viel an einer schnellen Ausführung liegen.

Hast Du mir nen Tipp

Hat das Array immer nur 5 Elemente?
In dem Fall gibt es wohl keinen allgemeinen Sortieralgorithmus, der bei "gut gemischten Elementen" in den meisten Fällen viel schneller sein kann als Bubblesort.

Warum mußt Du das Array überhaupt in ein Zielarray kopieren und dann nur das Zielarray sortieren?
Kannst Du die einzelnen Werte nicht bereits beim Einfügen in das Array "sortiert einfügen"?

Schneller werden kannst Du insbesondere dann, wenn die Daten im Array nicht zufällig gleichverteilt vorkommen, sondern wenn Du über die Art der Daten irgendwelche Annahmen machen kannst. Wenn Du z.B. weißt, dass z.B. von fünf Werten immer zwei Werte unter 10 und zwei Werte über 10 liegen und nur ein Wert vollkommen beliebig ist, kannst Du wesentlich effektiver Sortieren (oder beim Erstellen des Arrays einfügen) als wenn Du gar keine Annahmen über die Daten im Array machen kannst.
651  International / Deutsch / Re: lcd.begin vs. Serial.print !?!? on: March 21, 2014, 08:59:42 am
Am Ram scheint es jedoch nicht zu liegen

Stimmt, denn Du scheinst einen MEGA und keinen UNO oder vergleichbares zu verwenden.
RAM ist genug vorhanden.
652  International / Deutsch / Re: Indexinhalte eines Arrays nach deren Größe ordnen on: March 21, 2014, 08:54:00 am

Das ist der sogenannte "Bubblesort" Algorithmus. Bubblesort ist am einfachsten zu implementieren, aber insbesondere bei sehr vielen zu sortierenden Elementen nicht das schnellste Sortierverfahren.

size ist in dem Fall die Anzahl der Elemente im Array.

Also
int size=sizeof(tollesArray)/sizeof(tollesArray[0]);  // Größe des gemamten Arrays in Bytes durch Größe eines Elements

Eine "Sortierung" erfolgt übrigens immer an Ort und Stelle, im selben Array.
Als zusätzlicher Speicher wird nur Zwischenspeicher (Variable "temp") zur Aufnahme eines einzigen Elements beim Vertauschen von Elementen im Array benötigt.
653  International / Deutsch / Re: lcd.begin vs. Serial.print !?!? on: March 21, 2014, 07:43:56 am
damit anfangen kann ich aber zugegeben nichts  smiley-red

Eine Funktion zu verwenden, die selbst nochmal 4 Bytes RAM zusätzlich anfordert, wenn bereits der Verdacht des RAM-Speichermangels besteht, läßt das Programm noch mehr durchdrehen als sonst schon.

Nimm die Funktion:
Code:
int freeRam () {
  extern int __heap_start, *__brkval;
  int v;
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
}
und rufe diese auf mit:
Code:
Serial.println(freeRam () );

Und zwar möglichst auch mal in einer Programmversion mit weniger Plumpatsch, die gerade noch läuft.
654  International / Deutsch / Re: lcd.begin vs. Serial.print !?!? on: March 21, 2014, 07:09:06 am
Auf was für einem Controller soll das Programm laufen?

Lasse Dir mal am Ende der setup-Funktion den freien RAM-Speicher ausgeben/anzeigen!

Falls es um einen Controller mit 2 KB RAM geht, würde ich darauf tippen, dass bei dem ganzen Plumpatsch an verwendeten Libraries dem Controller der RAM ausgeht, sprich, dass Dein Sketch mehr RAM-Speicher verbrauchen würde als der Controller überhaupt eingebaut hat.
655  International / Deutsch / Re: PERMANENTE PROBLEME MIT COMPILIEREN VON CODE FÜR DEM DUE on: March 21, 2014, 05:31:18 am
WER kennt grundsätzlichen Änderungen oder Zusätze die unbedingt beachtet werden müssen, das Programme fehlerfrei portiert werden können. Welche Funktionen müssen vorhanden sein, das eventuell auch fremde Bibliotheken funktionieren ...

Ganz einach:
Eine Library, die auf dem DUE funktionieren und eine bestimmte Hardware steuern soll, muss speziell für den DUE geschrieben sein.
656  International / Deutsch / Re: Encoder gesucht on: March 21, 2014, 05:23:14 am
vorallem das falsch gezählt wird beim Encoder auslesen.

Das falsche Zählen ist systembedingt durch die Art der Auswertung in Deinem Sketch bzw. der verwendeten Drehgeber-Library. Mal eine kleine Übersicht der möglichen Auswertelogiken für Drehgeber mit einer Bewertung aus meiner Sicht:

Auswertelogik für Drehgeber basiert auf:
- Hardware-Interrupts
- PinChange-Interrupts
==> unbrauchbar für alle mechanischen, prellenden Drehgeber.
==> Eignung für hochwertige opto-elektrische Drehgeber mit eigener Auswertelogik, die ein prellendes Signal vermeidet

Auswertelogik für Drehgeber basiert auf:
- Polling
==> brauchbar abhängig vom Anwendungsfall für jede Art Drehgeber, einschließlich mechanische, prellende.

Auswertelogik für Drehgeber basiert auf:
- Timer-Interrupts
==> brauchbar in fast allen Anwendungsfällen für jede Art Drehgeber, einschließlich mechanische, prellende.

Alles, was im Playground an Drehgeberauswertung vorgestellt wird, ist nur für optoelektronische Drehgeber der 1000-Euro-Klasse mit eigener Signalelektronik brauchbar, die nicht-prellende Signale erzeugen. Solche Drehgeber haben eigene Elektronik eingebaut und benötigen eine eigene Stromversorgung. Intern basieren diese Geber auf berührungslosen optischen Prinzipien. Anwendungsfälle sind z.B. Drehspindeln von Maschinen, die genau in der Anzahl Umdrehungen und Winkelstellung der Spindel überwachst werden müssen. Für die einfachen mechanischen Drehgeber mit mechanischem Schleifkontakt sind sämtliche im Playground vorgestellten Auswertelogiken unbrauchbar (obowhl die Autoren des Playground-Beitrags das wohl anders zu sehen scheinen).
657  International / Deutsch / Re: Encoder gesucht on: March 20, 2014, 06:23:13 pm
ich hatte hier schon einmal einen Thread eröffnet, wo du mir mit dem Sketch geholfen hattest. (Ist nicht der einzige Thread den ich gerade durchgeblättert habe)
Das Problem war aber immer, dass diese nicht so genau liefen wie erwünscht.

Welcher Thread war das?

Meine Hardware für dieses Projekt ist ein Pro Mini, ALPS Drehencoder (falls ich keinen besseren finden sollte) sowie ein 1.8" Serial Display. Bei der loop kann es sehr gut vorkommen, dass diese nicht immer innerhalb von 1-2ms durchlaufen ist. Muss ich aber im Test mal messen.

Um mit "Polling des Drehgebers in der Loop" bei starkem Prellen gut klarzukommen, sollte die Loop niemals länger als 2ms für einen Durchlauf benötigen, wenn keine Impulse verlorengehen sollten.

Ansonsten: Auswertung in Timer-Interrupts.

Mit dem Taster des Encoders möchte ich 6 Säulen durchschalten (Werte für R, G, B, etc.) und mit dem Encoder selber die Werte hoch und runter regeln. Sobald der Taster erneut gedrückt wird, schalte ich eine Säule weiter und schicke, wenn Daten sich verändert, an den Arduino mit den WS2812B.

Das hört sich doch eigentlich so an, als wenn Du einen Timer-Interrupt für die Drehgeber-Auswertung noch frei haben könntest?

Sind die WS2812B  am selben Arduino angeschlossen wie der Drehgeber? Während die WS2812B LED-Controller angesteuert werden, sollen dann aber wohl hoffentlich keine Drehgeber-Impulse gezählt werden? Die Ansteuerung der WS2812B blockieren nämlich alle Abläufe auf dem Controller: Loop UND sogar Interrupts. Das meinst Du hoffentlich nicht, dass die Drehgeber nicht ausgewertet werden, während die Ansteuerung der LEDs erfolgt?

Ansonsten ist das harmlos. Mal angenommen, Du hast einen Drehgeber, der 20 Impulse pro Umdrehung abgibt, macht 80 Codewechsel pro Umdrehung, und Du drehst ihn mit einer Drehzahl von höchstens 2 Umdrehungen pro Sekunde. Dann wären das maximal 160 Codewechsel pro Sekunde (gültige, ohne Prellen), also
1000 ms / 160 = 6,25 ms pro Codewechsel.

Das Prellen zwischen den Codewechseln dauert praktisch nie länger als 1 ms, so dass abzüglich Prellzeit nach einem Codewechsel der richtige Code für mehr als 6,25ms-1ms= 5,25ms ansteht. Mit 500 Timer-Interrupts (alle 2ms) oder 1000 Timer-Interrupts pro Sekunde (je 1 pro ms) lassen sich selbst so stark prellende Drehgeber extrem sauber auswerten.

Wenn die Auswertelogik stimmt.

Bei der Ansteuerung von WS2812B  LED-Controllern mußt Du allerdings berücksichtigen, dass der Controller komplett blockiert wird, während er die LEDs ansteuert. Der Controller kann in dieser Zeit nicht senden, nichts empfangen, nichts zählen und nichts anderes verarbeiten als die WS2812B-Ansteuerung und die Interrupts sind blockiert, bis die letzte LED angesteuert wurde.
658  International / Deutsch / Re: Encoder gesucht on: March 20, 2014, 05:48:35 pm
gibt es eine gute und nicht alzu kostspielige alternative zu den ALPS Drehencodern? Ich habe von diesen Encodern einige sehr günstig bei ebay geschossen. Problem aber, diese Prellen sehr stark auch bei software Entprellung mittels Greycode (war ein Sketch von Jurs). Das Problem ist, dass die Übergänge sehr hart sind, soll heißen, wenn ich in den nächsten Punkt nicht einraste, fällt dieser leicht zurück und gibt ein neues Signal aus.

Drehgeber mit einem Arduino-Sketch auszuwerten ist normalerweise überhaupt kein Thema.
Und bis zu einer gewissen maximalen (ziemlich hohen) Zählrate spielt es überhaupt keine Rolle, ob es sich um billige stark prellende oder teure und wenig prellende Drehgeber handelt. Für alle normalen Anwendungsfälle tun es die billigen stark prellenden bei entsprechender sachdienlicher Auswertelogik genau so gut wie teure.

Allerdings darf man es nicht so machen wie es im Arduino-Playground beschrieben wird:
http://playground.arduino.cc/Main/RotaryEncoders

Auf der Seite steht zur Drehgeberauswertung nur ziemlich schlecht funktionierender Quatsch.
Praktisch unbrauchbarer Quatsch, der um so schlechter funktioniert, je stärker die Drehgeber prellen.

Wenn Du mit einem von mir hier geposteten Sketch ein Problem mit Drehgebern hast, gibt mal nähere Hinweise! Zu Drehgebern habe ich hier im Forum bisher sehr wenig gepostet, eigentlich kann ich mich nur an einen Spezialfall erinnern, bei dem es um eine Spindel ging, die immer abwechselnd und vorhersehbar eine Drehphase und eine Stillstandsphase hatte, und da ging es darum, Drehphasen und Stillstandsphasen zu unterscheiden, in Drehphasen die Impulse zu zählen und in Drehpausen die Zahl der gezählten Impulse anzuzeigen. Das hatte ich direkt in der loop gemacht. Diese Auswertung durch Polling in der loop-Funktion ist allerdings für Programme, bei denen die loop-Funktion auch mal länger als 1 bis 2 ms laufen kann, auch nicht der Weisheit letzter Schluß. Das Polling von Drehgebern eignet sich nur für Programme mit sehr schnelllaufender loop.

Für allgemeine Programme mit teils langsam laufender loop-Funktion muss die Auswertung von Drehgebern über regelmäßige Timer-Interrupts erfolgen. Ich kann mich nicht erinnern, dazu schon mal einen Beispielcode gepostet zu haben.
659  International / Deutsch / Re: Arduino Mega 2560 nach verwendung des Watchdog Timers nicht mehr beschreibbar on: March 20, 2014, 02:11:16 pm
Was hast Du genau gemacht?
Nicht nur "mit dem Watchdog-Timer" gespielt (z.B. für den Sleepmode), sondern "einen Watchdog-Reset programmiert"?

-Funktioniert das auch mit einem Mega 2560?

Bevor Du irgendwas kompliziertes anfängst, das auf möglicherweise veralteten/uralten Informationen aus dem Internet beruht, würde ich eher mal ausprobieren, ob der aktuelle MEGA-Bootloader nicht bereits entsprechend fehlerbereinigt ist, ohne dass Du selbst einen eigenen Bootloader-Quellcode zu einem Bootloader-Executable kompilieren brauchst. Das ist nämlich nicht so ganz trivial.

In jedem Fall benötigst Du einen ISP-Programmer.
Notfalls einen zweiten "Arduino as ISP" mit entsprechendem Sketch und entsprechender Hardware-Verkabelung.

Also mal die Arduino Version 1.0.5 installieren
Dann mit dem ISP den aktuellen "Bootloader neu installieren".

Ist der Fehler dann weg und der MEGA funktioniert wieder? ==> Glückwunsch!

Wenn der Fehler auch mit einem aktuellen MEGA-Bootloader nicht beseitigt werden kann:
Schreibe Dir einen kurzen eigenen Sketch, der sofort im setup() den Watchdog deaktiviert und lade diesen Sketch mit dem ISP-Programmer hoch!

Und danach wie folgt verfahren:
Wenn Du mit Bootloader und nur noch ohne Watchdog-Timer programmieren möchtest, danach wieder einen Bootloader installieren.

Und wenn Du immer noch mit Watchdog-Reset experimentieren möchtest: Lasse den Bootloader weg und lade alle Sketche NUR MIT ISP!

Einen Bootloader installiert zu haben und gleichzeitig Watchdog-Reset nutzen zu wollen, ist nicht wirklich sinnvoll. Das machst Du besser auf einem System ohne Bootloader, auf das der Sketch mit einem ISP hochgeladen wird.
660  International / Deutsch / Re: Poblem mit V-Plotter und GRBL on: March 20, 2014, 05:40:02 am
Nachdem ich gestern die Berechnung der Länge a0 hergeleitet habe, zwischen Seilpunkt B und dem Koordinatenursprung 0, folgt heute nun die Berechnung der Längen a und b in Abhängigkeit von den rechtwinkligen Koordinaten x und y.

Einfach zwei weitere Striche in der Zeichnung hinzugefügt und die Punkte E und F dazugemalt, und schon haben wir zwei neue rechtwinklige Dreiecke, mit denen wir rechnen können.

Dreieck BEC und Dreieck CFA

Zuerst zum Dreieck BEC und dessen Seiten:
Strecke BE = yB-y (erste kurze Seite)
Strecke EC = xB+x (zweite kurze Seite)
Strecke BC = a    (die gesuchte Seillänge a als lange Seite)

Pythagoras zum Dreieck BEC:
a2 = (xB+x)2 + (yB-y)2

Seillänge a:
a = sqrt((xB+x)2 + (yB-y)2)  ==> "a-Formel"


Danach das Dreieck CFA und dessen Seiten
Strecke CF = xA-x  (erste kurze Seite)
Strecke FA = yA-y  (zweite kurze Seite)
Strecke AC = b  (die gesuchte Seillänge b als lange Seite)

Pythagoras dazu:

b2 = (xA-x)2 + (yA-y)2

Seillänge b:
b= sqrt((xA-x)2 + (yA-y)2)       ==> "b-Formel"

Für die Veränderung der Länge a-a0 definiere ich die Variable "da" ("da" für "Delta a"):
da = a-a0

Für die Veränderung der Länge b-b0 definiere ich die Variable "db" ("db" für "Delta b"):
db = b-b0

Die Werte a und b werden wie in diesem Beitrag beschrieben berechnet, die Werte a0 und b0 wie im Beitrag gestern beschrieben. Differenz bilden und man hat die Werte da und db, die man anstelle von x und y zum Verstellen verwenden muss.

Das ganze noch in eine Arduino-Funktion "calc_ab"  gegossen und die Koordinaten der Seilrollen als Konstanten definiert:

Code:
// V-Plotter calculations by 'jurs' for German Arduino Forum
// Details: http://forum.arduino.cc/index.php?topic=226277.0

#define XB 500.0
#define XA XB
#define YB 600.0
#define YA YB

void calc_ab(float x, float y, float &da, float &db)
{
  // db = b - b0
  db= sqrt((XA-x)*(XA-x) + (YA-y)*(YA-y)) - sqrt(YA*YA+XA*XA);
  // da = a - a0
  da= sqrt((XB+x)*(XB+x) + (YB-y)*(YB-y)) - sqrt(YB*YB+XB*XB);
}

void plotPunkt(float x, float y)
{
  float da, db;
  calc_ab(x,y,da,db);
  Serial.print("x=");Serial.println(x);
  Serial.print("y=");Serial.println(y);
  Serial.print("da=");Serial.println(da);
  Serial.print("db=");Serial.println(db);
  Serial.println();
}


void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);
  float x,y;
  plotPunkt(-100,-100);
  plotPunkt(100,-100);
  plotPunkt(100,100);
  plotPunkt(-100,100);
}

void loop() {
}

Und schon kann man aus rechtwinkligen x-y-Plotterwerten die schiefwinkligen V-Plotterwerte da und db errechnen und die Umrechnungsfunktion in einem Sketch verwenden.
Pages: 1 ... 42 43 [44] 45 46 ... 193