[Discussie] Arduino-topic

[BosGnoom]

@Atmoz Zover ik weet is een Bluetooth module een seriële verbinding, zonder kabel dan.

Op een "standaard" Arduino zit RX en TX aan de USB interface vast. Ik kan me goed indenken dat hierdoor je seriële verbinding raar gaat doen, zeker als er een USB kabel aan vast zit... Via SoftSerial zal dat beter werken, omdat je dan een dedicated verbinding hebt.

Je code ziet er complex uit (Ai... String-functies, dat is niet fijn in 2kb geheugen).

Wat gebeurt er als je een simpel echo programma schrijft, eventueel via de SoftSerial?

[ Voor 0% gewijzigd door BosGnoom op 30-06-2020 22:38 . Reden: @Atmoz excuus voor de typo in je naam :-( ]

[DataGhost]

BosGnoom schreef op dinsdag 30 juni 2020 @ 14:50:
Op een "standaard" Arduino zit RX en TX aan de USB interface vast.

Dit hangt van je chip/board af, bijvoorbeeld een Leonardo / ATmega32U4 heeft naast een set TX/RX nog dedicated USB-pins dus daarbij kan dit zonder problemen, maar een Uno heeft een ATmega328P die maar 1 set TX/RX heeft en als ik de traces op een foto van het boardje volg zit diezelfde inderdaad aan de USB-chip vast. Het zal waarschijnlijk opgelost zijn door andere pins te kiezen voor de BT-module.

Waarschijnlijk gaat het nu mis door het outputten van alle verkeer over USB, waardoor transfers door elkaar kunnen lopen. Het zal al een heel stuk beter werken zonder de logging, maar dat sluit niet uit dat er nog USB-verkeer optreedt wat de boel in de war zou kunnen sturen.

[ Voor 22% gewijzigd door DataGhost op 30-06-2020 15:15 ]

[Raymond P]

Hoe hoort je data eruit te zien?
Heb je geen conflict met je start/end markers?

[Atmoz]

BosGnoom schreef op dinsdag 30 juni 2020 @ 14:50:
@Atmos

Wie?

Zover ik weet is een Bluetooth module een seriële verbinding, zonder kabel dan.

Klopt

Op een "standaard" Arduino zit RX en TX aan de USB interface vast. Ik kan me goed indenken dat hierdoor je seriële verbinding raar gaat doen, zeker als er een USB kabel aan vast zit... Via SoftSerial zal dat beter werken, omdat je dan een dedicated verbinding hebt.

Hmzzz, ik dacht altijd dat als je de hardwarematige RX/TX wilt gebruiken dan je tijdens het programmeren die draadjes even eruit moet halen, en dat je natuurlijk niet meer kunt debuggen in de IDE.

Maar jij zegt dus dat ookal die ik bovenstaand, dat er alsnog "storing" optreed vanwege die USB-chip?!
Met andere woorden: eigenlijk kun je die hele UART op zo'n UNO nergens anders voor gebruiken dan voor te debuggen?!

Je code ziet er complex uit (Ai... String-functies, dat is niet fijn in 2kb geheugen).

Ik weet dat String-functies "zwaar" zijn, maar als het past, dan past het, toch? (of is dat niet zo? c.q. kan het alsnog ergens anders voor nadelig zijn?)

Wat gebeurt er als je een simpel echo programma schrijft, eventueel via de SoftSerial?

Dat is het "gekke" net... met SoftSerial werkt het eigenlijk prima. Maar ik dacht dus: als ik een "dedicated" UART ter beschikking heb, dan heeft die natuurlijk voorkeur boven een (blocking) software oplossing

Maar niets is minder waar blijkt wel...

DataGhost schreef op dinsdag 30 juni 2020 @ 15:13:
[...]

Dit hangt van je chip/board af, bijvoorbeeld een Leonardo / ATmega32U4 heeft naast een set TX/RX nog dedicated USB-pins dus daarbij kan dit zonder problemen, maar een Uno heeft een ATmega328P die maar 1 set TX/RX heeft en als ik de traces op een foto van het boardje volg zit diezelfde inderdaad aan de USB-chip vast. Het zal waarschijnlijk opgelost zijn door andere pins te kiezen voor de BT-module.

Waarschijnlijk gaat het nu mis door het outputten van alle verkeer over USB, waardoor transfers door elkaar kunnen lopen. Het zal al een heel stuk beter werken zonder de logging, maar dat sluit niet uit dat er nog USB-verkeer optreedt wat de boel in de war zou kunnen sturen.

Op dat laatste lijkt het inderdaad verdacht veel.
Dan snap ik ook waarom ik eigenlijk alleen maar schema's tegen kom waar zo'n HC-05 juist NIET aan de UART is gekoppeld Ik vond het al zo vreemd!

Raymond P schreef op dinsdag 30 juni 2020 @ 16:13:
Hoe hoort je data eruit te zien?
Heb je geen conflict met je start/end markers?

De data hoort er zo uit te zien:

start*1*5

Vandaar dat ik <start*1*5> stuur.
Nee, de start/end markers werken perfect.
Want met SoftSerial werkt het dus wel bijna altijd goed

[teaser]

Atmoz schreef op dinsdag 30 juni 2020 @ 16:49:
[...]


Ik weet dat String-functies "zwaar" zijn, maar als het past, dan past het, toch? (of is dat niet zo? c.q. kan het alsnog ergens anders voor nadelig zijn?)

Met String kun je ongewild veel allocaties doen op de heap. En veel alloceren-dealloceren-alloceren-dealloceren... maakt een gatenkaas van de heap, en daarmee kun je in de problemen komen als je eens een groter stukje geheugen nodig hebt. Als er dan geen groot genoeg gat meer over hebt, is het gedaan met spelen. Hoe minder geheugen, hoe sneller je er tegen kan lopen.
Het ding is dat je door gebruik van String geen controle hebt over hoeveel en wanneer er wordt gealloceerd, daarom dat meer gevorderde programmeurs er liever geen gebruik van maken.

[itcouldbeanyone]

Durango schreef op maandag 8 juni 2020 @ 00:03:
Voor een cosplay helm project heb ik 2 dot led 8x8 matrix schermpjes (MAX7219) aangesloten op en een arduino nano 3.0 ATMEGA328. Alles werkt maar na een minuut of 10/15 loopt hij vast dan glitcht de animatie en word de animatie niet meer correct weer gegeven. Het uit en weer aan zetten lost dit niet op alleen na een her upload van het script. Waar zou dit aan kunnen liggen?

[Afbeelding]

[Afbeelding]

Dit is het script


[...]

Uhmm mischien ff nadenken voor compressie, dat stukje code kan 20 keer compacter, dit kost je een hoop flash wat je voor andere dingen kan gebruiken

[Atmoz]

Ik heb een probleempje met een (goedkope) servo.
Als deze niet gebruikt wordt doet deze heel soms toch een beetje bewegen.
Je hoort 'm dan ook wat zoemen/trillen.

Als oplossing had ik onderstaande code gemaakt:

code:

void MoveServo(){

  #define CYCLES_PER_ROTATION 1024; //8192;
  ServoTimer2 myservo;  // create servo object to control a servo
  myservo.attach(4);  // attaches the servo on pin 9 to the servo object
  digitalWrite(4, LOW);

  delay(200);
  
  myservo.write(2000);
  delay(1000);
  myservo.write(1600);  

  digitalWrite(4, LOW);
  myservo.detach(); 

}

En dat werkt eigenlijk super goed
Alleen is dit beperkt tot een aantal keer.... daarna doet de servo helemaal niets meer
Dat zal wel liggen aan het max. limiet dat je het object "myservo" kunt/mag aanmaken. (please correct me if I'm wrong!)

Hoe kan ik dit beter oplossen? Ik had al ergens gelezen dat iemand met hetzelfde probleem de pin (in mijn geval 4) wanneer niet gebruikt voor de servo als input te declareren, maar dat werkt bij mij helaas niet...

[Atmoz]

Is het serieus dat niemand hier een oplossing voor weet

Ik zie in dit topic geregeld VEEL ingewikkeldere dingen voorbij komen...
Hier moet toch een slimme oplossing voor zijn?

En dat een servotje "trilt" (jitter?) komt volgens mij ook wel vaker voor.
Dus ik hoop dat iemand hier een fijne oplossing daarvoor heeft

[Raymond P]

@Atmoz Wellicht is er wat meer info nodig.

Je zou een scope aan pin 4 kunnen hangen om te zien wat er gebeurt.
Je PWM is niet zuiver of je servo pikt ruis op. Slechte soldeerverbindingen?

Wat zie je op Serial? Crasht je controller niet toevallig?
Doet de library die je gebruikt ook netjes de timers detachen of loopt je RAM vol met functies?

[Accretion]

Je hebt een probleem met een goedkope servo.
Oplossing is simpel, een dure servo kopen?

Maak een minimaal stukje code waarin je alleen de servo aanstuurt en niets anders.

Als dan nogsteeds het probleem zich voordoet, ligt het aan de servo/hardware, niet aan je code.

Check dan of je voeding stabiel is en/of voeg wat condensators toe.
En/of kijk of een andere servo deze problemen niet heeft, dan kun je echt uitsluiten wat het probleem is.

[teaser]

Atmoz schreef op vrijdag 3 juli 2020 @ 20:12:

En dat werkt eigenlijk super goed
Alleen is dit beperkt tot een aantal keer.... daarna doet de servo helemaal niets meer
Dat zal wel liggen aan het max. limiet dat je het object "myservo" kunt/mag aanmaken. (please correct me if I'm wrong!)

Mogelijk.
Definieer myservo buiten de functie en doe de attach in de setup(). De detach() is dan niet meer nodig (vermoed ik, ik ken de library niet en heb nog nooit een servo aangestuurd). In MoveServo() moet je dan enkel de writes en delays doen.

[Atmoz]

Thanks voor de reacties / het meedenken!!

Raymond P schreef op maandag 6 juli 2020 @ 08:14:
@Atmoz Wellicht is er wat meer info nodig.

Je zou een scope aan pin 4 kunnen hangen om te zien wat er gebeurt.
Je PWM is niet zuiver of je servo pikt ruis op. Slechte soldeerverbindingen?

Een scope heb ik helaas niet.
Nee, de verbindingen zijn goed
Mijn gevoel zegt dat de servo zelf niet echt ruis op pikt, want als ik de code gebruik zoals eerder gepost, dan is er totaal geen ruis.
Dus het moet iets zijn in de hardware en/of software van de Arduino.

Wat zie je op Serial? Crasht je controller niet toevallig?

Serial werkt perfect. Ook als de servo "ineens" niets meer doet
Dus daarmee is bewezen dat de controller niet crasht.

Doet de library die je gebruikt ook netjes de timers detachen of loopt je RAM vol met functies?

Ik denk inderdaad dat het iets is met de library.
Omdat ik ook de softwareSerial library gebruik, moest ik een andere library voor de servo gebruiken, namelijk: "ServoTimer2"

Accretion schreef op maandag 6 juli 2020 @ 08:29:
Je hebt een probleem met een goedkope servo.
Oplossing is simpel, een dure servo kopen?

Klopt, het is een zeer cheape servo. Maar dat heeft er vrij weinig mee te maken aangezien het dus wel goed werkt met eerder geposte code. Alleen (door een probleem in de software) niet lang genoeg Maar daarmee is ook wel weer bewezen dat de servo an sich niets mankeert.

Maak een minimaal stukje code waarin je alleen de servo aanstuurt en niets anders.

Als dan nogsteeds het probleem zich voordoet, ligt het aan de servo/hardware, niet aan je code.

Check dan of je voeding stabiel is en/of voeg wat condensators toe.
En/of kijk of een andere servo deze problemen niet heeft, dan kun je echt uitsluiten wat het probleem is.

Dat ga ik inderdaad nog eens proberen

teaser schreef op maandag 6 juli 2020 @ 09:09:
[...]

Mogelijk.
Definieer myservo buiten de functie en doe de attach in de setup(). De detach() is dan niet meer nodig (vermoed ik, ik ken de library niet en heb nog nooit een servo aangestuurd). In MoveServo() moet je dan enkel de writes en delays doen.

Zo hoe jij het beschrijft is gewoon de "standaard" methode zoals het normaal gebeurt.
Maar dan is die servo-pin ook altijd "gekoppeld" aan de servo-library. En omdat 'ie het dan juist zo raar doet, heb ik deze oplossing bedacht. Op die manier wordt de servo-pin alleen gebruikt om de servo aan te sturen wanneer het nodig is. De rest van de tijd (99%) is die pin gewoon "stil" en doet de servo ook niets

Dus eigenlijk zou ik dit gewoon graag zo laten, maar dan wel met een oplossing zodat ik het meer dan een paar keer kan gebruiken...

Ik heb zojuist nog even getest: nadat ik de Arduino opnieuw start/reset kan ik precies 8x de servo laten bewegen. Daarna stopt het. De Serial monitor loopt gewoon wel nog door. Dus de controller zelfs crasht niet. In de library zag ik tevens staan:

This library uses Timer2 to drive up to 8 servos using interrupts so no refresh activity is required from within the sketch.

Die 8 kan geen toeval zijn, toch? Betekend dat niet gewoon dat ik maar 8 instanties van die "myservo" kan aanmaken? En op de manier zoals ik het nu doe, raak ik na 8x aan dat limiet. Ergens wordt dus boel niet volledig opgeruimd waardoor ik al snel aan die 8x zit...

Is er geen manier te vinden om dat servo-object te verwijderen iedere keer?

[Raymond P]

Je zou kunnen beginnen met nagaan of er geen manier is om dat servo object niet 8 keer aan te maken.

Als je zoals @teaser aangeeft je servo definitie global maakt ben je daarvan af en kan je je attach en detach gewoon blijven gebruiken (neem ik aan).
Of je gebruikt een fatsoenlijke library (of schrijf het zelf).

Dat is natuurlijk wel symptoombestrijding, Je kan ook gewoon het probleem oplossen.
Als je servo actief is dan krijgt hij signaal.

Als je servo ontkoppelt niet raar doet dan inplementeert de gebruikte library de interupts niet netjes, timers kloppen niet of je microcontroller is overbelast.

[roeleboel]

Atmoz schreef op vrijdag 3 juli 2020 @ 20:12:
Ik heb een probleempje met een (goedkope) servo.
Als deze niet gebruikt wordt doet deze heel soms toch een beetje bewegen.
Je hoort 'm dan ook wat zoemen/trillen.

Als oplossing had ik onderstaande code gemaakt:

code:

void MoveServo(){

  #define CYCLES_PER_ROTATION 1024; //8192;
  ServoTimer2 myservo;  // create servo object to control a servo
  myservo.attach(4);  // attaches the servo on pin 9 to the servo object
  digitalWrite(4, LOW);

  delay(200);
  
  myservo.write(2000);
  delay(1000);
  myservo.write(1600);  

  digitalWrite(4, LOW);
  myservo.detach(); 

}

En dat werkt eigenlijk super goed
Alleen is dit beperkt tot een aantal keer.... daarna doet de servo helemaal niets meer
Dat zal wel liggen aan het max. limiet dat je het object "myservo" kunt/mag aanmaken. (please correct me if I'm wrong!)

Hoe kan ik dit beter oplossen? Ik had al ergens gelezen dat iemand met hetzelfde probleem de pin (in mijn geval 4) wanneer niet gebruikt voor de servo als input te declareren, maar dat werkt bij mij helaas niet...

Werkt het wel/beter als je als laatste regel code dit toevoegt binnen je functie:

code:

delete myservo;

[DataGhost]

roeleboel schreef op maandag 6 juli 2020 @ 11:44:
[...]


Werkt het wel/beter als je als laatste regel code dit toevoegt binnen je functie:

code:

delete myservo;

Het is geen pointer dus dat lijkt me op verschillende manieren niet goed gaan.

[Atmoz]

Klopt, het is geen pointer. Maar ik had dit idee vanmorgen wel al getest.
Maar ook dan werkt het maar 8x. Er blijft (ondanks die delete) toch nog iets in het geheugen hangen van dat object....

[DataGhost]

Mja, verwacht geen uitgebreide memory management in embedded code. Wat je nu probeert te doen is geen standaard use case, dus waarschijnlijk is er uberhaupt niet over nagedacht en anders is er waarschijnlijk de afweging gemaakt dat het "netjes" doen teveel extra code kost die in 99,9% van de gevallen niet gebruikt wordt.

Maar zoek vooral de library op en kijk rond regel 50 van de source

Als je het echt op de lelijke manier wilt doen kan je de library forken en een constructor maken waaraan je zelf een chanIndex meegeeft.

[ Voor 12% gewijzigd door DataGhost op 06-07-2020 12:16 ]

[Raymond P]

Die lib faciliteert toch gewoon de opties om daar netjes mee om te gaan?

[Atmoz]

DataGhost schreef op maandag 6 juli 2020 @ 12:12:
Mja, verwacht geen uitgebreide memory management in embedded code. Wat je nu probeert te doen is geen standaard use case, dus waarschijnlijk is er uberhaupt niet over nagedacht en anders is er waarschijnlijk de afweging gemaakt dat het "netjes" doen teveel extra code kost die in 99,9% van de gevallen niet gebruikt wordt.

Maar zoek vooral de library op en kijk rond regel 50 van de source

Als je het echt op de lelijke manier wilt doen kan je de library forken en een constructor maken waaraan je zelf een chanIndex meegeeft.

Je bedoeld dat ik de boel "voor de gek" moet houden om NBR_CHANNELS flink op te hogen?

Raymond P schreef op maandag 6 juli 2020 @ 15:27:
Die lib faciliteert toch gewoon de opties om daar netjes mee om te gaan?

Nee, volgens mij niet...
Welke opties bedoel je dan?

[DataGhost]

Atmoz schreef op maandag 6 juli 2020 @ 16:13:
[...]


Je bedoeld dat ik de boel "voor de gek" moet houden om NBR_CHANNELS flink op te hogen?

Um, nee. Ik zeg behoorlijk letterlijk wat je kan doen en dat is niet die var ophogen. Dat kan wel, maar dan loop je na X keer weer tegen hetzelfde probleem aan, en afhankelijk van hoe "flink" je aan de slag gaat ben je misschien direct door al je RAM heen. Lees de library eens en kijk wat er gebeurt. Dan zie je ook gauw genoeg dat het "destroyen"/detachen helemaal geen reet doet met je servo (behalve je pin niet terug LOW pullen als je het te vroeg doet (wat je ook doet)) en een nieuwe instance maken en waarde schrijven ook niks speciaal anders doet dan gewoon een andere waarde schrijven op een bestaande instance. Je moet dit gewoon global houden. Het probleem zit dus in je servo, of in de manier waarop jij hem aanstuurt.

[Raymond P]

Atmoz schreef op maandag 6 juli 2020 @ 16:13:
[...]

Nee, volgens mij niet...
Welke opties bedoel je dan?

De methods attach/detach. Je gebruikt ze al, maar niet hoe ze bedoeld zijn.

[Durango]

itcouldbeanyone schreef op woensdag 1 juli 2020 @ 20:37:
[...]


Uhmm mischien ff nadenken voor compressie, dat stukje code kan 20 keer compacter, dit kost je een hoop flash wat je voor andere dingen kan gebruiken

Dan ben ik wel benieuwd hoe je dit zou willen doen met de zelfde frame rate (knipperen en animatie van de ogen)

[itcouldbeanyone]

Durango schreef op donderdag 9 juli 2020 @ 21:31:
[...]


Dan ben ik wel benieuwd hoe je dit zou willen doen met de zelfde frame rate (knipperen en animatie van de ogen)

Je data bevat een heleboel dezelfde waardes,
Om te beginnen zou ik een 2e array maken van 8bits
Waarin een counter komt te staan welke aangeeft hoevaak je je waarde uit het grotere array wilt laden.

[DataGhost]

itcouldbeanyone schreef op vrijdag 10 juli 2020 @ 22:11:
[...]


Je data bevat een heleboel dezelfde waardes,
Om te beginnen zou ik een 2e array maken van 8bits
Waarin een counter komt te staan welke aangeeft hoevaak je je waarde uit het grotere array wilt laden.

Een andere supermakkelijke oplossing is een array met alle unieke patronen maken, en de originele array vervangen door pointers naar elk patroon. Dan ga je van 8 naar 2 bytes "per patroon". Je hebt nu 608 patronen * 8 bytes = 4864 bytes. Daarvan zijn 22 patronen uniek, dat is 176 bytes, en dan heb je nog 608 * 2 bytes voor je pointers-array, 1216 bytes voor een totaal van 1392 bytes, bijna 4x zo weinig dus. Misschien niet de efficiëntste manier van compressie (qua ruimte) maar qua code-overhead is het maar 1 pointer dereference extra dus snelheid lever je niet in en je hoeft bijna geen code aan te passen.

[itcouldbeanyone]

DataGhost schreef op vrijdag 10 juli 2020 @ 23:36:
[...]

Een andere supermakkelijke oplossing is een array met alle unieke patronen maken, en de originele array vervangen door pointers naar elk patroon. Dan ga je van 8 naar 2 bytes "per patroon". Je hebt nu 608 patronen * 8 bytes = 4864 bytes. Daarvan zijn 22 patronen uniek, dat is 176 bytes, en dan heb je nog 608 * 2 bytes voor je pointers-array, 1216 bytes voor een totaal van 1392 bytes, bijna 4x zo weinig dus. Misschien niet de efficiëntste manier van compressie (qua ruimte) maar qua code-overhead is het maar 1 pointer dereference extra dus snelheid lever je niet in en je hoeft bijna geen code aan te passen.

Klopt maar is vaak wel complex om te bergrijpen wat er gebeurt.
Conpressie kan zo klein dat alles vanuit het sram geheugen kan waardoor je positive impact meer zal hebben op snelheid.
Als er iets traag is aan een arduino zijn het wel het flash geheugen, en omgaan met 32 of 64 bits

[DataGhost]

itcouldbeanyone schreef op zaterdag 11 juli 2020 @ 11:38:
[...]


Klopt maar is vaak wel complex om te bergrijpen wat er gebeurt.
Conpressie kan zo klein dat alles vanuit het sram geheugen kan waardoor je positive impact meer zal hebben op snelheid.
Als er iets traag is aan een arduino zijn het wel het flash geheugen, en omgaan met 32 of 64 bits

Ik zou niet weten waarom 1 pointer dereference (terwijl je met memcpy_P al met pointers werkt) complex zou zijn om te begrijpen wat er gebeurt, terwijl jij een heel decompressie-algoritme voorstelt. Als de compressie nog veel kleiner gaat dan mijn voorstel zit je allang niet meer naar triviale algoritmes te kijken en dan is je winst een stuk minder want dat algoritme bestaat ook uit code (bytes). Ook kan je de uitgepakte array (ruim 4K) in deze vorm niet in de 2K SRAM van die chip kwijt dus je zal het sowieso moeten combineren met iets anders.

Anyway, op een 328P kost het laden van een byte uit flash 3 cycles*, dus ben je 24 cycles kwijt aan het inladen van een patroon**, op 16MHz is dat anderhalve microseconde. Voor het dereferencen van de pointer ben je nog eens 2 cycles kwijt. Qua snelheid heeft dat geen enkele impact dus, je zou dit bijna 700000 keer per seconde uit flash kunnen halen dus in de context van een display heeft het geen nut dit sneller te maken door het vanuit SRAM te doen. Als je dit echt per se wilt kan je prima aan de start van het programma beide arrays uit mijn voorbeeld inladen (dat past namelijk wel), dan heb je het "voordeel" dat je loads nog maar 2 cycles* kosten ipv 3, dus 16 ipv 24. Zit je aan 1 ipv 1.5 microseconde
* Datasheet, hoofdstuk 31, LPM, LD
** dan moet je alleen geen memcpy_P gebruiken maar zorgen dat je met registers blijft werken. Maar dit is al zo verwaarloosbaar weinig data dat dat in de praktijk niet uitmaakt.

Als je bedoelt dat je de gecomprimeerde data in SRAM in moet laden en voor elk patroon de decompressie moet draaien, moet je ervoor zorgen dat het algoritme voor elke input in minder dan 26 cycles draait.

"Omgaan" met 32 of 64 bits is ook helemaal niet traag, afhankelijk van je definitie van omgaan. Voor gewoon een waarde uit het geheugen laden en er niks mee doen is het niets anders dan werken met 4 of 8 bytes. Als je er wiskunde mee gaat doen, ja, dat is relatief erg traag ten opzichte van 8- of 16-bits getallen. Een uint64_t is verder gewoon een container voor "8 bytes" zonder dat dat iets over de performance zegt.

[ Voor 16% gewijzigd door DataGhost op 11-07-2020 12:56 ]

[Durango]

DataGhost schreef op vrijdag 10 juli 2020 @ 23:36:
[...]

Een andere supermakkelijke oplossing is een array met alle unieke patronen maken, en de originele array vervangen door pointers naar elk patroon. Dan ga je van 8 naar 2 bytes "per patroon". Je hebt nu 608 patronen * 8 bytes = 4864 bytes. Daarvan zijn 22 patronen uniek, dat is 176 bytes, en dan heb je nog 608 * 2 bytes voor je pointers-array, 1216 bytes voor een totaal van 1392 bytes, bijna 4x zo weinig dus. Misschien niet de efficiëntste manier van compressie (qua ruimte) maar qua code-overhead is het maar 1 pointer dereference extra dus snelheid lever je niet in en je hoeft bijna geen code aan te passen.

Dat zou zeker een hoop data schelen zo had ik er nog niet naar gekeken '608 patronen Daarvan zijn 22 patronen uniek' mja

[teaser]

Interessante discussie. Wat @DataGhost voorstelt vind ik in ieder geval een elegante oplossing. Weinig extra werk, nauwelijks complex en veel winst. Ideaal dus. Wat complexiteit betreft is het misschien wat subjectief, maar enkele regeltjes comments of een goede code structuur en descriptieve methodnamen maken al veel duidelijk.

Voor deze toepassing is het waarschijnlijk gewoon niet eens nodig, als je bordje 1 taak heeft en het geheugen volstaat daarvoor moet je in feite geen extra moeite doen. Maar ik zou waarschijnlijk gewoon doen omdat het leuk is

[Atmoz]

Kan iemand me vertellen waarom onderstaande code zo ONTZETTEND vreemd reageert?

code:

#include <VirtualWire.h>   //RX433 op pin11

#ifdef __AVR__
  #include <avr/power.h>
#endif

#define CYCLES_PER_ROTATION 1024; //8192;
#define PIN            7
#define NUMPIXELS      16

int delayval = 30; 
int angle;
int pwm;


void setup() {

  pinMode(2, OUTPUT);    //led
  pinMode(4, OUTPUT);    //servo

  Serial.begin(9600);  

  vw_set_ptt_inverted(true);   // Required for DR3100
  vw_setup(2000);              // Bits per sec
  vw_rx_start();               // Start the receiver PLL running

  Serial.println("Arduino started!");

}

void loop() {

  uint8_t buf[VW_MAX_MESSAGE_LEN];
  uint8_t buflen = VW_MAX_MESSAGE_LEN;

  if (vw_get_message(buf, &buflen)){
    int i;
    String str = (char*)buf;

   if(str.indexOf("STOP") > -1){
     digitalWrite(2, HIGH);       //led AAN
     delay(1000);
     Stop();
     digitalWrite(2, LOW);        //led UIT
    }
  }
}



void servoPulse (int angle)
{
  pwm = angle * 9 + 500;
  digitalWrite(4, HIGH);
  delayMicroseconds(pwm); //First delay
  digitalWrite(4, LOW);
  delay(50); //Second delay
}


void Stop(){
 for (angle = 0; angle <= 180; angle += 50)  {
   servoPulse(angle); delay(10); }
}

Hoe het zou moeten werken:

Indien "STOP" ontvangen via RF433-receiver --> LED even aan + servo laten bewegen

Hoe het nu werkt:

Bij 1e keer "STOP" ontvangen via RF433-receiver --> LED even aan
Bij 2e keer "STOP" ontvangen via RF433-receiver --> LED even aan + servo laten bewegen
Bij 3e keer "STOP" ontvangen via RF433-receiver --> LED even aan
Bij 4e keer "STOP" ontvangen via RF433-receiver --> LED even aan + servo laten bewegen
etc....

De servo laat dus maar de helft v/d tijd van zich horen.
Ik snap er niets van... De code wordt toch iedere keer hetzelfde uitgevoerd

[teaser]

Ik zie sowieso een paar vieze dingetjes. pwm en angle hoeven geen globale variabelen te zijn. Je gebruikt angle zelfs als globale variabele én als lokale parameter.
Maar op zich levert dat hier geen probleem op.

Wat probeer je eigenlijk precies te bereiken? Want ik zie hier niet 1 pulse per ontvangen STOP, maar 4 pulsen die telkens in tijd vergroten. Eerst 500µs, dan 950µs, 1400µs en 1950µs. Als je doel is de servo 180° te laten draaien dan is dit niet hoe je je doel gaat bereiken.

[mcDavid]

also, maar weinig servo's zullen in een tijdspanne van ~200ms 150 graden kunnen verdraaien, laat staan ook nog een keer terug naar 0 voordat ze dat doen.

[Atmoz]

Thanks!

Dat was een (volledige) gepikte code van op een blog ergens
Je zou toch verwachten dat zoiets goed werkt dan...

Inmiddels heb ik het zelf ook werkend:

code:

void Stop(){

int servo0 = 600;
int servo180 = 2100;
int inc = 20;
int pos = servo0;

  pos = servo0;

  for (int i = 0; i < 40; i++) {
    
    pos += inc;

    digitalWrite(4, HIGH);
    delayMicroseconds(pos);
    digitalWrite(4, LOW);
    delay(20);
  }

  for (int i = 0; i < 40; i++) {

    pos -= inc;

    digitalWrite(4, HIGH);
    delayMicroseconds(pos);
    digitalWrite(4, LOW);
    delay(20);
  }
}

Best handig om zonder library een servo te kunnen bedienen

[Dutchess_Nicole]

Ik heb al jaren een paar arduino's in de kast liggen voor allerlei projecten waar ik vervolgens nooit wat mee gedaan heb, jullie kennen dat vast wel...

Maar sinds kort heb ik een leuk projectje gevonden waarvoor ik weer eens zin had om een arduino voor te gebruiken!

Ik heb een patch kast gekocht, en ik wil remote in de gaten houden hoe warm het daarbinnen wordt (hij komt in de meterkast te hangen dus koeling is best belangrijk).

Ik ben dus begonnen met een arduino als controller, waarbij ik 2 eisen had: Ik wil dat het boardje zijn eigen bootloader heeft zodat ik zelf niet met avrdude etc. hoef te hannessen, en ik wil dat het apparaat via USB gevoed kan worden, zodat ik geen externe adapter hoef aan te sluiten.

Uiteindelijk ben ik op een Adafruit Feather 328p uitgekomen, waarvan ik er 1 besteld heb. Dit omdat deze lekker klein is, wat handig is met mijn breadboard, en omdat de Atmega328p die erop zit meer dan genoeg is voor wat dit apparaatje hoeft te doen.

Ik heb er een onewire temperatuursensor bij gekocht, een aantal weerstandjes had ik nog liggen van vorige pogingen en ik ben begonnen met een basis programma in elkaar te zetten.

Al vrij snel had ik mijn eerste temperatuur waarden uit de USB monitor!



Met deze setup ben ik dus gaan stoeien, De fan die hier aangesloten is is een 5V Noctua fan. Deze is dus geschikt om met USB te voeden! Dat maakt het voor mij een stuk makkelijker omdat ik dan niet ook nog ergens 12v vandaan hoef te halen.

Daarna was het tijd om de boel van het breadboardje te halen, dus heb ik Fritzing erbij gepakt en heb ik een (ontzettend beginners) PCB'tje geschetst. Deze heb ik maar gelijk laten maken, omdat ik tevreden was met het ontwerp.



Na een paar daagjes kwamen ze binnen dus ik heb er pin headers op gesoldeerd en zie hier het resultaat!





Nou alleen het remote gedeelte nog, toch?

Gelukkig, omdat het dingetje met USB gevoed wordt, kan ik de ingebouwde USB Serialport gebruiken om data te exporteren. En omdat ik veel met JSON werk leek het me handig om de gegevens die de arduino gebruikt voor het PWM signaal in dat formaat te verzenden.

Dus even vrotten met de programmering en een paar libraries later heb ik dit:

code:

#include <OneWire.h>
#include <DallasTemperature.h>
#include <ArduinoJson.h>

const int capacity = JSON_OBJECT_SIZE(2);
StaticJsonDocument<capacity> doc;
JsonObject object=doc.to<JsonObject>();
char buffer[100];

float temp = 0.0; //Temperature read from sensor
int outWire = 3;
int oneWireBus = 5; // Temperature sensor Pin
OneWire oneWire(oneWireBus); // Onewire Init
DallasTemperature sensors(&oneWire); // Onewire Init
float minTemp = 20.0; // Minimum temp that maps to 0
float maxTemp = 60.0; // Maximum temp that maps to 255
int dutyCycle = 0;

void setup(void) {
 pinMode(LED_BUILTIN, OUTPUT); // Disable builtin LED on pin 13
 digitalWrite(LED_BUILTIN, LOW);

 object["temp"] = 0.0;
 object["power"] = 0.0;

 Serial.begin(9600);
 sensors.begin();  
}

void loop(void) {
  sensors.requestTemperatures();
  temp = sensors.getTempCByIndex(0);
  
  dutyCycle = map(temp, minTemp, maxTemp, 0, 255);
  object["temp"] = temp;
  object["power"] = dutyCycle;
  serializeJson(doc, buffer);
  Serial.println(buffer);
  if (minTemp > dutyCycle) {
    digitalWrite(outWire, LOW);
  } else {
    analogWrite(outWire, dutyCycle);
  }
  
  delay(1000);
}

Dit programma'tje is net 8KB dus past makkelijk in de controller, en 1x per seconde is meer dan snel zat om te reageren op temperatuur wisselingen.

De output van deze serial connection is

code:

{"temp":33.125,"power":82}

,wat natuurlijk super makkelijk de decoden is.

Via een custom nodejs appje decode ik dit, en stuur ik het door naar een prometheus instance die ik op een servertje heb draaien. Grafana ervoor en dit is het resultaat!



Al met al ben ik best tevreden met het resultaat!

Ik kan nu precies zien wat het dingetje aan het doen is, hoe warm het wordt bij de sensor (deze komt uiteindelijk natuurlijk in het rack te hangen, tegen de bovenwand) en hoeveel power (in de vorm van PWM signal) de fans krijgen in een poging de boel weer af te koelen.

Wat vinden jullie ervan?

[ Voor 31% gewijzigd door Dutchess_Nicole op 01-08-2020 16:20 ]

[Reinder83]

Kwam net deze ATMegaZero tegen, een arduino compatible board met een pi zero form factor.

[mcDavid]

Reinder83 schreef op vrijdag 21 augustus 2020 @ 09:01:
Kwam net deze ATMegaZero tegen, een arduino compatible board met een pi zero form factor.

Leuke! Makkelijke manier om RTOS en Linux te combineren.

Interestingly, the board includes an 8-pin header for mounting an ESP8266 ESP-01 module, adding Wi-Fi to the overall feature set

Misschien is dit nog wel het interessantste though, jammer dat ze niet gewoon direct een ESP8266 aan boord genomen hebben ipv een Atmel.

[Kek]

mcDavid schreef op vrijdag 21 augustus 2020 @ 11:17:
[...]


Leuke! Makkelijke manier om RTOS en Linux te combineren.


[...]

Misschien is dit nog wel het interessantste though, jammer dat ze niet gewoon direct een ESP8266 aan boord genomen hebben ipv een Atmel.

grappig inderdaad, maar een ATmega32U4 is wel echt karig.. een esp of samd/arm zou leuker zijn geweest..

[SuperKris]

Tijd om dit arme topic weer eens een schop te geven. Zonde dat deze zo uit het zicht blijft.

Ik heb een projectje lopen waar ik een redesign op aan het doen ben en het plan is momenteel om een Arduino Mega Pro Embeded te gebruiken. Ik heb deze geselecteerd op de volgende wensen:

- Geheugen en snelheid moet voldoende zijn voor een 264x64 OLED via de U8G2 library. Een ATmega328 doet het dan eigenlijk nier meer lekker qua geheugen en snelheid
- Minimaal 2 hardware seriële poorten
- 6 interrupt pinnen voor bediening. Zonder interrupts registeren de knopjes niet lekker
- 7 PWM uitgangen voor makkelijke aansturing van indicatie LEDs (moeten kunnen dimmen)

De I/O op de mega is verder een beetje overkill en als het goedkoper en kleiner kan zou dat heel mooi zijn.

Is er een beter alternatief voor mij?

[Accretion]

SuperKris schreef op maandag 5 oktober 2020 @ 13:50:
Tijd om dit arme topic weer eens een schop te geven. Zonde dat deze zo uit het zicht blijft.

Ik heb een projectje lopen waar ik een redesign op aan het doen ben en het plan is momenteel om een Arduino Mega Pro Embeded te gebruiken. Ik heb deze geselecteerd op de volgende wensen:

- Geheugen en snelheid moet voldoende zijn voor een 264x64 OLED via de U8G2 library. Een ATmega328 doet het dan eigenlijk nier meer lekker qua geheugen en snelheid
- Minimaal 2 hardware seriële poorten
- 6 interrupt pinnen voor bediening. Zonder interrupts registeren de knopjes niet lekker
- 7 PWM uitgangen voor makkelijke aansturing van indicatie LEDs (moeten kunnen dimmen)

De I/O op de mega is verder een beetje overkill en als het goedkoper en kleiner kan zou dat heel mooi zijn.

Is er een beter alternatief voor mij?

Qua geheugen en snelheid?

De mega2560 gaat niet veel 'sneller' zijn; maar doordat je extra geheugen beschikbaar hebt; kan het minder een limitatie zijn.

Bij grote installaties met meerdere ledstrippen (essentieel dus een beeldscherm) wordt vaak een Teensy gebruikt. Een vergelijkbaar platform; maar dan met een veel hogere clock.

Ik weet echter niet in hoeverre jou U8G2 library daarop compatible zijn; maar dat lijkt me de beste gok.

Daarnaast; je zou een interrupt pin kunnen gebruiken voor alle inputs; maar dan op het moment van de interrupt zelf checken welke knop het was. Echter; je moet altijd proberen om je loop-time zo kort mogelijk te houden (wat ook kan door extra CPU snelheid er tegenaan te gooien) maar de beste oplossing hierin zit in je software.

[Shadow_Agent]

SuperKris schreef op maandag 5 oktober 2020 @ 13:50:
Tijd om dit arme topic weer eens een schop te geven. Zonde dat deze zo uit het zicht blijft.

Zeker! Mooie dingen hier voorbij zien komen, maar kan je niet helpen
Ik heb onlangs een starter kit gekocht en volg nu de lessen van Paul McWother (oid) op YouTube
YouTube: Arduino Tutorial 1: Setting Up and Programming the Arduino for Absol...

skip geregeld door de video's, de man is wat lang van stof soms Verder wel leerzaam!

[Lennyz]

SuperKris schreef op maandag 5 oktober 2020 @ 13:50:
Tijd om dit arme topic weer eens een schop te geven. Zonde dat deze zo uit het zicht blijft.

Ik heb een projectje lopen waar ik een redesign op aan het doen ben en het plan is momenteel om een Arduino Mega Pro Embeded te gebruiken. Ik heb deze geselecteerd op de volgende wensen:

- Geheugen en snelheid moet voldoende zijn voor een 264x64 OLED via de U8G2 library. Een ATmega328 doet het dan eigenlijk nier meer lekker qua geheugen en snelheid
- Minimaal 2 hardware seriële poorten
- 6 interrupt pinnen voor bediening. Zonder interrupts registeren de knopjes niet lekker
- 7 PWM uitgangen voor makkelijke aansturing van indicatie LEDs (moeten kunnen dimmen)

De I/O op de mega is verder een beetje overkill en als het goedkoper en kleiner kan zou dat heel mooi zijn.

Is er een beter alternatief voor mij?

STM32F103

- Arduino compatible
- Goedkoper
- Kleiner

Wel bij voorkeur kiezen voor de black variant.

[SuperKris]

Accretion schreef op maandag 5 oktober 2020 @ 14:25:
[...]


Qua geheugen en snelheid?

De mega2560 gaat niet veel 'sneller' zijn; maar doordat je extra geheugen beschikbaar hebt; kan het minder een limitatie zijn.

Bij grote installaties met meerdere ledstrippen (essentieel dus een beeldscherm) wordt vaak een Teensy gebruikt. Een vergelijkbaar platform; maar dan met een veel hogere clock.

Ik weet echter niet in hoeverre jou U8G2 library daarop compatible zijn; maar dat lijkt me de beste gok.

Daarnaast; je zou een interrupt pin kunnen gebruiken voor alle inputs; maar dan op het moment van de interrupt zelf checken welke knop het was. Echter; je moet altijd proberen om je loop-time zo kort mogelijk te houden (wat ook kan door extra CPU snelheid er tegenaan te gooien) maar de beste oplossing hierin zit in je software.

De oudere versie van mijn code heeft op een Mega rond de 60ms nodig om naar de display te schrijven. Tijdens die tijd is de arduino onbereikbaar voor bijvoorbeeld seriële communicatie. Prima mee te leven, maar sneller zou leuk zijn Bij een Mega heb ik ook zat geheugen. Een nano zit echter al bijna vol alleen de display aansturing.

Die teensy is een mooi ding, maar misschien wat overkill. Ik heb dan een wat grotere nodig ivm de benodigde I/O en dan word het misschien onnodig duur.

Lennyz schreef op maandag 5 oktober 2020 @ 19:56:
[...]


STM32F103

- Arduino compatible
- Goedkoper
- Kleiner

Wel bij voorkeur kiezen voor de black variant.

Die STM32 ziet er wel heel goed uit dus ik ben het even gaan uitpluizen op basis van deze pin-out:
https://easyeda.com/r3bers/STM32F103C8T6-Test-Board

Ik kom een heel eind met de IO op dat board, maar als ik mijn lijstje voor I.O verder uit werk kom ik net iets kort helaas. Voor de basis kom ik 3 digitale uitgangen (bij voorkeur PWM) tekort.



Sommige I/O kan ik wel terugbrengen door te multiplexen, maar dat maakt het ontwerp weer ingewikkelder. In de gebruikte drukknoppen zitten bijvoorbeeld 11 LEDS die ik wil aansturen. Ik kan best 4 daarvan op 1 PWM zetten, maar dan heb ik nog steeds normale inputs gaan multiplexen. In bovenstaand voorbeeld heb ik ook nog geen pinnen opgenomen voor uitreidingsporten die ik wel graag zou toevoegen.

Ik ben bang dat ik toch aan die Mega vast zit met zoveel IO. Overigens zou flashen via USB ook wel een bonus zijn. Ik ben iets aan het ontwikkelen waarbij ik mensen zonder al te veel kennis de arduino wil laten flashen.

[toekie]

Even voor de lol, ik dacht alles gezien te hebben kwa arduino en aliexpress maar deze is nieuw, arduino-ish anime bordje.

https://nl.aliexpress.com..._668%233374%2315176%23644

Hoe krijg je het verzonnen!

[Accretion]

toekie schreef op woensdag 14 oktober 2020 @ 13:01:
arduino-ish anime bordje.

Dat is heel apart, inderdaad.

Wel cool dat er een aantal buttons een buzzer en RGB lampje op zitten. Een standaard Arduino bord kun je eigenlijk weinig mee zonder externe componenten.
Niet eens zo'n gek idee; knopjes werken wanneer niet ingedrukt als een open contact, dus je hebt er in theorie ook geen last van.

De LEDs zijn wellicht onhandig aangezien je daardoor minder stroom uit een pin kan halen, maar ter indicatie dat de output aan staat, is wel handig.

(hopelijk kun je de buzzer wel ontkoppelen voor als je de pin voor een andere functie nodig hebt)

[Shadow_Agent]

Misschien kan iemand mij helpen: ik heb nu een standaard Elegoo breaboard uit zo;n Arduino starterskit. Allemaal leuk en aardig maar a) kwaliteit is matig tot slecht b) breadboard zit vol. Dus ik wil iets nieuws, maar wil wel iets kwalitatief goed kopen. ook betere kabels zijn wenselijk. Waar kopen jullie dat en wat zijn ervaringen? Eleshop al even gekeken, is dat goed spul?

en motor's/servo's etc, waar kopen jullie dat?

[DataGhost]

Accretion schreef op woensdag 14 oktober 2020 @ 14:16:
[...]

De LEDs zijn wellicht onhandig aangezien je daardoor minder stroom uit een pin kan halen, maar ter indicatie dat de output aan staat, is wel handig.

(hopelijk kun je de buzzer wel ontkoppelen voor als je de pin voor een andere functie nodig hebt)

Zo te zien hebben ze drivertjes voor de LEDs dus daar heb je geen last van, en de bij de buzzer zit een fysieke switch om hem uit te schakelen.

[DataGhost]

Shadow_Agent schreef op woensdag 14 oktober 2020 @ 14:42:
Misschien kan iemand mij helpen: ik heb nu een standaard Elegoo breaboard uit zo;n Arduino starterskit. Allemaal leuk en aardig maar a) kwaliteit is matig tot slecht b) breadboard zit vol. Dus ik wil iets nieuws, maar wil wel iets kwalitatief goed kopen. ook betere kabels zijn wenselijk. Waar kopen jullie dat en wat zijn ervaringen? Eleshop al even gekeken, is dat goed spul?

