Arduino: while en || (OR werkt niet zoals ik dacht

Van de while is het i.d.d. de bedoeling dat er gewacht wordt tot er een bepaalde actie is uitgevoerd. Zoals b.v. dat er gewacht wordt als de trekkracht te hoog is, tot de oorzaak daarvan verholpen is.


// Winding motor stap
void wstap() {
// These four lines result in 1 step:
  digitalWrite(wstepPin, HIGH);
//  delayMicroseconds (1/wKHz*1000);
//  digitalWrite(wstepPin, LOW);
  draadmeter();
  if (aR0 >575){
    Serial.println("STOP! Draadspanning te hoog");
    while (wstopPin == HIGH) {}
  }
    digitalWrite(wstepPin, LOW);
}

 
   #define aR2 analogRead(A2)

   Serial.println(aR2);
    sw = aR2;

Realiseer je wel dat hier 2 keer de analoge waarde van aR2 gelezen word en die heel verschillend kunnen zijn.

Beter is denk ik om ze om te draaien

   sw = aR2;
   Serial.println(sw);
    

  while (aR2 > sw){dgf();}
  Serial.print("Stopwaarde is:");
  Serial.println(aR2);

Hier print je een andere waarde voor aR2 dan waarmee je de while () ingaat.
Volgens mij is sw de stopwaarde en noem het dan ook stopwaarde ipv sw. Maar ipv de stopwaarde print je de actuele waarde. Op zich niet zo erg is meer een verbeter puntje denk ik.

Op zaterdag 19 juli 2025 18:22:22 schreef benleentje:
Dat doet precies wat het doen moet?

Als wstopPin laag is dan word dit blok met code uitgevoerd en aan het aan van dat blok met code word er gewacht totdat de pin weer hoog is. Of anders gezegd wstopPin moet wel veranderen want ander blijft het daar eeuwig wachten.

??
Als wstopPin laag is dan komt ie inderdaad in het blok, maar dan racet hij ook ineen keer door de while. Dat lijkt mij toch niet de bedoeling?

Maar misschien blijft hij lang genoeg in de for-loop hangen, dat kan ik van hier niet zien.

De volgorden tussen "==", "&&", "||" en "? .. : .." en zo is een beetje vaag.

Enerzijds kan ik het niet goed onthouden, anderzijds, doen sommige compilers het "verkeerdom". Dat zal wel een overblijfsel zijn uit vervlogen tijden, maar "niet onthouden" en "zeker weten" zijn belangrijk.

Dus ik heb de gewoonte om niet: 


  while (wstopPin == HIGH && dstopPin == HIGH){}

maar


  while ( (wstopPin == HIGH) && (dstopPin == HIGH) ){}

te schrijven.

[Bericht gewijzigd door rew op (17%)] 

while (wstopPin == HIGH && dstopPin == HIGH){}
   if (wstopPin == LOW) {
      Serial.println("Naar begin 1e laag en bevestig draad.");
      ...
      while (wstopPin == HIGH) {}
   }
   
  ...
   }

Ik vind de geneste high,low,high vergelijkingen wat curieus. Ik denk dat het makkelijk fout gaat als de timing net verkeerd valt. In dit geval lijkt dat je bijna onmogelijk bij die "1e laag" komt.

De && while moet immers starten met wstop HIGH en dan exact 1 read later moet deze wstop LOW zijn.

Het is zoiets als een kaartje controleren een halve meter na het draaihekje. Ja er zal er 1 op de miljoen zijn die in die halve meter zijn kaartje verliest.

De && while moet immers starten met wstop HIGH en dan exact 1 read later moet deze wstop LOW zijn.

Is dat wat DeKees bedoelde? Dat had ik inderdaad nog niet gezien.

IK zat me nog te concentreren op wat de "#define wstopPin digitalRead(5)" en de rest van de define's wel verstandig is. Of dat je niet verder in de problemen kan helpen omdat elke keer als je wstopPin gebruik hij altijd een digitalRead() doet terwijl dat soms niet de bedoeling is.

Het is zoiets als een kaartje controleren een halve meter na het draaihekje. Ja er zal er 1 op de miljoen zijn die in die halve meter zijn kaartje verliest.

Toch niet helemaal? Zolang beide voorwaarden hoog zijn blijft hij toch al die tijde in de While() hangen, en als je daar zo lang in blijft dan word de wstopPin echt wel een keer laag.

