Trapezium profiel voor steppers.

Ik wil een trapezium vormig snelheidsprofiel voor steppers aanhouden.

Stel mijn max snelheid vmax mijn max versnelling is amax.

Als ik dan gedurende t tijd versnel beweeg ik in die tijd dx = 0.5 amax * t2. Als ik gedurende t tijd constante snelheid beweeg, dan beweeg ik dx = v * t.

Voor de trapezium vorm moet ik versnellen gedurende t = vmax/amax.

Als ik nu op positie N wil eindigen, reken ik de versnel/vertraag tijd uit: t = vmax/amax. Nu reken ik de afstand uit die daarmee gemoeid is: dxacc = 2 * 0.5 amax * t2 = vmax2/amax. Als dit groter is dan N dan is er geen horizontaal stukje in de trapezium vorm en moet ik opnieuw beginnen: N = 2 * 0.5 * amax * t2 => t2 = N/amax => t = sqrt (N/amax).

Anders gaan we verder en rekenen we uit hoeveel er nog met constante snelheid verplaatst moet worden: dxcs = N - dxacc.En daaruit volgt dan de tijd dat we met constante snelheid moeten bewegen. tcs = dxcs / vmax.

Eenvoudig, rechttoe, rechtan. Maar nu komt het.... Dit is helemaal precies als "t" een "real" is. Maar ik werk in tijdstappen.

dus even een concreet voorbeeld: Stel ik accellereer 10 tijdstappen van 100ms met 100stappen/sec/sec, dan leg ik in die tijd 10+20+... +100 = 550 stappen af. 1100 met het afremmen er bij en om 2000 stappen te doen moet ik nog negen tijdstappen met constante snelheid van 100stappen per tijdstap doorlopen.

Als ie het simuleer met tacc = 10, tcs = 10 en acc= 10, kom ik precies op 2000 stappen uit. Ik heb hierboven iets verkeerd gedaan. Randcondities en zo. Zal me aan me reet roesten.

Wil ik nu 2100 stappen doen, dan verleng ik gewoon de constante snelheid tijd met 1 stap en klaar. Maar wat nu als ik 50 stappen meer wil doen? Mijn gevoel zegt me dat dit ook redelijk makkelijk moet kunnen. Met de "drie fases" is er niet genoeg speelmogelijkheid om alle mogelijke waardes te bereiken, Maar wat nu als ik bijvoorbeeld tijdens het afremmen op snelheid 50 1 tijdstap extra blijf hangen? 1 tijdstap lang acc=0 ipv -10. Nu kan ik 2050 maken, maar nog niet 2045 stappen.

Mijn vraag: Weet iemand een algorithme waarmee ik precies op de gewenste positie kan uitkomen?

Bovenstaande "afronding" 9/10 ga ik zelf kunnen oplossen.

c code:

#include <stdio.h>
#include <stdlib.h>

int main (int argc, char **argv)
{
  int a, v, x, t, t1, t2;

  a = atoi (argv[1]);
  t1 = atoi (argv[2]);
  t2 = atoi (argv[3]);
  x = v = 0;
  for (t=0;t<t1;t++) {
     v += a;
     x += v;
    printf ("t%d: x=%d, v=%d\n", t, x, v);
  }
  for (t=0;t<t2;t++) {
    x += v;
    printf ("t%d: x=%d, v=%d\n", t1+t, x, v);
  }
  for (t=0;t<t1;t++) {
     v -= a;
     x += v;
    printf ("t%d: x=%d, v=%d\n", t1+t2+t, x, v);
  }
  exit (0);
}

code:

> ./a.out 10 10 10
t0: x=10, v=10
t1: x=30, v=20
t2: x=60, v=30
t3: x=100, v=40
t4: x=150, v=50
t5: x=210, v=60
t6: x=280, v=70
t7: x=360, v=80
t8: x=450, v=90
t9: x=550, v=100
t10: x=650, v=100
t11: x=750, v=100
t12: x=850, v=100
t13: x=950, v=100
t14: x=1050, v=100
t15: x=1150, v=100
t16: x=1250, v=100
t17: x=1350, v=100
t18: x=1450, v=100
t19: x=1550, v=100
t20: x=1640, v=90
t21: x=1720, v=80
t22: x=1790, v=70
t23: x=1850, v=60
t24: x=1900, v=50
t25: x=1940, v=40
t26: x=1970, v=30
t27: x=1990, v=20
t28: x=2000, v=10
t29: x=2000, v=0
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
fatbeard

