Digitaal meetwiel maken

Nee, een absolute encoder heeft interne elektronica die de telling bijhoudt en ofwel serial of parallel de data verzendt naar een µcontroller, en dat vraagt tijd.
Intern heeft een absolute encoder een incremental encoder + telling aan boord.

Als je enkel een incremental hebt moet je zelf de telling van de signalen verwerken.

Op 15 juni 2017 17:49:19 schreef Geerten van Dam:
Dat heeft vast te maken met het onderscheidt in draairichting? GJ_?

Precies, en als er iemand met dat wiel heen en weer wiebelt dat ie niet als een malle gaat optellen

Op 15 juni 2017 18:17:57 schreef MGP:
Nee, een absolute encoder heeft interne elektronica die de telling bijhoudt..

Een absolutencoder heeft meestal gewoon een schijf met het benodigde aantal bits, gebruikelijk in grey. Een multiturn absoluut heeft zelfs meerdere schijven en tandwielkasten.
De programmeerbare zie je wel meer en meer. Dat geldt trouwens ook voor incrementele encoders. Er zijn zelfs encoders die je zelf kunt configureren als incrementeel en absoluut, tellers, nokkenschakelaar enz.

Wat me trouwens gelijk op het volgende brengt: IFM heeft er dus zo een met scherm er al op. Eigenlijk heeft die precies wat TS zoekt. En goedkoop ook nog, ik geloof iets van 180 euro. Heb ik een keer gebruikt en dat beviel prima.

Tja, het gaat snel in die wereld en ik ben er al een tijdje uit, de intelligentste die wij toen gebruikten was een Fraba Posital 24bit met Devicenet.
Er stonden er toen +-25stuks op 1 machine(continu pers).

edit: @TS weet je al tot hoeveel hij moet tellen in meters en de snelheid van meten?

Een mogelijkheid om het nauwkeuriger te maken , een versnelling maken tov het metende roterende wiel, zo kun je veel meer pulsen crieren en dus nauwkeuriger, je moet dan wel sneller kunnen tellen.bv met een reduktor.
Als je toch een rotary encoder wil gebruiken neem dan een meerkanaals om zo te kunnen bepalen vooruit of achteruit.
Tellen met lichtsluisjes is denk ik veel goedkoper, 2 stuks.
Is sluis 1 eerder actief dan sluis 2 is voorruit tellen, is sluis 2 eerder dan 1 achteruit tellen.
Per omwenteling van de versnelde sluis kan dan voor/achter geteld worden.

Op de vraag tot hoeveel hij moet tellen en de snelheid daarvan. 100 meter is voldoende en een display met 6 getallen moet genoeg zijn wanneer ik de waarde in mm weergeef. De snelheid ben ik nog niet helemaal uit, maar ga er vanuit dat men op de werkvloer niet vlug gaat rennen. dus 1,11 meter/sec moet wel voldoende zijn. in combinatie met een diameter van 20 mm zou dit uitkomen op 1060 rpm.

Het heeft niets met jou opstelling van doen, maar er staat wel een stukje over encoders in. Misschien heb je er iets aan.

https://www.circuitsonline.net/artikelen/view/48

1060rpm dat is dan grof gerekend 20tr/s aan 1024imp/omw (encoder) = 20Khz.

Dat vermenigvuldigd met 3 om zeker geen pulsen te missen komt dat op 60kHz samplefreq, wat heel veel is.
Interrupts zullen meer dan nodig zijn.

Misschien een en ander nog wat beter omschrijven of uitdenken.

1024 ppr is ook veel te veel, de lengte van een draad gaat meestal per cm en zoals ik het graag wil, zou een nauwkeurigheid van 1 mm zijn. 0,05 mm heeft geen enkele meerwaarde

Vandaag komt mijn arduino binnen ? dus wie weet kan ik dan ook eens mee praten. Fijn dat jullie zo meedenken!!

