oki
deine hex geht, fast:D
es kommt nix raus. homing macht er auch net.
das dmx signal schein anzukommen die led2 blinkt munter wenn ich dmx ändere.
auch die dips gehen.
kannst du mal bitte die schritte beschreiben wie du die hex erzeugt hast?? ich habe wohl irgendwo nen fehler gemacht.
mfg maik
ich habe strg+F7 gedrückt.
das projekt habe ich ja hochgeladen. vielleicht hast du den aufruf der check_step() bei Dir vergessen...
den output habe ich im simulator und mit leds kontrolliert - er entspricht eigentlich der spezifikation.
und wieder was gelernt:D
avr studio erzeugt ja selber die hex file8o
das stand aber nicht im handbuch
des halb der umweg über winavr.
werde mal meine hex jetze probieren.
oki es geht :D:D:D:D:D:D
aber nur sehr langsam und vieeel zu wenig schritte !!!
der fehler lag in der optischen ungleichheit. siehe reihenfolge der ports in dem bild.
ich weiss das es richtig ist (nummerierung) aber naja, wer lesen kann ist klar im vorteil
mfg maik
Dann schau mal in den Header der Stepper-lib...
(max. Beschleunigung ist 254)
Bei einem größeren Schrittwinkel dauert das Homing länger: Ich weiß hier nicht, wo ich steh - deswegen kann ich nicht groß beschleunigen...
Du kannst aber schauen, wie weit Du das Delay im Homing runtersetzen kannst - geh aber nicht bis an die Schrittverlustgrenze!!
Viel Spaß,
Hendrik
PS:
Vielleicht bekommst Du ja die Beschleunigung mit Excel oder Scilab gebacken...
okioki
beschleunigung
also max acceleration(ACC) ist 254 - habe jetze mal 240 drinne 
geht recht gut, könnte aber noch schneller sein, für meine zwecke aber volkommen ausreichend !!
delay runter nehmen
z94: delay= (0xFF -ACC);
das wären also (255-240) = 15 richtig ??
er fährt nun das homing relative schnell aber sehr gut !!
rampe
reicht es wenn ich ind der tabelle jeweils einen zwischen wert dazu schreibe und #define RAMP_LEN (50) auf 100 setze ?? um die rampe zu verdoppeln??
mfg maik
Die Rampe orientiert sich an der möglichen Beschleunigung und der gewünschten Endgeschwindigkeit.
Du solltest also nicht interpolieren sondern die Rampe mit hilfe der geg, Formeln für Deinen Fall berechnen.
(Meine Skalierung ist ein Trick, um schnell verschieden große Beschleunigungen durchspielen zu können. Darauf könntest Du dann verzichten.)
Ich schieb Dir ein paar Rampen mit den gleichen Basisdaten wie die alte durch Matlab:
Wie Du siehst, kommen nur neue Werte hinzu. Die Abstände werden durch die Beschleunigung (durch die Skalierung) bestimmt.
Beachte:
Speed ist derzeit int8, geht also von -128..127.
Deshalb kannst Du ohne Umwandlung nur mit Tabellen bis 127Werten arbeiten.
Es kann sein, dass Du bei hoher Beschleunigung und langen Rampen in den Resonanzdrehzahlbereich kommst. Da bricht Dir dann das Drehmoment weg. Versuch also mit einer kürzeren Rampe drunter zu bleiben.
wahnsinn :D:D
danke
habe mal das proiert was ich vor hatte;
diese rampe
const uint16_t Ramp[] PROGMEM = { //acceleration, deceleration (step durations)
27145, 23987, 20829, 19195, 17560, 16515, 15471, 14729, 13987, 13424, 12862, 12417, 11972, 11608, 11244, 10939, 10635, 10375, 10115, 9890, 9665, 9467, 9270, 9095, 8920, 8763, 8606,
8465, 8324, 8196, 8068, 7951, 7834, 7726, 7619, 7520, 7421, 7329, 7238, 7152, 7067, 6987, 6908, 6834, 6760, 6690, 6620, 6554, 6489, 6427, 6366, 6307, 6249, 6193, 6138,
6085, 6033, 5983, 5933, 5886, 5839, 5793, 5748, 5705, 5662, 5620, 5579, 5539, 5500, 5462, 5424, 5387, 5351, 5316, 5281, 5247, 5214, 5181, 5149, 5118, 5087, 5056, 5026,
4997, 4968, 4940, 4912, 4885, 4858, 4831, 4805, 4779, 4754, 4729, 4705, 4681, 4657, 4634, 4611, 4588, 4566, 4544, 4522
};
geht schon mal sehr gut
also die übergänge von langsam auf schnell sind extrem weicher geworden!!!
werde deine mal testen.
nur musste ich fest stellen das die anfahrt und brems rampe sich nicht wirklich verändert.
sondern nur die lauf ruhe!! also die übergänge von langsam auf schnell und umgekehrt.
bei ende des dmx-signals bei voller beschleunigung endet immer noch mit einem abrupptem stopp!!
kann st du mir mal bitte erklären was die zahlen in dieser tbelle bedeuten?? ist mir noch nich wirklich klar!
* ausserdem stopt die ausgabe immer wider und der motor steht kurz und fährt dann schnell wider an!! könnte das ein timing problem sein??
mfg maik
also henne 
nichts für ungut, aber meine variante läuft wehsentlich ruhiger !!
mal abgesehen von den aussetzern
ich werde mal noch mal interpolieren auf 200.
und noch mal testen:D achja die 300ter geht garnicht, er ruckelt nur vor sich hin?(
mfg maik
Liest Du eigentlich meine Posts?
(>125Werte -> unzulässig)
Bei Problemen mit der Accelaration Control musst Du Dir diese vornehmen.
Die Tabelle gibt die Dauer der Schritte bei verschiedenen Geschwindigkeiten an.
Ich habe die Geschwindigkeitsführung mal in den CBuilder abgetippt und komme auf das gewünschte Verhalten ohne Fehler.
soorrrryy?(
hab ich voll überlesen die zahl, bin im kopf von 254 ausgegangen
habe jetze mal ne rampe mit 75 gemacht mit diesen werten:
27145, 25566, 23987, 22408, 20829, 20012, 19195, 18378, 17560, 17038, 16515, 15993, 15471, 15100, 14729, 14358, 13987, 13706, 13424, 13143, 12862, 12640, 12417, 12195, 11972, 11790, 11608, 11426, 11244, 11092, 10939, 10787, 10635, 10505, 10375, 10245, 10115, 10003, 9890, 9778, 9665, 9566, 9467, 9369, 9270, 9183, 9095, 9008, 8920, 8842, 8763, 8685, 8606, 8536, 8465, 8395, 8324, 8260, 8196, 8132, 8068, 8010, 7951, 7893, 7834, 7780, 7726, 7673, 7619, 7570, 7520, 7471, 7421, 7375, 7329, };
muss sagen fast perfekt. bei acc = 245
läuft fast ruckfrei und auch sehr leise.
werde mal weiter testen:D
aber bis jetze muss ich nochmal herzlich danken für deine tolle arbeit.
mfg maik
ps. jetz begreif ich auch warum deine 300ter nich ging
mit dem Zaunpfahl wink:
Was tut man, wenn int_8 zu klein ist?
Womit wird derzeit begrenzt, wie viele Werte aus der Tabelle gelesen werden? Muss man also bei den Tests ständig an der Tabellenlänge rumdoktern?
Es ist jetzt Dein Code...
VG,
Hendrik
PS: Anbei noch eine 200er Table mit deutlich mehr Dampf. Da hast Du wieder mehr Spielraum mit der Beschleunigung.
hui hui hui:D
meine??
naja habe jetze erstmal auf 16bit gestellt damit ich mehr schritte nehmen kann.
habe auch gleich die 200ter probiert und musste doch feststellen das 200 schritte für die rampe nicht ausreichen. da dies nur eine 16tel umdrehung des steppers ist und somit nur eine 128tel umdrehung des mh-kopfes ist, also fast 2° drehung in der die komplette rampe abgearbeitet wird.
nun ist die frage ob mann mehr rampen schritte macht oder die dauer der rampen-schritte erhöht ??
werde mal eine rampe mit 2000 schritten probieren und berichten.
mfg maik
ps um die beschleunigung gehts mir garnicht mal, er soll sehr ruhig anfahren und bremsen, wegen der hohen trägheit.
soooo
es läuft,
also hab mal nen bissle rum probiert, mit rampe ,acc, usw.
habe nun eine beschleunigung (acc) von: #define ACC (252) //acceleration
und eine rampe von: #define RAMP_LEN (2512)
die rampe habe ich, in openoffice calc, mit nem sinus berechnet.
nun fehlt nur noch eine kleine pause zwischen den richtungs wechseln.
das delay im homing habe ich von hand festgelegt da es sonst bei dieser acc zu schnell wäre.
: delay= (0xff -200);
und die dazu gehörige rampe sieht so aus.
mfg maik
ps. der status von avrstudio
Program: 6566 bytes (80.2% Full)
(.text + .data + .bootloader)
Data: 32 bytes (6.3% Full)
(.data + .bss + .noinit)
so und hier nun
die noch sanftere version mit
#define RAMP_LEN (3180)
und die rampe dazu
mfg maik
ps. werde mir mal ne cam besorgen:D
Build started 21.8.2008 at 15:36:09
AVR Memory Usage
----------------
Device: atmega8515
Program: 7902 bytes (96.5% Full)
(.text + .data + .bootloader)
Data: 32 bytes (6.3% Full)
(.data + .bss + .noinit)
Build succeeded with 0 Warnings...
dum di dum
und hier das versprochene video
sorry für die handycam quali:D
wie man hört ist er noch sehr laut, ich hoffe das läst sich noch ändern??
was mann leider im video nicht sieht ist das zeitweise aussetzen, das aber nicht von der rampe zu kommen scheint. da es auch mit henne seiner original rampe auftritt. die referenzfahrt (homing) macht er ohne rucken. also könnte es am dmx empfang oder an der schritt berechnung liegen??
ich hoffe henne guckt sich das nochmal an.;)
ansonsten aber schon sehr gelungen.
mfg maik
achja
alles was nicht die FW betrifft wird im scanner & mh thread weiter geführt.
angelegenheiten der FW werden natürlich hier fortgesetzt.
mfg maik
@ Henne
kann st du mir sagen wieso der übergang von rampe auf maxspeed so ruckt??
sollte er nicht beim letzten rampen eintrag schon die maxspeed erreicht habe??
wen du den code dazu brauchst, bitte sagen.
mfg maik
muhaha:D
ich habs hinbekommen !!
der übergang von rampe auf maxspeed ist nun fliessend
habe einfach die rampen länge runter genommen,
#define RAMP_LEN (2850) //#define RAMP_LEN (3180)
ohne die tabelle zu verändern.!?
welche tabellen werte lässt er weg?? die letzten oder die ersten??
nun braucht er nur noch ne pause(richtungswechsel)
mfg maik
Newly created posts will remain inaccessible for others until approved by a moderator.
The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.