Honourable Member

Volgens mij haal je je met die tijdstappen meer ellende op de hals dan dat het oplost. Het zal z'n reden hebben, maar toch...

Als ik het dus goed begrijp is het aantal stappen per tijdsstap altijd hetzelfde. Dat impliceert dat je totale afstand (in stappen!) nooit een priemgetal mag zijn...

Om met die opzet elk gewenst aantal stappen te kunnen 'behappen' wordt het noodzakelijk om het aantal stappen per tijdseenheid variabel te maken (maar nog steeds binnen de tijdsstap constant), dan reken je je alleen het hubuskulubus (helemaal als de verplaatsing binnen een gegeven tijd voltooid moet zijn)...

Het is overigens (vooral als de positionering perfect moet zijn) verstandig om de vertraging iets 'rustiger' te doen dan de versnelling om overshoot te vermijden.

[edit]
Ik zie nu dat je al doet wat ik stelde: variabel aantal stappen per tijdstap.
Ik denk verder...

Een goed begin is geen excuus voor half werk; goed gereedschap trouwens ook niet. Niets is ooit onmogelijk voor hen die het niet hoeven te doen.
Lambiek

Special Member

SparkyGSX had daar een oplossing voor in C geloof ik.

https://www.circuitsonline.net/forum/view/142445

Als je zoiets bedoeld tenminste.

Als je haar maar goed zit, GROETEN LAMBIEK.
fatbeard

Honourable Member

Op 9 mei 2020 10:09:14 schreef Lambiek:
SparkyGSX had daar een oplossing voor in C geloof ik.

https://www.circuitsonline.net/forum/view/142445

>:) geen post nummer? Dat wordt lezen...

Curieus, als ik dat topic ga lezen levert pagina 3 een 'applicatie-fout' op...

Mijn voorlopige insteek is

  • bepaal de theoretische acceleratie tijd Tacct (real)
  • bepaal de theoretische acceleratie afstand Dacct (real)
  • bepaal de theoretische constante snelheidsafstand Dcvt (real)
  • bepaal de theoretische constante snelheidstijd Tcvt (real)
  • bepaal de werkelijke constante snelheidstijd Tcv door Tcvt naar beneden af te ronden op hele tijdstappen
  • bepaal de werkelijke constante snelheidsafstand Dcv (Tcv*vmax)
  • bepaal de werkelijke acceleratie afstand Dacc (N-Dcv)
  • bepaal de werklijke acceleratie tijd Tacc door Tact naar boven af te ronden op een even(!) aantal hele tijdstappen
  • bepaal de benodigde acceleratie a (real)

Nu kun je met deze waarde in elke stap spelen (omhoog/-laag afronden) zodat je -cumulatief- op het juiste aantal stappen uitkomt.

Nadeel (?) is dat je niet helemaal eenparig versnelt/-traagt.

Een goed begin is geen excuus voor half werk; goed gereedschap trouwens ook niet. Niets is ooit onmogelijk voor hen die het niet hoeven te doen.
Lambiek

Special Member

Op 9 mei 2020 09:27:52 schreef fatbeard:
Het is overigens (vooral als de positionering perfect moet zijn) verstandig om de vertraging iets 'rustiger' te doen dan de versnelling om overshoot te vermijden.

Ik vraag me af of dat iets uitmaakt bij een stappenmotor. Je zet een bepaalde massa in beweging, verplaatst die en aan het eind rem je weer af. De massa blijft het zelfde.

Op 9 mei 2020 10:37:29 schreef fatbeard:
>:) geen post nummer? Dat wordt lezen...

O, sorry vergeten. Dat is pagina 4. :)

Als je haar maar goed zit, GROETEN LAMBIEK.
fatbeard

Honourable Member

Op 9 mei 2020 11:14:02 schreef Lambiek:
Ik vraag me af of dat iets uitmaakt bij een stappenmotor. Je zet een bepaalde massa in beweging, verplaatst die en aan het eind rem je weer af. De massa blijft het zelfde.

