Druckbare Version
Wo hast Du denn diesen nicht funktionierenden Mega her? War das noch ein Alter, den Du hattest? Wenn die Pins nicht tun, was sie tun sollen und das nicht nur einer ist, kannst Du den wohl entsorgen. Aufbewahren bringt nichts, ärgerst Dich immer wieder mit herum!
MfG
da bei mir nichts vor überraschungen sicher ist, habe ich immer ein paar MEGA's aus china (bestand momentan sieben eingebaut, die man auch kanibalisieren könnte) und zwei in reserve... :-)
Du weißt nicht, was wirklich alles defekt ist. Du siehst nur ein Symptom, den Pin. Also weg damit. Wie bekommt man eigentlich einen Prozessor kaputt? Den letzten hab ich komplett gehimmelt, als ich auf dem einen Kanal meines Netzteils sorgfältig 3,3V mit Strombegrenzung eingestellt, das CPU-Board aber an den Kanal mit 16V angeschlossen habe. Da ich mir beim Auslöten nicht viel Mühe gebe, kann ich den sowieso nur wegwerfen.Zitat:
Zitat von inka
MfG Klebwax
nach dem tausch des MEGA bin ich jetzt auf dem entwicklungsstand vor dem umbau auf die version mit der RAMPS-platine, das fahren mit IR-fernbedienung wie auch mit dem smartphone funktioniert soweit...
Mit der verdrahtung bin ich (fast) zufrieden, die motorzuleitungen muss ich noch ein bischen ordentlicher verlegen, da warte ich aber noch auf die crimpzange aus china...
Anhang 34812
was mir nicht gefält, ist das anfahren der schrittmotoren, ist mir zu rucklig, habe dazu ein kurzes video gedreht. Im ersten part startet der motor rückwärts, direkt, ohne irgendwelchen zusatcode. Da ruckelts wie immer. Nach dem stop starte ich den motor vorwärts, mit einer zusatzbeschleunigung funktion. Da wird ein array eingelesen an der stelle der statischen delays in der ansteurungsroutine für die stepper. Hab vieles über die S-funktion" gelesen, habe die arraytabelle in zwei teile zerlegt, eine für die anfahrt, eine fürs abbremsen. Ob ich die für's abbremsen brauche, weiss ich noch nicht...
Was mir nun noch kopfzerbrechen bereitet ist der ruckler zwischen den anfahrbeschleunigungsroutine (die wäre an sich ok) und dem übergang zur normalen vorwärtsbewegung.
Nun der code, der hauptteil, da sind gleich am anfang auch die arrays fürs anfahren und abbremsen:
hier ist die funktion für vorwärtsfahren:Code://LCD
#include <LCD.h>
#include <LiquidCrystal_I2C.h>
LiquidCrystal_I2C lcd(0x3F, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);
int sinus_rauf [] =
{ 0, 0, 0, 0, 1, 1, 1, 2, 2, 3, 4, 5, 5, 6, 7, 9,
10, 11, 12, 14, 15, 16, 18, 20, 21, 23, 25, 27, 29 ,31, 33, 35,
37, 39, 42, 44, 46, 49, 51, 54, 56, 59, 62, 64, 67, 70, 73, 76,
78, 81, 84, 87, 90, 93, 96, 99,102,105,108,111,115,118,121,124,
127,130,133,136,139,143,146,149,152,155,158,161,164,167,170,173,
176,178,181,184,187,190,192,195,198,200,203,205,208,210,212,215,
217,219,221,223,225,227,229,231,233,234,236,238,239,240,242,243,
244,245,247,248,249,249,250,251,252,252,253,253,253,254,254,254,
}; //128
int sinus_runter [] =
{
254,254,254,254,253,253,253,252,252,251,250,249,249,248,247,245,
244,243,242,240,239,238,236,234,233,231,229,227,225,223,221,219,
217,215,212,210,208,205,203,200,198,195,192,190,187,184,181,178,
176,173,170,167,164,161,158,155,152,149,146,143,139,136,133,130,
127,124,121,118,115,111,108,105,102, 99, 96, 93, 90, 87, 84, 81,
78, 76, 73, 70, 67, 64, 62, 59, 56, 54, 51, 49, 46, 44, 42, 39,
37, 35, 33, 31, 29, 27, 25, 23, 21, 20, 18, 16, 15, 14, 12, 11,
10, 9, 7, 6, 5, 5, 4, 3, 2, 2, 1, 1, 1, 0, 0, 0
}; //128
//resett pin definieren
#define PIN2RESET 10
// DIR und STEP pins definieren
#define dirPin_VL 28
#define stepPin_VL 26
#define dirPin_HL 55
#define stepPin_HL 54
#define dirPin_VR 34
#define stepPin_VR 36
#define dirPin_HR 61
#define stepPin_HR 60
//definiere enable pins:
#define enbl_VL 24
#define enbl_HL 38
#define enbl_VR 30
#define enbl_HR 56
//steps pro umdrehung definieren:
#define stepsPerRevolution 200 //1600
uint8_t taste = 0;
uint8_t s_vor = 0;
uint8_t s_rueck = 0;
uint8_t s_links = 0;
uint8_t s_rechts = 0;
uint8_t s_stop = 0;
uint8_t s_parken = 0;
uint16_t step_delay = 2000;
void setup()
{
//LCD
lcd.begin(16, 2);
lcd.clear();
lcd.setCursor(0, 0);
lcd.setBacklight(HIGH);
lcd.print("outdoor FB switch");
lcd.setCursor(0, 1);
lcd.print("smartphone 1");
delay(2000);
lcd.clear();
//pins als output:
pinMode(dirPin_VL, OUTPUT);
pinMode(stepPin_VL, OUTPUT);
pinMode(enbl_VL, OUTPUT);
pinMode(dirPin_HL, OUTPUT);
pinMode(stepPin_HL, OUTPUT);
pinMode(enbl_HL, OUTPUT);
pinMode(dirPin_VR, OUTPUT);
pinMode(stepPin_VR, OUTPUT);
pinMode(enbl_VR, OUTPUT);
pinMode(dirPin_HR, OUTPUT);
pinMode(stepPin_HR, OUTPUT);
pinMode(enbl_HR, OUTPUT);
// deaktiviere enable pins:
digitalWrite(enbl_VL, HIGH);
digitalWrite(enbl_HL, HIGH);
digitalWrite(enbl_VR, HIGH);
digitalWrite(enbl_HR, HIGH);
Serial1.begin(115200);
Serial.begin(115200);
//resett pin zustand definieren
pinMode(PIN2RESET, INPUT);
//resett pin aktivieren
digitalWrite(PIN2RESET, HIGH);
}
void loop()
{
if (Serial1.available())
{
taste = Serial1.read();
Serial.println(taste);
// taste_neu = taste;
delay(50);
tasten_abfrage();
}
richtung_abfrage();
}
/***********************************************************/
void richtung_abfrage(void)
{
if (s_rechts == 1) rechts_drehen();
if (s_links == 1) links_drehen();
if (s_vor == 1) vorwaerts();
if (s_rueck == 1) rueckwaerts();
if (s_stop == 1) alle_stepper_stop();
if (s_parken == 1) parken();
}
/***********************************************************/
void tasten_abfrage(void)
{
switch (taste)
{
case 116:// fahre vor - FB smartphone "t"
{
// beschleunigen();
vorwaerts();
break;
}
case 115:// fahre rückwärts - FB smartphone "s"
{
rueckwaerts();
break;
}
case 100:// rotate rechts - FB smartphone "d"
{
rechts_drehen();
break;
}
case 97:// rotate links - FB smartphone "a"
{
links_drehen();
break;
}
case 49: //alle stepper stop - FB smartphone "1"
{
alle_stepper_stop();
break;
}
case 51: //parken - FB smartphone "3"
{
parken();
break;
}
}
}
/***********************************************************/
void reboot()
{
pinMode(PIN2RESET, OUTPUT);
digitalWrite(PIN2RESET, LOW);
delay(100);
}
/************************************************************/
wie bekomme ich den ruckler beim vorwärtsfahren weg? Hab schon alles mögliche versucht, bisher leider ohne erfolg :-(Code:void vorwaerts(void)
{
if (s_vor == 0)
{
// enable pins aktivieren:
digitalWrite(enbl_VL, LOW);
digitalWrite(enbl_HL, LOW);
digitalWrite(enbl_VR, LOW);
digitalWrite(enbl_HR, LOW);
//richtung bestimmen
digitalWrite(dirPin_VL, LOW);
digitalWrite(dirPin_HL, LOW);
digitalWrite(dirPin_VR, HIGH);
digitalWrite(dirPin_HR, HIGH);
for (int i = 0; i < 127; i++)
{
digitalWrite(stepPin_VL, HIGH);
digitalWrite(stepPin_HL, HIGH);
digitalWrite(stepPin_VR, HIGH);
digitalWrite(stepPin_HR, HIGH);
delayMicroseconds(1750 + sinus_rauf[i]);
digitalWrite(stepPin_VL, LOW);
digitalWrite(stepPin_HL, LOW);
digitalWrite(stepPin_VR, LOW);
digitalWrite(stepPin_HR, LOW);
delayMicroseconds(1750 + sinus_rauf[i]);
}
digitalWrite(stepPin_VL, HIGH);
digitalWrite(stepPin_HL, HIGH);
digitalWrite(stepPin_VR, HIGH);
digitalWrite(stepPin_HR, HIGH);
delayMicroseconds(step_delay);
digitalWrite(stepPin_VL, LOW);
digitalWrite(stepPin_HL, LOW);
digitalWrite(stepPin_VR, LOW);
digitalWrite(stepPin_HR, LOW);
delayMicroseconds(step_delay);
s_vor = 1;
s_rueck = 0;
s_links = 0;
s_rechts = 0;
s_stop = 0;
s_parken = 0;
}
else
{
digitalWrite(stepPin_VL, HIGH);
digitalWrite(stepPin_HL, HIGH);
digitalWrite(stepPin_VR, HIGH);
digitalWrite(stepPin_HR, HIGH);
delayMicroseconds(step_delay);
digitalWrite(stepPin_VL, LOW);
digitalWrite(stepPin_HL, LOW);
digitalWrite(stepPin_VR, LOW);
digitalWrite(stepPin_HR, LOW);
delayMicroseconds(step_delay);
}
}
Habe heute den nachmittag an der neuen crimpzange verbracht. Die ersten 3 kontakte waren nix, dann ging es etwas besser und nach 10 kontakten habe sich sogar eine gewisse routine eingestellt, dann wusste ich wann ich was wie nutzen muss. Es ist im prinzip einfacher als das verlöten der dupont kontakte, auch wenn's doch fummelige arbeit ist. Die zugentlastung ist definitiv besser, die litzen halten besser in der hülse, die qualität der verbindung selbst - das wird sich zeigen. Ich jedenfalls mache mein dupontkabel in zukunft mit der crimpzange...Zitat:
Zitat von Klebwax
Da hab ich am Anfang sicher mehr für die Tonne gekrimpt.Zitat:
Zitat von inka
MfG Klebwax
naja, einiges vom Nachmittag ist für crimp- tutorials auf YouTube draufgegangen, deshalb habe ich wohl nicht so viel geschrottet...
Wenn schon so ausführlich von der Crimpzange gesprochen wird, bin ich neugierig um welche es sich handelt. Ich habe vor kurzem mit einigen zu tun gehabt, für 10, 20 und 45 € um zu sehen, mit welcher man am besten die JIS Crimpzange für 350€ ersetzen oder irgendwie umgehen kann.
also viel erfahrung damit habe ich ja nicht:
zuerst hatte ich diese zange:
Anhang 34817
die war insofern ungeeignet, weil das crimpen rein nach gefühl stattfindet - oder ich hab die "automatisierte" crimpfunktion nicht gefunden
die zweite zange:
Anhang 34818
kostet das doppelte der ersten, aber auch nur 15€. Ist nur zum crimpen, hat aber eine "ratsche", die ein halten zwischendurch und das richten der litze zum kontakt möglich macht, das hatte die erste nicht. Man kann - in grenzen - mit einem stellring das mass einstellen auf das die crimpung der reinen kupferlitze stattfinden soll. Ist mir aber auch nicht 100%tig gelungen. Das "vorformen" der lappen der zufgentlastung geht gut. Nacharbeit an der crimpstelle ist aber auch hier notwendig - die quetschung des kupfers etwas nachdrücken, die quetschung der isolierung etwas "richten", damit es besser in die hülse passt. Es ist aber insgesamt einfacher als das löten. Und qualitativ besser...
Danke für die Information, ich bin ungefähr hier angekommen https://www.youtube.com/watch?v=jHfYzrSF4pY und hatte bis dahin schon mit Spitzzangen einzelne Kontakte gecrimpt was sicher auf die Dauer keinen Sinn macht.
Ich staune nur über die Preise der Originalwerkzeuge.
https://www.google.de/search?sxsrf=A...cSoBR0Q4dUDCAs
ja, das ist wahnsin, man wird aber kaum in die verlegenheit kommen auszuprobieren inwiefern so ein preis gerechtfertigt ist. Ich fand dieses tutorial recht gut - auch fehler, bzw. probleme werden dort dargestellt...
Die primäre Funktion der Ratsche ist, daß man keine Crimpung mit zu geringem Druck machen kann. Man muß immer bis zu Ende durchdrücken, bevor man die Zange wieder öffnen kann. Und wieweit man durchdrücken muß, kann man manchmal einstellen. Das ist bei "Originalzangen" eher selten, da gibt es Vorgaben für den Pressdruck. Die Crimpung muß am Ende gasdicht sein.Zitat:
Zitat von inka
Das darf nicht sein. Wenn das nötig ist, passen Pressmatrix und Kontakt nicht wirklich zusammen. Jeder Kontakthersteller kocht da sein eigenes Süppchen. Um da auf der sicheren Seite zu sein, verwenden Profis die Zangen, die ihm der Kontakthersteller anbietet. Und das kostet.Zitat:
Nacharbeit an der crimpstelle ist aber auch hier notwendig - die quetschung des kupfers etwas nachdrücken, die quetschung der isolierung etwas "richten", damit es besser in die hülse passt. Es ist aber insgesamt einfacher als das löten. Und qualitativ besser...
Das Problem für den Bastler ist, daß er den Hersteller seines Kontaktes nicht wirklich kennt. Selbst wenn der Name eines Herstellers genannt wird, kann man nicht sicher sein, ob der Kontakt wirklich daher kommt. Man muß also experimentieren. Da aber die billigen Zangen kaum 10% der professionellen kosten, kann sich das lohnen.
MfG Klebwax
beide einwände sind sicher ok, also die gasdichtheit und keine nacharbeit / nachdrücken, allerdings würde ich schon zwischen hobby und professioneller anwendung unterscheiden wollen - allein "gasdicht", nichts für ungut, aber das klingt nach "für die ewigkeit" - ich baue meine roboter für jetzt, da ist eine relativ günstige, schnelle und einigermassen sichere verbindung für mich völlig ausreichend - in ein paar monaten, höchstens jahren sind die rooby's höchstens noch was für die glasvitrine - wenn überhaupt...
EDIT: hab jetzt sowas wie eine glasvitrine :-)
Anhang 34851
auch beim outdoor gehts jetzt weiter, die grösseren räder sind da und auch endlich mit stabilen druckteilen an den steppern befestigt
Anhang 34852
die richtigen räder sind endlich da, die steuerung damit ist - hauptsächlich beim drehen - noch ungewohnt, das vor- und zurück unproblematisch, beim seitlichen schieben so, wie ich es schon kenne. Habe ein video hier hochgeladen. Bin selbst überrascht über die "lebendigkeit" der bewegungen. Hätte ich so nicht erwartet...
ein solarpanel ist - zumindest mechanisch - eingebaut, erstmal fest, unter der durchsichtigen abdeckung. Elektrisch habe ich es noch nicht angeschlossen, weil es als 12V beschrieben und verkauft wurde, aber 19V in der einbausituation liefert...
Nun 12V heißt, sie soll einen 12V Bleiakku laden. Dazu brauchts rund 14V. Und 19V ist die Leerlaufspannung. Zusammen mit der eingebauten Diode, die das Entladen des Akkus im Dunkeln verhindert, kommen dann beim Laden so die 14V zusammen. Belaste die Zelle mal und miss Spannung und Strom. Da ist's ganz schnell vorbei mit den 19V.Zitat:
Zitat von inka
MfG Klebwax
Die Bewegungen sehen ziemlich cool aus.
Wieviel Schub liefern diese Räder ?
Ich meine, Steigungen usw....kann der damit überhaupt ernsthafte Steigungen hoch fahren?
bei 25° ist er am oberen ende der rampe nach dem stopp zurückgerutscht:
https://www.youtube.com/watch?v=u-sE3guYhXE
bei 20° normal rauf und runtergefahren:
https://www.youtube.com/watch?v=t8sk6ldp5fI
das waren noch andere räder, mit kunststoffrollen, die schwarzen räder haben gummirollen, müsste also noch ein bischen besser werden.
Zitat:
Zitat von inka
hat doch nicht so gut geklappt.... :-(
Schon eine weile habe ich mich gewundert, dass das filament so locker auf der trommel sitzt. Nach ein paar druckabbrüchen, weil das filament offensichtlich nicht weiter transportiert wurde, habe ich mir die trommel genauer angeschaut:
Anhang 34892
ich weiss nicht was zu den brüchen geführt hat, ob die tatsache, dass das filament vom grössten durchmesser der originalspule auf den kleinsten durchmesser der anderen spule gezwängt wurde, oder die qualität des filament selbst. Vielleicht wird das original filament sogar im warmen zustand auf die rollen gewickelt?
Das ist vermutlich PLA. Das Problem habe ich auch immer wieder. Habe das auch schon gehabt das es auf der originalen Spule gebrochen ist. Das passiert, soweit ich weiß, wenn das Material älter wird.
Aus diesem Grund bin ich froh das mein Creality einen Filamentsensor hat.
MfG Hannes
Hehe-sowas hab ich auch noch nicht gesehen.Meins wird, nach längerer Lagerzeit, auch etwas spröde-aber dass es schon auf de rRolle zerfällt, hatte ich noch nie.
Ich hab welches hier, was schon länger als ein Jahr rumliegt (zwar in der Plastiktüte, aber die offen) drucken kann ich das immernoch ohne weiteres..
Das gibt es wohl öfters, bin auch schon mehrmals darüber gestolpert, wo User das in den 3D-Drucker-Foren schrieben. Ich selbst habe auch Filament auch noch nie so lange gelagert, dass es irgendwann in mehrere Teile zerbrochen wäre. Man kann ja dann kleinere Mengen kaufen. Umgewickelt habe ich aber auch noch nie, ich stelle einfach die großen Rollen neben den Drucker.
MfG
ich bin auch etwas weitergekommen, die SR04 sensoren sind - beweglich - am rahmen angebracht, zu sehen hier ...
Sieht cool aus, wie der sich den Weg frei schielt...:)
hab es unüberlegter weise in ein bereits erledigtes thema gepostet, hier , wohin es eigentlich hingehört, noch einmal zusammengefasst...
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Hi Sly,Zitat:
Zitat von Rabenauge
ich lerne neue sachen (auch simple timer :-) ) gerne aus der kombination von beschreibung und beispiel und der "blink without delay" code ist nun ein zu simples beispiel. Würde Dir das was ausmachen hier Deinen code öffentlich zu machen? Eine PM geht natürlich auch, aber vielleicht gibt's noch andere die lernen wollen? :-)
wäre super, dann könnte ich endlich meine loop für den outdoor fertigschreiben ohne ständig verzweifeln zu müssen...
antwort zusammengebastelt:
-----------------------------------------
Aber gern doch.
Hier mal ein paar Auszüge aus dem Code des XPlorer1, da wird das auch so gehandhabt.
Zuerst bauen wir und nen Timner zusammen, der anhand von den millis() bei Bedarf "Ticks" erzeugt:
Code:void timer() //***************** mehrere Sekundenticks erzeugen **********************************
{
unsigned long aktuelleMillis = millis();
if (aktuelleMillis - vergangeneMillis >= interval) // Sekunde um
{
vergangeneMillis = aktuelleMillis;
halbeTick ++; // 500ms sind um
if(halbeTick>2) // hier ist eine volle Sekunde vorbei
{
halbeTick=1; // wechselt alle halbe Sekunde
sekundenTick++; // wechselt jede volle Sekunde
gemachtFlag=0; // Aufgabe-erledigt-Flag zurücksetzen
}
if(sekundenTick==5) // mehr brauchen wir nicht
{
sekundenTick=0;
}
}
}
Der hier erzeugt jede halbe Sekunde nen Tick, und zusätzlich zählt er die Sekunden jedesmal bis fünf hoch.
Im Grunde ein umgeschriebenes "blink_without_delay"...
Im Hauptprogramm muss dieser Timer natürlich auch "hin und wieder" aufgerufen werden (immer, wenn Zeit ist), das Stück Code ist tatsächlich das _komplette_ Hauptprogramm:
Code:
void loop()
{
timer();
manageLichter();
sekundenAufgaben(); // je nachdem, was der Timer grade hat...
delay(2); // Zeit lassen für Anfragen vom NodeMCU
}
Im Unterprogramm "sekundenAufgaben" wird nun aufgedröselt, je nachdem, welchen Wert der Timer gerade hat:
Code:void sekundenAufgaben()
{
if((sekundenTick==0)&&(gemachtFlag==0)) //wenns nicht schon erledigt wurde...
{
messeAkku();
}
if((sekundenTick==1)&&(gemachtFlag==0))
{
berechneLichtstaerke();
gemachtFlag=1;
}
}
Die gewünschten Intervalle (in denen der Timer halt "tickt") stellt man dann einfach mit passenden Konstanten ein:
Die Variable "gemachtFlag" verhindert, dass die jeweilige Aufgabe innerhalb des einen Intervalls ...zigmal erledigt wird- nur wenn die auch 0 ist, wird die Aufgabe abgearbeitet, und nachdem sie erledigt wurde, wird das Flag auf 1 gesetzt.Code:unsigned long vergangeneMillis = 0; // hier der letzte Tick
const long interval = 500; // Intervall, 500 Millisekunden
Im Code zum XP2 hab ich inzwischen fünf oder sechs solche Flags-der hat einiges mehr zu tun, hehe.
Der zählt aber auch die Sekunden bis 20 hoch....das Beispiel ist in alle möglichen Richtungen anpassbar, man kann den Timer schneller oder langsamer ticken lassen, man kann ihn weiter oder weniger weit hochzählen lassen, ganz wie man es gerade braucht.
Das ist natürlich keine Atomuhr- da der nur abgefragt wird, wenn keine anderen Aufgaben zu erledigen sind (hier z.B. kommt noch das manageLichter() dazwischen), geht er nicht supergenau, aber wen jucken Abweichungen von nen paar Millisekunden denn- meistens ist das Wurst.
Falls du noch Fragen dazu hast- frag einfach.
---------------------------------------------------------------------
mache ich, muss es mir erstmal genauer anschauen....
gleich die erste frage:
und das ist jetzt wirklich so, dass die in der loop aufgerufenen task's laufen, unabhängig davon, wie lange sie dauern, während die loop weiter abgearbeitet wird?
Echtes Multitasking funktioniert mit nem Single-Core nicht.
Meine Lösung dürfte aber ein ziemlich guter Kompromiss sein, weil alles zeitkritische in separaten Tasks "am Stück" erledigt werden kann. Insofern lautet die halbe Antwort: ja.
Es ist egal, wie lange ein einzelner Task braucht.
Danach hat loop() wieder die Kontrolle-die läuft inzwischen _nicht_ weiter!
Die Schaltuhr aber schon....
timer() wird ja _nur_ in loop() aufgerufen, wenn also irgendein anderer Task läuft (und mal länger dauert) dann nicht.
Dadurch ist es auch möglich, dass mal Ereignisse überhaupt nicht ausgeführt werden (weil die Schaltuhr schon drüber gerasselt ist in der Zwischenzeit).
Aber bei vielem ist das egal: ein Akku stirbt nicht, wenn er mal erst nach 40 Sekunden abgefragt wird, statt alle 20.
PWM läuft auch, wenn sie einmal gestartet ist, weiter (das ist schon sowas wie Multitasking), also geht das meistens so schon.
Man muss zwischen Multitasking und Multithreading unterscheiden, oft wird das nicht scharf getrennt.Zitat:
Zitat von Rabenauge
Auf kleinen MCUs ist es Multithreading (time slice scheduling, round-robin), und hier stimmt das so nicht mit Single- vs. Multicores: der Due (M3 SAM) ist z.B. ein Singlecore, der mit der Scheduler Lib recht gutes kooperatives Multithreading kann, dieselbe Lib läuft auch z.B. mit einem M0/Zero (SAMD).
Auch die neuen SAMD M4 (ebenfalls Singlecores) beherrschen laut Arduino Multithreading.
Die Scheduler Lib wurde zwischenzeitlich auch für AVRs portiert, erfordert aber deutich mehr Justierungen für das Speichermanagement.
Hier werden vom Thread Scheduler jedem Thread je eine eigene Zeitscheibe zugeteilt, und bei Wechsel zur nächsten alle Variablen und Register gesichert - ist er wieder dran, werden alle wieder zurückgelesen und dort weitergemacht, wo vorher aufgehört wurde.
Doch auf Multicores läuft es deutlich besser, wie z.B. auf dem ESP32: der kann sogar preemptives Multithreading (ähnlich POSIX pthread und C++ std::thread), wobei jeder seiner beiden Cores genau so time-slice scheduling macht mit sehr vielen Parallel-Threads wie ein Singlecore - grundsätzlich nicht anders, aber hier können eben z.B. 20 Threads auf 2 "Schultern" verteilt werden.
Zitat:
Zitat von Rabenauge
bei der umstellung vom FB betrieb auf selbständiges fahren gibts probleme. Und zwar fährt der roboter "abschnittsweise", also stotternd. Der verursacher sind die aufrufe für die entfernungsmessung, ohne die pingabfragen fährt der ganz ok... Die frequenz des "stotterns" ist abhängig von der grösse des ping-intervalls...
---------------------------------------------------------------
@rabenauge: Kann ich solche programmabschnitte mit dem "timer-system" kombinieren, oder muss ich völlig umdenken? Es müsste z.b. noch die bewegung des servos dazukommen..., da geht ja richtung kontinuierliche bewegung wahrscheinlich garnix...
Wie fragst Du die US module ab? nach der lib, oder anders?
---------------------------------------------------------------
das hier ist der haupt-fahrt-code welches aus der loop() aufgerufen wird:
vor dem start frage ich noch die US-module ab, der roboter soll ja nicht nach vorne anfahren, wenn er vor einer wand steht, die abfrage ist "entprellt", damit es nicht mehrere ergebnisse gibt, es wird für rechts und links abgefragt:Code:void alle_motoren_vorwaerts_hindernis(void)
{
currentMillis = millis();
dauer_fahrt = 200;
if (currentMillis - previousMillis > dauer_fahrt)
{
if (start_ping_rechts || start_ping_links == true)
{
aktuelle_ping_millis = millis();
if (aktuelle_ping_millis - vergangene_ping_millis > interval_ping)
{
vergangene_ping_millis = aktuelle_ping_millis;
ping_distanz_rechts();
ping_distanz_links();
}
}
//servo_und_ping();
if (hindernis_rechts == true)
{
ausweichen_hindernis_rechts();
hindernis_rechts = false;
}
if (hindernis_links == true)
{
ausweichen_hindernis_links();
hindernis_links = false;
}
else
{
hindernis_rechts = false;
hindernis_links = false;
Serial.println("alle motoren vorwaerts_hindernis");
vorwaerts();
}
}
}
die eigentliche entfernung wird hiermit gemessen, auch wieder für rechts und links ausgelegt:Code:void hindernis_vorh_rechts_entprellt(void)
{
if (start_ping_rechts == false)
aktuelle_ping_millis = millis();
if (aktuelle_ping_millis - vergangene_ping_millis > interval_ping)
{
vergangene_ping_millis = aktuelle_ping_millis;
ping_distanz_rechts();
}
if (uS_rechts != NO_ECHO)
{
if (((uS_rechts / US_ROUNDTRIP_CM) <= 25) && mehrfach_zaehler_rechts == 0)
{
hindernis_rechts = true;
mehrfach_zaehler_rechts = 1;
}
else if (((uS_rechts / US_ROUNDTRIP_CM) <= 25) && mehrfach_zaehler_rechts == 1)
{
mehrfach_zaehler_rechts = 0;
}
}
else
{
if (((uS_rechts / US_ROUNDTRIP_CM) <= 25) && mehrfach_zaehler_rechts == 1)
{
hindernis_rechts = false;
mehrfach_zaehler_rechts = 0;
}
else if (((uS_rechts / US_ROUNDTRIP_CM) <= 25) && mehrfach_zaehler_rechts == 0)
{
mehrfach_zaehler_rechts = 1;
}
}
}
die ganzen prints habe ich auch schon mal auskommentiert, es ändert nichts an meinem problem...Code:void ping_distanz_rechts(void)
{
uS_rechts = sonar_rechts.ping();
Serial1.print("Ping: ");
Serial1.print(uS_rechts / US_ROUNDTRIP_CM);
Serial1.println(" cm");
Serial.print("Ping: ");
Serial.print(uS_rechts / US_ROUNDTRIP_CM);
Serial.println(" cm");
delay(100); // hinzugefügt am 30.1.17 wg. doppelausweichen
start_ping_rechts = true;
}
Ich benutze keine Bibliothek für das bisschen Ultraschall- das kann man zu Fuss auch machen:
Wie steuerst du deine Motoren an- mit PWM?Code:void pingVorne()// ******************** Vorn nach Hindernissen suchen **************************************
{
delay(100); // ggf, alte Echos abklingen lassen, die halbe Zeit reicht auch
digitalWrite(triggerVorne, LOW);
delayMicroseconds(2);
digitalWrite(triggerVorne, HIGH); //Trigger Impuls 10 µs
delayMicroseconds(10);
digitalWrite(triggerVorne, LOW); //Messung starten
long laufZeit = pulseIn(echoVorne, HIGH,maxEntfernung); // Echo-Zeit messen, aber nicht zu lange warten
float messung=laufZeit/ 58.2; //Laufzeit in cm umrechnen
entfernungVorne = ((entfernungVorneAlt*0.2)+(messung*0.8)); // Ergebnis glätten
if(entfernungVorne==0) // das gibts nicht, also muss die Bahn frei sein
{
entfernungVorne=120;
}
entfernungVorneAlt=entfernungVorne;
Serial.print("Vorne: ");
Serial.print(entfernungVorne);
Serial.println(" cm");
}
Die läuft nämlich weiter, auch wenn in der Zwischenzeit andere Dinge erledigt werden.
Wenn du an einen Pin PWM(soundso) schickst, läuft die dort so lange, bis was anderes gesagt wird...
Ebenso Servo-Impulse- du kannst einem Servo ne Soll-Position senden, und schon andere Dinge tun, bevor es die erreicht-das funktioniert.
Man muss aber aufpassen: die Servo-Bibliothek verträgt sich nich unbedingt mit jeder anderen- beispielsweise gibt es Probleme mit programmierbaren LED's..das hängt mit den Timern zusammen.
In meinem (unfertigen) Test-Unterprogramm läuft das so ab:
-es wird vorn und hinten "gepingt"
-anhand der zurückgelieferten Distanzen wird die mögliche Geschwindigkeit festgelegt (je näher Hindernis, desto langsamer), und dann wird der berechnete Wert für die Geschwindigkeit ans eigetliche Fahrprogramm übergeben, also ungefähr so:
SpeedVorgabe=255;
fahreGeradeaus(); // das ist das eigentliche Fahrprogramm
Das Fahrprogramm nutzt dann diese Speed-Vorgabe als "Sollwert"- regelt aber nach Bedarf da noch selber dran herum.
Anschliessend schickt es die berechneten PWM-Werte an den Motortreiber.
Da sich die PWM nicht ändert (bis sie, beim nächsten Aufruf des Fahrprogrammes ggf, geändert _wird), fährt der locker und flüssig vor sich hin...
Hier gehts von vorne los:
Hauptprogramm ruft
Test-Unterprogramm, das ruft
Ping-Unterprogramm, berechnet anhand dessen Antwort die Soll-Geschwindigkeit, und schickt die zum
Fahrprogramm
und so weiter.
Das Ganze läuft _nicht_ über die Timer-Funktion einige Beiträge weiter oben, aber der läuft trotzdem im Hintergrund (wird im Hauptprogramm bei jedem Zyklus aufgerufen), der löst dann Zusatzaufgaben aus wie ab und an den Akku-Füllstand überprüfen usw.
Du kannst das ausprobieren: schick mal eine PWM an irgendeinen geeigneten Pin (an den du _irgendwas_ hängst, was dir auch anzeigt, dass die PWM weiter läuft, es geht schon mit ner LED+Vorwiderstand), und lass den Rechner danach mit delay(1000) einfach warten.
Du wirst sehen: das delay() beeinflusst die PWM _nicht!
Genauso kannst du in der Zeit irgendwelche Sensoren abfragen oder so- das juckt die PWM nicht, die läuft und läuft...
Ja, das mit PWM ist wohl die einzige Möglichkeit, einen sauberen Gleichlauf der Stepper hinzubekommen.
Ansonsten ist doch ein ESP32 vorhanden: https://www.elektormagazine.de/magaz...ktor-138/56969
Sind immer dieselben Probleme, unter Nutzung nur einer CPU.
Für die Steuerung des Fahrgestells kann auch ein Arduino NANO verwendet werden. Kommandos kann dem per serieller Schnittstelle schicken (oder andere, die frei sind). Ultraschall und andere Sachen können mit dem ESP32 oder dem MEGA parallel zum NANO abgearbeitet werden.
MfG
danke erstmal, das braucht ein bischen...
ein "zwischen"problem:
- der timer läuft, da werden die sekundenaufgaben aufgerufen, in denen die pingroutine:
gestartet wird.Code:if ((sekunden_tick == 1) && (gemacht_ping_links_flag == 0))
{
ping_distanz_links();
Serial.print("Ping: ");
Serial.print(uS_links / US_ROUNDTRIP_CM);
Serial.println(" cm");
}
in der pingroutine
wird aber das pingergebnis trotz des ping-flags auf 1 "100mal" ausgedruckt. Wieso? Wo muss die flagänderung denn hin? In der loop wird sie ja zuerst auf "0" gesetzt, dann in den sekundenaufgaben abgefragt und letztendlich in der pingroutine wieder auf 1 gesetzt...Code:void ping_distanz_links(void)
{
uS_links = sonar_links.ping();
gemacht_ping_links_flag = 1;
start_ping_links = true;
}
Das ist natürlich Unsinn. Das klassische Multitasking System UNIX wurde auf und für eine PDP8 bzw PDP11 geschrieben. Und das waren Single-Core CPUs. Linux wurde zuerst auf einem 386 gebaut, ebenfalls Single Core. Und das erste preemptive Windows, Windows NT, lief auch auf einem Single Core.Zitat:
Zitat von Rabenauge
Sicher nicht. Du hast ja schon mal mit AccelStepper() rumgespielt. Die kann das. Ebenso wie alle 3D-Drucker oder Lasergravierer mit grbl. Aus der Doku zu AccelStepper:Zitat:
Zitat von Moppi
Die Arduino SW ist ja Open Source. Man kann also sowohl in die PWM Library als auch in AccelStepper reinschauen und sehen, wie das da gemacht wird.Zitat:
You can have multiple simultaneous steppers, all moving at different speeds and accelerations, provided you call their run() functions at frequent enough intervals.
Dazu benutzt man Interrupte. Dafür sind sie da. Oder man macht es kooperativ, wie AccelStepper es mit seiner run()-Funktion tut.Zitat:
Zitat von Moppi
MfG Klebwax
oder man verwendet wie ich grundsätzlich Multithreading, per Due Scheduler, pthread oder std::thread samt mutexes und thread-prios.Zitat:
Zitat von Klebwax
Hm- wo setzt du das Flag wieder auf 0?
Wahrscheinlich liegt dort der Hase im Peffer....
Ist am Ende auch nur ein Timer Interrupt. Wenns mal etwas komplizierter wird, muß da doch selber ran. Da kann man den Umgang mit Timer und Interrupt gleich selbst lernen. It's not rocket scienceZitat:
Zitat von HaWe
MfG Klebwax
Nein, wann soll ich das gemacht haben?Zitat:
Zitat von Klebwax
Allerdings ist Rabenauges Einwand mit dem PWM ja nicht verkehrt. Wenn es so funktioniert, wärs eine umkomplizierte Lösung.
MfG
warum das Rad neu erfinden, wenn es erprobte, stabile und bewährte Libs gibt, die die Problematik handeln können? Ich programmiere ja auch in UNIX/LINUX das Multithreading nicht selber, sondern nutze die bewährten POSIX und std Libs, gleiches gilt für die entsprechenden Libs fürs ESP RTOS und den ebenfalls bewährten Due Scheduler.Zitat:
Zitat von Klebwax
Sorry, bezog sich nicht auf dich sondern inka, weiter vorne im Thread.Zitat:
Zitat von Moppi
Warum sollte zum Ansteuern von Schrittmotoren eine Funktion für DC-Motoren mit PWM besser geeignet sein, als eine (AccelStepp), die extra für Schrittmotore geschrieben wurde?Zitat:
Zitat von Moppi
Wenn sie alle Probleme lösen, ist es ja gut. Ich sehs noch nichtZitat:
Zitat von HaWe
MfG Klebwax
Ich kenne AccelStepp nicht. Damals kam die Frage auf, was in der Lib passiert, weil es Probleme bei der Ansteuerung der Stepper gab. Inka hatte doch glaub ich diese Lib eingesetzt?Zitat:
Zitat von Klebwax
Wenn die die Probleme auch löst, ist es doch schön und gut. Dennoch, wenn ich mir den Code von Inka angesehen habe, denke ich auch, dass PWM eine unkomplizierte Lösung ist. Warum, hatte Rabenauge bereits beschrieben, dem gab eigentlich nichts hinzuzufügen, Versuch ist es wert, vielleicht löst es bereits das Problem.
MfG
ich sehe vor allem nicht, dass hier selbstgestrickte Methoden auch nur annähernd die Probleme lösen, die von den MT Libs (Scheduler, C/POSIX, C++/std::thread, UNIX, RTOS) längst beherrscht werden.Zitat:
Zitat von Klebwax
Ich kannte die Library auch nicht und habe daraufhin mal die Dokumentation und den Source gelesen. Da kann man sehr gut erkennen, wie das da gelöst ist.Zitat:
Zitat von Moppi
Da braucht man nicht viel zu probieren. Es reicht einfach zu überlegen, wie man mit analogWrite() die Pulsfrequenz, auf die es ja beim Stepper ankommt, und nicht die Pulsebreite oder den Dutycycle einstellt. Ich hab auch davon den Source gelesen. Das basiert auf der PWM Hardware des Prozessors. Damit ist einerseits klar, daß die PWM-Hardware weiterläuft, und andererseits daß sie zur Ausgabe von unterschiedlichen Frequenzen ungeeignet ist.Zitat:
Wenn die die Probleme auch löst, ist es doch schön und gut. Dennoch, wenn ich mir den Code von Inka angesehen habe, denke ich auch, dass PWM eine unkomplizierte Lösung ist. Warum, hatte Rabenauge bereits beschrieben, dem gab eigentlich nichts hinzuzufügen, Versuch ist es wert, vielleicht löst es bereits das Problem.
In beiden Fällen ist aber der wesentliche Teil der Software ein-zwei Dutzend Zeilen lang. Das mit einem Rad zu vergleichen, das man nicht neu erfinden will, ist schon etwas schräg.
MfG Klebwax