Ik weet niet wat je precies met je breadboards doet, maar ik heb een stapeltje dezelfde (maar dan van ali voor een krats). Werken prima voor snelle prototypetjes maar de bedoeling is wel dat je je schakeling daarna omzet in iets beters op een echte print natuurlijk. Dus wat voor problemen ervaar je precies?

[Accretion]

DataGhost schreef op woensdag 14 oktober 2020 @ 15:16:
[...]
Zo te zien hebben ze drivertjes voor de LEDs dus daar heb je geen last van, en de bij de buzzer zit een fysieke switch om hem uit te schakelen.

Aah, helemaal top! Klinkt als een leuk bordje, maar die print er op; wil je ook niet mee geassocieerd worden

[DataGhost]

Accretion schreef op woensdag 14 oktober 2020 @ 16:09:
[...]


Aah, helemaal top! Klinkt als een leuk bordje, maar die print er op; wil je ook niet mee geassocieerd worden

Ik zit te denken er eentje te bestellen gewoon omdat het kan Ze hebben er trouwens ook eentje met een eendje (ha-ha) als je dat liever hebt, verder hetzelfde bordje maar dan geel ipv roze dus.

[Dutchess_Nicole]

Shadow_Agent schreef op woensdag 14 oktober 2020 @ 14:42:
Misschien kan iemand mij helpen: ik heb nu een standaard Elegoo breaboard uit zo;n Arduino starterskit. Allemaal leuk en aardig maar a) kwaliteit is matig tot slecht b) breadboard zit vol. Dus ik wil iets nieuws, maar wil wel iets kwalitatief goed kopen. ook betere kabels zijn wenselijk. Waar kopen jullie dat en wat zijn ervaringen? Eleshop al even gekeken, is dat goed spul?