Klopt als een bus.
Het zou alleen kunnen gebeuren als de versnelling te hoog gekozen is, dan kan de motor slippen.
Nu ik daar wat beter over nadenk is het inderdaad onzin: als de motor zou slippen vanwege een te hoge versnelling doet-ie dat ook bij het optrekken en bereikt-ie dus niet de gewenste eindpositie... |:(

Ik ben meer gewend aan systemen met positie-meldingen, dan is het aantal stappen slechts een richtlijn en mag de motor ook wat slippen.
Dat gebeurt dan meestal tijdens optrekken, maar ik vertrouw Rew het wel toe om de versnelling aan de juiste kant van voorzichtigheid te kiezen. :)

Een goed begin is geen excuus voor half werk; goed gereedschap trouwens ook niet. Niets is ooit onmogelijk voor hen die het niet hoeven te doen.

Ik kan in het genoemde topic geen "code-in-C" van sparkyGSX vinden. Er wordt wel geprutst met gegeven een accelleratie, en wat tijden.

Ook wordt er wat handgezwaaid met een array waar je de inter-stap-tijden in zou zetten. Zolang je enkele stapjes doet in een single-threaded omgeving dan zijn dat leuke dingen. Mijn aanpak is dat ik vast 10000 interrupts per seconde vraag, en iedere tijdstap doe ik "x += v". Als die v nu zeg .04348 is, dan is dat bij mekaar iedere 23 tijdstappen meer dan 1 en dan moet ik de stappenmotorcontroller vertellen om een stapje voorwaarts te gaan. En zo kan ik dus een snelheid van 434.8 stappen-per-seconde bereiken. Maar 444.6 stappen per seconde is net zo makkelijk. Maar goed. Dit alles heb ik integer-only al helemaal werkend.

Als er stappen gemist worden is dat bij het optrekken: Dan werken de inertie en wrijving in dezelfde richting. Relatief is de motor iets krachtiger bij het afremmen: De wrijving HELPT de motor. Ik heb geen zin om een andere afrem-vertraging te kiezen. Dus het numerieke versnellingsgetal moet je bepalen door te kijken naar het optrekken.

Als je iets te snel optrekt, dan is het vrijwel altijd zo dat dan nooit meer gesynced wordt totdat de boel weer stilstaat.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
buckfast_beekeeper

Golden Member

Is deze Atmel/microchip appnote geen mooi begin?

Van Lambiek wordt goede geuze gemaakt.

Kijk ook eens naar de accel stepperlibraries:
http://www.airspayce.com/mikem/arduino/AccelStepper
Daarmee kun je meerdere motoren aansturen met acceleratie en decelleratie.

Op 9 mei 2020 14:21:13 schreef buckfast_beekeeper:
Is deze Atmel/microchip appnote geen mooi begin?

Ik begin te begrijpen waarom dat soort documenten "mijn" probleem niet hebben:

Ik werk met een snelheid die uitgedrukt wordt in 2^-24 steps per 100 us. Zij gaan uitrekenen wanneer de volgende pulse moet komen, maar ik vind dat tot makkelijk 30k pulsen per seconde per motor mogelijk moeten zijn. En dat met tot 32 motoren. (met een miljoen pulsen per seconde is de standaard implementatie "pin hoog, wacht 1us, pin laag" om een pulse te sturen niet meer mogelijk....)

Dan is: we rekenen uit wanneer de volgende pulse/stap moet komen en regelen dan een interrupt ineens niet meer een optie. Met twee motoren tegelijk ga je het probleem krijgen dat je misschien zat tijd overhoudt tussen de interrupts, maar op een gegeven moment krijg je interrupts die zo dicht bij mekaar zitten dat je "te laat" bij de andere bent. Of een interrupt mist of zoiets. Dat wordt allemaal heel ingewikkeld. Bij mij is het gewoon per motor:

code:

v += a; 
x += v;
if (x > 0) {
  set (dir);
  while (x > 2^24) {pulse (mypin); x -= 2^24;}
} else {
  clr (dir);
  while (x < 0) { pulse (mypin); x += 2^24;} 
}
if (--nsteps == 0) 
   // afhandelen doorgaan naar volgende fase (andere a, nieuwe nsteps)/stoppen. 

Zolang ik dat voor alle motors afkrijg binnen de 80-90 us die er gebruikt mogen worden als ALLES tegelijk gebeurt, dan is het prima.

