Hahaha in de vs, dan zal ik het maar niet over Tump hebben. Ik vind het echt vet dat je deze code weer efficiënter hebt gemaakt, daar kan ik ook weer veel van leren. Het leuke is doordat ik steeds meer snap en bijgeleerd heb, dat ik nu echt wel dingen ga herkennen.  Wat ik trouwens ook leuk vind om te horen is hoe jouw werkwijze is zoals je beschreef, dat jij ook vaak eerst een code maakt die makkelijk te lezen is en daar nog een beetje bij schaaft om het  efficiënter te maken.

De laatste 2 codes, werken niet helemaal juist, maar dat maakt ook niet uit hoor. Ik ga proberen deze te fixen, dat is wel een leuke uitdaging voor mij.

Trouwens wat mij nog niet helemaal duidelijk is, doordat als ie sneller werkt door een efficiëntere code, wordt ie dan ook ietsje nauwkeuriger ( minder afwijking in de tijd) of maakt dat niet uit?

Ik ga morgen deze sketch in de praktijk testen en kijken of het nu een stuk beter gaat lopen samen met de echte tijd. Ik zal je natuurlijk op de hoogte houden.

Ja laten we maar niet praten over dat geval ja ... oh wat een schande. Gelukkig mag ik niet stemmen als buitenlander, maar de gemiddelde persoon die op Trump gestemd heeft zegt: We willen verandering. Nou dat zullen ze dan ook krijgen ook he? 

Leuk om te horen dat je dingen begint te herkennen en er plezier in hebt! Mooi! 

Snellere code zorgt inderdaad voor nauwkeurigere timing. Niets is zo moeilijk om code te schrijven voor realtime. De kleinste verandering kan grote gevolgen hebben (zowel negatief als positief).

Mocht de code niet goed werken, laat het dan even weten. Ik heb hier geen spullen om te testen helaas, maar ik kijk graag met je mee. 

Helaas, helaas en helaas, wat baal ik nu. Er zit weer een grote afwijking in. In het beging zit het allemaal wel strak uit, maar toen ik terug kan van mijn test opstelling zag ik na 8,30 uur dat er een tijdsafwijking zat van 30 sec. Ik heb nu voor de zekerheid een tweede extra externe stopwatch bij gezet om evt. andere afwijkingen uit te sluiten, maar denk toch dat het in de arduino zit. 

Ik wil nu toch heel graag een rtc module gaan gebruiken. Ik dacht simpel de code te verander door "millis" te vervangen door "now". of denk ik daar te makkelijk over?? Want ik krijg een fout melding dat "now" niet was not declared in this scope. Ik dacht dat "now" de huidige tijd is!

Hieronder de aangepaste code met rtc!!

// Date and time functions using a DS3231 RTC connected via I2C and Wire lib
#include <Wire.h>
#include "RTClib.h"
RTC_DS3231 rtc;

// Efficienter om deze als define's op te geven ipv een variable
#define in1 4
#define in2 5
#define in3 6
#define in4 7
#define TijdsduurLEDAan 1000
#define interval 5000
// Bijhouden welke stap we doen, en wat het maximum aantal stappen is
#define currentNumberMax 4
byte currentNumber = 1;     
unsigned long voorgaandeMillis = 0;        // laatste keer dat iets werd uitgevoerd
void setup()
{
 pinMode(in1, OUTPUT);
 pinMode(in2, OUTPUT);
 pinMode(in3, OUTPUT);
 pinMode(in4, OUTPUT);
}
void loop()
{
  unsigned long huidigeMillis = now();
  if (huidigeMillis - voorgaandeMillis >= interval) {
    // 1 minuut verstreken - reset tijd
    voorgaandeMillis = huidigeMillis;
    // N.b.: Dit kan efficienter, maar dit is voor nu even beter leesbaar:
    switch (currentNumber) {
     case 1: 
       digitalWrite(in1, HIGH);
       digitalWrite(in2, LOW);
       digitalWrite(in3, LOW);
       digitalWrite(in4, LOW);
       break;
     case 2: 
       digitalWrite(in1, LOW);
       digitalWrite(in2, HIGH);
       digitalWrite(in3, LOW);
       digitalWrite(in4, LOW);
       break;
     case 3: 
       digitalWrite(in1, LOW);
       digitalWrite(in2, LOW);
       digitalWrite(in3, HIGH);
       digitalWrite(in4, LOW);
       break; 
     case 4: 
       digitalWrite(in1, LOW);
       digitalWrite(in2, LOW);
       digitalWrite(in3, LOW);
       digitalWrite(in4, HIGH);
       break;
     }
    if(currentNumber<currentNumberMax) {
      currentNumber++;   // volgende stap
    } else {
      currentNumber = 1; // terug naar 1
    }
    delay(TijdsduurLEDAan); // wachttijd voor we alle LEDs weer uitzetten
    // Alle LEDs weer uitzetten
    digitalWrite(in1, LOW);
    digitalWrite(in2, LOW);
    digitalWrite(in3, LOW);
    digitalWrite(in4, LOW);
  } // if
}  // loop

 De aangepaste efficientere code van de laatste keer, is waarschijnlijk de fout dat de leds nieuw low worden gezet. Hoe dat kan weet ik nog niet, maar ik ben verder aan het speuren in die code.