en motor's/servo's etc, waar kopen jullie dat?

Breadboards verschillen nogal van kwaliteit. Ik volg een YT serie van Paul McWorther die ook gebruik maakt van een Elegoo arduino kit en op al zijn video's zie je dat de connecties vaak erg slecht zijn.

Op YT zit ook een kanaal van Ben Eater die veel dingen maakt op breadboards en die heeft een gedeelte van een video besteed aan dit onderwerp: https://youtu.be/fCbAafKLqC8?t=75

Je zou even kunnen kijken wat voor BB je nu hebt en of dat een beetje goeie kwaliteit hoort te zijn. Zo niet dan kun je uit die video halen waar je op moet letten bij het aanschaffen van een goeie kwaliteit BB.

[Shadow_Agent]

Dutchess_Nicole schreef op woensdag 14 oktober 2020 @ 19:45:
[...]


Breadboards verschillen nogal van kwaliteit. Ik volg een YT serie van Paul McWorther die ook gebruik maakt van een Elegoo arduino kit en op al zijn video's zie je dat de connecties vaak erg slecht zijn.

Op YT zit ook een kanaal van Ben Eater die veel dingen maakt op breadboards en die heeft een gedeelte van een video besteed aan dit onderwerp: https://youtu.be/fCbAafKLqC8?t=75