Tuurlijk ik heb veel liever een interrupt belasting van onder de 10% maar als je 32 steppers tegelijk wilt sturen, dan moet je accepteren dat dit misschien > 50% van je CPU gaat gebruiken.

Dus.... wat zij doen is accel, dat levert een X aantal volle stappen op. Dan weet je precies hoeveel stappen dat zijn geweest en dan doen ze niets anders dan enkele stapjes geven totdat ze met het afremmen weer op nul snelheid en de gewenste positie uitkomen.

Goed..... Dat betekent dus dat ik precies moet uitrekenen hoeveel nano-stapjes ik in de accel/decel fase doe. Dan hou ik een aantal nano stapjes over die ik moet doen in de "constante snelheid" fase.

Als ik dan uitreken hoe veel (nano-)stapjes er dan overblijven voor de constante snelheid fase, dan kan ik de tijd van die fase naar boven afronden en de snelheid verlagen totdat het vrijwel precies klopt.

Ik krijg dan een kleine snelheids-aanpassing tussen de fases, dus m'n planning gaat dan van 3 fase-records naar 5, waarbij de nieuwe maar 1 tijdstap hebben. Ik ga de planner herschrijven en dan kijken of het werkt. :-)

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
buckfast_beekeeper

Golden Member

Is de processor daar nog geschikt voor? EdingCNC gebruikt een 252MHz 32bit controller om 4 assen aan te sturen met 400kHz in hun CNC720. Of 1600kHz voor alle steppers samen. Uw doel is 1000kHz voor 32 steppers. Dan kom je op zowat 160MHz 32bit. Persoonlijk denk ik dat EdingCNC toch weet wat de mogelijkheden zijn en hebben ze versnellen, snelheid houden en vertragen best wel onder de knie.

Van Lambiek wordt goede geuze gemaakt.
Lambiek

Special Member

Ik gebruik ook de controller van Bert Eding, prima spul.

Als je haar maar goed zit, GROETEN LAMBIEK.
trix

Golden Member

ik kan je niet helpen zoals je wel weet, ik moet iets soortgelijks doen, maar dan minder nouwkeurig. maar als ik het goed begrijp, gebruik je geen drivers.

eigenwijs = ook wijs
Lambiek

Special Member

Zonder drivers gaat het niet lukken hoor.

Als je haar maar goed zit, GROETEN LAMBIEK.

Op 9 mei 2020 12:43:06 schreef rew:
Ik kan in het genoemde topic geen "code-in-C" van sparkyGSX vinden.

https://www.circuitsonline.net/forum/view/message/2024863#2024863

Deze code was voor één motor, je zou het met meer motoren kunnen doen, maar voor elke motor heb je dan een eigen timer nodig, dus dat schaalt slecht.

Ik heb het ooit gemaakt in een FPGA, in integers, met een variatie op het Bresenham lijn algoritme; bij elke interrupt tel je X op bij een accumulator, als die groter of gelijk is aan Y zet je een stap en trek je Y af van die accumulator. X en Y zijn dan de totale tijd en het totale aantal stappen in die tijd. Voor een acceleratie zou je dan X steeds groter moeten maken, of Y steeds kleiner; het is dan alleen niet triviaal om meerdere motoren perfect synchroon te houden.

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

De marlin code voor 3D printers doet 4 steppers op max 3 steps ieder, iedere 100 microseconde. 120k steps per sec met een 16MHz processor.

Ik werk nu met een 48MHz processor, maar die is 32bit. Dat scheelt enorm in de 32-bit berekeningen die moeten gebeuren. Ik denk dat ik een eind kom met dit ding. Door iets slim aan te pakken kan je zomaar een factor tien in performance winnen, dus EdingCNC die een 252MHz processor nodig heeft.

Sparky: Jou code zet een timer interrupt op het moment dat een pulsje gegeven moet worden. Dat werkt prima voor 1 motor, kan je werkend krijgen voor 2 of 3 maar daarna houdt het op: De kans dat je heel dicht bij mekaar pulsjes voor meerdere motoren moet gaan geven wordt groot en dan krijg je gezeik met een interrupt die je plant voor de toekomst maar tegen de tijd dat je dat in het register gefrot hebt, dan is het "verleden" en gaat de hardware gewoon 65536 cycles te laat je interrupt triggeren.

