abonnement Unibet Coolblue
  donderdag 26 mei 2022 @ 15:48:02 #1
47760 Grote_Swets
En groot is tie....
pi_204871834
Ik heb op mijn CNC machine zo'n Ebay 15watt led laser gebouwd.
Deze laser kan je PWM aan sturen...

Misschien , ik weet niet of het mag? maar kan je eerst even dit bekijken: https://www.arjan-swets.com/hardware/cnc/Laser/laser_intro.html

De meeste mensen sturen zo'n laser alleen aan/uit, maar ik wilde ook met het via PWM spelen.

Dus ik heb in een Arduino Due het eerste onderstaande programma staan.

Met de input "Mode"kan ik kiezen tussen Aan/Uit mode of de PWM mode.
in de Aan/Uit mode, komt er een 2de input binnen op de Arduino, van uit de CNC besturing, welke hoog word als de Laser aan moet.
De Arduino stuurt dan PWM255 naar de Laser, en als de input laag word, stuurt hij PWM 0 naar de laser...

In de PWM mode, kijk de arduino naar 2 inputs. een step en een Dir input.
De arduino gedraagt zich zeg maar als een stepperdriver. en gebruikt die 2 inputjes om de PWM waarden naar de laser op of af te tellen, en kan ik dus vanuit me cnc besturing de sterkte van de laser regelen.

ik maak een toolpad, waar ik wit = 0 mm diep, en waar zwart 0,00255 mm diep is, de Cam software verdeelt de grijstinten van een bitmap in 255 stapjes...
als ik dit toolpad niet naar de z-as (op/Neer) stuur, maar naar de Arduino stuur kan ik dus een foto branden in hout.

Dit hele verhaal werkt!! want je ook op de bovenstaande link kan zien.

Er is alleen een Probleem... het branden van een Laser in hout is natuurlijk niet erg lineair.. dus Als ik de laser PWM 1 stuurt, brand hij natuurlijk nog geen licht grijs lijntje....
Dus later kwam ik er achter dat de laser (afhankelijk van het materiaal natuurlijk) pas wat begint te doen bij PWM 64... en dat als je eenmaal over een bepaalde waarden ga, je ook geen verschil meer zie, laat ik hier even zeggen 128, maar nogmaals dat is heel erg afhankelijk waar je op brand).

Dit heb ik eerst geprobeerd op andere plekken goed te krijgen.... In de cam software, maar dat was moeilijk... ik heb ook met Photoshop geprobeerd een bitmap omt te zetten naar 255 grijstinten, maar dan dat zwart geen 0 is, maar 64 ofzo...
Heb ook heel veel rond gevraagd en gezocht... eigenlijk niets makkelijks kunnen vinden....

En opeens dacht ik, waarom doe ik het niet in de arduino...

Dus het verhaal is eigenlijk, de CNC software stuurt nog steeds dmv de step/dir puls 0 tot 255 naar de arduino,
maar in plaats dat ik deze waarde 1 op 1 door stuur naar de PWM moet ik hem verschalen....

Dus ik zat te denken, om dmv 2 potmeters een Min en een max output in te stellen...
Dat 2de programma (de nog in testfase versie) staat er als 2de...

Ook dit werkt... (althans in de simulator)


Alleen, ik wil dit hele verhaal zo snel mogelijk hebben... Ik wil niet dat ik stappen ga missen met de CNC machine?

Ik heb begrepen dat dat rekenen met Float getallen heel erg traag kan zijn?
maar blijft het pulsen op de interrupts dan nog wel gewoon goed gaan?

wat die teller mag eigenlijk niet gek doen....

Dus? wie kan er meer vertellen? helpen, mee denken enz enz....

Alvast bedankt!!!!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
int  PWM_Out  =  64 ; 
int  CounterValue  =  1 ; 
int  StepPin  =  7 ; 
int  DirPin  =  8 ; 
int  Mode  =  3 ; 
int  OnOff  =  2 ; 
int  Laser  =  9 ;
 