Je zou even kunnen kijken wat voor BB je nu hebt en of dat een beetje goeie kwaliteit hoort te zijn. Zo niet dan kun je uit die video halen waar je op moet letten bij het aanschaffen van een goeie kwaliteit BB.

Tnkx voor de link naar Ben Eater! Had zelf ook een ander YT filmpje gevonden, en ook hij raadde BusBoard aan. Zelf volg ik ook de lessen van Paul McWorther "Hold your breath everyone [kijk moeizaam] BOOM!" Leerzaam maar Paul is ook wel erg lang van stof

Heb (ook) de Elegoo kit en het is toch allemaal net niet. Die fan motor zijn beide draadjes al los en zit nu met plakband vast, bij gebrek aan een soldeerbout. Vind het zelf leuk om op basis van één project, door te borduren dus m'n enige bordje zit nu stampvol met sensoren en kabels haha.

[kweetnie]

Ben bezig met een nieuw TV meubel te maken, echter wil ik deze voorzien van wat "slimme" techniek. Nu dacht ik dat op te kunnen lossen door een Arduino te gebruiken.

Wat wil ik? Het TV meubel zal uit 3 afgesloten (valdeur) compartimenten bestaan, waarin zaken als PS/Xbox/Next/Shield etc. staan. Dit gaat dus bij gebruik behoorlijk opwarmen, hiervoor heb ik een temperatuur sensor in gedachte. Per vak 1 tempsensor die bij te hoge temp een ventilator aanzet of harder bij veel te hoge temperaturen.

Vervolgens nog een schakeling voor een ledstrip van helder daglicht in de vakken, die aangaat bij openen van de deur van het compartiment.

Toekomstige nice to have zou zijn, alles via homeassistent uit te kunnen lezen.

Nu heb ik zeer beperkte ervaring met arduino of elektronica zelf maken/programmeren. Maar eens moet de eerste keer zijn
Na veel lezen, zoeken en rommelen met een Arduino starterskit, ben ik tot het volgende schema in Fritzing gekomen.

Ben ik hiermee op de juiste weg? Of zitten er enorme fouten in? Wanneer het schema namelijk klopt, kan ik me gaan richten op de volgende hindernis.... de code...

Kan me namelijk voorstellen dat ik misschien her en der nog wat weerstanden mis, of dat een enkele voeding van 75w 6amp niet voldoende is. Of gewoon draden verkeerd aangesloten...

Geplande onderdelen: (sommige al in bezit)

• 5m 300 Units 3528 LEDs 12V DC Flexible LED Strip Lights,300lm/meter, 4.8W/meter, LED Tape, 6000K Daylight White (Deze knip ik op in 3 delen voor de compartimenten)
• DS18B20 TO-92 Thermometer Temperature Sensor with cable - Waterproof - High temperature - 1m
• Power 72 W 12 V 6 A Switching Power Supply; MeanWell LRS/75 mm/12; Transformer Driver
• Built-In Wired Security Window Gate Contact Sensor Alarm Magnetic Switch Magnetic Door Sensor Normally Closed
• 1-relay, 5V, KY-019 Parent relay
• LM2596 DC-DC Step Down Voltage Converter Switch Regulator
• Noctua NF-A20-PWM
• Arduino Uno rev3

Ik weet dat ik nog niets heb gedaan om dit te kunnen koppelen aan HA via wifi of kabel. Maar wil het eerst in een lab omgeving hebben werken voordat ik verder ga. Daarnaast is het een nice to have, veel kan ik al aflezen door slimme stekkers te gebruiken.

Alle hulp tips en tricks zijn welkom!

(via pm, kan ik de .fzz sturen als dat makkelijker is)

[AteGjalt]

Je zou een dual supply kunnen nemen ipv een converter, dus een voeding die 12v en 5v levert.
Leds aansturen via een transistor is misschien ook nog een optie, heb je ook dim mogelijkheden.
Verder zou ik het stap voor stap opbouwen en dan alles samenvoegen. Misschien alvast nadenken over een protocol voor wanneer je het gaat koppelen aan een esp oid.

[ Voor 15% gewijzigd door AteGjalt op 26-10-2020 09:25 ]

[kweetnie]

@AteGjalt Dank je voor de tips, die dual voeding had ik niet aan gedacht, was ik ook nog nergens tegengekomen. Maar helaas die MeanWell voeding is juist een onderdeel dat ik al in mijn bezit heb, dus voor nu is de voordeligste optie gewoon een step down converter erbij.
Ja, dimmen van de strip is een goeie, ga ik overwegen.

Ik weet dat ik het moet gaan bouwen om te zien hoe en wat het gaat werken, alleen als ik nu op deze manier al gelijk wat fouten eruit kan filteren zou dat mooi zijn.
Twijfel nog beetje over die Magnetic switches of die zo goed aangesloten zijn, of dat daar nog een weerstand bij moet. Zie dat namelijk af en toe wel bij andere projecten online, maar ook regelmatig niet.