Of zoals in je analogie. Die ene bezoeker laat 1 miljoen keer zijn kaartje zien en moet dan gelijk weer terug behalve als hij zijn kaartje verliest. Of eigenlijk mogen alleen degene door die het kaartje naar 1 meter verliezen, Of zie ik dat verkeerd?

[Bericht gewijzigd door benleentje op (40%)]

Wel de code is niet erg gemakkelijk te lezen en daardoor wordt je snel op het verkeerde spoor gezet.

Hier dus ook: Let op de "{}" na de while(). Die is gemakkelijk te missen.


 while (wstopPin == HIGH && dstopPin == HIGH){}
   if (wstopPin == LOW)

Had ik ook gemist vooral omdat de If daarna is ingesprongen lijkt het dus dat je na de While in dat blok gaat.

Maar volgens mij maakt het ook niet veel uit. OF je niet op de while wacht en daarna kijkt of wstopPin laag is of dat je dat continu in de while blijft doen. Tenminste ik zie geen verschil.

Ik denk zelf dat het laatste beter is dat de if in de while staat. Want datzijn de condities voor mij tenminste duidelijk. Maar goed is zou het denk ook niet op de manier programmeren.

Wel, zonder die haakjes komt hij alleen binnen de while als wstopPin HIGH is.
Die is dan dus niet LOW, dus dan gaat hij nooit in het if-blok, tenzij de status verandert precies tussen de while en de if.

Maar met de haakjes blijft hij in de while hangen totdat 1 van de 2 LOW wordt.
En daarna kun je dus testen welke dat is.


#define wstopPin digitalRead(5)
#define dstopPin digitalRead(9)

uint8_t ws, ds;
do
{
  ws = wstopPin;
  ds = dstopPin;
}
while ((ws == HIGH) && (ds == HIGH));

if ((ws == LOW) && (ds == HIGH)) {...}
else if ((ws == HIGH) && (ds == LOW)) {...}
else {...}

Op zaterdag 19 juli 2025 23:11:22 schreef deKees:
Wel, zonder die haakjes komt hij alleen binnen de while als wstopPin HIGH is.
Die is dan dus niet LOW, dus dan gaat hij nooit in het if-blok, tenzij de status verandert precies tussen de while en de if.

Maar met de haakjes blijft hij in de while hangen totdat 1 van de 2 LOW wordt.
En daarna kun je dus testen welke dat is.

Mijn (simpele beginners) idee is/was dat de arduino dan niet al die code tussen de haakjes (accolades?) van de while hoeft uit te voeren.

Toen het nog niet werkte omdat ik die ene digitalRead vergeten was, had ik dat stuk code er wel tussen gezet omdat ik toen nog dacht dat dat de oorzaak was.

Verder is programmeren niet m'n sterkste kant en heb ik er weinig ervaring in.

De software is nu geschreven in termen die de processor vertelt wat hij doen. En het werkt, dus in dat opzicht is het project geslaagd.

Maar zoals gezegd is het niet gemakkelijk om te volgen wat er nu gebeurt. Meerdere mensen hebben bijv de krulhaakjes gemist. Om dat op te lossen kun je de zaak opsplitsen in functionele blokken. en een leesbare indentering toepassen. Dat kost niks, maar maakt de code al wel een stuk leesbaarder.

Dan krijg je bijv iets als dit - met alleen wat extra linefeeds en verplaatsen van haakjes:


#define wstopPin digitalRead(5)
#define dstopPin digitalRead(9)
#define aR0 analogRead(A0)
#define aR1 analogRead(A1)
#define aR2 analogRead(A2)

// Winding motor stap
void wstap() 
{
   // These four lines result in 1 step:
   digitalWrite(wstepPin, HIGH);
   //  delayMicroseconds (1/wKHz*1000);
   //  digitalWrite(wstepPin, LOW);
   draadmeter();
   if (aR0 > 575)
   {
      Serial.println("STOP! Draadspanning te hoog");
      while (wstopPin == HIGH)
      {}
   }
   digitalWrite(wstepPin, LOW);
}


