Show your projects! Part 31

@Angela, bedankt voor de uitleg. De twee stappenmotortjes hebben die 7.5 graden of 1.8 graden per stap. Ik heb geen 3d printer maar kan het, denk ik , wel maken. Wordt dan voor volgend jaar.
Ad

Op 2 april 2018 17:15:05 schreef kombucha:
echt knap, moet ik voor mijn 2.5 jarige pleegzoon ook eens bouwen (3d printer is onderweg)

Pasen is bijna voorbij, je hebt dus een heel jaar de tijd.

@hex173 De stappenmotortjes zijn type 28BYJ-48 5volt uitvoering. De servo is een SG90. In de stappenmotors zit een tandwielvertraging met een vreemde verhouding: 63.68395 op 1. In de software wordt gerekend met 64 op 1. Beetje onnauwkeurig maar maakt allemaal niet uit.

De prachtige bouwbeschrijving is hier te vinden:

github.com/ProbotXYZ/EggBot/blob/master/AssemblyInstructions/Assembly_Instruction_en.pdf

En het complete project hier: github.com/ProbotXYZ/EggBot inclusief de parts die geprint moeten worden met de 3D.

De Arduino uno heb ik vervangen voor een Arduino nano en de driverboards voor de steppenmotors door een ULN2803.

De software voor de Arduino heb ik aangepast omdat de hele omtrek van het eitje niet gebruikt werd. De add-on voor inkscape heb ik ook aangepast omdat de serieele poort niet herkend werd.

Op 2 april 2018 22:24:34 schreef Angela:
In de stappenmotors zit een tandwielvertraging met een vreemde verhouding: 63.68395 op 1. In de software wordt gerekend met 64 op 1.

...met een originele stapgrootte van xxx (weet ik niet meer, geen zin om uit te rekenen), komt dat neer op ruim 2000 stapjes per omwenteling. Kortom, zat resolutie.

Ik heb mij de afgelopen twee dagen bezig gehouden met het leren aansturen van een 7-segment display. Niet echt indrukwekkend, maar ik ben al bij al toch een dikke dag bezig geweest om alles uit te vissen. (Ik vind de keuze van multiplexen nogal vreemd) Ik heb hier maar twee van de vier cijfers aangesloten, omdat de twee andere toch nagenoeg hetzelfde zijn.

Ik heb geen foto van wat er onder het display zit. Die ben ik vergeten te maken. Maar het stelt opzich niet veel voor. Een paar weerstanden om de stroom te regelen en 2 torren om de kathodes aan te sturen. Een achterkant heb ik wel.

En dan nog de code om alles aan te sturen:

byte segmenten[2][17][2]=
{
  {
    {7,13},
    {6,0},
    {3,14},
    {7,6},
    {6,3},
    {5,7},
    {5,15},
    {7,0},
    {7,15},
    {7,7},
    {7,11},
    {4,15},
    {1,13},
    {6,14},
    {1,15},
    {1,11},
    {128,128}
  },
  {
    {104,112},
    {0,48},
    {56,80},
    {48,112},
    {80,48},
    {112,96},
    {120,96},
    {0,112},
    {120,112},
    {112,112},
    {88,112},
    {120,32},
    {104,64},
    {56,48},
    {120,64},
    {88,64},
    {128,128}
  }
};

volatile byte counter = 0;
volatile byte multiplex = B00000001;
volatile bool divider = false;
byte segment1 = 0;
byte segment2 = 0;

ISR(TIMER1_COMPA_vect){
  //tellen tot 0xFF
  if (divider){
  counter ++;
  PORTB = PORTB ^ B00100000; //heartbeat
  }
  divider = !divider;
}

ISR(TIMER2_COMPA_vect){
  
  //kathode wisselen
  PORTB = (PORTB & ~(B00000011)) | multiplex;//wisselen van cathode
  PORTD = segmenten[0][segment1][multiplex>>1] + segmenten[1][segment2][multiplex>>1]; //segmenten kiezen
  multiplex = (multiplex ^ B00000011); //klaarzetten voor volgende ronde

}

void setup(){
  //Begin met setup
  
  DDRD = B11111111;  //PORTD allemaal uitgang
  DDRB = B00100011; //PORTB pin 0 & 1 & 5 uitgang
  
  cli(); //disable interrupts

  //setup timer 1
  TCCR1A = 0;
  TCCR1B = 0;
  TCNT1 = 0;

  OCR1A = 62499; //match for f = 2Hz
  TCCR1B = 0b00001011; //enable CTC mode and set prescaler to 64
  TIMSK1 = 0b00000010; //enable output compare A match
  
  //setup timer 2
  TCCR2A = 0;
  TCCR2B = 0;
  TCNT2 = 0;

  OCR2A = 155; //match for f = 50Hz
  TCCR2A = 0b00000010; //enable CTC mode
  TCCR2B = 0b00000111; //set prescaler to 1024
  TIMSK2 = 0b00000010; //enable output compare A match
  
  sei(); //enable interrupts
}