[AteGjalt]

@kweetnie De weerstand is voor de pull-up, deze link legt t wel duidelijk uit hoe het precies werkt.
https://www.electronicshu...reed-switch-with-arduino/
Een andere proximity switch kan ook, zijn kleinere opties beschikaar. Of simpelweg een micro schakelaar.

[ Voor 21% gewijzigd door AteGjalt op 26-10-2020 20:35 ]

[kweetnie]

Goed... ben al een tijdje bezig met het bouwen van eerder genoemde plan. Echter loop ik tegen het probleem aan dat ik het niet voor elkaar krijg om de ventilator goed aan te sturen,

Nu heb ik al zoveel forumposts her en der gevonden gelezen, de code geprobeerd en zonder gewenst resultaat.Dat ik inmiddels ten einde raad ben..
Is er iemand die werkende code heeft met schema, hoe 1 PWM fan aan te sturen via een Arduino of mega. Laat staan de 3 fans die ik in de planning heb.

Problemen waar ik tegenaan loop, kan de fan alleen sturen op 50% of 100%. Uitzetten lukt niet. Dit terwijl volgens de specs van de fan dit allemaal mogelijk is https://noctua.at/pub/med...fications_white_paper.pdf

Hieronder de code die ik gebruik, nu met een library special voor PWM. Echter dat maakt ook niet het verschil. Ook zonder library en direct de 25khz intel spec gebruiken geeft hetzelfde resultaat.

C++: Fantest

 #include<PWM.h>

int fanPulse = 10;
int fanPin = 9;
unsigned long pulseDuration;

int32_t frequency = 25000;

void setup()
{
  Serial.begin(9600);
  pinMode(fanPulse, INPUT);
  digitalWrite(fanPulse,HIGH);
  bool success = SetPinFrequencySafe(fanPin, frequency);
  if(success) {
    pinMode(9, OUTPUT);
    digitalWrite(9, HIGH);
  }
}

void readPulse() {
  pulseDuration = pulseIn(fanPulse, LOW);
  double frequency = 1000000/pulseDuration;
 
  Serial.print("RPM:");
  Serial.println(frequency*60/2);

}

void loop()
{
  int i = 0;
  Serial.println("Off...");
  analogWrite(fanPin,0);
  Serial.print("RPM:");
  Serial.println(frequency*60/2);
  delay(20000);
  Serial.println("start...");
  analogWrite(fanPin,80);
  Serial.print("RPM:");
  Serial.println(frequency/2*60);
  delay(20000);
  Serial.println("50%...");
  analogWrite(fanPin,127);
  Serial.print("RPM:");
  Serial.println(frequency/2*60);
  delay(20000);
  Serial.println("75%...");
  analogWrite(fanPin,200);
  Serial.print("RPM:");
  Serial.println(frequency/2*60);
  delay(20000);
  Serial.println("Full...");
  analogWrite(fanPin,255);
  Serial.print("RPM:");
  Serial.println(frequency/2*60);
  delay(20000);
}

Ook al diverse andere pins gebruikt, in de hoop dat ik iets over het hoofd zag met de 25kHz pulse... maar nee.

En hier het schema.


Alle tips en tricks zijn welkom.

[Accretion]

kweetnie schreef op vrijdag 6 november 2020 @ 21:32:
Alle tips en tricks zijn welkom.

Maak eens een leeg project waarbij je enkel analogWrite doet.

Je print elke keer dezelfde RPM, doe "int i = 0" doet niks.

Waarom gebruik je soms "fanPin" en soms "9".

Je zet ook "SetPinFrequencySafe" maar overschrijft de status van die pin daarna direct met HIGH?
En daarna nog met AnalogWrite.

FanPulse zet je als input, maar daarna meteen HIGH? Of bedoelde je input_pullup?

Test eens met een LED, of die wel steeds helderder wordt met je PWM signaal. En daarna met de fan.

Maar creëer een werkbare situatie, als dit niet werkt moet je op google zoeken naar anderen die dit soort fans aansturen.
Maar vanuit die werkbare situatie kun je daarna een gecompliceerder project maken.

Op dit moment heb je namelijk geen idee of het aan de fan of aan de code ligt?