Op 16 juni 2017 10:48:21 schreef MGP:
1060rpm dat is dan grof gerekend 20tr/s aan 1024imp/omw (encoder) = 20Khz.

Nee, 80KHz. Altijd een AB encoder gebruiken op een meetwiel: counts/rev = PPR x 4

Deze heeft alles al kant en klaar aan boord, inclusief een omzetting naar user units. In principe zou deze gewoon de millimeters in het scherm moeten kunnen presenteren:

ifm-ROP520-Encoder-Performance-with-display-and-IO-Link-e-15-n.pdf

Ook zonder de mogelijkheden is het al een goedkope encoder.
Manuals heb ik eventueel ook nog trouwens.

Op 16 juni 2017 19:42:48 schreef GJ_:
Nee, 80KHz...

Ja en nee, als je de op- en neergaande flank telt is dat wel zo, anders is dat niet nodig van zo hoog maar dan vermindert de resolutie.

Vroeger veel getest met seriële interrupt gedreven inputs van een 286 PC onder dos, die kon makkelijk 100kHz aan maar dan gebruik makend van de schakeling die in Radio Bulletin stond in de jaren '80 en die jij nog gepost hebt hier op CO

Maar zoals ik al schreef zal hij zich heel goed moeten bedenken hoe hij het gaat aanpakken.

MGP, als je niet ECHT de vier-kwadrants meting doet, dan ga je in bepaalde gevallen verkeerd tellen. Je moet alle vier de flanken registreren.

m.i. moet je NIET "op 60kHz" gaan bemonsteren. Je moet een hardware-timer van de microcontroller gebruiken.

Ik was van plan om vandaag even geen zin in m'n eigen werk te hebben en op zoek naar iets anders om te doen. Misschien maak ik dit even.

[edit]
Je wiel heeft een diameter van 20mm, dus een omtrek van 62.8mm Met een encoder van 600PPR kom je dan op 0.104mm per stapje. Met 1.11m/s kom ik dan op 10615 pulsen per seconde. Mijn encoder is volgens mij gespect op max 100k. dus daar zitten we een factor tien onder.