void  setup ( ) 

  pinMode ( DirPin ,  INPUT_PULLUP ) ; 
  pinMode ( StepPin ,  INPUT_PULLUP ) ; 
  pinMode ( Mode ,  INPUT_PULLUP ) ; 
  pinMode ( OnOff ,  INPUT_PULLUP ) ;
 
  analogWriteResolution ( 8 ) ; 
  pinMode ( Laser ,  OUTPUT ) ;
 
  attachInterrupt ( digitalPinToInterrupt ( StepPin ) ,  Count ,  RISING ) ; 
  attachInterrupt ( digitalPinToInterrupt ( DirPin ) ,  ChangeDir ,  CHANGE ) ; 
 
void  loop ( )  { 
  if  ( digitalRead ( Mode )  ==  HIGH ) 
  { 
    if  ( digitalRead ( OnOff )  ==  HIGH ) 
    { 
      PWM_Out  =  254 ; 
    } 
    else
    { 
      PWM_Out  =  0 ; 
    } 
  } 
  analogWrite ( Laser ,  PWM_Out ) ; 
 
void  Count ( ) 

  PWM_Out  =  PWM_Out  +  CounterValue ; 
  if  ( PWM_Out  >  254 ) 
  { 
    PWM_Out  =  254 ; 
  } 
  if  ( PWM_Out  <  0 ) 
  { 
    PWM_Out  =  0 ; 
  } 
}
 
void  ChangeDir ( ) 

  CounterValue  =  1 ; 
  if  ( digitalRead ( DirPin ) ) 
  { 
    CounterValue  =  -1 ; _ } }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
int PWM_Out = 64;
int tmpPWM_Out;
int CounterValue = 1;
 
int InHigh = 255;
int InLow = 0;
 
int OutputHigh = 128;
int OutputLow = 64;
 
int tmp1;
int tmp2;
float tmp3;
int tmp4;
float tmp5;
 
// in - outputs
int StepPin = 7;
int DirPin = 8;
int Mode = 3;
int OnOff = 2;
int ScaleOn = 5;
int Laser = 9;
 
void setup()
{
  pinMode(DirPin, INPUT_PULLUP);
  pinMode(StepPin, INPUT_PULLUP);
  pinMode(Mode, INPUT_PULLUP);
  pinMode(OnOff, INPUT_PULLUP);
 
  pinMode(ScaleOn, INPUT_PULLUP);
 
  analogWriteResolution(8);
  pinMode(Laser, OUTPUT);
 
  // interrupts on de Step an Dir inputs
  // try to make it as fast as posible, because we don't want to miss steps
  // maybe the Dir input on a normal input is Better?
 
  attachInterrupt(digitalPinToInterrupt(StepPin), Count, RISING);
  attachInterrupt(digitalPinToInterrupt(DirPin), ChangeDir, CHANGE);
}
 
void loop() {
  if (digitalRead(Mode) == HIGH)            // on/off mode on
 
    // if the On/Off mode is active, we are not sending step and Dir pulses
    // so Count and ChangeDir are never called
  {
    if (digitalRead(OnOff) == HIGH)         // on off input
    {
      PWM_Out = 254;
    }
    else
    {
      PWM_Out = 0;
    }
  }
 
  if (digitalRead(ScaleOn) == HIGH)        // Scale fubction on
  {
 
    //  RealActualValue:=( ( ( OutputHigh - OutputLow ) / ( InHigh - InLow ) ) * (r_Raw-InLow)) + OutputLow;
 
    tmp1 = OutputHigh - OutputLow; // = 128 - 64
    tmp2 = InHigh - InLow; // = 255-0
    tmp3 = (float) tmp1 / (float) tmp2;
    tmp4 = PWM_Out - InLow;
 
    tmp5 = tmp3 * (float)tmp4;
 
    tmpPWM_Out = (int)tmp5 + OutputLow;
 
  }
  else                                    // Scale fubction off
  {
    tmpPWM_Out = PWM_Out;
  }
 
  analogWrite(Laser, tmpPWM_Out);        // real output to laser
}
 