// Draadgeleider init
void Dgw()
{
  Serial.println("Ga naar sensor");

  while (aR2 > sw)
  {  dgf();
  }

  Serial.print("Stopwaarde is:");
  Serial.println(aR2);
  Serial.println("Ga naar Midden");

  for (int d = 0; d < (350); d++)
  {  dgb();
  }

  Serial.println("Midden uitlijning O.K.?");
  while (wstopPin == HIGH && dstopPin == HIGH)
  {}

  if (wstopPin == LOW) 
  {   
      Serial.println("Naar begin 1e laag en bevestig draad.");
      for (int d = 0; d < (lw/2); d++)
      {  dgf(); 
      }
      Serial.println("Controleer uitlijning draad en wikkellichaam.");
      Serial.println("Begin met wikkelen, O.K.?");
 
      while (wstopPin == HIGH)
      {}
   }
   else if (dstopPin == LOW) 
   {
      Serial.println("Zet draadgeleider handmatig in het midden.");
      Serial.println("Druk O.K als de draadgeleider in het midden staat.");

      while (wstopPin == HIGH)
      {}

      Serial.println("De draadgeleider gaat nu 35mm naar de sensor");
      Serial.println("die wordt uitgelezen.");
      
      for (int d = 0; d < (350); d++)
      {  dgf(); 
      }

      Serial.print("Nieuwe Sensorwaarde is:");
      Serial.println(aR2);
      sw = aR2;
      Dgw();
   }
}

Zelf zou ik nog wel een paar stappen verder gaan, en termen gebruiken die aangeven wat nu eigenlijk de bedoeling is, en minder in termen die aangeven wat de processor moet doen om dat voor elkaar te krijgen.

Bijv:
wstopPin blijkt een OkButton te zijn. Die kun je dan ook zo noemen.

Funktienamen Dgw(), dgf() dgb() zeggen mij niks. Daar zou ik andere namen voor gebruiken.

aR0 aR1 aR2 zeggen mij ook niks. Wat probeer je daar te meten?

Je gebruikt een paar keer 

    while (wstopPin == HIGH)
      {}

Daar zou ik dan een funktie voor maken:

void WaitForOkButton()
{  while (wstopPin == HIGH)
   {}
}

.

Over het leesbaarder maken...

Vaak zijn er knoppen voor users en schakelaars om "einde beweging" te signaleren. Daar is het signaal dan laag als de gebruiker op de knop drukt of de mechanica bij het eind.

Wat jij in een define stopt is het lezen van de pin en gaat dan in de main code met == HIGH en == LOW werken.

Mijn voorstel is om met een define (of gewoon functie)(*) ergens te "verstoppen" dat het signaal laag is (of niet) als er op die knop gedrukt is.

je krijgt dan code 


   // wacht zolang 1 van beide knoppen ingedrukt is.
   while (stopbuttonpressed () || startbuttonpressed () ) {}

Merk op dat het ook ineens veel leesbaarder wordt als je de bedoeling van de code in een comment zet.

Die "lege lus" kan je ook doen met een ; (puntcomma) ipv {}. Als je die dan in z'n eentje op de volgende regel zet, dan is het duidelijker dat er niets in de lus zit. Of je kan je comment: "doe niets terwijl we wachten op loslaten" daar zetten.

(*) Een moderne compiler ziet dat een functie maar zeer kort is en zal hem vanzelf inlinen als dat sneller is.

Vergeet ook niet om je schakelaars te ontdenderen. Kan in hardware met een filtertje of in software. In software kun je een teller laten oplopen als de pin hoog is, en laten aflopen als de pin laag is. Bereikt de teller een bovengrens, bijvoorbeeld 10, dan is de pin definitief hoog. Bereikt de teller 0 dan is de pin definitief laag. Het mooiste is als je de pin sampled in een timer interrupt, dan is het gedrag altijd hetzelfde. Maar in de arduino wereld is het volgens mij meer gebruikelijk om dat gewoon in de main lus te doen... met af toe wat onvoorspelbaar (maar geaccepteerd?) gedrag tot gevolg.

Ik had e.e.a. aangepast met als gevolg dat het nu niet meer, of nog slechter :P werkt dan voorheen.

Ik ga de gehele code van nul af aan opnieuw schrijven met alle tips en adviezen. :)

Wel jammer dat het niet meer werkt.

Maar dat is inderdaad wel het risico van elke wijziging, dan kun je wel eens iets over het hoofd zien.

Meestal is het dan puzzelen om te vinden waar het mis gaat. Helemaal opnieuw beginnen is dan wel erg drastisch.