dit zit in de RTClib.h bestand;

// Code by JeeLabs http://news.jeelabs.org/code/

// Released to the public domain! Enjoy!

#ifndef _RTCLIB_H_

#define _RTCLIB_H_

#include <Arduino.h>

class TimeSpan;

#define PCF8523_ADDRESS 0x68

#define PCF8523_CLKOUTCONTROL 0x0F

#define PCF8523_CONTROL_3 0x02

#define DS1307_ADDRESS 0x68

#define DS1307_CONTROL 0x07

#define DS1307_NVRAM 0x08

#define DS3231_ADDRESS 0x68

#define DS3231_CONTROL 0x0E

#define DS3231_STATUSREG 0x0F

#define SECONDS_PER_DAY 86400L

#define SECONDS_FROM_1970_TO_2000 946684800

// Simple general-purpose date/time class (no TZ / DST / leap second handling!)

class DateTime {

public:

    DateTime (uint32_t t =0);

    DateTime (uint16_t year, uint8_t month, uint8_t day,

                uint8_t hour =0, uint8_t min =0, uint8_t sec =0);

    DateTime (const DateTime& copy);

    DateTime (const char* date, const char* time);

    DateTime (const __FlashStringHelper* date, const __FlashStringHelper* time);

    uint16_t year() const { return 2000 + yOff; }

    uint8_t month() const { return m; }

    uint8_t day() const { return d; }

    uint8_t hour() const { return hh; }

    uint8_t minute() const { return mm; }

    uint8_t second() const { return ss; }

    uint8_t dayOfTheWeek() const;

    // 32-bit times as seconds since 1/1/2000

    long secondstime() const;   

    // 32-bit times as seconds since 1/1/1970

    uint32_t unixtime(void) const;

    DateTime operator+(const TimeSpan& span);

    DateTime operator-(const TimeSpan& span);

    TimeSpan operator-(const DateTime& right);

protected:

    uint8_t yOff, m, d, hh, mm, ss;

};

// Timespan which can represent changes in time with seconds accuracy.

class TimeSpan {

public:

    TimeSpan (int32_t seconds = 0);

    TimeSpan (int16_t days, int8_t hours, int8_t minutes, int8_t seconds);

    TimeSpan (const TimeSpan& copy);

    int16_t days() const { return _seconds / 86400L; }

    int8_t hours() const { return _seconds / 3600 % 24; }

    int8_t minutes() const { return _seconds / 60 % 60; }

    int8_t seconds() const { return _seconds % 60; }

    int32_t totalseconds() const { return _seconds; }

    TimeSpan operator+(const TimeSpan& right);

    TimeSpan operator-(const TimeSpan& right);

protected:

    int32_t _seconds;

};

// RTC based on the DS1307 chip connected via I2C and the Wire library

enum Ds1307SqwPinMode { OFF = 0x00, ON = 0x80, SquareWave1HZ = 0x10, SquareWave4kHz = 0x11, SquareWave8kHz = 0x12, SquareWave32kHz = 0x13 };