void Count()
{
  PWM_Out = PWM_Out + CounterValue;     // step pulse input on the rising edges Interrupt
  if (PWM_Out > 254)
  {
    PWM_Out = 254;
  }
  if (PWM_Out < 0)
  {
    PWM_Out = 0;
  }
}
 
void ChangeDir()
{
  CounterValue = 1;                  // Dir input
  if (digitalRead(DirPin))
  {
    CounterValue = -1;
  }
}


[ Bericht 0% gewijzigd door Grote_Swets op 26-05-2022 15:52:19 (schrijffout) ]
  donderdag 26 mei 2022 @ 16:40:18 #2
47760 Grote_Swets
En groot is tie....
pi_204872182
tmpPWM_Out = map(PWM_Out, 0, 255, OutputLow, OutputHigh);

vind net (online) de map fuctie... volgens mij doet dat het zelfde....
weet alleen niet of dat sneller is?
pi_204872715
Los even op @FlippingCoin
pi_204872885
Dus je hele vraagstuk komt neer op een functie die een 0...255 mapt naar een aantal pulsen die respondeert met een grijstint?


Wat gaat er nu mis? Om de snelheid van floating point arithmetics hoef je jezelf geen zorgen te maken lijkt mij, kan mij niet voorstellen dat dit de eventuele bottleneck zou vormen.

Heb je al een werkende versie gehad?
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
pi_204875617
quote:
0s.gif Op donderdag 26 mei 2022 16:40 schreef Grote_Swets het volgende:
tmpPWM_Out = map(PWM_Out, 0, 255, OutputLow, OutputHigh);

vind net (online) de map fuctie... volgens mij doet dat het zelfde....
weet alleen niet of dat sneller is?
Je kan de map functie gebruiken, of je kan gewoon de volgorde van je bewerkingen aanpassen: eerst de vermenigvuldiging uitvoeren, dan pas de deling: dan verlies je enkel de cijfers achter de komma.

bvb: 49/50*60:
in float: 58.8, en daarna (int)58.8 ---> 58
als je het in integers uitrekent:
49/50*60 --> 0*60 ---> 0
49*60/50 --> 2940/50 ---> 58

Dat je een Due gebruikt maakt het makkelijker (die gebruikt vier bytes voor een int, meer dan genoeg)

tmp1 = OutputHigh - OutputLow; // = 128 - 64
tmp2 = PWM_Out - InLow;
tmp3 = tmp1 * tmp2;
tmp4 = InHigh - InLow; // = 255-0
tmp5 = tmp3 / tmp4;
tmpPWM_Out = tmp5 + OutputLow;

of simpelweg:
tmpPWM_Out= OutputLow + (OutputHigh - OutputLow) * (PWM_Out - InLow) / (InHigh - InLow);

Branden van grijswaarden op hout is lastig. Had zelf een laserbrander in elkaar geknutseld met delen van twee oude flatbed scanners, een arduino uno (met SD Card adapter) en een blauwe 1.8W laserdiode. De afbeelding stond op de SD card, en werd lijn per lijn geschreven (wat erg lang duurde).
Branden van tekst of zwart-wit tekeningen en patronen ging perfect, maar grijstinten...
Probleem is dat het hout (voor zichtbaar licht) niet overal even donker is, de lichtere delen reflecteren veel laserlicht, de donkere delen minder, die absorberen dus meer energie, waardoor ze sneller opwarmen en sneller verkolen. En eens ze verkolen (zwart worden) absorberen ze de energie bijna volledig, waardoor ze nog sterker opwarmen.