Maar ik heb wel ooit een printer-driver opnieuw geschreven omdat er een bug inzat die we niet konden vinden. Die nieuwe driver had precies dezelfde bug die we toen wel konden oplossen doordat we wisten bij welke wijziging het weer misging.

Op zaterdag 19 juli 2025 21:33:29 schreef K7Jz:

while (wstopPin == HIGH && dstopPin == HIGH){}
   if (wstopPin == LOW) {
      Serial.println("Naar begin 1e laag en bevestig draad.");
      ...

Ik vind de geneste high,low,high vergelijkingen wat curieus...

Inderdaad ik was gefopt door het inspringen van die regel onder de while na het niet opmerken van de {}.

Balen dat het niet meer werkt. Gewoon rustig opnieuw beginnen, niets aannemen, veel naar de Serial printen. De genoemde tips van rew en deKees (leesbare heldere functienamen, buttonXPressed() zijn absoluut aan te raden. Ik hou het zelf graag ook volledig engels tenzij het displayuitvoer is voor een zeer beperkte ééntalige doelgroep is.

De while(){} truuk belemmert je iets anders met de controller te doen. Niet erg, maar ook debugging kan lastig worden omdat je niet weet waar de controller nu hangt als je meerder van die loopjes hebt.

while( ! buttonXPressed ) { SerialPrint "buttonX not pressed" } // zoiets kan kan verhelderend zijn (krijg je wel veel serial text van, eventueel kleine delay toevoegen).

Bedenk ook dat elke programmeur elke keer weer ook zijn eigen code opnieuw zou kunnen schrijven, dus de perfect code waar iedereen stil van is bestaat denk ik niet :)

Op maandag 21 juli 2025 11:30:37 schreef deKees:
Wel jammer dat het niet meer werkt.

Maar dat is inderdaad wel het risico van elke wijziging, dan kun je wel eens iets over het hoofd zien.

Meestal is het dan puzzelen om te vinden waar het mis gaat. Helemaal opnieuw beginnen is dan wel erg drastisch.

Maar ik heb wel ooit een printer-driver opnieuw geschreven omdat er een bug inzat die we niet konden vinden. Die nieuwe driver had precies dezelfde bug die we toen wel konden oplossen doordat we wisten bij welke wijziging het weer misging.

Het deel voor deel opnieuw schrijven heeft wel als voordeel dat ik nieuwe inzichten er in kan verwerken.

Dus stap voor stap zou het goed moeten komen. :)

Bij deze vast de eerste resultaten. Ik heb i.i.g. zo goed mogelijk op die inspring gelet. :P


// Wikkelmachine besturing versie 2.0
// Definieer (stepper)motor, steps per 360 graden,
// sensor aansluitingen en stuursignalen.
#include <EEPROM.h>
#define windingrichting 2
#define windingenable 3
#define draadrichting 4
#define draadenable 5
#define stap 6
#define hardwarefout digitalRead(7)
#define draadmeter_A 8 digitalRead(8)
#define draadmeter_B 9 digitalRead(9)
#define draadtensiesensor analogRead(A0)
#define draadreferentie analogRead(A1)
#define Steps 6400

int positiewaarde = 0;

float wikkellichaam_MM = 30.00;
int totaalwindingen = 5000;
int draaddiameter = 100;


int wikkellichaam = wikkellichaam_MM * 1000;
int laagwindingen;
int wikkellagen;
int restantwikkelingen;


void setup() {
  Serial.begin(9600);
  EEPROM.get(0,positiewaarde);
//Declare pins als output or input:
  pinMode (2, OUTPUT);
  pinMode (3, OUTPUT);
  pinMode (4, OUTPUT);
  pinMode (5, OUTPUT);
  pinMode (6, OUTPUT);
  pinMode (7, INPUT_PULLUP);
  pinMode (8, INPUT_PULLUP);
  pinMode (9, INPUT_PULLUP);
  berekendata();
  printsetupdata();
}

void berekendata () {
  laagwindingen = wikkellichaam / draaddiameter;
  wikkellagen = totaalwindingen / laagwindingen;
  restantwikkelingen =  totaalwindingen % laagwindingen;
}

void stepping() {
  for (int s=0; s < Steps;) {
    digitalWrite(stap, HIGH);
    delayMicroseconds(20);
    digitalWrite(stap, LOW);
    s++;
  }
}