class RTC_DS1307 {

public:

    boolean begin(void);

    static void adjust(const DateTime& dt);

    uint8_t isrunning(void);

    static DateTime now();

    static Ds1307SqwPinMode readSqwPinMode();

    static void writeSqwPinMode(Ds1307SqwPinMode mode);

    uint8_t readnvram(uint8_t address);

    void readnvram(uint8_t* buf, uint8_t size, uint8_t address);

    void writenvram(uint8_t address, uint8_t data);

    void writenvram(uint8_t address, uint8_t* buf, uint8_t size);

};

// RTC based on the DS3231 chip connected via I2C and the Wire library

enum Ds3231SqwPinMode { DS3231_OFF = 0x01, DS3231_SquareWave1Hz = 0x00, DS3231_SquareWave1kHz = 0x08, DS3231_SquareWave4kHz = 0x10, DS3231_SquareWave8kHz = 0x18 };

class RTC_DS3231 {

public:

    boolean begin(void);

    static void adjust(const DateTime& dt);

    bool lostPower(void);

    static DateTime now();

    static Ds3231SqwPinMode readSqwPinMode();

    static void writeSqwPinMode(Ds3231SqwPinMode mode);

};

// RTC using the internal millis() clock, has to be initialized before use

// NOTE: this clock won't be correct once the millis() timer rolls over (>49d?)

class RTC_Millis {

public:

    static void begin(const DateTime& dt) { adjust(dt); }

    static void adjust(const DateTime& dt);

    static DateTime now();

protected:

    static long offset;

};

#endif // _RTCLIB_H_

Aha, ik heb een andere Probleem gevonden. Als ik de tijd test doe in de praktijk met alleen dat de leds worden geschakeld is de afwijking een heel stuk kleiner. na 11 uur ongeveer 5 seconden loopt ie voor. Dit zal misschien kunnen opgelost worden door 60x11=660, 5:660=0,0076x1000=7,6 ms erbij op 1min= dus dan wordt 60008 als interval.

Maar de vraag die ik nu nog moet stellen en uitzoeken of deze afwijking van 5 sec ook wel klopt omdat ik nu de stopwatch van mijn Iphone 5 hebt gebruikt. Het zal kunnen dat deze ook niet helemaal klopt daarom zal ik om het uit te sluiten ook gaan testen met een de echte werkelijke tijd van een atoomklok.

Maar het is nu wel duidelijk geworden dat als ik de zelfde arduino met de zelfde code een stappenmotor ga schakelen op tijd dan er dan een flinke afwijking komt. Dus het moet dan ergens aan de stappenmotor of stappendriver liggen. Waarom dat zo is begrijp ik niet, als iemand dat wel snap hoor ik het graag. Ik gebruik na Dual H Bridge module L298N als driver voor de stappenmotor. Nu ga ik testen met een A3967 EasyDriver Stappenmotor, deze kan minder vermogen (ampère) schakelen maar dat geeft niet in mijn toepassen. Ik heb ook nog een andere pro stappenmotor weet even niet het type uit mijn hoofd. We zullen kijken of er nog interessant ontdekken eruit komen

Als ik de delay op 2-5ms zet dan werkt het misschien ook beter. Dit gaan we natuurlijk nog uittesten. Ik moet nu nog een andere code maken voor de easy driver, deze werkt net wat anders. Ik ben er nog niet helemaal uit, maar ik wil nu toch echt proberen zelf die code te schrijven

Nou je bent wel lekker bezig Remko! Mooi! 

Het tijdsverloop is wel raar en ik kan dan alleen maar gokken dat de Arduino klok niet 100% zuiver loopt. We kijken steeds naar precies 60.000 ms. Maar het kan dus zijn dat de lus zelf ook nog een heel klein beetje wegsnoept maar dan zou ik niet verwachten dat het tijdsverloop steeds groter wordt.

Ik heb zelf (nog) niks met stappenmotors of RTC gedaan. Maar nu weet je wel waarom ik zei dat realtime programmeren tricky kan zijn ... 
(heb het weleens voor andere dingen nodig gehad en ben uit pure ellende het probleem maar op een andere manier gaan oplossen - vergelijkbaar met de oplossing die ik je hier gaf)