Even om er makkelijker over te kunnen praten: Ik gebruik het begrip nanosteps om 2-FPOS_SHIFT microstep aan te duiden. Mijn code definieert die FPOS_SHIFT als 14, terwijl ik hierboven naar 24 hintte. Ik heb er toen ik de code schreef over zitten nadenken: daar zal een reden voor geweest zijn. Waarschijnlijk dat ik zo "redelijke" afstanden nog prima in 32 bits kan berekenen. Ik werk hieronder met de defaults uit mijn code: maxa=128, maxv=50000. Met de fpos-shift van 14 resulteert dit al in 3 ongeveer microsteps per interrupt op 10kHz. IK realiseer me nu dat ik ook recent de snelheid voor de lol nog flink heb opgeschroeft. Meer dan drie per interrupt werkt dus ook nog. Dat was met een onbelaste stepper.

Ik heb de planner nu ook in een gewoon linux-programma gestopt. Ik kan nu de planner en de executie gewoon in een Linux programma draaien. Dus als eerste: Er was een flink verschil in de accelleratie-steps waar de planner mee rekende en wat er in werkelijkheid was. Dat komt omdat de snelheid niet precies op maxv uitkomt maar ergens in de range <maxv-maxa ... maxv>. Als je dan met de originele maxv verder rekent ipv deze afgeronde versie dan krijg je grotere fouten. Dat ben ik nu aan het fixen.

Huidige situatie is dat ik op ongeveer -0.6*maxv uitkom op de gewenste waarde.... Dat kan beter: 1 stapje meer en ik kom op +0.4*maxv uit. Dat komt omdat ik het aantal stapjes moet afronden en niet truncaten.

Als ik dit dan ook goed doe, dan zou ik nog een max afwijking hebben van 0.5*maxv. Met een fpos-shift van 14 die resulteert in 0.3*maxv zit ik dan binnen anderhalve microstep van de target. Dus ergens tussen -2 en +2 van de gewenste waarde. Dat is vaak nauwkeurig genoeg.

Toch ga ik nog even kijken of ik met een extra accelleratie-stap in het constante-snelheid deel niet nog meer nauwkeurigheid kan bereiken.....

Plan gevormd!

Even met concrete voorbeelden:

Om 3000 microsteps te doen moet ik nu 595 stappen met constante snelheid 49920 doen om op ongeveer +30000 nanosteps uit te komen. Ik doe dus 29702400 steps terwijl het er maar 29672400 moeten zijn. Als ik nu niet het constante snelheid deel op 49920 doe, maar op 29672400/595 = 49869.6, dan kom ik al veel dichterbij! Het verschil in snelheid is maar 50, dus dat kan ik in 1 tijdstap veranderen. Als ik nu die .6 van 49869.6 naar BOVEN afrond, en dan na 0.6 van het CS deel nog 1 extra tikkie snelheid naar beneden doe, dan krijg ik volgens mij exacte resultaten.

planning wordt dan:

code:

  tijd   versnelling
  390    128
  1      -50
  345    0
  1      -1
  247    0
  1      50
  390    -128
  

Effe snel uit het hoofd, ongeveer en dan zou ik 3000 microsteps, 49152000 nanosteps moeten hebben gedaan.

Ik dank de grote teddyberen.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
buckfast_beekeeper

Golden Member

Op 10 mei 2020 09:44:28 schreef rew:[...]
Ik werk nu met een 48MHz processor, maar die is 32bit. Dat scheelt enorm in de 32-bit berekeningen die moeten gebeuren. Ik denk dat ik een eind kom met dit ding. Door iets slim aan te pakken kan je zomaar een factor tien in performance winnen, dus EdingCNC die een 252MHz processor nodig heeft.
[...]

Conclusie: Eding kent er de ballen van? Voor hun 6-stepper gebruiken ze eveneens de 252MHz.

Van Lambiek wordt goede geuze gemaakt.
Lambiek

Special Member

Op 10 mei 2020 09:44:28 schreef rew:
....., dus EdingCNC die een 252MHz processor nodig heeft.