Bij "grijze" pixels was dat overduidelijk: iets lichter hout werd bij bvb 10 ms belichting slechts lichtgrijs, terwijl iets donkerder hout na 8 ms reeds zwart was.
Maw, de grijstinten versterkten vooral het contrast dat in het hout aanwezig was. Ander probleem was dat de lijnen iets overlapten (afstand tussen twee lijnen was 0.17 mm, maar een zwart gebrande lijn was iets breder dan 0.17 mm). Dus bij het branden van de volgende lijn was het hout op die plaatsen reeds donkerder dan elders en brandde dus veel sneller in.

Ik dacht dat ik het misschien kon verhelpen met feedback: had 2 fotodiodes (één voor zichtbaar licht, één voor infrarood, maw hitte) aan de laser bevestigd (gericht op het hout), om laserduur te bepalen op basis van de gemeten lichtsterkte (hoe hoger, hoe meer reflectei van de laser, hoe langer belichten) of hittestraling (laser stoppen wanneer een bepaalde waarde bereikt wordt) , maar heb er daarna niets meer mee gedaan (had enkele onderdelen voor een ander project nodig).

Misschien zou het met een infrarood laser beter gaan, ik kon nergens een absorptiespectrum van hout vinden maar best mogelijk dat infrarood veel minder gereflecteerd wordt.
Ich glaube, dass es manchmal nicht genügend Steine gibt und
Ich bin mir sicher, dass auch schöne Augen weinen
  donderdag 26 mei 2022 @ 23:42:21 #6
47760 Grote_Swets
En groot is tie....
pi_204876749
quote:
16s.gif Op donderdag 26 mei 2022 17:47 schreef FlippingCoin het volgende:
Dus je hele vraagstuk komt neer op een functie die een 0...255 mapt naar een aantal pulsen die respondeert met een grijstint?

Wat gaat er nu mis? Om de snelheid van floating point arithmetics hoef je jezelf geen zorgen te maken lijkt mij, kan mij niet voorstellen dat dit de eventuele bottleneck zou vormen.

Heb je al een werkende versie gehad?
Ik heb nu het onderstaande: en in de simulator werkt het....
dus mach3 stuur dmv 2 outputs (step en dir) de PWM counter op en neer...

En via de map function ( toch wel makkelijker als mijn zelf gemaakt map functie, die het trouwens wel gewoon deed)

dus alles werkt....

maar wat er meer door mijn hoofd speelt, hoe snel is het allemaal....
ik wil eigenlijk niet, dat het verhaal pulsen gaat missen vanuit de CNC besturing...
Vandaar dat ik de Step/Dir input al op een interrupt heb zitten....

Het eerste verhaal, zonder de map, of mijn eigen gemaakte scale som , werkte goed...
.

Ik heb eigen geen idee hoe de arduino Due omgaat met dit soort funlties...

ik zou ook even moeten kijken hoesnel de pulsjes zijn van uit de CNC-controller, die hij bij moet houden...
maar dat zit toch wel ergens tussen de 35 a 75 K...

Dus de vraag is meer gaat hij het bijhouden... ?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
int PWM_Out = 64;
int tmpPWM_Out;
int Direction = 1;

int InHigh = 255;
int InLow = 0;

int OutputHigh;
int OutputLow;

// in - outputs
int StepPin = 7;
int DirPin = 8;
int Mode = 3;
int OnOff = 2;
int ScaleOn = 5;
int AnalogLow = A0;           // potentiometer wiper (middle terminal) connected to analog pin 3
int AnalogHigh = A1;          // potentiometer wiper (middle terminal) connected to analog pin 3
int Laser = 9;

