Een stukje over elektronica en PCB's
Eerder schreef ik al dat het veel uitmaakt of je een goed gemaakt bordje gebruikt of een slecht gemaakt bordje. Aan de reacties op diverse forums te zien denk ik dat de meeste mensen dit effect onderschatten…
De beste elektronica die je kunt krijgen zijn de commerciële CNC controllers. Die kosten alleen ook zowel qua software als hardware serieus knaken, een stuk meer althans dan ik ervoor over heb. Aan het andere eind van het spectrum zit zo’n beetje Plain Old Grbl van Gnae (POG) en parallel Break Out Boards (BOB). Die zijn echt bijzonder populair… Dus waarin zit nou eigenlijk het verschil?
Allereerst wat we nou eigenlijk willen en waar we op moeten letten. CNC’s zijn heel goed in het produceren van een enorme hoeveelheid EMI (ElectroMagnetic Interference), maw: ruis. Ruis is vervelend, want het betekent dat je endstop afgaat als hij dat niet doet, het betekent dat je stappenmotor een stapje zet als hij dit niet doet, etc, etc. Dat kan best lelijk worden in de praktijk, in het slechtste geval kan je er zelfs je machine mee vernietigen. Dat willen we uiteraard niet, want dat is zonde. Hoe meer stroom er loopt door je machine, hoe meer EMI. Een 24v spindle op een CNC3018 doet dus niet zo veel, maar een 220V VFD spindle is wel serieus. Naast EMI hebben CNC machines vaak veel devices eraan vast geknoopt; daarmee bedoel ik bijv. wat servo’s, een rs485 aansluiting voor een closed loop spindle, een rotary encoder, etc, etc. En tot slot is er het kleine dingetje timing.
De elektronica is uitsluitend bedoeld voor de aansturing van dit alles, zodat de motoren hun pulses krijgen en de eindstops aankomen. Vrijwel alle elektronica-bordjes hebben hierbij een microprocessor, die een deel van het werk oplost. In het ideale geval wil je dat hierbij de microprocessor alleen op hoofdlijnen alles aanstuurt, en dat kleine dedicated “hardware peripherals” de hoge-frequentie details aansturen. Bij gebrek aan peripheral moet je meestal het issue in software oplossen.
Surprise, surprise, hardware oplossingen zijn vrijwel altijd beter hier. Als praktisch voorbeeld, pak bijvoorbeeld “pulse width modulation” (PWM). PWM is een manier om een blok-hoek signaal te maken door een bit aan en uit te toggelen. Voor kleine servo motoren is dat op gemiddeld 50 Hz, wat allemaal niet zo spannend is. Voor stappenmotoren gaat het echter om veel hogere frequenties en wordt het spannender. Hoe beter je deze timing voor elkaar krijgt, hoe soepeler het allemaal loopt, omdat je daarmee telkens op het juiste moment kunt “stappen”; slechte timing noemen we ook wel “jitter”. Ik denk dat we het er allemaal wel over eens kunnen worden dat “stapjes zetten” het meest belangrijke is wat een CNC hardware en firmware doet.
Waarom is “jitter” zo naar? Als je een stap zet op een stappenmotor, wordt in principe dit “stapje” gezet. Maar: dit is niet instantaan; omdat massa traag is en je nogal wat verplaatst, zet je het liefste stapjes op het moment dat je motor aan het beginpunt van het volgende stapje is aangekomen – waarbij je dus gebruik maakt van het traagheidsmoment van je machine, ipv. hier tegenin werkt. Stel je nu voor dat je timing niet zo lekker is, en je er telkens een stukje naast zit. Het effect hiervan op de motor is dat je telkens net-niet lekker uitkomt en de motor dus het stuk continue aan het versnellen en vertragen is. Maw, je krijgt geen mooie vloeiende beweging, maar een schokkende beweging. Uiteraard zie je dit terug in je werk.
Merk op dat er twee componenten zijn aan de timing hier. Allereerst hebben we het moment waarop een stap wordt gezet, en ten tweede hebben we de lengte van de pulse. Beiden moeten zo precies mogelijk worden getimed. Maar: computers zijn digitale componenten die werken op een klokfrequentie en ook nog andere dingen te doen hebben - en dus zit er inherent een onnauwkeurigheid in.
Allereerst hebben we de pulses voor stappenmotoren. Stappenmotoren geef je een pulse met een bepaalde lengte, zeg: 4 us. Afhankelijk van de driver wordt hierbij gekeken naar de “leading” (omhoog) of “trailing” (omlaag) edge. Voor het beste resultaat wil je dus dat je hardware vrijwel precies altijd die 4 us pulses geeft, ongeacht wat er verder allemaal gebeurt. Ten tweede moet je je realiseren dat het moment waarop deze pulse optreedt géén veelvoud is van die 4 us – want “tijd” is een continue iets! Hoe preciezer we in de software kunnen zeggen wanneer een pulse optreedt, hoe beter de “motion” van je cnc machine en hoe mooier het resultaat gaat zijn. Overigens kan je dit resultaat kan ook echt zien als je bijvoorbeeld aluminium of een ander metaal gaat frezen.
Timing zit tot slot ook nog in latency. In sommige gevallen is je timing van de eerste twee aspecten heel mooi – maar zit er een tijdsverschil tussen het “event” en het “signaal”. Een voorbeeld is een I2C/SPI pin extender, die veel worden gebruikt om een gebrek aan input pinnetjes op te vangen. Je kunt met een oscilloscoop meten hoeveel tijd er zit tussen het signaal en het daadwerkelijk doorkrijgen van dit signaal. Bij een gemiddelde pin extender die op 100 kHz draait is dat ongeveer 5 tot 10 us. Het verschil in latency van 5 us is hierbij een groter probleem dan de daadwerkelijke latency, omdat het ervoor zorgt dat de “triggering” van bijvoorbeeld endstops niet meer “repeatable” is. En dat kan ervoor zorgen dat je machine niet meer precies haaks is, of dat je homing niet meer op hetzelfde punt eindigt.
Enter hardware versus software. Als je hardware geen PWM doet, moet je dat dus zelf nadoen. Dat kan, maar in alle gevallen zijn dingen die je “moet nadoen” gevoelig voor jitter, omdat achtergrond processen tijd kosten. Kortom, niet ideaal… De meeste kleine processors zoals STM’s, ESP’s en Arduino’s hebben daarom hardware peripherals hiervoor, wat betekent dat je bepaalde processen op de achtergrond kunt laten doorlopen, ongeacht wat er allemaal verder gebeurt. Uiteraard, mits je firmware hier op de juiste manier gebruik van maakt en je bordje deze hardware ook gebruikt. Evenzo hebben pin extenders vaak een “interrupt” pin, waarmee je precies de latency kunt bepalen. Een paar andere voorbeelden:
Rotary encoders zijn het eerste voorbeeld. Pak bijv. een 5000 pulses per revolution optical encoder, wat niet heel bijzonder is. Een 1605 ball screw is 5 mm / rev. Met een rate van 6k mm/min kom je op 20 revolutions per seconde. Dat is dus worst case 100.000 pulses per seconde op een A en B lijn. Dat is al best serieus veel data, terwijl je nog niets hebt… Als je ze niet snel genoeg kunt afhandelen, heb je een probleem. Maar: met een hardware peripheral (zoals een dedicated IC of een PCNT zoals op de ESP32 zit:
https://docs.espressif.co...nce/peripherals/pcnt.html ) is het triviaal om te doen.
Tweede voorbeeld is I2S. De meeste devices hebben weinig pins. Een BOB heeft uit mijn hoofd 16 I/O pins, een Arduino, ESP of STM meestal een stuk of 20. Dat is niet zo veel… en een veelvoorkomend probleem is daardoor dat je meestal te weinig pinnetjes hebt. Met I2S IC’s kan je via 3 lijnen 32 high speed pins aansturen… zelfs snel genoeg voor stappenmotors. Hoe snel precies? Wel, je stappenmotoren wil je aansturen op toch wel 100 kHz per pin of meer. 32x100 kHz serieel geeft 3.2 MHz op 3 pinnetjes (de werkelijke snelheid van I2C ligt overigens nog veel hoger). Direct Memory Access (DMA) is hierbij de hardware peripheral die met I2S een hoop goed maakt. In plaats van direct PWM te sturen naar je stappenmotoren, zet je met DMA de stappen in een buffer, die dan door de hardware naar je motoren wordt gestuurd. Kortom, ongeacht wat je allemaal nog meer allemaal voor taken uitvreet in je firmware, zolang de buffer maar netjes gevuld blijft, is het goed.
Hardware timers zijn de laatste peripheral die behoorlijk relevant zijn. Een nauwkeurige hardware timer die op een hoge frequentie loopt is veel beter in staat om op het juiste tijdstip de CPU een signaaltje te geven (om bijv. een stapje te zetten) dan een timer die op een lage frequentie loopt. Kortom, hieruit volgt direct dat we hoe dan ook een bordje zoeken met een vrij hoge klokfrequentie. Meer is echt veel beter hier; een 16 MHz Arduino met een maximale timer frequentie van 16 MHz / 1024 bit resolution = 16 kHz voldoet gewoon niet voor een beetje machine.
Naast hardware peripherals wil ik ook graag nog een opmerking maken over de kwaliteit van de PCB zelf. EMI en piekspanningen zijn echt wel een probleem van een CNC machine die een 220v spindle aanstuurt; dit zou ik niet onderschatten. Wat ik dus verwacht van een bordje is dat het isolatie heeft, om kan gaan met kortsluiting op de inputs, en dat het redelijk robuust is met power management. Dus daarmee bedoel ik dat er een aardige capacitor en inductor op zit om dipjes op te vangen, er wat filtering toegevoegd is, schmitt triggers er op zitten voor mooie edges, en dat er evt nog wat diodes en zekeringen op zitten voor andere ellende.
Waar ik bij high-speed lines (zoals I2S) op let is dat er ook aandacht is besteed aan placement en dat het een 4-laags PCB is. Voor scherpe 'edges', die nodig zijn voor correct functioneren van de componenten, is dit essentieel. Als je PCB een paar euro kost, ga er maar vanuit dat dit alles niet het geval is – zowel de componenten als de fabricage van een dergelijke pcb zijn daarvoor te duur… En zelfs van de kleur kan je al eea. afleiden; meerlaags PCB's komen eigenlijk alleen in het groen (want $$$ en pcb assembly services doen moeilijk daarover) en als je weet waar je op moet letten zie je dat het niet de standaard PCB-groen is, maar net iets een andere (donkerdere) tint...
De rest, zoals SD kaartjes, WiFi access, displays, etc maakt me allemaal niet zo veel uit. Dit valt bij mij onder het kopje “gimmick”.
Goed, een hele waslijst aan nuttige verlangens dus. Dus wat zijn de kandidaten?
1. Een standaard POG bordje. Peripherals van een Arduino zijn er heel weinig en de snelheid van een Arduino is dramatisch laag. Extensie is waardeloos, de I/O ports zijn er veel te weinig. Het mag dan ook niets kosten…
2. Een van de vele POG clones voor Due, Mega, etc, etc. Ik heb er een stuk of 4 liggen inmiddels, ze hebben een beetje dezelfde issues als POG.
3. BOB’s. Ik denk niet dat we het hier lang over hoeven te hebben, ze voldoen niet aan de timing constraints, hebben weinig I/O ports en de kwaliteit van de bordjes laat te wensen over. Wel zijn ze spotgoedkoop. Nouja, Mach3 kost geld. LinuxCNC op BOB is dan beter, want er zijn kernel modules om het (veel) meer real-time te krijgen - maar dan nog zet ik vraagtekens erbij.
4. Teensy boards. Deze draaien GrblHAL. Now we’re getting somewhere. De Teensy 4.1 haalt zelf serieuze snelheden met 600 MHz, wat op zich een goede start is. Het is ergens jammer dat het allemaal op GRBL is gebaseerd, want dit doet de Teensy niet veel goeds… Het doet wel RS485 (spindle), SPI/I2C (I/O expanders) en iets obscuurs genaamd “FlexIO” wat neerkomt op geemuleerde I2S. Kosten zijn ook best aardig, deze Teensy bordjes zijn niet heel goedkoop maar ook weer niet gigantisch duur. ADC/DAC is beperkt, hardware counters lijken er niet te zijn, maar dat is op zich op te lossen via een hardware SPI counter. Phil Barrett verkoopt best aardige controllers, het enige waar ik hier niet echt blij mee ben is de firmware.
5. MESA FPGA. Mesa heeft echt wel wat mooie FPGA bordjes liggen voor LinuxCNC. Het begint all-in een beetje interessant te worden rond de 700 euro laatste keer dat ik keek. Kost wel wat… Qua wiring lijkt het me wel een nachtmerrie en ik weet ook nog niet hoe blij ik ga worden van de firmware, maar verder ziet het er best als super speelgoed uit…
6. ESP32. De ESP32 is best een geinige chip, aangezien hij heel veel high-speed Peripherals ondersteunt. Het ding draait op 240 MHz en is dual core. De ESP32 is zelf best goedkoop, een DIY bordje kost je ongeveer 5 euro. De prijs wordt gedrukt doordat de kritieke delen geconcentreerd zijn op meerlaags PCB’s. Maar, je moet nog wel een fatsoenlijke CNC PCB hebben voordat je er iets mee kunt doen. O.a. Barton Dring verkoopt best aardige bordjes via Tindie voor FluidNC. Ook hier is het jammer dat het op GRBL gebaseerd is, maar verder is het best mooi.
(Er zijn nog meer varianten denkbaar, zoals bijv. het gebruiken van een Raspberry Pi in combinatie met een BOB, maar bovenstaande zijn wel de meest voor de hand liggende.)
Je kunt het al raden, ik ben voor de laatste gegaan. De features die er niet waren in FluidNC, heb ik maar gewoon geprogrammeerd en toen was ik ineens een van de core developers. Ach ja, zo gaan dat soort dingen soms…
Ik kan iedereen die geen electrical engineer is aanraden om gewoon een bordje te kopen. Dus niet te doen waar ik veel te veel tijd aan heb besteed.

Met een bordje bedoel ik dus een bordje en geen troep met een paar weerstandjes en condensatoren als filter. De ESP32 manier gebruikt een I2S extender voor de pinouts en die hebben specifieke placements op de PCB en specifieke requirements voor hoe de lijntjes lopen nodig. Schmitt triggers zijn niet optioneel, anders wordt de microprocessor overspoeld met interrupts door ruis. In theorie kan dat op een 2-lagen bordje als je een goede electrical engineer hebt, in de praktijk is 4 lagen meestal beter. Maar: 4 lagen bordjes kosten geld boven de 10x10 cm. Daarnaast wil je je lijntjes kort houden. Als je dat niet doet… nouja, dan krijg je ruis op de lijn, steps die worden gemist, kortom: ellende. Doe je het goed, krijg je 32 output ports. Dat is dus meer dan 8 motors die je kunt aansturen. Hoe snel? De scope zegt dat 300 kHz niet echt een probleem is - meer dan zat dus.
De ESP32 heeft een PCTR peripheral die gebruikt kan worden voor rotary encoders. Dat ding wordt helaas niet door de firmware ondersteunt. RS485 VFD’s worden wel al best aardig ondersteund. Inputs op een bordje van Bart hebben opto-isolatie en schmitt triggers. Kortom, er is nagedacht over ruis. PWM is prima; ADC, DAC gaat wel okee. En het is embedded, dus een real time systeem. Via RMT kan je pulses controleren op standaard pins.
Dus, klaar dan? Nou, niet echt… Ik mis nog wat diodes en zekeringen, wiring is een drama en vooral: zelfs met die 32 extra outputs kan ik nog wel wat meer I/O gebruiken… Terug naar de drawing board dus.
Ik heb zelf maar wat PCB’s geklust.
En nog maar wat iteraties gesoldeerd…
En uiteindelijk kwam ik in een vierde iteratie met wat hulp van Bram uit op dit:
Een aantal extra bordjes heb ik ook geklust die kunnen worden aangesloten via CAN bus, dat is nog een serieuze WIP...
Dit is mijn laatste versie van een bordje met:
- 4 lagen PCB’s, galvanische scheiding voor inputs, filtering, zekeringen, schmitt triggers, maw: de hele rimbam
- 8x motors
- 16x endstops (2 per axis)
- 2x 10v/5v output voor een laser en/of spindle
- 4x general purpose inputs voor low-latency werk zoals probes
- Optionele ruimte voor 9 SPI kanalen voor rotary encoders. Of voor andere outputs, we zien wel…
- Een CAN bus voor alle nice-to-have gimmicks die ik al dan niet al heb bedacht
Cable management was ik geen fan van met al die controllers, dus daar heb ik wat op bedacht. De bekabeling van mijn machine gebeurt via standaard RJ45 (UTP) kabels, zowel voor de stappenmotoren als voor de endstops. Met RJ45 breng je het signaal waar je moet zijn, vanaf daar heb ik kleine bordjes die het signaal aansluitbaar maken op je hardware. Als eindresultaat heb ik dus gewoon een bundeltje UTP en ter plekke wat kleine aansluitbordjes.
Voor de gimmicks heb ik ook al wel wat spul bedacht. Ik heb een input module gemaakt voor optical / spi rotary encoders en een bordje voor wat buttons en wat rotaries, etc. Dat is allemaal nog niet zo in beton gegoten, we zien wel. Die dingen worden aangesloten met een RJ12 kabel.
Tsja, zou het ding eigenlijk wel doen wat ik wil? Als ik het goed heb gedaan, krijg ik mooie ‘scherpe’ edges, mooie gelijke pulses en relatief weinig overshoot. Om dat te weten heb ik dus het ding aan een scope gehangen en ben me helemaal suf gaan scopen:
De pulses zijn heel mooi gelijk en met de juiste breedte, de overshoot is niet zo groot en dat alles tot dik in de 300 kHz range. Meer dan zat voor de gemiddelde stappertjes. Er zitten wel wat kleine foutjes in het eerste bordje, maar dat lossen we wel op in versie twee. Dik tevreden dus.
En na de nodige software te hebben geschreven kwamen ook de endstops en andere componenten tot leven. Ook in het echt zijn de EMI problemen tot nu toe: nul.
In principe heb ik nu dus de hardware om alles te doen wat ik wil. Voor nu draait het allemaal prima op FluidNC. Dat wil overigens nog niet zeggen dat ik ook volledig tevreden ben over de software… maar meer daarover volgende keer in “firmware”.
[
Voor 3% gewijzigd door
atlaste op 28-04-2022 14:48
]