Het is eindelijk gelukt. 100 % lukt natuurlijk niet en dat ligt niet aan de arduino zelf hoor. Ik krijg na eerst ongeveer per 1 uur 1 seconde vertraging en na 11 uur loopt het weer ietsje voor. Dit kan ik dus ook niet corrigeren met  een ms meer of minder. Maar is ook heel waarschijnlijk niet nodig omdat ik denk dat het wel zich zelf wel in evenwicht houdt

Het probleem is dat de lengte van de puls de bepaalde factor is. Ik heb nu na veel verschillende instelling gevonden dat het bij 50ms moet zijn. Als je korte of langer doet dan gebeuren er hele rare dingen zoals als, tijdsafwijking stappen opeens met of tegen de klok in en ook stappen overslaan. 

Als ik een de andere driver gebruikt dan moet ik weer hele andere ms tijd voor de pulsen gebruiken. Daar maakt het natuurlijk ook nog uit of je full steps kiest of bv 1/2 step of 1/8 enz. Maar ook als je full steps kiest heb je nog steeds andere plustijd nodig dan die andere driver, raar maar waar

Ik denk zelf dat de stappenmotor met combinatie driver er niet echt is voor gemaakt is  om 1 stap rustig te maken maken in bv 1 min.  Als je snel  stappen gaat zetten  en bv 200 stappen lukt het allemaal prima.

Ik had nog een filmpje gemaakt over een stappenmotor, dit laat wel een andere simpele toepassing zien, misschien is het wel grappig om naar te kijken. Hier volgt de link van mijn video:    arduino, motor stepper by one step at a time 

Leuk! Hahah! 

Ik ga het zeker lezen. Maar wat ik al eerder zei, als ik met de test met de leds uitvoer dan het loopt het strakker dan met de stappenmotor. Het ligt echt niet aan de Arduino.

Het kan zijn dat de aansturing van de motor misschien de Arduino timing van slag brengt? LEDs trekken nauwelijks stroom, steppers daarentegen verbruiken wat meer stroom. Of gebruik je een driver (die mogelijk vertraging veroorzaakt)?

Je hebt eigenlijk wel gelijk. Ik ben er nu (bijna) uit. Ik het ligt zeker aan de stappen motors en hun stroom verbruik. Ik de h-brigde stappen driver aangesloten op een regelbare voeding van iets van 10-15 ampere. Ik ben er achtergekomen als ik op de juiste spanning zet 7,9 volt en als de die motor stappen gaat maken dan zakt de spanning 0,3 v in, dus wordt het 7,6. Als ik de regelbare voeding hoger of lager zet dan gaat de stappenmotor alle kanten op, die niet mogen, zoals tegen en met de klok in, halve of stappen over slaan. het klopt dus dan niets meer van. Ik heb dus ook andere stappen driver en daar kan je ook de stoomsterkte instellen en als je daar verschillende keuzen maakt dan gebeurt er ook steeds verschillende rare ongecontroleerde bewegingen. 

Ik heb ook nog een andere truckje bedacht dat is heel rondje( bij deze motor is dat 200 stappen) plus een stap maken, dat kan ook misschien nog helpen als ie niet een stap wilt maken.

Oh ... inzakkende spanning is niet echt lekker nee, en zeker bij een voeding die 10-15A aankan ... klinkt alsof er toch iets niet helemaal jofel gaat met de stappen motors. Maar, ik moet ook eerlijk zeggen dat ik (nog) niks met stappen motors heb gedaan. Kun je de voeding van de Arduino en de stappen motors scheiden? Ik doe dat zelf namelijk als ik met LED strips aan de slag gaan die vaak ook flink wat stroom trekken ...

Ik heb de voedingen gescheiden. Nee er is geen probleem meer, dat inzakken is niet erg. Het is eigenlijk soort onbelast en belast denk ik. De stappen motor werkt nu goed hoor. 

Laat maar horen als je hulp nodig hebt ... en als alles werkt; wel even hier posten he? Altijd erg leuk om resultaten te zien (maar niet verplicht natuurlijk!).