void printsetupdata () {
  Serial.print("Totaal aantal windingen ");
  Serial.print(totaalwindingen);
  Serial.println(" op een ");
  Serial.print("wikkellichaam van ");
  Serial.print(wikkellichaam_MM);
  Serial.println(" millimeter.");
  Serial.print("De draaddiameter is ");
  Serial.print(draaddiameter);
  Serial.println(" micrometer.");
  Serial.println();
  Serial.print("Het aantal wikkellagen is ");
  Serial.print(wikkellagen);
  if (restantwikkelingen != 0) {
    Serial.print(" plus 1");
    wikkellagen++;
  }
  Serial.println(".");
  Serial.print("Het aantal windingen per laag is ");
  Serial.print(laagwindingen);
  Serial.println(".");
  Serial.println();
  if (restantwikkelingen != 0) {
    Serial.print("Het aantal restantwikkelingen is ");
    Serial.println(restantwikkelingen);
    Serial.println("windingen op één extra laag.");
    Serial.print("Het aantal wikkellagen is nu ");
    Serial.print(wikkellagen);
    Serial.println(".");
  }
}



void loop() {
  digitalWrite(windingrichting, LOW);
  digitalWrite(windingenable, HIGH);

  for (int w=0; w < totaalwindingen;) {
    stepping();
    w++;
  }

  digitalWrite(windingenable, LOW);
  while (hardwarefout == HIGH);
  delay(1000);
}

Dat ziet er wel heel anders uit. Nu zie je toch beter war er gebeurt. :)

Ik vind stepping() wel een beetje vreemd:
- Die doet telkens 6400 stappen. Dat zou ik als parameter meegeven.
- Geen delay na stap LOW? Dan word die meteen weer hoog voor de volgende stap.
- Een delay van 20 microseconden lijkt me wel erg kort. Misschien moet je ook versnellen aan het begin en vertragen aan het eind van de sequence.

De stappenmotoren komen soms niet op gang als de frequentie te hoog is. Maar dat vind ik nu nog niet zo'n groot probleem.

Ik wil het zo opzetten dat de stapper voor het winden continue doorloopt en dat de stapper voor de draadgeleider tegelijk z'n stapjes doet.

Dus bij een draaddikte van 100 µm is dat voor de geleider een halve omwenteling, Daar zit een 1:5 vertraging op op een M6 as. Die is 1mm per hele omwenteling van 360 graden van die as.

Van de 6mm as is 360 graden rotatie 1mm verplaatsing, dus is 36 graden rotatie van de M6 as 0.1 mm aka 100 µm. 5x36= 180 graden van de stapper is dus 100 µm. dat is bij 1/32 3200 stapjes. Of als de DRV8825 op 200 stappen staat 100 stappen.

1/1 200 = 100
1/2 400 = 200
1/4 800 = 400
1/8 1600 = 800
1/16 3200 = 1600
1/32 6400 = 3200

stappen voor 100 µm verplaatsing.
Bij een 1/1 is 1 stap van de stapper 2 µm verplaatsing als ik het goed begrijp.

De verplaatsing van de draadgeleider moet bepaald worden door de diameter van de wikkeldraad. Dus bij een 500 µm draad moet die 500 µm per 360 graden van de wikkelmotor opschuiven.

Tot nu toe doet hij 1 omwenteling van de windingstapper, die stopt waarna de draadgeleider het vereiste aantal µm opschuift en dan stopt. Waarna de windingstapper weer 1 wikkeling doet. enz.

Ik ben aan het uitzoeken of ik de stapper van de draadgeleider het vereiste aantal stappen kan laten maken door de enable gedurende dat aantal stappen hoog te maken. En daarna weer laag.

Of ik moet via een AND in de software de geleiderstapper een eigen stap pin geven en daarmee sturen. De enable werkt echter ook als een soort AND.

Het lastige voor mij is echter om de twee for loops 'simultaan' te laten lopen.

Als je een stepper motor driver gebruikt zoals de A4988, dan moet de step input hoog zijn gedurende minimaal 1 microseconde. In de praktijk is "digitalWrite" langzamer dan een microseconde, dus


  digitalWrite (step, HIGH);
  digitalWrite (step, LOW);

werkt. Maar toch zou ik om toekomstbestendig te zijn:


  digitalWrite (step, HIGH);
  delay_us (1);
  digitalWrite (step, LOW);