Ik denk niet dat je dat kunt vergelijken met waar jij mee bezig bent rew. Dat ding zet ook de coördinaten om naar G-code en gaat gewoon door als de pc een interrupt staat te doen, om wat voor reden dan ook. Bert komt uit de CNC wereld, dus die weet heus wel waar hij mee bezig is. :)

Ik vind het in ieder geval prima spul wat hij verkoopt.

Maar waar heb jij in vredes naam 32 stappenmotoren voor nodig? Of is het voor een klant?

Als je haar maar goed zit, GROETEN LAMBIEK.

@buckfast_beekeeper, Er zijn talloze manieren om iets te implementeren. Slimme mensen kunnen een probleem bekijken en dan voor een bepaalde oplossing kiezen die op dat moment geschikt lijkt. Zo heeft sparkyGSX de zelfde oplossing gekozen als het AVR appnote. En ik heb zo m'n redenen dat ik liever niet die aanpak neem.

Als je kijkt naar wat men in de jaren zestig bijvoorbeeld aan "navigatie-computer" kon maken om naar de maan te gaan. Stel ik geef jou een atmega328, en vraag je om een programma te maken om vlieg naar de maan te doen. Live correcties uitrekenen om precies goed uit te komen enz enz. En een maanlanding? je hebt in de AVR 2k RAM en 32k flash. Succes! Klein beetje niet-eerlijk: De AVR heeft maar half zo veel RAM en ROM als de AGC. Maar daar staat tegenover dat je een 8x snellere klok hebt.

Dat als voorbeeld van dat men vroeger met heel weinig resources toch behoorlijk grote dingen voor mekaar kreeg. Dat is gewoon lang genoeg naar de mogelijkheden van de hardware staren en innovatieve manieren zoeken om voor mekaar te krijgen wat je wilt.

De STM32F072 heeft iets van 14 timers. Maar zeg dat je niet in 1x allemaal mag gebruiken (nodig voor andere dingen). Kan jij 16 10bits PWM signalen op 0.5MHz maken? Ik wel. 2 of 3 poorten van 16 outputs gaat denk ik ook lukken. En als je naar de hardware specs kijkt zal je zien dat "48 PWM outputs" niet op de feature-lijst staat. Als je dan als engineer naar je baas loopt en zegt: Nee dat kan ie niet, kijk maar! dan krijg je gewoon gelijk.

En in de moderne wereld is: gooi d'r maar een PWM chipje tegenaan of "stop het in een FPGA" of "koop maar een snellere CPU" gewoon een prima oplossing. Maar dat wil nog niet zeggen dat je soms met een "rare" of "andere" oplossing niet HEEL andere performance kan krijgen.

code:

assurancetourix:~/stepper_planner> ./planner 3000
49152000 microsteps 
asteps = 19468800
128 390 -33 1 0 593 33 1 -128 390 

komt op 402 steps van de theoretische waarde uit. Een 2.4% kans dat ie 1 microstapje verkeerd staat. Niet slecht.

Op 10 mei 2020 10:37:10 schreef Lambiek:
Maar waar heb jij in vredes naam 32 stappenmotoren voor nodig? Of is het voor een klant?

Klant wil significant MEER dan 32 stappenmotoren aansturen. Ik heb als deel-doel eerst maar eens 32 stappenmotoren vanuit m'n ene CPU genomen. En als ie dan 64 stappenmotoren wil: Moet ie m'n printje maar 2x kopen. En wil ik 1024 stappenmotoren dan zijn dat 32 printjes die ie moet kopen. Je mag me een mietje noemen, maar met 4 steppers en 256 bordjes mwah. Minder elgant. Misschien zakelijk niet slim om zo "je hebt minder bitwizard hardware nodig" te adverteren, maar ja ik denk mee met de klant naar de mooiste oplossing ook al is dat niet altijd in mijn belang.

Update: Mijn planner-programmatje kan nu zonder de hele simulatie te runnen precies voorspellen waar ie uitkomt. En dat gaat heel netjes als ik 3000 tot 3009 stapjes vraag, maar als ik dan een typefout maak en 30010 stapjes vraag, dan schrik je van hoe groot de afwijking ineens is. Dat komt omdat de afwijking orde-van-groote het aantal stapjes in het constante-snelheid deel is. Dus met (bijna) 10x meer stapjes constante snelheid 10x meer afwijking aan het eind. Ik ga het "eentje meer-of-minder" halverwege het CS deel nog implementeren.....

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
Lambiek