void setup()
{
  pinMode(DirPin, INPUT_PULLUP);
  pinMode(StepPin, INPUT_PULLUP);
  pinMode(Mode, INPUT_PULLUP);
  pinMode(OnOff, INPUT_PULLUP);

  pinMode(ScaleOn, INPUT_PULLUP);

  analogWriteResolution(8);
  pinMode(Laser, OUTPUT);

  // interrupts on de Step an Dir inputs
  // try to make it as fast as posible, because we don't want to miss steps
  // maybe the Dir input on a normal input is Better?
  attachInterrupt(digitalPinToInterrupt(StepPin), Count, RISING);
  attachInterrupt(digitalPinToInterrupt(DirPin), ChangeDir, CHANGE);

  if (digitalRead(DirPin))  // Dir input
  {
    Direction = -1;
  }

}

void loop() {
  if (digitalRead(Mode) == HIGH)                                                                // on/off mode on

    // if the On/Off mode is active, we are not sending step and Dir pulses
    // so Count and ChangeDir are never called
  {
    if (digitalRead(OnOff) == HIGH)                                                             // on off input
    {
      PWM_Out = 255;
    }
    else
    {
      PWM_Out = 0;
    }
  }

  if (digitalRead(ScaleOn) == HIGH)                                                             // Scale fubction on
  {
    OutputLow = analogRead(AnalogLow) / 4;
    OutputHigh = analogRead(AnalogHigh) / 4;
    tmpPWM_Out = map(PWM_Out, 0, 255, OutputLow, OutputHigh);                                   // scale wanted value between 2 potmeter setpoints..
  }
  else                                                                                          // Scale fubction off
  {
    tmpPWM_Out = PWM_Out;
  }

  analogWrite(Laser, PWM_Out);                                                                  // real output to laser
}

void Count()
{
  PWM_Out = PWM_Out + Direction;                                                                // step pulse input on the rising edges Interrupt
  if (PWM_Out > 255)
  {
    PWM_Out = 255;
  }
  if (PWM_Out < 0)
  {
    PWM_Out = 0;
  }
}

void ChangeDir()
{
  Direction = 1;                                                                              // Dir input on a change interrupt
  if (digitalRead(DirPin))
  {
    Direction = -1;
  }
}


[ Bericht 0% gewijzigd door Grote_Swets op 27-05-2022 00:08:15 (schrijffout) ]
pi_204876793
quote:
0s.gif Op donderdag 26 mei 2022 23:42 schreef Grote_Swets het volgende:

[..]
Ik heb nu het onderstaande: en in de simulator werkt het....
dus mach3 stuur dmv 2 outputs (step en dir) de PWM counter op en neer...

En via de map function ( toch wel makkelijk als mijn zelf gemaakt map fuctie, die het trouwens wel gewoon deed)

dus alles werkt....

maar wat er meer door mijn hoofd speelt, hoe snel is het allemaal....
ik wil eigenlijk niet, dat het verhaal pulsen gaat missen vanuit de CNC besturing...
Vandaar dat ik de Step/Dir input al op een interrupt heb zitten....

Het eerste verhaal, zonder de map, of mijn eigen gemaakte scale som , werkte goed...
.

Ik heb eigen geen idee hoe de arduino Due omgaat met dit soort funlties...

ik zou ook even moeten kijken hoesnel de pulsjes zijn van uit de CNC-controller, die hij bij moet houden...
maar dat zit toch wel ergens tussen de 35 a 75 K...

Dus de vraag is meer gaat hij het bijhouden... ?
[ code verwijderd ]

Dus je grootste zorg is dat de CNC besturen sneller pulsen stuurt dan je arduino kan afhandelen? Dan zou je daar een buffer tussen kunnen plaatsen misschien.

Een thread die alleen maar luistert naar CNC input en het op een queue plaatsen, en een andere thread dit laten consumeren. Ik heb verder nooit wat gedaan met een laser of zo dus misschien mis ik het eea.
I think that it’s extraordinarily important that we in computer science keep fun in computing
For all who deny the struggle, the triumphant overcome
  donderdag 26 mei 2022 @ 23:58:42 #8