doen. Dat geeft ook aan dat je begrepen hebt dat ie 1 microseconde hoog moet zijn. (Ik geloof dat ik een keer getest heb dat in de handleiding (datasheet) staat: 1 microseconde, maar dat ie ook al reageert op een VEEL kortere puls. )

Ik zou daarachter dan de "tijd tussen twee pulsen" aan delay zetten.

dus: 


void pulse (int pin) {
  digitalWrite (pin, HIGH);
  delay_us (1);
  digitalWrite (pin, LOW);
}


void stepping (int pin, int steps) {
   for (int s=0;s<steps;s++) {
      pulse  (pin);
      delay_us (100); // aanpassen
   }
}

Ik heb het puls geven naar een aparte functie gehaald. Ik heb de "standaard loop" gebruikt met for (x=0;x<eind;x++) Dat is standaard zoals een lus geschreven wordt, door de s++ elders te plaatsen doorbreek je de standaard manier van schrijven die helpt dat iedereen herkent wat je aan het doen bent.

Ik geef OOK de pin door aan de stepping functie. Dan kan je straks ook met een andere stepper gaan steppen.

Het lastige voor mij is echter om de twee for loops 'simultaan' te laten lopen.

Dat kan wel, bijv met freertos. Maar dat is weer een heel nieuwe puzzel.

In dit geval is het makkelijker om de 2 for-loops om te bouwen naar een enkele for loop. En dan binnen de loop beide motoren af en toe een puls geven.

Als je wilt kan ik wel een opzet maken, al kan ik het hier niet testen bij gebrek aan hardware.

Twee threads die alletwee een stepper aansturen is denk ik geen goed plan. De kans dat je "even" een hikje hebt omdat de andere thread bezig is, die is heel groot. En als je dat soort hikjes hebt, dan krijg je dat je motor even stilstaat en vervolgens vanuit stilstand moet accellereren naar de snelheid die je had.

In het hart wordt het: 



update_motor (struct motor *m)
{  
  //m->v += m->a;
  m->fpos += m->v;
  if (m-> fpos > FPART) {
     pulse (m->pin, m->dirpin, 1);
     m->pos ++;
  }
  if (m-> fpos <     0) {
     pulse (m->pin, m->dirpin, 0);
     m->pos --;
  }
}

Daar moet dan nog omheen dat je de pins initialiseert, en in de gaten houdt wanneer je wil stoppen, dat soort dingen. Ik heb de verwerking van de "versnelling" nog uitgecommentarieerd omdat we dat nog niet echt besproken hadden, behalve dan dat het eigenlijk zou moeten. En dat kan met deze opzet redelijk makkelijk.

Anderzijds, er IS een stepper library die dit soort dignen zou moeten kunnen.

Enable kun je niet gebruiken om de stap te sturen. Daarmee schakel je de chip volledig uit, zowel de uitgangen als ook de mirco-stepper.

Dus ik zou beide Enables aan 1 pin hangen, en de 2 Steps apart aansturen.

Ik heb de update in een nieuw draadje gezet: https://www.circuitsonline.net/forum/view/169595

het probleem met de steppers is min of meer opgelost met:


// regelt het aansturen van de stappenmotoren.
void stepping() {
  // Initialisatie van de teller voor het aantal
  // stappen van de draadverplaatsings motor.

  int deelfactor = 0;  // verdeelt de draadpulsen gelijkmatig over draadsteps.
  int d = 0;           // bruto draadsteps draadteller;

  // De steps teller voor 1 360 graden rotatie
  // van de windingmotor.
  for (int s = 1; s < Steps + 1; s++) {
    deelfactor = s % (Steps / draadsteps);
    windingpuls();

    // Als de trekkracht op de draad te hoog wordt dan
    // noodstop om dat probleem op te losen.
    if (draadtensiesensor > 60) {
      Serial.print("STOP! Draad tensie te hoog: ");
      Serial.println(draadtensiesensor);
      while (okknop == HIGH);
    }

    // Als teller d kleiner is dan het aantal
    // draadsteps en deelfactor is nul, tel er 1 bij op
    // en geef de draadmotor 1 stap.
    if (d < draadsteps && deelfactor == 0) {
      d++;
      if (d > draadsteps) {
        d = 0;
      }
      draadpuls();
    }

    // Vertraging om de frequentie van de stepperpulsen
    // te regelen.
    delayMicroseconds(microsec);

    // Meet hoeveel draad er is gebruikt.
    draadmeter();
  }
}