void loop(){
    segment2 = (counter & 0b00001111); //eenheden
    segment1 = (counter >> 4); //tientallen
    delay(10);
}

Het vreemdste vond ik hier die delay(10). Zonder wil hij niet tellen, dan blijft het voor eeuwig en een dag op '00' staan. Met werkt het perfect. Die oplossing kwam ik toevallig tegen toen ik begon te debuggen met serial.println(). Een paar van die lijntjes in de main loop en m'n sketch werkte perfect. Zonder die lijntjes deed ie geen moer. Iemand een idee waar dat aan kan liggen?

Uiteindelijk wil ik het display gaan gebruiken om het toerental van een benzine-motortje af te lezen.

Misschien dat het weg wordt geoptimaliseerd, maak segment1 en segment2 ook eens volatile?

EDIT: @rew hieronder:segment1/2 worden alleen in de main geschreven en in de ISR's gebruikt, maar ISR's worden nooit aangeroepen vanuit je programma. De optimizer zou wel eens kunnen denken dat ze nooit gelezen/gebruikt worden. ISR's zijn volgens mij niet helemaal optimizer compatible...

Wat ook een mogelijkheid is, je interrupts lopen niet totdat je een stukje Arduino code implementeert dat die registers wel goed zet. Om dat te testen kun je de delay(n) verplaatsen naar setup()? Je zal het display dan zeker niet meer met het oog zien tellen, maar dat ging waarschijnlijk al niet.