47760 Grote_Swets
En groot is tie....
pi_204876809
quote:
0s.gif Op donderdag 26 mei 2022 21:33 schreef crystal_meth het volgende:

[..]
Je kan de map functie gebruiken, of je kan gewoon de volgorde van je bewerkingen aanpassen: eerst de vermenigvuldiging uitvoeren, dan pas de deling: dan verlies je enkel de cijfers achter de komma.

bvb: 49/50*60:
in float: 58.8, en daarna (int)58.8 ---> 58
als je het in integers uitrekent:
49/50*60 --> 0*60 ---> 0
49*60/50 --> 2940/50 ---> 58

Dat je een Due gebruikt maakt het makkelijker (die gebruikt vier bytes voor een int, meer dan genoeg)

tmp1 = OutputHigh - OutputLow; // = 128 - 64
tmp2 = PWM_Out - InLow;
tmp3 = tmp1 * tmp2;
tmp4 = InHigh - InLow; // = 255-0
tmp5 = tmp3 / tmp4;
tmpPWM_Out = tmp5 + OutputLow;

of simpelweg:
tmpPWM_Out= OutputLow + (OutputHigh - OutputLow) * (PWM_Out - InLow) / (InHigh - InLow);

Branden van grijswaarden op hout is lastig. Had zelf een laserbrander in elkaar geknutseld met delen van twee oude flatbed scanners, een arduino uno (met SD Card adapter) en een blauwe 1.8W laserdiode. De afbeelding stond op de SD card, en werd lijn per lijn geschreven (wat erg lang duurde).
Branden van tekst of zwart-wit tekeningen en patronen ging perfect, maar grijstinten...
Probleem is dat het hout (voor zichtbaar licht) niet overal even donker is, de lichtere delen reflecteren veel laserlicht, de donkere delen minder, die absorberen dus meer energie, waardoor ze sneller opwarmen en sneller verkolen. En eens ze verkolen (zwart worden) absorberen ze de energie bijna volledig, waardoor ze nog sterker opwarmen.

Bij "grijze" pixels was dat overduidelijk: iets lichter hout werd bij bvb 10 ms belichting slechts lichtgrijs, terwijl iets donkerder hout na 8 ms reeds zwart was.
Maw, de grijstinten versterkten vooral het contrast dat in het hout aanwezig was. Ander probleem was dat de lijnen iets overlapten (afstand tussen twee lijnen was 0.17 mm, maar een zwart gebrande lijn was iets breder dan 0.17 mm). Dus bij het branden van de volgende lijn was het hout op die plaatsen reeds donkerder dan elders en brandde dus veel sneller in.

Ik dacht dat ik het misschien kon verhelpen met feedback: had 2 fotodiodes (één voor zichtbaar licht, één voor infrarood, maw hitte) aan de laser bevestigd (gericht op het hout), om laserduur te bepalen op basis van de gemeten lichtsterkte (hoe hoger, hoe meer reflectei van de laser, hoe langer belichten) of hittestraling (laser stoppen wanneer een bepaalde waarde bereikt wordt) , maar heb er daarna niets meer mee gedaan (had enkele onderdelen voor een ander project nodig).

Misschien zou het met een infrarood laser beter gaan, ik kon nergens een absorptiespectrum van hout vinden maar best mogelijk dat infrarood veel minder gereflecteerd wordt.
Ja het is ook zo maar kijken of ik een beter resultaat kan krijgen....



Dit ziet er al beter uit, maar hier heb ik met Paintshop pro zelf de kleuren zitten verschuiven....
en je ziet wel de verschillende tinten....

maar onder die handen zie je een zwart rechthoek. maar dat rechthoek loopt links van zwart (laser op 255) naar rechts naar wit (laser op 0).
en daar zie je ook dat van wit naar zwart in een heel klein gebied zit..

dus ik wil een bitmap omzetten naar bijvoorbeeld 16 tinten grijs... en dat ik met 2 potmeters wat kan rommelen, en kan zien of ik dan bettere resultaten krijg....