[Bericht gewijzigd door rew op zaterdag 17 juni 2017 08:51:46 (26%)

Er zijn verschillende methoden van aanpakken, de beste methode is deze van GJ_, één kopen.
Ik tracht mij altijd in de schoenen van de TS te plaatsen en wat jij daar voorstelt is voor een starter niet doenbaar, daar gaat veel tijd over.

Edit: met een schakeling zoals in de link heb je zelfs geen µC nodig, enkel een up-down counter IC, dan moet je enkel een gepaste encoder en wiel hebben/maken.

Natuurlijk zal hij heel blij zijn als iemand het voor hem maakt en zal u heel dankbaar zijn

edit2: Maar zoals ik vroeger al dikwijls heb aangehaald, moest ik als bedrijf iets uitgeven als stageproject, dan zou de stagiair de opdracht meekrijgen van zoveel mogelijk commerciële toestellen/stukken te gebruiken.
Ik heb het genoeg meegemaakt met de opkomst van de digitale elektronica. Er wordt iets gemaakt en geïnstalleerd en de maker verandert van werk of studeert af en gaat elders werken en daar sta je dan als er zich panne voordoet.
Dat is ook waar GJ_ voortdurend zit op te hameren, ik versta hem wel maar het blijft interessant om als stagiair iets te kunnen tonen.
Maar goedkoop is in die omgeving meestal duurkoop.

[Bericht gewijzigd door MGP op zaterdag 17 juni 2017 10:16:50 (39%)

OK. Het werkt.

Je mag van mij mijn testopstelling kopen.

Ik heb getest met: Encoder 600PPR (2400 stapjes op de counter!), maar mogelijk krijg je een 400PPR encoder die nu niet HIER is.... EUR 25.

STM32 development bordje wat ik ontworpen en gemaakt heb. Verkoop ik voor 20 euro.

SPI kabeltje 2 euro.

SPI_LCD 10 euro.

Ik heb geen wieltjes, geleiding o.i.d. gemaakt. Je moet zelf iets regelen als een USB_batterypack als het mobiel moet zijn. (dat lijkt me een prima oplossing om 5V te krijgen, oplaad circuit etc allemaal al gemaakt).

Ik ben een sterke voorstander van "ik doe niet je huiswerk voor je". Als anderen vinden dat ik niet je huiswerk voor je mag maken, dan gaat het niet door. Er blijft m.i. nog wel eea over voor jou om te regelen. Deels hangt het af van wat jou studie-richting is.

Voor de prijs moet hij het niet laten, u kennende zal dat wel in orde zijn.

Ik zie maar 1 probleem en dat is zijn stageverslag.

Welke encoder heb je gebruikt? 25E is niet veel.

D'r ligt hier een LPD3806-600BM-G5-24C waarmee ik getest heb. Mogelijk is die duurder dan de 25 euro die ik vraag voor die andere die op m'n werk ligt. Ze voelen hetzelfde aan.

Dat lijkt mij een uitgelezen kans voor gvd om zijn project te starten! En wellicht dat ie het ook nog commercieel kan maken, zoals het plan is. Hulde!

Op 15 juni 2017 14:58:35 schreef Shiptronic:
? waarom? Zelf zou ik er een voordeel in zien om het wiel 512mm te maken met bv. 1024 encoder , elk stapje is dan 0,5 mm

Om niet met floats te hoeven klooten?

Mijn code heeft nu:

#define DIAM 20.0
#define PI 3.1415926535
#define CPR 600

    pos = (float)totcnt * DIAM * PI / CPR / 4;
    posi = pos*10; // in 0.1mm.

En dat kost:

   text    data     bss     dec     hex filename
  26252    1292   15280   42824    a748 build/ch.elf
  22156    1292   15280   38728    9748 build/ch.elf

waarbij de onderste de integer versie is die een paar procent afwijkt. Het verschil is dus 4k aan library code voor de floats die naar binnengetrokken wordt..... OK. Nog even wat zitten optimaliseren..... Haakjes toegevoegd, double gezet waar eerst float stond, en nu....

   text    data     bss     dec     hex filename
  23404    1292   15280   39976    9c28 build/ch.elf

kost het nog maar 1248 bytes over de integer versie. Dat is 1% van de flash in m'n processor.

de code is nu:

    pos = (double)totcnt * (10 * DIAM * PI / CPR / 4);
    posi = pos; // in 0.1mm.

Waarbij de comment nu 2 regels hoger moet. (ook de declaratie van pos is double ipv float geworden).

Op 17 juni 2017 16:01:10 schreef rew:
[...]Om niet met floats te hoeven klooten?

.

Ja , en kan ik het zelf ook handig volgen

Wauw, wat je wel niet allemaal kunt met zo'n forum, ik wil de opstelling graag kopen! Maar wat ook wordt aangegeven, ik zou er graag ook zelf van leren. Maar een voorbeeld is komt daarbij zeker van pas. Als u mij kunt vertellen wat de verzendkosten zullen zijn moet er zeker een passende manier zijn om het bij mij te krijgen.

[Bericht gewijzigd door Geerten van Dam op maandag 19 juni 2017 10:35:47 (12%)

Op 19 juni 2017 10:24:22 schreef Geerten van Dam:
.............is mijn normale e-mail voor als u vertrouwelijke info stuurt.

Ik zou als ik jou was je Email adres even bij je gegevens zetten, en niet openbaar.

Netjes geregeld rew.

Dat is misschien nog wel slimmer ja!

Hoe doen ze dat in een dig. schuifmaat? Nog nooit een opengemaakt. Als ik vragen mag?

Even voor volledigheid, de gemaakte opstelling kan ik ook zo programmeren dat deze voor wielen van een andere diameters werkt?

Aan de code van rew te zien wel, dat moet je dan aanpassen naar de nieuwe diameter van het meet wiel.