rew
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
Volgens mij staat er bovenaan ergens iets met include <avr.h> of <delay.h> en daar komt de routine "_delay_us()" vandaan.
Die moet je ergens vertellen dat je klok 1MHz is, en als je dat update naar "20MHz", dan duurt die precies even lang bij 20Mhz als eerst.
(De call-overhead is te groot om op 1MHz een delay van 5 us in een subroutine te doen. Volgens mij is is ie slim genoeg om dat te zien en maakt dan iets terplekke wat 5us duurt: nop;nop;nop;nop;nop; . )
Dat draait allemaal in main ben ik bang...
Dit soort code is inderdaad heel erg afhankelijk van de speed van je mainloop.
Je had/kan beter een 5us interrupt maken waarin je steeds iets moet doen of niet. Al is 5uS wel erg rap voor 1 Mhz.
Het gevaar van deze code is dat als je nog meer wilt gaan doen in je main loop dat van invloed is op deze timing. Als je op dezelfde manier je uart uit wilt gaan lezen in de main, dan gaat hem dat zo niet worden. Daar heb je echt interrupts voor nodig
#include <util/delay.h> staat er inderdaad bovenaan.
de code die ik tot dusver heb is opgebouwd zoals het stukje wat ik heb gepost, dus eigenlijk allemaal blokken na elkaar, die nooit tegelijk kunnen worden aan geroepen.
veel met een constructie als:
while (voorbeeld = 1)
{
doe je ding, b.v. stepper sturen
if (limitswitch = reached)
{
voorbeeld = 0
ga naar het volgend blok
}
}
while (volgend blok)
enz.
en zo gaat de uart communicatie straks ook een zo'n blok. want ik hoef niets te communiceren terwijl er een andere taak word uitgevoerd.
dus:
Op 5 februari 2020 07:50:04 schreef Stijnos:
Het gevaar van deze code is dat als je nog meer wilt gaan doen in je main loop dat van invloed is op deze timing. Als je op dezelfde manier je uart uit wilt gaan lezen in de main, dan gaat hem dat zo niet worden. Daar heb je echt interrupts voor nodig
is bij mij niet aan de orde.
neemt niet weg dat het voor verbetering vatbaar is, want wanneer ik straks b.v. in een diagonale lijn wil bewegen (X-as & Y-as tegelijk) dit met mijn set-up een probleem word. maar voorlopig is dat nog niet nodig, en ik denk dat dat ook niet gaat komen.
rew
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
Als we nu afspreken dat jij de komende maanden/jaren steeds hier statusupdates van je project post, dan verheug ik me er op om te lezen hoe je stukje bij beetje de adviezen die hier gegeven zijn implementeert die je nu aan het negeren bent.
negeren, dat klopt toch niet helemaal.
dit is een onderdeel van een redelijk groot iets (in ieder geval voor mij 
) dat besturing technisch zeer goed is op te delen in blokken, dat maakt alles een heel stuk simpeler. het moeilijkste blok moet ik nog eigenlijk aan beginnen, is al wel een beetje getest in het klein, maar nog niet IRL.
dus daar werk ik nu naar toe. daarvoer moet ik werkende steppers, display, controls (b.v. drukknop), UART, en RS485 hebben. dat stukje stepper code wat ik heb gepost is daar dus een onderdeel van, en dat is zeker (minimaal goed) om het moeilijkste deel te kunnen testen.
straks als alles werkt, dan zit ik in wat rustiger vaarwater, dat is het moment om dingen te her overwegen. om b.v. de stepper code te verbeteren, want zoals ik eerder al had gezegd zie ik daar ook beperkingen (2 assen tegelijk, mocht ik dat ooit willen).
dus dat ik dingen negeer (alle adviesen opvolgen is ook onmogelijk omdat ze soms tegen strijdig zijn), is toch echt niet waar, ik heb ze nu nog niet altijd nodig, omdat ik "zo snel mogelijk" naar het moeilijke stuk wil.
verder wil ik benadrukken dat ik alle adviesen en reacties enorm waardeer,
zonder julie zou zo'n project vele male moeilijker worden. 
ahh Netjes maken doen we later nog wel eens 
uhuh..
Ik begrijp je manier van aanpak en vermoed dat programmeren redelijk nieuw voor je is, maar zoals je het omschrijft dat dit iets is/wordt van een veel groter iets, dan ga ik je (net als rew) nu al zeggen dat je straks of in de problemen komt qua timing, dingen die niet parallel kunnen en of dat je door de bomen het bos niet meer ziet.
Mijn eerste tip is om per blok te kijken wat het doet en moet doen.
probeer die functionaliteit in een functie te stoppen.
Het is daarbij echt killing om while loops te gebruiken met delays er in.
Dat zorgt ervoor dat je microcontroller niks anders kan doen in de tussentijd.
Die delay tijd is dus weggegooide tijd. In die tijd kan je micro bijvoorbeeld een 2e as aansturen of beetje communiceren of weet ik veel wat.
JE code bevat nu 4x dit blok code
for (pulse = 0; pulse < 1000; pulse ++) // number of pulses i need
{
x = x + 1;
pulse_stepper_driver_RX_high; // pulse to stepper driver = 1
_delay_us(5);
pulse_stepper_driver_RX_low; // pulse to stepper driver = 0
TCNT1 = x;
TCCR1B |= (1<<CS10); // prescaler = 1 = start timer
while ((TIFR & (1<<TOV1))==0);
TCCR1B &= ~(1<<CS10); //prescaler = 1 = stop timer
TIFR|= (1 << TOV1); // make overflow flag "0" yes you have to write a "1"
}Dat had je zowieso al mooi in een functie kunnen stoppen met als argument de draairichting (x+1 of x-1) en het aantal stappen (100 hier)
Mocht dit dan niet lekker werken hoef je het niet op 4 plaatsen aan te passen en Als je Main loop 4 functies bavat inde zin van
#define UP_DIRECTION (1)
#define DOWN_DIRECTION (-1)
typedef enum {
MOVE_ACTION_1,
MOVE_ACTION_2,
MOVE_ACTION_3,
MOVE_ACTION_4
} E_moveActions;
E_moveActions moveAction = MOVE_ACTION_1l
main() {
switch(moveAction) {
case MOVE_ACTION_1:
StepperMoveNumberOfSteps(UP_DIRECTION, 1000);
break;
case MOVE_ACTION_2:
StepperMoveNumberOfSteps(DOWN_DIRECTION, 1000);
break;
case MOVE_ACTION_3:
StepperMoveNumberOfSteps(UP_DIRECTION, 1000);
break;
case MOVE_ACTION_4:
StepperMoveNumberOfSteps(DOWN_DIRECTION, 1000);
break;
default:
break;
}
if (moveAction < MOVE_ACTION_4) {
if (StepperGetState() == STEPPER_STATE_IN_POSTION) {
moveAction++;
}
}
}
dan begrijp iemand of in ieder geval jezelf je code nog misschien (een jaar later ofzo)
Die stepper functions stop je dan netjes in een aparte sourceFile stepper.c en stepper.h ofzo.
Nog mooier en logischer zou zijn om op hoog niveau een functie te maken in de zin van
StepperSetNewPosition(500)Je hebt een homing sensor dus bij de init loop je terug naar de aanslag en dan ben je op positie 0. Vanaf daar hou je het aantal stappen bij en weet je altijd waar je zou moeten zitten (er vanuit gaan de dat je geen slip hebt)
Een 2e tip is als je hiervoor openstaat het zo te maken dat de functie MoveNumberOfSteps enkel een variabele richting en aantal stappen zet, maar niet zelf de pulsen voor de stepper gaat maken.
Ik heb je stepper driver bekeken en ik snap eigenlijk niet waarom jouw 1 Mhz uberhaubt van belang is. Jouw stepper driver bepaald het aantal stappen en 1 stap is gewoon een vaste verplaatsing van afstand.
Dus als je hem 1000 pulsen geeft ongeacht op welke snelheid dan verplaatst de motor zich even ver.
Ik zou een interrupt maken met je timer 1 op bijvoorbeeld 500uS of misschien wat sneller als dat toelaat.
En die interrupt controlleert of het aantal stappen is gemaakt en zo niet dan doet hij de een keer de pulse pin hoog maken en de andere keer de pulse pin laag.
Meer niet.
Als je dit aan het doen bent zet je een vlaggetje (beter een enum met status) STEPPER_IS_MOVING en heb je het aantal stappen bereikt in je interrupt dan zet je deze status op STEPPER_IN_POSITION
In je main loop hoef je dan enkel een gewenste positie te schrijven en parallel op de achtergrond gaat die stepper wel naar de positie die jij wilt. Ondertussen doe je van alles tot de status meld STEPPER_IN_POSITION.
Op deze manier kun je in de main 10 of 100 verschillende taken doen en doet die stepper etc zijn ding wel, waar jij niet op hoeft te wachten.
Goed genoeg tips
Doe ermee wat je wilt, maar neem van mij aan, als je straks tegen issues aanloopt dat het niet werkt of niet meer wilt werken dan zat hier je fout. Het design, de schaalbaarheid en het overzicht. Dat zijn dingen die je later niet nog even doet of aanpast.
[Bericht gewijzigd door Stijnos op (12%)]
programeren van programma's van deze omvang is inderdaad behoorlijk nieuw voor mij. en daardoor ken ik natuurlijk ook niet alle constructies en methodes. en daar zit eigenlijk de basis v/h (mogelijk aankomende) probleem.
als je aan een code begint is het meest belangrijke dat je een goed methode kiest, er zijn mischien wel 4 of 5 manieren om een stepper te acc.-nominaal-decc. die wanneer je naar de as staat te kijken allemaal het zelfde doen. maar er is er maar een de beste natuurlijk, en dat is diegene die toelaat om meerdere taken te doen zonder afbreuk te doen aan de werking van die ene as.
dus de juiste methode kiezen,....... heb ik niet gedaan, want ik kende die methode simpelweg niet. daarom ben ik blij dat je hem een keer uitlegt. kan ik die implementeren in mijn code. alleen nog even wachten tot ik het moelijke stuk werkend heb.
stijnos, bedankt.
graag gedaan, we moeten /hebben het allemaal moeten leren.
Vind het leuk dat iemand niet meteen naar arduino grijpt
Als je verder ergens tegenaan loopt dan horen we het wel weer.
Wat ga je maken als ik vragen mag?
2x geprobeerd een arduino, en ik vond het 2x niks. maar toen had ik al vaker met een AVR gewerkt.
een X-Y constructie die een voorwerp kan "inscannen" en de daaruit gekomen data kan bewerken (het moeilijke gedeelte) en vervolgens natekent.
prototype is c.a 3x2 mtr.
Maar een Arduino is toch niet meer dan een AVR met een bootloader ?
ik bedoel het arduino framework.
Dat heeft bakken vol met kant en klare libs, waardoor je gewoon een stepper lib include en dan alleen nog maar wat highlevel functies heb om een aantal stappen te maken.
Opzich super handig om snel te kunnen ontwikkelen en te prototypen en ik maak me er ook steeds meer schuldig aan als het voor een proto is of voor een eenmalig projectje wat niks mag kosten.
Het jammere ervan vind ik dat mensen niet meer weten wat er onder water gebeurt, wat interrupts zijn, hoe je die moet gebruiken.
Of dat altijd nog nodig is is de vraag..
Ik weet ook niet meer hoe mijn pc helemaal werkt en hoe de processor het ram geheugen aanspreekt of gebruikt...Om daar een applicatie voor te maken vraagt deze kennis niet echt meer. Bij microcontrollers vind ik dat toch nog wel relevantere kennis. Daar is de acceptatie grens van een crashende applicatie of een niet werkend product toch wel wat anders ben ik van mening.
buckfast_beekeeper
Van Lambiek wordt goede geuze gemaakt.
Zorg minstens op 1 punt van elke as voor een fysiek eindpunt (eindeloop schakelaar) reken niet alleen op je stappen in het geheugen.
3m * 2m = 6m² = 3 000mm * 2000mm = 6 000 000mm². Hoeveel px/mm² gaat je resolutie worden. Bij een nauwkeurigheid van 1/10mm heb je al snel 600 000 000px of 600Mpx.
edit: @stijnos: Probleem is vooral dat de arduino libs niet altijd even goed geschreven zijn. Een probleem trouwens van alle code die je vindt op het internet. Werkt het niet, dan is het vaak sneller iets nieuws te maken dan op zoek te gaan naar de fout. Kan de lib meer dan je nodig hebt, dan heb je overhead of je moet de code gaan aanpassen. Kan de lib net niet wat je wil, dan ben je toch weer aan het zelf ontwikkelen.
De vergelijking met de PC loopt ook wat mank. Daar heb je een OS dat vele zaken van je overneemt. Bij een µC dien je dat OS zelf te schrijven.
[Bericht gewijzigd door buckfast_beekeeper op (49%)]
ik vond bij de arduino o.a. de programeer omgeving al niet lekker werken.
er zijn inderdaad eindschakelaar voorzien die de voeding v/d stepperdrivers afschakeld.
3x2 mtr. op delen in pixels van 1x1 cm. 300 x 200 = 60k (dat varieert een beetje in andere topics, omdat dit aan te passen moet zijn).
hier heb ik al een paar topics over gehad b.v. deze:
buckfast_beekeeper
Van Lambiek wordt goede geuze gemaakt.
Waarom voeding stepper afschakelen? Normale werkwijze is een NC contact aansluiten op je controller. Ook een kabelbreuk wordt zo gedetecteerd. Zodra het contact opent dient de controller de stepper onmiddellijk in stop te zetten. Normaal zet je ook je locatie dan terug op 0. Als deze 'homing' onbedoeld gebeurd, dan kan je best een homing uitvoeren aan lage snelheid en dan je locatie op 0 zetten.
Als je de voeding van de stepper onderbreekt, hoe krijg je die terug aan het draaien?
ik bedoelde de (mechanische) eindschakelaars op het begin en einde v/d as. daar waar je normaal gesproken nooit komt. dat is dan een noodstop.
buckfast_beekeeper
Van Lambiek wordt goede geuze gemaakt.
Je hebt toch een 'home' sensor nodig op elke as? Hoe bepaal je anders je 0 punt? Na een koude start ga je normaal een home run maken. Is je huidige locatie je home punt, dan maak je normaal een aantal stappen van het punt weg. Je controleert dan of het home contact gesloten wordt. Daarna verplaats je de 'kop' terug naar het home punt. Traag, zonder stappen te tellen. Zodra je home referentie zich terug opent ben je op punt 0. Vanaf daar ga je tellen. Een home run gebeurd vaak voor elke as apart. Bij 3D-CNC eerst Z-as omhoog (tool uit werkstuk). Daarna Y-as naar home gevolgd door de x-as.
ik heb ook een home sensor (benaderings schakelaar).
als de X-as b.v. naar het begin loopt komt hij eerst bij de home switch, en mocht hij om wat voor reden dan ook deze missen dan komt de eindschakelaar.
maar het is goed dat je beschrijft wat te doen als de as al op de home schakelaar staat, dat was ik me al een paar dagen aan het afvragen hoe andere CNC machines dat doen.