Zwart/wit werkt perfect....
pi_204879692
quote:
0s.gif Op donderdag 26 mei 2022 23:42 schreef Grote_Swets het volgende:

[..]
Ik heb nu het onderstaande: en in de simulator werkt het....
dus mach3 stuur dmv 2 outputs (step en dir) de PWM counter op en neer...

En via de map function ( toch wel makkelijker als mijn zelf gemaakt map functie, die het trouwens wel gewoon deed)

dus alles werkt....

maar wat er meer door mijn hoofd speelt, hoe snel is het allemaal....
ik wil eigenlijk niet, dat het verhaal pulsen gaat missen vanuit de CNC besturing...
Vandaar dat ik de Step/Dir input al op een interrupt heb zitten....

Het eerste verhaal, zonder de map, of mijn eigen gemaakte scale som , werkte goed...
.

Ik heb eigen geen idee hoe de arduino Due omgaat met dit soort funlties...

ik zou ook even moeten kijken hoesnel de pulsjes zijn van uit de CNC-controller, die hij bij moet houden...
maar dat zit toch wel ergens tussen de 35 a 75 K...

Dus de vraag is meer gaat hij het bijhouden... ?
[ code verwijderd ]

Het is een processor op 84 MHz, 32-bit vermenigvuldiging neemt één clock cyclus in beslag, 32-bit deling is in hardware geimplementeerd. De hele berekening zou minder dan een microseconde in beslag moeten nemen, al hangt dat af van hoe de map functie geimplementeerd is (de meeste "Arduino functies" lijken veel meer tijd te nemen dan nodig).
Je kan testen hoe lang het duurt, bvb met

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
volatile int tmpPWM_Out;
volatile int PWM_Out = 215;
volatile int OutputLow = 64;
volatile int OutputHigh = 255;

void setup() {
  Serial.begin(9600);
  unsigned long tijd = micros();
  for (long int i = 0; i < 100000; i++) {
    tmpPWM_Out = map(PWM_Out, 0, 255, OutputLow, OutputHigh);
  }
  Serial.println(micros() - tijd);
}

void loop() {
}
De variabelen zijn volatile gemaakt om compiler optimalisation te beletten: anders zal de compiler (als ie goed is) zien dat de berekening in de for-lus steeds hetzelfde resultaat oplevert, dus zal hij die uit de lus nemen en ervoor plaatsen. Waarna een lege lus overblijft die niets doet en dus verwijderd kan worden.
"volatile" vertelt de compiler dat er zaken buiten het programma (kunnen) zijn die de variabelen (het geheugen waarin ze opgeslagen zijn) ook kunnen gebruiken en wiijzigen, waardoor hij die optimalisatie niet kan uitvoeren.

Ik gok dat in jouw loop de analogRead(AnalogLow) en analogRead(AnalogHigh) de meeste tijd in beslag nemen. Hoe lang een AnalogRead op de Due standaard duurt is niet duidelijk, een blog uit 2015 claimt dat je met analogRead() zo'n 100k samples per seconde kan nemen, dan zou jouw loop dus maximaal 50000 keer per seconde uitgevoerd worden.
In een thread uit 2012 meldt iemand 40 usec voor een analogread, wat neerkomt op 25000 samples per seconde. Misschien waren eerdere versies van analogRead trager?