Special Member

Op 10 mei 2020 10:44:29 schreef rew:
Klant wil significant MEER dan 32 stappenmotoren aansturen.

Oké, meer dan 32 zijn er aardig wat.

Misschien zakelijk niet slim om zo "je hebt minder bitwizard hardware nodig" te adverteren, maar ja ik denk mee met de klant naar de mooiste oplossing ook al is dat niet altijd in mijn belang.

Ik weet niet of dat niet slim is, je kunt beter mee denken met de klant dan alleen maar aan je zelf denken. En vroeg of laat komt een klant daar toch wel achter, gewoon eerlijk blijven. :)

Als je haar maar goed zit, GROETEN LAMBIEK.

Inderdaad: Ik hoop dat dat soort dingen zich op de lange termijn terugbetalen.

Oké, meer dan 32 zijn er aardig wat.

Maar dus significant meer dan 32, niet een paar meer dan 32, maar ECHT een veelvoud. Maar goed. Het is veilig om te stellen dat het project een beetje onder het stof geraakt is. Hardware opgestuurd en ... een jaar later bellen ze met een vraag over aansluiten.... Sindsdien niets meer van gehoord. Die gasten hebben het te druk met hun echte werk om dit er bij te doen. Jammer. Zo nu en dan een paar vrije uurtjes en dan komen ze met wilde plannen. Genoeg geld om d'r effe wat geld tegenaan te gooien en het dan te laten verpieteren.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
fatbeard

Honourable Member

Het begint meer en meer als een kinetic art project klinken.

Alhoewel, met de gerapporteerde resonsetijden is 'kinetic' wel erg relatief. :P

De meeste oplossingen daarvoor zijn gedistribueerd: elk element heeft een eigen controller die aan een (485)bus hangt. Verstuurd worden de nieuwe posities en elke node handelt 'zijn' stepper geheel zelfstandig af...

Een goed begin is geen excuus voor half werk; goed gereedschap trouwens ook niet. Niets is ooit onmogelijk voor hen die het niet hoeven te doen.

Heb je wel eens naar de chips van Trinamic gekeken. Die hebben motion controller en stepperdriver in een chip.
Je kunt er vanuit een computer 256 aansturen. Ze kosten €5.49 bij Digikey.
Ben je in en klap van alles af alleen maar via spi de gegevens invoeren.
https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC51…

Ik had ooit iets van 1 of 2 motoren ge-implementeerd. Toen die klant om "veel" kwam vragen heb ik wat zitten prutsen dat het redelijk werkte. Zoals gezegd die klant is er niet mee doorgegaan. Dus mijn huidige codebase wat "van alles en nogwat" doet bevat (tot enkele dagen geleden) nog steeds de "#define MAX_MOTORS 32". Ik had afgelopen week ineens dat het er op leek dat eea niet genoeg geheugen had en toen heb ik dat teruggezet naar "8".

Ik wil nog steeds een keer een "ultimate 3D-printer-controller" maken. En dan wil ik zeker rond de 8 steppers kunnen aansturen. Denk aan X, Y, Z1, Z1, E1, E2, E3: Dat zijn er al zeven.

Ik ben even niet meer geinteresserd in de richting "het moeten er 1000 worden". Ik heb gewoon een eenvoudige microcontroller en de vraag was hoe ik de planning moest aanpassen om wat nauwkeuriger op de gewenste eindpositie te komen. De kludge die er nu in zat begon op te vallen: Ga zo goed als je kan naar de gewenste positie en start dan nogmaals een move op om het verschil er uit te halen. Een klant die 1 tot 3 motors gebruikt begon het op te vallen dat ie soms wat overshoot had.

Door de discussie hier heb ik een bugje er uitgehaald: (ik rekende met de ingestelde maxv ipv de maxv die werkelijk bereikt wordt door een aantal stappen maxa te doen). En ik heb wat verfijninen van het algorithme doorgevoerd. De afwijkingen die ik nu nog zie zijn in de orde van grootte van een atoom (in werkelijkheid: een kleine kans om een paar µm d'r naast te komen te zitten. Mooi. Nu wat printjes insturen naar de PCB fabrikant.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/