Het is mij ook niet duidelijk of je de ingebouwde analogWrite (met aangepaste frequentie https://playground.arduino.cc/Code/PwmFrequency/) of een library gebruikt, aangezien je wel nog steeds analogWrite aanroept.

[teaser]

readPulse wordt nergens aangeroepen.
pulseDuration is een global maar wordt nergens anders gebruikt
frequency is een global maar wordt in readPulse opnieuw gedeclareerd, dus de waarde daarvan gaat niet buiten die method (als deze aangeroepen zou worden).

Probeer eens met pwmWrite ipv analogWrite in je loop.

[kweetnie]

Dank voor de tips. Ben zoals verzocht helemaal opnieuw begonnen. Dit is nu mijn code:

code: filename

 #include <TimerOne.h>

const int fanPin = 9; //Blue wire fan

void setup(void)
{
  Timer1.initialize(40);  // 40 us = 25 kHz
  Serial.begin(9600);
  Serial.println("Simple single pwm controlled fan test");
}

void loop(void)
{
    Timer1.pwm(fanPin, 0);
    Serial.println("Off");
    Timer1.setPwmDuty(fanPin, 341); // 0 - 1023 0 = off 1023 = max
    Serial.println("33%");
    delay(20000);
    Timer1.setPwmDuty(fanPin, 1023); // 0 - 1023 0 = off 1023 = max
    Serial.println("100%");
    delay(200000);
}

Hierin maak ik gebruik van de TimerOne library :
https://github.com/PaulStoffregen/TimerOne
Meer info een voorbeelden:
https://www.pjrc.com/teensy/td_libs_TimerOne.html

Deze zou ervoor moeten zorgen dat de juiste kHz voor de fan gebruikt wordt. Nu mogen duidelijk zijn dat ik zeker geen expert ben, maar super beginner.
Wat mij nu opvalt met deze simpele code is dat ik de fan kan aansturen op 50-100% Dit is puur op gehoor en gevoel van de fan, want zoals eerder aangegeven krijg ik de rpm niet goed uitgelezen. Het lijkt erop dat ik niet beneden de 50% kan komen. En ook tussen de 50 en 100 zit volgens mij maar 1 stap in snelheid.

Hoe ga ik nu de RPM goed uitlezen? En eventueel tot een verklaring komen waarom ik niet beneden de 50% kan sturen. Dit zou namelijk volgens de specificaties van de fan, wel degelijk moeten kunnen traploos tussen 20-100%.
En waarom kan ik de fan niet uitschakelen via de PWM? ik verwacht dat wanneer ik setPwmDuty op 0 zet dat de fan stopt, maar nee kom niet beneden die 50%.

Ter test heb ik nu de fan even in 33% draaien voor 20 sec en dan op 100% voor 200sec. Merk duidelijk verschil tussen deze 2 standen, echter als ik 33% en 50% kies merk ik geen verschil.
Heb inmiddels behoorlijke spijt dat ik voor PWM fans ben gegaan.. dacht juist dat dit makkelijker was met aansturen en uitlezen... Nou daar kom ik als beginner behoorlijk bedrogen uit.

[kweetnie]

@teaser Heb ook nog even de volgende code gebruikt, met de pwmWrite. Dan is het effect dat het werkt voor ook alleen 50% en 100% en daar niets tussen of onder de 50%.

code:

#include<PWM.h>

int fanPin = 9;

void setup()
{
  Serial.begin(9600);

}

void loop()
{
  Serial.println("Off...");
  pwmWrite(fanPin,0);

  delay(20000);
  Serial.println("start...");
  pwmWrite(fanPin,80);

  delay(20000);
  Serial.println("50%...");
  pwmWrite(fanPin,127);

  delay(20000);
  Serial.println("75%...");
  pwmWrite(fanPin,200);

  delay(20000);
  Serial.println("Full...");
  pwmWrite(fanPin,255);

  delay(20000);
}

Dus die andere code met de TimerOne library werkt blijkbaar iets beter/anders.

[teaser]

Je eerste code snippet lijkt te kloppen als ik een example bekijk van de library.
Bij de tweede, met de pwm lib, doe je geen correcte setup.

Zelf heb ik ook geen ervaring met fans aansturen.
Je gaat toch moeten opzoeken welke frequentie de fan verwacht. Als die niet in de juiste range zit gaat het niet goed werken.
En om de RPM uit te lezen, dat is kwestie van pulsjes tellen en tijd meten. Even googlen op "arduino rpm counter". Belangrijk hierbij is dat je nergens delays gebruikt in je sketch, die verstoren de meting.

[Raven]

teaser schreef op zaterdag 7 november 2020 @ 17:13:
Zelf heb ik ook geen ervaring met fans aansturen.
Je gaat toch moeten opzoeken welke frequentie de fan verwacht. Als die niet in de juiste range zit gaat het niet goed werken.

Als het een 4-pins fan is van het soort dat je in pc's vind, dan is (zo uit mijn hoofd) een 5V pulssignaal met een frequentie tussen de 21kHz en 28kHz vereist.

[kweetnie]

Dat klopt het is een PC fan en heeft 25kHz nodig om goed te werken. Maar dat is inmiddels geen probleem meer en heb ik aan de praat. Kan nu ook versnellen/vertragen en doormiddel van toevoegen van een relay uit/aan schakelen. Wat me echter nog steeds echt niet lukt is de RPM redelijk meten via de sense wire. Iemand misschien nog wat suggesties op basis van de volgende code

code:

// Include the libraries
#include <OneWire.h>
#include <DallasTemperature.h>
#include <TimerOne.h>

#define ONE_WIRE_BUS 5 // Thermometer Data wire (yellow) is plugged into port ? on the Arduino
#define precision 12 // OneWire precision Dallas Sensor
#define PIN_SENSE 2 //where we connected the fan sense pin. Must be an interrupt capable pin (2 or 3 on Arduino Uno)
#define DEBOUNCE 20 //0 is fine for most fans, fans may require 10 or 20 to filter out noise
#define FANSTUCK_THRESHOLD 500 //if no interrupts were received for 500ms, consider the fan as stuck and report 0 RPM

const int Fan_A_PWM = 9; //PWM (Blue) wire Fan_A_PWM
const int Relay_A = 4; //pin for Relay A
int tempMin = 24;   // the Celsius temperature to start the fan
int tempMax = 30;   // the maximum Celsius temperature when fan is at 100%
unsigned long volatile ts1 = 0, ts2 = 0; //Interrupt handler. Stores the timestamps of the last 2 interrupts and handles debouncing

OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with OneWire device
DallasTemperature sensors(&oneWire); // Pass our oneWire reference to Dallas Temperature.

void tachISR() {
  unsigned long m = millis();
  if ((m - ts2) > DEBOUNCE) {
    ts1 = ts2;
    ts2 = m;
  }
}

unsigned long calcRPM() { //Calculates the RPM based on the timestamps of the last 2 interrupts. Can be called at any time.
  if (millis() - ts2 < FANSTUCK_THRESHOLD && ts2 != 0) {
    return (60000 / (ts2 - ts1)) / 2;
  } else return 0;
}

void setup(void)
{
  pinMode(PIN_SENSE, INPUT_PULLUP); //set the sense pin as input with pullup resistor
  attachInterrupt(digitalPinToInterrupt(PIN_SENSE), tachISR, FALLING); //set tachISR to be triggered when the signal on the sense pin goes low
  Timer1.initialize(40);  // 40 us = 25 kHz
  Serial.begin(9600); // start serial
  sensors.begin(); // Start up the library
  Serial.println("Simple single pwm controlled fan Test");
  pinMode(Relay_A, OUTPUT); //Relay A to switch Fan_A
  Timer1.pwm(Fan_A_PWM, 0);
}

float Read_Sensor_1_Temp() {
  sensors.requestTemperatures(); // Send the command to get temperatures
  Serial.print("Temperature: ");
  Serial.println(sensors.getTempCByIndex(0));
  return sensors.getTempCByIndex(0);
}

void SetFanA () {
  float Sensor_1_Temp = Read_Sensor_1_Temp(); // Request sensor value
  int Speed_Fan_A = map(Sensor_1_Temp, tempMin, tempMax, 200, 1023); // Map (change) the sensor reading of <=1 to >=1023 to a value between 10 and 100
  Serial.print("Fan A Speed: ");
  Serial.print(Speed_Fan_A);
  Serial.println(" ");
  Timer1.setPwmDuty(Fan_A_PWM, Speed_Fan_A); // set the fan speed
  // if the temperature is above the tempMin threshold, turn on Relay_A
  if (Sensor_1_Temp > tempMin) {
    digitalWrite(Relay_A, HIGH);
  } else {
    digitalWrite(Relay_A, LOW);
  }
}

void loop()
{
  SetFanA();
  Serial.print("RPM:");
  Serial.println(calcRPM());
}

Als de fan uitstaat krijg ik nog steeds RPM terug, de gedeelte is wel 0 maar er zit van alles bij.
Zie hier een voorbeeld van verschillende snelheden met de RPM output. Schaal voor het instellen van de snelheid is nu nog 0 - 1023.

RPM	Off	337	748	Full speed
RPM	0	1428	1428	810
RPM	178	1304	1363	810
RPM	0	1428	1428	810
RPM	176	1428	1428	833
RPM	0	1363	1428	810
RPM	19	1304	1428	833
RPM	0	1428	1428	810
RPM	97	1200	1363	810
RPM	44	1304	1363	833

Fan specs:

NF-A20PWM
Rotational speed (+/- 10%)	800 RPM
Rotational speed with L.N.A. (+/- 10%)	550 RPM
Min. rotational speed (PWM, +/-20%)	350 RPM
Airflow	146,9 m³/h
Acoustical noise	18,1 dB(A)
Max. input power	0,96 W
Max. input current	0,08 A
Operating voltage	12 V
Voltage PWM signal	5 V

Zoals je in de specs en output table kan zien, klopt het redelijk op full speed en daar heb ik ook geen probleem mee met die afwijking. Echter waarom klopt er niets van alles wat daarvoor komt? Dat is nu juist hoger als dat de max is...

[DataGhost]

Je ISR kan zelfs middenin een berekening in calcRPM je (volatile) variabelen aanpassen, dus let daarop. Ik zou het niet op die manier gedaan hebben maar juist een klein stukje van het rekenwerk in de ISR gezet hebben (dit kan zonder delingen en vermenigvuldigingen). Ik heb een vergelijkbare meting tot 13000rpm waarbij ik micros() gebruik en dan zelfs nog delingen in de ISR zonder timing-issues verderop, dus je hebt nog best wat ruimte. Ik denk dat je hiervan de effecten ziet bij 19 en 44rpm, dat duurt namelijk langer dan je stuck threshold dus zou je functie niet eens terug moeten kunnen geven. Bij integer-delingen zonder vaste typed variabelen heb ik trouwens af en toe wat kriebels dus probeer misschien iets met 60000L en 2L.

Daarnaast heb je 1200, 1304, 1363 en 1428rpm teruggehad, wat resp. 25, 23, 22 en 21ms zijn, en je debounce is 20ms. Doe daarmee wat je wilt Klinkt een beetje als een floating pin, maar je gebruikt wel een pullup in je code. Het makkelijkste is een scope of logic analyser eraan hangen maar ik gok zomaar dat je die niet hebt dus je zal je circuitje na moeten lopen.

[kweetnie]

@DataGhost Dank je voor je reactie. En voor de tips. Echter ben ik verre van skilled met programmeren. Echt een copy/paste held met veel logisch nadenken kom ik een eind. En natuurlijk uren puzzelen

Maar je geeft aan dat jij het anders zou doen om dit te berekenen, heb jij daar ook een stukje code voor dat ik dan beter kan gebruiken?
De RPM code die ik nu gebruik is een van de vele die ik inmiddels gebruikt/getest heb en hij werkt dus inderdaad niet direct goed. Maar kreeg hiermee wel de beste resultaten, echter heb ik totaal geen bezwaar om een andere aanpak te hanteren.
Kan inderdaad wel die debounce terug op 0 zetten, verwacht ook niet dat bij een kwaliteits fan dit echt nodig zou zijn.

En ik beschik inderdaad niet over apparatuur om echt op onderzoek uit te gaan. Maar zal alles nog eens goed nalopen en kijken of het ergens uit de aansluitingen komt.

[DataGhost]

kweetnie schreef op dinsdag 10 november 2020 @ 19:34:
@DataGhost Dank je voor je reactie. En voor de tips. Echter ben ik verre van skilled met programmeren. Echt een copy/paste held met veel logisch nadenken kom ik een eind. En natuurlijk uren puzzelen

Maar je geeft aan dat jij het anders zou doen om dit te berekenen, heb jij daar ook een stukje code voor dat ik dan beter kan gebruiken?

Ja, maar daar leer je niet zoveel van Je hebt een paar volatile variabelen, die worden elke keer dat ze gebruikt worden opnieuw gelezen uit het geheugen. Een instructie is ondeelbaar, een regel code niet (dus: kan onderbroken worden). Je ISR (als het goed is ook ondeelbaar) gaat gewoon lopen op het moment dat er iets gebeurt, ongeacht waar je normale programma mee bezig is. Als je code dus de formule a - b aan het uitrekenen is, heeft a al gelezen maar b nog niet, en jouw ISR komt er doorheen fietsen om zowel a als b te wijzigen dan klopt er van je uitkomst dus helemaal niks meer. Dus dat zal je op de een of andere manier moeten zien te voorkomen.

Kan inderdaad wel die debounce terug op 0 zetten, verwacht ook niet dat bij een kwaliteits fan dit echt nodig zou zijn.

Bij 800rpm zou de debounce van 20ms geen invloed moeten hebben omdat je tegen ongeveer 37ms bij twee pulsen per omwenteling aan zit te kijken, en bij langzamer draaien zou die tijd alleen maar langer moeten zijn. Je vraag zou dan moeten zijn waarom je kennelijk kortere pulsen ziet. En je rekent *misschien* met niet-matchende datatypen waardoor je resultaat anders zou kunnen zijn dan je verwacht. Ik weet niet precies waar je probleem zit maar beide zaken moet je aanpakken denk ik.

[Dutchess_Nicole]

kweetnie schreef op dinsdag 10 november 2020 @ 16:48:
Dat klopt het is een PC fan en heeft 25kHz nodig om goed te werken. Maar dat is inmiddels geen probleem meer en heb ik aan de praat. Kan nu ook versnellen/vertragen en doormiddel van toevoegen van een relay uit/aan schakelen. Wat me echter nog steeds echt niet lukt is de RPM redelijk meten via de sense wire. Iemand misschien nog wat suggesties op basis van de volgende code

code:

// Include the libraries
#include <OneWire.h>
#include <DallasTemperature.h>
#include <TimerOne.h>

#define ONE_WIRE_BUS 5 // Thermometer Data wire (yellow) is plugged into port ? on the Arduino
#define precision 12 // OneWire precision Dallas Sensor
#define PIN_SENSE 2 //where we connected the fan sense pin. Must be an interrupt capable pin (2 or 3 on Arduino Uno)
#define DEBOUNCE 20 //0 is fine for most fans, fans may require 10 or 20 to filter out noise
#define FANSTUCK_THRESHOLD 500 //if no interrupts were received for 500ms, consider the fan as stuck and report 0 RPM

const int Fan_A_PWM = 9; //PWM (Blue) wire Fan_A_PWM
const int Relay_A = 4; //pin for Relay A
int tempMin = 24;   // the Celsius temperature to start the fan
int tempMax = 30;   // the maximum Celsius temperature when fan is at 100%
unsigned long volatile ts1 = 0, ts2 = 0; //Interrupt handler. Stores the timestamps of the last 2 interrupts and handles debouncing

OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with OneWire device
DallasTemperature sensors(&oneWire); // Pass our oneWire reference to Dallas Temperature.

void tachISR() {
  unsigned long m = millis();
  if ((m - ts2) > DEBOUNCE) {
    ts1 = ts2;
    ts2 = m;
  }
}

unsigned long calcRPM() { //Calculates the RPM based on the timestamps of the last 2 interrupts. Can be called at any time.
  if (millis() - ts2 < FANSTUCK_THRESHOLD && ts2 != 0) {
    return (60000 / (ts2 - ts1)) / 2;
  } else return 0;
}

void setup(void)
{
  pinMode(PIN_SENSE, INPUT_PULLUP); //set the sense pin as input with pullup resistor
  attachInterrupt(digitalPinToInterrupt(PIN_SENSE), tachISR, FALLING); //set tachISR to be triggered when the signal on the sense pin goes low
  Timer1.initialize(40);  // 40 us = 25 kHz
  Serial.begin(9600); // start serial
  sensors.begin(); // Start up the library
  Serial.println("Simple single pwm controlled fan Test");
  pinMode(Relay_A, OUTPUT); //Relay A to switch Fan_A
  Timer1.pwm(Fan_A_PWM, 0);
}

float Read_Sensor_1_Temp() {
  sensors.requestTemperatures(); // Send the command to get temperatures
  Serial.print("Temperature: ");
  Serial.println(sensors.getTempCByIndex(0));
  return sensors.getTempCByIndex(0);
}

void SetFanA () {
  float Sensor_1_Temp = Read_Sensor_1_Temp(); // Request sensor value
  int Speed_Fan_A = map(Sensor_1_Temp, tempMin, tempMax, 200, 1023); // Map (change) the sensor reading of <=1 to >=1023 to a value between 10 and 100
  Serial.print("Fan A Speed: ");
  Serial.print(Speed_Fan_A);
  Serial.println(" ");
  Timer1.setPwmDuty(Fan_A_PWM, Speed_Fan_A); // set the fan speed
  // if the temperature is above the tempMin threshold, turn on Relay_A
  if (Sensor_1_Temp > tempMin) {
    digitalWrite(Relay_A, HIGH);
  } else {
    digitalWrite(Relay_A, LOW);
  }
}

void loop()
{
  SetFanA();
  Serial.print("RPM:");
  Serial.println(calcRPM());
}

Als de fan uitstaat krijg ik nog steeds RPM terug, de gedeelte is wel 0 maar er zit van alles bij.
Zie hier een voorbeeld van verschillende snelheden met de RPM output. Schaal voor het instellen van de snelheid is nu nog 0 - 1023.

RPM	Off	337	748	Full speed
RPM	0	1428	1428	810
RPM	178	1304	1363	810
RPM	0	1428	1428	810
RPM	176	1428	1428	833
RPM	0	1363	1428	810
RPM	19	1304	1428	833
RPM	0	1428	1428	810
RPM	97	1200	1363	810
RPM	44	1304	1363	833

Fan specs:

NF-A20PWM
Rotational speed (+/- 10%)	800 RPM
Rotational speed with L.N.A. (+/- 10%)	550 RPM
Min. rotational speed (PWM, +/-20%)	350 RPM
Airflow	146,9 m³/h
Acoustical noise	18,1 dB(A)
Max. input power	0,96 W
Max. input current	0,08 A
Operating voltage	12 V
Voltage PWM signal	5 V

Zoals je in de specs en output table kan zien, klopt het redelijk op full speed en daar heb ik ook geen probleem mee met die afwijking. Echter waarom klopt er niets van alles wat daarvoor komt? Dat is nu juist hoger als dat de max is...

1 van de dingen die ik gemerkt heb is dat de arduino niet standaard floating point precision toepast.
In mijn code block een paar posts terug kwam ik dat tegen als een trapsgewijs op- en aflopen van de PWM signalen per 6 of 7 units in plaats van vloeiend zoals je zou verwachten.

Met uitzondering van het PWM signaal inlezen (wat ik niet doe, vind ik minder interressant en ik had ook geen zin om het hele interrupt gedeelte er nog bij te trekken) doet onderstaande code volgens mij precies wat je wilt:

code:

#include <OneWire.h>
#include <DallasTemperature.h>
#include <ArduinoJson.h>

const int capacity = JSON_OBJECT_SIZE(2); // Create a json object containing 2 values
StaticJsonDocument<capacity> doc;  // Create a memory document
JsonObject object=doc.to<JsonObject>(); 
char buffer[100]; // Create a memory buffer to store contents for JSON inclusion

float temp = 0.0; // Temperature read from sensor
int outWire = 3;  // Wire to Fan headers
int oneWireBus = 5; // Temperature sensor Pin
OneWire oneWire(oneWireBus); // Onewire Init
DallasTemperature sensors(&oneWire); // Onewire Init
float minTemp = 20.0; // Minimum temp that maps to 0
float maxTemp = 60.0; // Maximum temp that maps to 255
int dutyCycle = 0;

float convertRange(float value, float inputRangeLowerBound, float inputRangeUpperBound, float outputRangeLowerBound, float outputRangeUpperBound) {
  return (value - inputRangeLowerBound) * (outputRangeUpperBound - outputRangeLowerBound) / (inputRangeUpperBound - inputRangeLowerBound) + outputRangeLowerBound;
  
}

void setup(void) {
 pinMode(LED_BUILTIN, OUTPUT); // Disable builtin LED on pin 13
 digitalWrite(LED_BUILTIN, LOW);
 pinMode(outWire, OUTPUT);
 
 object["temp"] = 0.0;
 object["power"] = 0;
 Serial.begin(9600);
 sensors.begin();  
}

void loop(void) {
  sensors.requestTemperatures(); // Request all temperatures from sensor
  temp = sensors.getTempCByIndex(0); // Pick first index from list of sensors
  dutyCycle = convertRange(temp, minTemp, maxTemp, 0.0, 255.0); // Move this to non-integer function
  object["temp"] = temp;
  if (dutyCycle < 50) {
    object["power"] = 0;
    digitalWrite(outWire, LOW);
  } else {
    object["power"] = dutyCycle;
    analogWrite(outWire, dutyCycle);
  }
  serializeJson(doc, buffer);
  Serial.println(buffer);
  
  delay(1000);
}

Ik heb hierbij de map() functie vervangen door een versie die met floating point nummers kan werken zodat ik pas na de berekening een cast naar int hoef te doen.

Dit werkt voor mij prima met 2 fans aangesloten.

[DataGhost]

Dutchess_Nicole schreef op donderdag 12 november 2020 @ 09:08:
[...]


1 van de dingen die ik gemerkt heb is dat de arduino niet standaard floating point precision toepast. [..] Ik heb hierbij de map() functie vervangen door een versie die met floating point nummers kan werken zodat ik pas na de berekening een cast naar int hoef te doen.

Dat staat gewoon beschreven voor de map-functie, die werkt met integer math. FP is sowieso veel duurder dus in de meeste gevallen is dat fijn. Maar in dit geval lijkt me dat niet van toepassing, aangezien alle operands integers zijn, en ze qua orde van grootte (60000 vs 500) ver genoeg uit elkaar liggen zodat integer math nog nauwkeurig genoeg is. Wel expliciet zorgen dat beide datatypes even groot en groot genoeg zijn, dat wil anders nog wel eens gekke resultaten opleveren.

doet onderstaande code volgens mij precies wat je wilt:

Misschien handig om die code te beperken tot het gedeelte wat je precies bedoelt, er staat nu heel veel code die niet nodig is voor je voorbeeld, waardoor het niet superduidelijk is over welk stuk je het precies hebt.

[Dutchess_Nicole]

DataGhost schreef op donderdag 12 november 2020 @ 11:44:
[...]

Dat staat gewoon beschreven voor de map-functie, die werkt met integer math. FP is sowieso veel duurder dus in de meeste gevallen is dat fijn. Maar in dit geval lijkt me dat niet van toepassing, aangezien alle operands integers zijn, en ze qua orde van grootte (60000 vs 500) ver genoeg uit elkaar liggen zodat integer math nog nauwkeurig genoeg is. Wel expliciet zorgen dat beide datatypes even groot en groot genoeg zijn, dat wil anders nog wel eens gekke resultaten opleveren.

Zeker, dat kwam ik dus ook tegen toen ik zocht waarom ik zulke gekke resultaten kreeg uit mijn berekening.
Maar dan moet je daar wel eerst op komen.
Ook snap ik prima waarom dat is, maar wederom, je moet het wel eerst weten om een afweging te maken of het problemen op gaat leveren.

[...]

Misschien handig om die code te beperken tot het gedeelte wat je precies bedoelt, er staat nu heel veel code die niet nodig is voor je voorbeeld, waardoor het niet superduidelijk is over welk stuk je het precies hebt.

Het leek me juist eigenlijk vrij duidelijk: Ik doe geen PWM uitlezen dus dat stuk ontbreekt, en de rest is gewoon het PWM signaal maken en de fans aansturen zoals ik al zei.

[DataGhost]

Ah, dan is daar de onduidelijkheid duidelijk. Waar je PWM uitlezen zegt bedoel je waarschijnlijk RPM-signaal uitlezen, en dat doe je niet in je code terwijl dat juist het deel is wat nu nog niet goed lijkt te werken. @kweetnie gaf namelijk al aan dat het PWM-signaal maken ondertussen prima werkte. Dan nog lijkt me een hele hoop code daarin overbodig, o.a. heel het json-gedeelte, maar dat ben ik.

[kweetnie]

Beide super dank voor de hulp, duurde even wat langer voor reactie. Erg druk op werk en vandaag pas want nieuwe spullen binnen gehad. Nu heb ik alles weer opnieuw aangesloten en nu zijn de metingen redelijk tot goed. Zitten af en toe nog wel wat spikes in maar, de RPM klopt goed en kan ik ook duidelijk het verloop zien. Het werkt dus zoals ik wil, probleem zat hem dus voornamelijk in het breadboard en kabels.

Die spikes die er af en toe zijn, komen vast door mijn code, maar ik heb gewoon echt niet genoeg kennis om te snappen wat ik daaraan moet veranderen om er vanaf te zijn.

Ik ga nu starten met meer temp sensors en fans en kijken of ik dat aan de praat krijg.

Wat ook nog fijn zou zijn, is het laten kloppen en stoppen van de waarde waarmee ik de fans start. En dit vertalen naar gewoon 0-100 ipv de huidige 0-1023. En die zie ik nu ook negatief of ver boven de 1023 gaan wanneer de temp hoger of lager is als de min/max waarde.

Zie als voorbeeld mijn serial output:
Temperature: 19.50
Fan A Speed: -302 <<--- dit zou niet langer als 0 mogen worden
RPM:0

of

Temperature: 31.37
Fan A Speed: 1143 <<--- max zou 1023 moeten zijn...
RPM:810

Nu weet ik dat het misgaat door die mapping die ik heb, maar heb echt geen idee hoe dit aan te passen naar iets dat gewoon netjes binnen de waardes blijft.
Is dat dan via een deel van jou code @Dutchess_Nicole ? met de float convertrange?

[DataGhost]

Als je waarden buiten je verwachte range krijgt gaat natuurlijk geen enkele range-conversie dat voor je oplossen. Je kan prima met die code 0-1023 naar 0-100 mappen, maar met -302 en 1143 heb je gewoon pech. Lijkt erop alsof iets met types niet helemaal goed gaat, maar het kan alsnog aan een berekening liggen. Als de code verder hetzelfde is zou je inderdaad kunnen proberen om die float convertrange te gebruiken om te zien of dat helpt.

[Dutchess_Nicole]

Die Float convertrange functie helpt alleen maar met het feit dat je flexibeler bent in het converteren van numerieke ranges. in mijn geval probeerde ik eerst dus een range van 20-60 graden (40 eenheden) om te zetten naar een range van 0-255 (256 eenheden).

per 1 graad levert dat een verschil van 6 of 7 (afhankelijk van afronding) eenheden in de output op. Dat is wat de float functie oplost.

De arduino toolkit heeft ook een functie genaamd constrain(), zie constrain voor details.
Deze zal een waarde altijd inperken tussen de minimum en maximum die je opgeeft.

Je kan het natuurlijk ook zelf doen door een

code:

if (value < 0) {
  value = 0;
}

if (value > 1023) {
  value = 1023;
}

toe te passen voordat je de value gebruikt.

Constrain is dan misschien wat meer geoptimaliseerd maar dat is min of meer wat het doet.

[DataGhost]

Dutchess_Nicole schreef op maandag 16 november 2020 @ 09:26:
Die Float convertrange functie helpt alleen maar met het feit dat je flexibeler bent in het converteren van numerieke ranges. in mijn geval probeerde ik eerst dus een range van 20-60 graden (40 eenheden) om te zetten naar een range van 0-255 (256 eenheden).

per 1 graad levert dat een verschil van 6 of 7 (afhankelijk van afronding) eenheden in de output op. Dat is wat de float functie oplost.

De arduino toolkit heeft ook een functie genaamd constrain(), zie constrain voor details.
Deze zal een waarde altijd inperken tussen de minimum en maximum die je opgeeft.

Je kan het natuurlijk ook zelf doen door een

code:

if (value < 0) {
  value = 0;
}

if (value > 1023) {
  value = 1023;
}

toe te passen voordat je de value gebruikt.

Constrain is dan misschien wat meer geoptimaliseerd maar dat is min of meer wat het doet.

Ik zou in dit geval niet als eerste optie naar constrain grijpen. Als een waarde buiten de verwachte range valt heeft dat vaak een andere oorzaak. Als jij mij vraagt om het antwoord van 7-5= tussen 0 en 10, ik zeg -2, dan ben jij hopelijk niet tevreden met 0 als uitkomst van constrain.

Edit: my bad, niet helemaal goed gelezen waar die variabele vandaan kwam. In dit geval toch wel de juiste suggestie

[ Voor 4% gewijzigd door DataGhost op 16-11-2020 11:52 ]

[kweetnie]

@DataGhost Nee het is geen pech of fout in de code. Het klopt gewoon, maar ik wil het "afvlakken" dus dat het niet verder omlaag kan ook al is de temp lager. En niet verder omhoog als de temp hoger is. Overigens is het maar een controle waarde die ik nu tijdelijk wil zien, of de fan netjes in stappen omhoog/omlaag gaat op basis van de temp. Staat alleen niet netjes als die steeds op negatieve of te hoge waardes uitkomt. Maar met de input van Dutchess ga ik een heel eind komen.

@Dutchess_Nicole Top dank je voor die uitleg, ga ik mee aan de slag!

[kweetnie]

In dit geval maakt het niet uit, lager als 0 is nog steeds dezelfde fan speed. En datzelfde bij een hogere temp als de max. De max fanspeed is gewoon 1023, dus van mij mag die waarde blijven hangen op 1023 ook al is het in volgens de mapping 1500. Dat doet namelijk niets af aan de fanspeed die kan toch niet harder.

Dus is het meer om de output leesbaar te houden en te weten wanneer draait het op max en wanneer op min.

[DataGhost]

kweetnie schreef op maandag 16 november 2020 @ 11:34:
@DataGhost Nee het is geen pech of fout in de code. Het klopt gewoon, maar ik wil het "afvlakken" dus dat het niet verder omlaag kan ook al is de temp lager. En niet verder omhoog als de temp hoger is. Overigens is het maar een controle waarde die ik nu tijdelijk wil zien, of de fan netjes in stappen omhoog/omlaag gaat op basis van de temp. Staat alleen niet netjes als die steeds op negatieve of te hoge waardes uitkomt. Maar met de input van Dutchess ga ik een heel eind komen.

@Dutchess_Nicole Top dank je voor die uitleg, ga ik mee aan de slag!

Ah, juist, dan is constrain precies wat je zoekt inderdaad

kweetnie schreef op maandag 16 november 2020 @ 11:37:
In dit geval maakt het niet uit, lager als 0 is nog steeds dezelfde fan speed. En datzelfde bij een hogere temp als de max. De max fanspeed is gewoon 1023, dus van mij mag die waarde blijven hangen op 1023 ook al is het in volgens de mapping 1500. Dat doet namelijk niets af aan de fanspeed die kan toch niet harder.

Dus is het meer om de output leesbaar te houden en te weten wanneer draait het op max en wanneer op min.

Je wilt altijd dat je input klopt, helemaal als je dingen in registers schrijft. Negatieve getallen kunnen interessante bijwerkingen hebben. Als je -302 in een 16-bits unsigned register stopt wat gebruikt wordt voor een duty-cycle, ziet de processor daar 65234 staan en aangezien dat groter is dan 1023 kan ik me een 100% duty cycle als gevolg voorstellen. Als alleen naar 10 bits van het register gekeken wordt dan lijkt het alsof er 722 in staat, ongeveer 70%. Ondertussen verwacht jij 0%.
Als je een library gebruikt heb je kans dat die het voor je oplost, als die wel signed variabelen gebruikt, anders zal min of meer hetzelfde gebeuren maar krijg je hopelijk wel een warning van de compiler.

[ Voor 46% gewijzigd door DataGhost op 16-11-2020 11:54 ]

[Raven]

Weet iemand toevallig hoe je de trailing zero uit een variabele kan halen wanneer deze variabele wordt gebruikt in een html pagina? Google en de Arduino docs en forum geven wel hits, maar in de vorm van

C++:

Serial.print(val, format)

en laat serial.print nou niet gebruikt worden.

Het gaat om de DHT sketch die de waarden op deze manier op een webpagina weergeeft:

C++:

String SendHTML(float Temperaturestat,float Humiditystat){
  String ptr = "<!DOCTYPE html> <html>\n";
  ptr +="<head><meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0, user-scalable=no\">\n";
  ptr +="<title>ESP8266 Weather Report</title>\n";
  ptr +="<style>html { font-family: Helvetica; display: inline-block; margin: 0px auto; text-align: center;}\n";
  ptr +="body{margin-top: 50px;} h1 {color: #444444;margin: 50px auto 30px;}\n";
  ptr +="p {font-size: 24px;color: #444444;margin-bottom: 10px;}\n";
  ptr +="</style>\n";
  ptr +="</head>\n";
  ptr +="<body>\n";
  ptr +="<div id=\"webpage\">\n";
  ptr +="<h1>Woonkamer</h1>\n";
  
  ptr +="<p>Temperature: ";
  ptr +=Temperaturestat;
  ptr +="&degC</p>";
  ptr +="<p>Humidity: ";
  ptr +=Humiditystat;
  ptr +="%</p>";
  
  ptr +="</div>\n";
  ptr +="</body>\n";
  ptr +="</html>\n";
  return ptr;
}

[Septillion]

code:

ptr += String(Temperaturestat, decimalPlaces);

Als Temperaturestat een float is en je het aantal decimalen bedoelt. Daar "trailing zero's" bij een decimaal niet bestaan

[ Voor 31% gewijzigd door Septillion op 20-11-2020 12:06 ]

[SuperKris]

Raven schreef op vrijdag 20 november 2020 @ 11:49:
Weet iemand toevallig hoe je de trailing zero uit een variabele kan halen wanneer deze variabele wordt gebruikt in een html pagina? Google en de Arduino docs en forum geven wel hits, maar in de form van

C++:

Serial.print(val, format)

en laat serial.print nou niet gebruikt worden.

Het gaat om de DHT sketch die de waarden op deze manier op een webpagina weergeeft:

C++:

String SendHTML(float Temperaturestat,float Humiditystat){
  String ptr = "<!DOCTYPE html> <html>\n";
  ptr +="<head><meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0, user-scalable=no\">\n";
  ptr +="<title>ESP8266 Weather Report</title>\n";
  ptr +="<style>html { font-family: Helvetica; display: inline-block; margin: 0px auto; text-align: center;}\n";
  ptr +="body{margin-top: 50px;} h1 {color: #444444;margin: 50px auto 30px;}\n";
  ptr +="p {font-size: 24px;color: #444444;margin-bottom: 10px;}\n";
  ptr +="</style>\n";
  ptr +="</head>\n";
  ptr +="<body>\n";
  ptr +="<div id=\"webpage\">\n";
  ptr +="<h1>Woonkamer</h1>\n";
  
  ptr +="<p>Temperature: ";
  ptr +=Temperaturestat;
  ptr +="&degC</p>";
  ptr +="<p>Humidity: ";
  ptr +=Humiditystat;
  ptr +="%</p>";
  
  ptr +="</div>\n";
  ptr +="</body>\n";
  ptr +="</html>\n";
  return ptr;
}

Ik weet niet precies wat je vraagt, maar als je het aantal cijfers van float achter de komma van een serial print wil bepalen dan doe je dat door het aantal cijfers achter de komma de benoemen:

https://www.arduino.cc/re...mmunication/serial/print/

Als ik mij niet vergis is het standaard 2 als je dit niet verder aangeest.

[Raven]

Septillion schreef op vrijdag 20 november 2020 @ 12:04:

code:

ptr += String(Temperaturestat, decimalPlaces);

Als Temperaturestat een float is en je het aantal decimalen bedoelt. Daar "trailing zero's" bij een decimaal niet bestaan

Was misschien handig geweest als ik dat had gemeld , float en 2 cijfers achter de komma, waarbij de laatste altijd 0 is en die 0 wil ik kwijt. Zal die optie van jou straks eens proberen.

edit: @Septillion Dat werkt, thanks

SuperKris schreef op vrijdag 20 november 2020 @ 12:07:
[...]


Ik weet niet precies wat je vraagt, maar als je het aantal cijfers van float achter de komma van een serial print wil bepalen dan doe je dat door het aantal cijfers achter de komma de benoemen:

https://www.arduino.cc/re...mmunication/serial/print/

Als ik mij niet vergis is het standaard 2 als je dit niet verder aangeest.

De webpagina laat 2 getallen achter de komma zien, waarbij de laatste altijd 0 is, die wil ik kwijt. Als het nou voor op de console was, dan had ik Serial.print(var, 1) kunnen gebruiken om er vanaf te komen, maar dat is niet het geval.

[Blomminator]

Ik heb jaren geleden heel kort een Uno gespeeld, maar verdween snel weer.
Bleef toch kriebelen, dus vorige week een StarterKit opgepikt.

Nu wil ik meten;
- gps locatie
- barometrische druk (voor hoogtemeters)
- temp

Daarna:
- wegschrijven via simkaart naar website
- indien geen netwerk, dan opslaan op sd-card

De hele bende in een klein doosje, en dan op batterijen, in de auto/rugtas. Zodat ik kan tracken waar ik was.

Nu ik dus pas 4 dagen bezig ben, is dit allemaal vrij veel.
De temp.sensor geeft wel keurig de temp weer op t schermpje, daar ben ik al erg blij mee.
Is het slimmer om 1 board te kopen met alles erin, of juist losse boards. En waar moet je zoal op letten bij een board scoren?

[Septillion]

@Blomminator Dat is een aardig ambitieus eerste project.

Voor development is het denk ik alleen maar handig dat alles los is. Maar als device later natuurlijk wat minder (maar hoeft geen probleem te zijn qua functie). Maar ik denk niet dat je zomaar een bord gaat vinden dat alles heeft wat je wilt. Dan zal je zelf een bord moeten maken. Je zou echt een PCB kunnen laten maken of je gaat aan de slag met experimenteer print. Laatste zou je voor nu ook al kunnen doen maar lijkt het me handig als je het zo maakt dat de individuele modules er nog af kunnen.

[Blomminator]

@Septillion Jup, de lat ligt weer hoog. Maar goed, go big or home!

Thnx, ik ga gewoon eea bestellen dan, want een board kan straks wisselen indien nodig. Zelf een PCB maken klinkt nog wel weer een stap verder.

[AteGjalt]

@Blomminator je kan eens kijken of een Seeed Studio LinkIt ONE voldoet, heeft ingebouwde GSM en GPRS dus scheelt iig weer een paar modules.
https://www.conrad.nl/p/s...entboard-arm7ej-s-1295555

[Klein_Kipje]

Neewbee hier,

Kan iemand me helpen met het volgende:

Ik heb een IF met drie voorwaarden.

IF 1 = high or 2 is high AND 3 is high then...

het is dus 1 of 2 en drie

Is dit de 'goede zin'

code:

 if (buttonState1 == HIGH || buttonstate2==HIGH && buttonState3 == HIGH) {

of euh ?

[InTheDisorder]

Je kan de 2e condition tussen haakjes zetten:

code:

 if (buttonState1 == HIGH || (buttonstate2==HIGH && buttonState3 == HIGH))

[mcDavid]

Klein_Kipje schreef op zondag 20 december 2020 @ 15:22:
Neewbee hier,

Kan iemand me helpen met het volgende:

Ik heb een IF met drie voorwaarden.

IF 1 = high or 2 is high AND 3 is high then...

het is dus 1 of 2 en drie

Is dit de 'goede zin'

code:

 if (buttonState1 == HIGH || buttonstate2==HIGH && buttonState3 == HIGH) {

of euh ?

Zowel je pseudo-code, je Nederlandse zin als je echte code zijn allemaal even ambigue.

De compiler zal er in dit geval `(a) || (b && c)` van maken, omdat && een hogere precedence heeft. Of dat het gedrag is wat je wilt is dus onduidelijk. Over het algemeen wordt het als "good practice" beschouwd om in dit soort situaties áltijd haakjes toe te passen, dan sluit je verkeerde volgordelijkheid helemaal uit en is bovendien direct duidelijk wat de bedoeling is.

[Klein_Kipje]

Zal het proberen beter uit te leggen

Ik heb een motor - vooruit / achter uit
2 drukknoppen voor vooruit A1 en A2, 2 voor achteruit B1 en B2. 2 eindschakelaars.C1 en C2

Als er op A1 OF A2 wordt gedrukt EN B1 en B2 en C1 is LOW moet de motor vooruit lopen.

Vandaar de vraag voor de IF statement met meerdere voorwaarden

[AteGjalt]

In dat geval wordt t
if ((A1=high || A2==high) && B1==high && B2==high && C1 == low)
{
//motor vooruit
}

Snap alleen niet goed waarom je 2 knoppen voor zowel voor- als achteruit hebt...

[Klein_Kipje]

AteGjalt schreef op zondag 20 december 2020 @ 23:54:
In dat geval wordt t
if ((A1=high || A2==high) && B1==high && B2==high && C1 == low)
{
//motor vooruit
}

Snap alleen niet goed waarom je 2 knoppen voor zowel voor- als achteruit hebt...

Een fysieke en 1 via een wemos D1.

[teaser]

Moet het dan niet zijn:

Klein_Kipje schreef op zondag 20 december 2020 @ 18:50:
Als er op A1 OF A2 wordt gedrukt EN B1 of B2 EN C1 is LOW moet de motor vooruit lopen.

In code dus:
if ((A1=high || A2==high) && (B1==high || B2==high) && C1 == low)

[AteGjalt]

Ik heb geen nachtbrein meer en er is een veel handigere manier om de motor te regelen: gebruik een mode met switch case
https://www.arduino.cc/re...rol-structure/switchcase/

Mode 0 = stop, 1 = vooruit, 2 = achteruit.
If ((A1=high || A2=high) && C1 = low){
Mode = 1; // vooruit
}
else If ((B1=high || B2=high) && C2 = low){
Mode = 2; // achteruit
}
else{
Mode = 0; //stop
}
If (Mode = 1 && C1 = high){
Mode = 0; // stop
}
If (Mode = 2 && C2 = high){
Mode = 0; // stop
}

[DataGhost]

Klein_Kipje schreef op zondag 20 december 2020 @ 18:50:
Zal het proberen beter uit te leggen

Ik heb een motor - vooruit / achter uit
2 drukknoppen voor vooruit A1 en A2, 2 voor achteruit B1 en B2. 2 eindschakelaars.C1 en C2

Als er op A1 OF A2 wordt gedrukt EN B1 en B2 en C1 is LOW moet de motor vooruit lopen.

Vandaar de vraag voor de IF statement met meerdere voorwaarden

Zoals vaker gezegd, bij twijfel altijd haakjes gebruiken. Dat maakt het later ook leesbaarder voor jou. Ondertussen weet je zelf je probleem nog niet goed te beschrijven in het Nederlands dus voordat je met het combineren van verschillende conditionele operators aan de slag gaat lijkt het me handig om het eerst duidelijker te krijgen voor een ander, zonder dat er tig verschillende posts om opheldering vragen. Als ik je stelling lees kan ik op verschillende plekken komma's plaatsen

Als er op A1 OF A2 wordt gedrukt EN B1 en B2 en C1 is LOW moet de motor vooruit lopen.
Als er op A1 OF A2 wordt gedrukt, EN B1 en B2 (wordt gedrukt), en C1 is LOW moet de motor vooruit lopen.
Als er op A1 OF A2 wordt gedrukt EN B1, en B2 en C1 zijn beide LOW moet de motor vooruit lopen.
Als er op A1 OF A2 wordt gedrukt EN B1 en B2 en C1 zijn alledrie LOW moet de motor vooruit lopen.

Vast nog meer te verzinnen. Als je dit helder hebt is de code vaak een 1:1 vertaling daarvan.

[D-Three]

Hang de knoppen fysiek parallel?

[Klein_Kipje]

DataGhost schreef op maandag 21 december 2020 @ 19:12:
[...]

Zoals vaker gezegd, bij twijfel altijd haakjes gebruiken. Dat maakt het later ook leesbaarder voor jou. Ondertussen weet je zelf je probleem nog niet goed te beschrijven in het Nederlands dus voordat je met het combineren van verschillende conditionele operators aan de slag gaat lijkt het me handig om het eerst duidelijker te krijgen voor een ander, zonder dat er tig verschillende posts om opheldering vragen. Als ik je stelling lees kan ik op verschillende plekken komma's plaatsen

Als er op A1 OF A2 wordt gedrukt EN B1 en B2 en C1 is LOW moet de motor vooruit lopen.
Als er op A1 OF A2 wordt gedrukt, EN B1 en B2 (wordt gedrukt), en C1 is LOW moet de motor vooruit lopen.
Als er op A1 OF A2 wordt gedrukt EN B1, en B2 en C1 zijn beide LOW moet de motor vooruit lopen.
Als er op A1 OF A2 wordt gedrukt EN B1 en B2 en C1 zijn alledrie LOW moet de motor vooruit lopen.

Vast nog meer te verzinnen. Als je dit helder hebt is de code vaak een 1:1 vertaling daarvan.

Goed punt, als je het zelf typt is het meer dan logisch maar dat is iid niet altijd zo voor de lezer.

Het is de onderste
Als er op A1 OF A2 wordt gedrukt EN B1 en B2 en C1 zijn alledrie LOW moet de motor vooruit lopen.

uitleg over het project is af en toe ook makkelijk om het makkelijker te maken.

als er op A1 of A2 gedrukt wordt moet de motor vooruit lopen, als er dan 'per ongeluk' tegelijk op B1 of B2 gedrukt wordt moet de motor stoppen.

C1 is een eindschakelaar, de motor mag/moet lopen lopen tot C1 high wordt

[Klein_Kipje]

D-Three schreef op maandag 21 december 2020 @ 21:20:
Hang de knoppen fysiek parallel?

Nee

[mcDavid]

In dit soort situaties raad ik aan eerst je waarheden aan variables toe te kennen. Bijv:

code:

Bool forward = input_1 || input_2
Bool backward = input_3 || input_4

Vervolgens wordt je vergelijking een heel stuk overzichtelijker:

code:

If (forward && !backward) {
  //do something
}

Doordat je States een naam gekregen hebben zie je in één oogopslag wat de logica doet.

[Erasmo]

Ik geef af en toe Arduino les aan een klasje, weet iemand nog leuke projecten? Ondertussen zijn we al bijna door de starterskit boekjes heen.

Heb al zelf een opdracht gemaakt die een zonnetracker maakt op basis van LDR's en servo's maar wellicht heeft iemand hier nog wat leuks gemaakt onlangs.

[roeleboel]

Ik heb een ventilatiesysteem dat ik kan aansturen door een 3-standenschakelaar.

Ik had al bedacht dat ik dit kan nabootsen door 2 relais te gebruiken, maar dan heb je altijd het risico dat je via een softwarefout de 2 tegelijk aanzet.

Bestaat iets in die aard dat ik via arduino softwarematig kan aansturen?
En zo ja: op welke (engelstalige) term moet ik zoeken? Of is de 'standaard oplossing' hier toch 2 relais gebruiken? 'driestandenschakelaar arduino' levert helaas niets bruikbaars op...

[DataGhost]

Software is niet magisch, het beschrijft juist heel precies wat er gebeurt. Als je simpele functies schrijft voor uit(), stand1() en stand2() (waarbij stand1 en stand2 beginnen met een call naar uit() als eerste) en vervolgens alleen maar die functies gebruikt, kan er eigenlijk niet heel veel mis gaan. Ja, als een relais is vastgesmolten in "aan" maar dan heb je andere issues.

Als je DPDT relais gebruikt kan je dit nog verder beveiligen, door de relais op elkaars ene pool aan te sluiten aan NC, en je load op de andere pool aan NO. Als je het ene relais dan aanzet, onderbreek je dus de mogelijkheid dat er spanning op het andere relais komt te staan, ook al doet je software het fout.

Quick and very dirty is dit wat ik bedoel. Dat is overigens gewoon een extraatje qua "beveiliging" want niks is instantaan dus er zal nog best een kort moment kunnen zijn dat beide relais bekrachtigd zijn. Je minimaliseert dat moment hiermee, maar je moet er in je software al voor zorgen dat het nooit kan gebeuren. Ehhh, het zou hiermee zelfs kunnen gaan oscilleren denk ik maar dan moet je wel heel goed timen.

[ Voor 29% gewijzigd door DataGhost op 18-01-2021 14:18 ]