[Bericht gewijzigd door Benadski op dinsdag 3 april 2018 19:08:50 (28%)

Nee, dat kan ie niet optimaliseren. In "loop" eindigt de functie, dan moet alles naar RAM weggeschreven zijn. Hetzelfde geldt voor waar ze gebruikt worden: Daar kan de compiler die variabelen niet anders dan uit RAM laden, 1x gebruiken en daarna... einde functie.

Oh hell, die gruwelijke wekker displays.

Die worden normaal door de voeding gemuxed, een trafo met middenaftakking waarvan elk set kathodes aan een van de buiten aansluitingen van de trafo hangt.

Logisch heb ik die dingen nog nooit gevonden, goedkoop zal wel het toverwoord zijn

@Benadski, @rew:
Het was toch de optimizer. Volatile er voor zetten deed 't em. Ik heb de term volatile dus duidelijk verkeerd begrepen. Ik dacht dat het zoiets was: "pas op! deze variabelen zouden zomaar opeens van waarde kunnen veranderen!" Maar het is dus enkel iets voor de optimizer in de zin van: "blijf hier maar braaf vanaf, ze zijn zeker ergens nuttig."

Dat de interrupts misschien niet liepen had ik ook al bedacht. Daarom dat ik die heartbeat in timer1 had gestoken. Dat timer2 dan ook liep, heb ik maar blind aangenomen.

@Sine:
Nee, logisch zijn die dingen niet. Ik ben een paar uur bezig geweest met tabellen maken. Eerst welke anode-kathode combi welk segment liet oplichten, dan welke combinaties ik nodig heb voor elk cijfer en dat dan vervolgens omzetten naar een byte die ik naar PORTD kan schrijven. Als ze door een transfo gemultiplexed worden, is het al logischer. Anders had ik 4 kathodes en 7 anodes gekozen. Daar bespaar je zelfs I/O mee.

Daar komt dan ook nog bij dat het meest linkse digit niet alle cijfers kan weergeven. segment f is daar niet voorzien. Ook weer kosten besparen vermoed ik. En om het helemaal af te maken, heeft de AM dot en de AL dot elks nog een eigen kathode. In plaats van die dan ook gauw op de al bestaanden aan te sluiten.

3d printer is vandaag aangekomen, stond in de tracking nog op te verzenden lol
(eggbot kan je krijgen voor ongeveer 50 euro: je kan er ook pingpong ballen, kerstballen enzo mee maken, zelfs glazen graveren)

Die wekkerdisplays zijn geoptimaliseerd om een zo simpel mogelijke ASIC te gebruiken voor de aansturing. Vandaar ook weer die aparte aansluitingen voor AL en AM.

Op 3 april 2018 20:53:53 schreef Shock6805:
@Benadski, @rew:
"pas op! deze variabelen zouden zomaar opeens van waarde kunnen veranderen!" Maar het is dus enkel iets voor de optimizer in de zin van: "blijf hier maar braaf vanaf, ze zijn zeker ergens nuttig."

Dat van "Pas op!", dat klopt wel ongeveer. Maar in een loop kan het handig zijn om een variabele tijdelijk gewoon in een register te bewaren en aan het eind de actuele waarde zo nodig terugschrijven naar RAM. Maar volatile betekent dat het lezen/schrijven van/naar RAM niet weggeoptimaliseerd mag worden.

for (i=0;i<256;i++)
   PORTA = i;

hier had de optimizer normaliter

for (i=0;i<256;i++)
   /*niets meer */;
PORTA = 255;

van gemaakt, maar omdat "PORTA" volatile is, weet ie dat ie de schrijf acties naar die variabele niet MAG wegoptimaliseren.

Wat ik me nog bedacht is dat de arduino IDE mogelijk in je source gaat zitten snuffelen en ipv:

void main (void)
{
  ...
  setup ();
  ... 
  while (1) {
    loop ();
    ... evt arduino interne dingen ... 
  }

iets bouwt waarin staat:

void main (void)
{
  ...
  setup ();
  ... 
  while (1) {
    ... inhoud van de loop functie. ...
    ... evt arduino interne dingen ... 
  }

Dan snap ik WEL dat ie deze optimalisatie uitvoert.

@Angela bedankt voor de genomen moeite en de gegevens, de vreemde reductie getallen zullen wel door het vertragingskastje veroorzaakt worden.
Ad

@Jeroon :
Goh, met welke DDS heb je dat gedaan ? Of bedoel je dat de dsPIC33 ook nog eens zelf het signaal genereert ?
Volgens mij wordt de volgende stap om een compleet printje hiervoor te ontwerpen met alles onboard, zodat het in een behuizing past.
Leuk project !

Op 7 april 2018 00:28:28 schreef oxurane:
@Jeroon :
Goh, met welke DDS heb je dat gedaan ? Of bedoel je dat de dsPIC33 ook nog eens zelf het signaal genereert ?
Volgens mij wordt de volgende stap om een compleet printje hiervoor te ontwerpen met alles onboard, zodat het in een behuizing past.
Leuk project !

De dsPIC doet ook de DDS-generatie ja. Dat gaat prima tot boven de 20 kHz. Ik heb nog wel een AD8933 boardje liggen, maar dat maakt het alleen maar ingewikkelder en het kost meer I/O's.

Verder zit alles al op 1 printje

Project waar ik al een tijdje mee bezig ben. Het is een 8 digit VFD dotmatrix display, een STM32 controller en ESP8266.
Het is meer de uitdaging om alles met een controller aan te sturen, de PWM voor het filament van de VFD, de refresh timing voor shiftregisters achter de display, PWM voor dimmen van de display, een UART naar de ESP en een UART voor debugging naar de PC, een LDR voor het dimmen van de display.
Een steile leercurve maar wel leuk om te doen. Op termijn wil ik ook dat er teksten over de display verschijnen van bijvoorbeeld domoticz sensoren.

Van houtklover naar buizenbuiger !
Toch een projectje ?

Filmpje zou wat duidelijker zijn.

Mwah, als je weet hoe een houtklover werkt is het geen raketwetenschap...

Op 8 april 2018 19:51:18 schreef BenI2C:
Filmpje zou wat duidelijker zijn.

Wil ik best voor je maken....
Maar het is een combi van een handbediende buigpers (china) welke ik op een kloofmachine heb gelast (pompte me zo nu en dan suf).

Ok duidelijk

En dan ben je zomaar 512 solderingen verder
Met dank aan Deurne en Henri die me op de connectoren wees.

[Bericht gewijzigd door bprosman op zaterdag 14 april 2018 17:52:52 (27%)

En dan ben je zomaar 512 solderingen verder

Dan leer je tenminste nog solderen...

Mini projectje. Nul soldeerverbindingen.

Op 14 april 2018 17:51:58 schreef bprosman:
En dan ben je zomaar 512 solderingen verder
Met dank aan Deurne en Henri die me op de connectoren wees.

Tsja, als je het over 19" racks hebt gaat bij mij meteen het belletje "DIN41612" rammelen (en 'b' of 'c' erachter). Je kunt niet zonder.

Ik zie ook dat je er zelf een mooie print voor gemaakt hebt. Dan weet je in ieder geval wel dat de steek goed is voor je kaartgeleiders (of je moet het zelf verprutsen met je afmetingen in je layout natuurlijk: maar daar hebben we een ander topic voor).