De snelheid hangt af van de gebruikte kloksnelheid ADCClock (een ADC conversie duurt meer dan 10 ADCClock periodes), die bepaald wordt door de de microcontroller clock en de waarde van de ingestelde prescaler ( ADCClock = MCK / ( (PRESCAL+1) * 2 ). Mogelijke waarden: van 42 MHz tot 164 kHz (denk ik).
De presclaer lager zetten zal de meeste winst opleveren, volgens Atmel kan de controller tot één miljoen samples per seconde nemen. Er zijn nog andere settings die de tijd beînvloeden maar ik weet niet of het veel zin heeft om die aan te passen.
SPOILER
Om spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.
De thread op arduino.cc[ heeft voorbeelden van het verhogen van de de ADCClock, het gebruik van de controller registers ipv de AnalogRead functie, en het inlezen van twee verschillende ADC kanalen (de microcontroller kan ingesteld worden om meerdere conversies na elkaar te doen, van verschillende pinnen).
De registers gebruiken is sneller dan de AnalogRead functie, want AnalogRead moet telkens alle nodige settings instellen voor het inlezen van één waarde van een specifieke pin, daarna de ADC opstarten, en wachten tot de conversie gedaan is. Met de registers moet je de settings slechts één keer instellen in setup() voor de pinnen die je wil inlezen, en na opstarten van de ADC kan het programma verder lopen, de waarden kan het later ophalen uit de registers. Je kan bovendien free running mode instellen, waarin de ADC de ingestelde pinnen steeds opnieuw zal samplen en converteren, dan moet je in loop() enkel de registers lezen waarin de resultaten van de conversie staan. Enkel wanneer de loop minder lang duurt dan 2 ADC conversies zal het programma moeten wachten tot de conversie beëindigd is.
Wat er precies gebeurd wanneer de ADC sneller is dan het programma weet ik niet precies, misschien pauzeert de ADC tot het programma de waarden opgevraagd heeft, of blijft ie runnen en overschrijft de waarden, dunno, maar die thread op arduino.cc lijkt genoeg info te bevatten (ik heb geen Due, heb het dus niet in detail bekeken).
Ich glaube, dass es manchmal nicht genügend Steine gibt und
Ich bin mir sicher, dass auch schöne Augen weinen
pi_204881173
quote:
0s.gif Op donderdag 26 mei 2022 23:58 schreef Grote_Swets het volgende:

[..]
Ja het is ook zo maar kijken of ik een beter resultaat kan krijgen....

[ afbeelding ]

Dit ziet er al beter uit, maar hier heb ik met Paintshop pro zelf de kleuren zitten verschuiven....
en je ziet wel de verschillende tinten....

maar onder die handen zie je een zwart rechthoek. maar dat rechthoek loopt links van zwart (laser op 255) naar rechts naar wit (laser op 0).
en daar zie je ook dat van wit naar zwart in een heel klein gebied zit..

dus ik wil een bitmap omzetten naar bijvoorbeeld 16 tinten grijs... en dat ik met 2 potmeters wat kan rommelen, en kan zien of ik dan bettere resultaten krijg....

Zwart/wit werkt perfect....
Mooie snelheid, ik ben jaloers.
Ich glaube, dass es manchmal nicht genügend Steine gibt und
Ich bin mir sicher, dass auch schöne Augen weinen
  zaterdag 28 mei 2022 @ 00:59:35 #11
47760 Grote_Swets
En groot is tie....
pi_204886364
Ik ga het maar gewoon eens proberen .... heb al een kastje gemaakt, met 2 potmetertjes er in.... en zal ik eens kijken wat me machine er mee doet....

Als het mis gaat, kan ik er altijd verder in duiken.... :-)
  zaterdag 28 mei 2022 @ 22:45:41 #12
47760 Grote_Swets
En groot is tie....
pi_204896082
Het ging dus goed, de arduino kan het nog steeds gewoon bijhouden:



en dit is gewoon een oud stukje MDF... vorige keer was dat echt niets.... maar nu kan ik het goed regelen....


Dit was wel een heel klein plaatje.... anders staat ik iedere keer een dag te wachten... :-)

ik zal morgen tijdens Max eens wat groters branden, op wat beter hout....
  zondag 29 mei 2022 @ 19:55:20 #13
47760 Grote_Swets
En groot is tie....
pi_204907305
Ja het gaat steeds beter.....

abonnement Unibet Coolblue
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')