De War Badge
Actuele versie: http://fablabamersfoort.nl/nl/fabpublicatie/poging-tot-pcb-frezen-met-de-mantis

Poging tot PCB frezen met de mantis

By matthijs on di 2 mei 2017 14:11:21
Even een PCB'tje frezen met de mantis bleek lastiger dan gehoopt. Een overzicht van problemen en oplossingen.
Machines: 

mantis

Moeilijkheidsgraad: 

Gemiddeld

Step by step instructions: 

Materiaal

Als ruw materiaal gebruik je PCB met egaal koper, waar je vervolgens sporen uit kan frezen. Dit bestaat in 2 smaken, FR2 (op papier gebaseerd) en FR4 (op glasfiber gebaseerd). Het FR4 maakt frezen sneller bot dan FR2, dus eigenlijk is alleen FR2 geschikt.

Dit materiaal vinden is wat lastig - van Hove in Amersfoort heeft er helemaal niets van. Conrad heeft er wel een van, wellicht ook andere Nederlands webshops. Het goedkoopste is waarschijnlijk via Ebay, hoewel de meeste te groot zijn - de kleinste maat leek 120x180mm te zijn, wat vrij precies op het bed van de Mantis past.

Let wel op dat je gewoon koper neemt. Er zijn ook printplaten die al een fotolaklaagje hebben, geschikt voor UV-belichting en etsen, maar dat  is bij frezen niet nodig (dus zonde van het geld en wellicht ook zwaarder voor de frees?).

Replicatorg

Onduidelijk welke settings (driver) er nodig is. Onderaan in het menu
(in een submenu) staat Ultimaker v1.0. De print op de mantis is een
Ultimaker V1.1, dus dit lijkt veelbelovend, maar werkt niet (hangt op
resetten / wacht op start).

Handmatig de seriele poort openen met minicom reset de printer (de
motoren maken even geluid) en toont daarna garbage - waarschijnlijk is
de buadrate verkeerd.

Printrun

Op aanraden van Peter heb ik PrintRun geprobeerd. Deze staat
standaard op 250000 bps, en dat werkt ook direct. Met minicom kan ik
ook op die bitrate geen zinnige output krijgen, maar het lijkt erop dat
minicom deze non-standaard bitrate niet pakt (IIR is er onder
linux een afwijkende API nodig voor niet-standaard bitrates).
Replicatorg werkt ook nog steeds niet nadat de goede bitrate in de
ultimaker.xml gezet is.

In ieder geval, PrintRun kan de printer aansturen.

Bij herhaaldelijke grote (+10cm) wijzigingen, lijkt de servo vast te
lopen. De max XY speed verlagen van 3000 mm/min naar 2000 mm/min helpt.

pcb2gcode

Als je niet alle opties op de commandline wil zetten kun je een
"millproject" bestand gebruiken met opties. Die moet wel precies zo
heten en in de huidige directory staan, pcb2gcode pakt hem dan
automatish op.

Als je zowel een outline als een front en/of back aan pcb2gcode geeft,
lijkt het erop dat de front/back leeg blijven. Door --fill-outline --outline-width 0.02 toe te voegen (niet helemaal zeker wat die laatste width precies instelt), lijkt het wel te werken.

De code die pcb2gcode genereerd bevat regels met alleen maar een X en Y
coordinaat. De firmware van de mantis lijkt die niet te snappen. Op de
pcb2gcode maillinglist wordt over, vermoedelijk, hetzelfde isse
geschreven:

> > First firmware I tried to use for my mill-controller was originally
> > meant to be used for RepRap's, and it didn't even support G00/G01
> > with multiple XY coordinates, so I had to change C++ code to output
> > each line as a separate G01 command. I have since moved on to adapt
> > grbl for my mill controller, and that works much better (supports
> > imperial units and G00/G01 command blocks).

Het gebruik van de grbl firmware lijkt dus een voordeel (wordt ook nog
druk aan ontwikkeld). Om de bestaande firmware toch te kunnen gebruiken
moet de gcode wat bewerkt worden:
 - inches naar mm met het online tooltje
 - G01 commando's toevoegen met de volgende (vim) regex: %s/^X/G01 &/ of met sed:

sed -i 's/^X/G01 &/' *.ngc

Het gebrek aan ondersteuning voor inches wordt mogelijk in de Marlin firmware (die volgens mij nu gebruikt wordt) opgelost: https://github.com/ErikZalm/Marlin/pull/978 Als alternatief zou een wijziging in pcb2gcode kunnen helpen (hier is een niet-perfecte versie: https://github.com/festlv/pcb2gcode-metric/commits/master)

Ik heb deze millfile gebruikt (waarden zijn grotendeels defaults, dus hecht
er niet teveel waarde aan):

# Based on http://reprap.org/wiki/PCB_Milling#Quickstart_2
# this is an example config file for pcb2gcode.
# place this in the same directory as your gerber files to save typing

# You may want to uncomment and change those in local project files
#front=JTAG-B_Cu.gbl
#back=Gen7Board.back.gbr
#drill=Gen7Board.plated-drill.cnc
#outline=contour.back.gbr

# parameters for isolation routing / engraving / etching
zwork=-0.008
zsafe=0.8
zchange=1.0
mill-feed=6
mill-speed=30000

# parameters for cutting out boards
cutter-diameter=0.059055118
zcut=-0.08
cut-feed=3
cut-speed=20000
cut-infeed=1

# drilling parameters
zdrill=-0.08
drill-feed=3
drill-speed=20000

offset=0.010
# generate voronoi regions
#offset=1.0
dpi=1000
#max-deviation=0

Wat pcb2gcode ook niet helemaal handig doet is de frees- en boorvolgorde. De sporen en gaten worden gedaan van links naar rechts, boven naar beneden, wat lang niet altijd de meest efficiente volgorde is. Ook lijken verplaatsingen met de freeskop omhoog niet sneller te gaan dan normaal, wat met name bij het boren (vanwege de langzame Z-verplaatsing) onnodig vertraging oplevert. Ik weet niet goed hoe dit zou moeten werken - bij alle commando's een F-optie geven zou helpen, maar je zou verwachten dat iig de G00 (snelle verplaatsing) en G01 (preciesieverplaatsing) allebei een eigen laatst opgegeven snelheid bijhouden, maar dat lijkt toch niet zo te zijn. Wellicht een beperking van de firmware?

grbl firmware

grbl is gemaakt voor het aansturen met een uno ipv een mega (er zijn
minder pinnnen nodig omdat er maar 3 assen zijn, geen
temperatuursensors, etc.). Aansturen met een mega kan ook (er is een pin
mapping aanwezig in cpu_map.h, maar die klopt niet met het gebruikte
ultimaker shield).

Om de mantis, met het ultimaker shield te kunnen gebruiken zou cpu_map.h
aangepast moeten worden. Echter, bij het uitzoeken van de pin mapping
blijkt dat grbl vereist dat alle direction pins op dezelfde poort
zitten en alle step pins op dezelfde poort zitten. Bij het ultimaker
shield is dit niet het geval, de pins zitten per as gegroepeerd (dus
eerst alle X pinnen, dan alle Y, etc.) waardoor de pinnen per type op
verschillende poorten komen.

Om dit op te lossen zou de code van grbl ingrijpend moeten worden
aangepast, met vermoedelijk performance-verlies tot gevolg. Dit lijkt
dus niet echt haalbaar.

Nulpunt

Als je in Kicad je PCB mooi midden op je scherm tekent, ipv in de hoek
(waar er een kantlijn door je ontwerp zou gaan lopen), dan worden de
uiteindelijke coordinaten in de gcode ook veel te hoog (de linker
bovenhoek van het document in Kicad komt dan overeen met de startpositie
van de mantis.

Omdat dat niet zo handig is, wil je kunnen bepalen waar de 0,0 van de
gcode komt te liggen. Op internet las ik ergens dat pcb2gcode de 0,0
automatisch linksboven in het ontwerp zou leggen, maar dat lijkt niet te
gebeuren (wel voor de PNG files die gegenereerd worden, dus als je die
over elkaar wil leggen, genereer dan altijd alle files tegelijkertijd).

Gelukkig kan het wel in Kicad, door te gebruik te maken van de
(onuidelijk genoemde) auxilary axis. Met "Place -> Drill and place
offset" (ook in de rechter toolbar te vinden) kun je het nulpunt van de
"auxilary axis" instellen.

Bij het exporteren kn je er vervolgens weer voor kiezen om de auxiliary
axis als nulpunt te gebruiken. Onder "File -> Plot" is er een optie "Use
Auxiliary axis as origin" voor de gerber files en vervolgens onder
"Generate drill file" is er "Drill origin: Auxiliary axis".

Merk op dat dit ding los staat van de "Grid origin" (vanuit waar het
grid gaat tellen, vaak wel nuttig om op in een hoek of het midden van je
ontwerp te plaatsen) en "layer alignment targets" (wat vermoedelijk een
soort van markeringen zijn die in het resultaat getoond worden).

Om in de mantis het nulpunt in te stellen kun je met de hand de frees op de goede plek zetten (met de controls in PrintRun) en dan op "reset" drukken om de Mantis te resetten. bij het opstarten stelt de Mantis de hudige positie in als nulpunt.

OpenSCAM

Dit is een tooltje wat de gegenereerde gcode files can simuleren om zo
het resultaat te previewen. Bij de koperlaag werkte de automatische
werkstukgeneratie niet zo goed (hij kwam te hoog uit, maar handmatig de
Z-offset aanpassen verhielp dit.

Later bleek dat er ook gewoon een veel makkelijker onlinetooltje beschikbaar is om pcb gcode te visualiseren: http://fablabamersfoort.nl/gcodevisualizer/

Gespiegelde assen

Bij een gedeeltelijk testprintje op karton leek het erop alsof de orientatie van de assen niet helemaal klopte. Het printje was gedraaid tov van het ontwerp. Echter, omdat het de onderkant van de PCB was, had hij eigenlijk over de Y-as gespiegeld moeten zijn. Wellicht is er dus, om wat voor reden dan ook, een spiegeling over de X-as opgetreden, wat samen een rotatie lijkt?

Nader onderzoek laat zien dat het resultaat inderdaad over de X-as opgetreden is (dwz, de Y-coordinaten zijn geinverteerd). Waar dat precies zit is natuurlijk niet helemaal duidelijk - ofwel Kicad heeft een rare orientatie (origin is top-left), ofwel het feit dat de Mantis het platform verplaatst ipv de freeskop zou de oorzaak kunnen zijn.

Twee mogelijke oplossingen: In de gcode de Y coordinaten te inverteren (negatief -> positief en v.v.), ofwel bij pcb2gcode de front en back te verwisselen. Dit laatste zorgt ervoor dat zowel front als back geinverteerde X-coordinaten heeft (pcb2gcode spiegelt de achterkant op die manier). Vervolgens heb je over beide assen gespiegeld, wat in feite een rotatie oplevert (je krijgt je PCB dan dus ondersteboven). Ik realiseer me net dat deze methode niet voor outline en drill werkt, dus wellicht dat de eerste optie handiger is.

In gcode inverteren kan met sed (xxxxxx is hier een tijdelijke placeholder die verder niet in de file zou moeten voorkomen):

sed -i 's/ Y-/xxxxxx/;s/ Y/ Y-/;s/xxxxxx/ Y/' *.ngc

Freesbreedte en freesjes

De breedte van de uitgefreesde isolatiebanen bepaald natuurlijk voor een groot gedeelte de beperkingen op het PCB ontwerp. Ik heb nu scherpe en puntige freesjes gebruikt (uit een apart bakje waar een stuk of 10 dezelfde in zitten, elk met een blauw rubber dopje). Het puntje daarvan is behoorlijk klein, wat doet vermoeden dat er smal gefreesd kan worden. Echter, het lijkt erop dat het freesje niet helemaal netjes om z'n as draait. Als de frees gewoon stil hangt en je hem naar beneden draait tot ie het PCB oppervlak net raakt, zie je dat er een rondje uitgefreesd wordt, met in het midden nog een stipje koper. Het puntje draait dus om het middelpunt heen, ipv dat de hele frees om het puntje draait. Dit rondje heeft een diameter van ongeveer 0,5mm, wat dus direct de minimum isolatiebreedte definieert. Door de frees zo diep mogelijk in de kop te steken, wordt het effect van het gewiebel van de frees ietsje kleiner - je komt dan op een freesbreedte van 0,4mm uit.

Wanneer je het freesbitje dieper in de kop steekt, let dan wel op dat bek van de kop nog wel goed grip heeft op de schacht van de frees en niet ten hoogte van het schuine stuk van het freesbitje terecht komt, dan heeft de bek te weinig grip. Verder moet de frees (of het boortje) ook nog voldoende uitsteken, aangezien de freeskop op een gegeven moment niet verder naar beneden kan (let op - er zit een microswitch die ervoor zorgt dat je hem via software nog net een paar millimeter minder diep kan krijgen dan fysiek mogelijk zou zijn).

Naarmate de freespunt wat meer gebruikt is en sluit wordt het freesspoor ook weer groter, het lijkt erop dat dat al snel 0,1mm scheelt, op langere termijn wellicht nog meer.

Naast de scherpe, puntige freesjes heb ik ook wat "normale" dremelfreesjes uit een assortimentsdoosje gebruikt. Dit waren freesjes zoals deze:

De twee puntigste (ééntje ongeveer de meest rechter op het plaatje, de andere staat er niet tussen) kunnen ook ongeveer 0,5mm á 0,7mm frezen. Ik weet niet of ze het ook wat langer uithouden of snel slijten, ik heb maar een paar millimeter geprobeerd.

Zie ook de Reprap wiki over freesbitjes.

Sporen frezen

Freesdiepte vaststellen is het handigst door de frees aan te zetten en dan de freespunt langzaam naar beneden laten zakken (met de hand aan de Z-as te draaien, or in PrintRun de -0.1mm knop te gebruiken). Zodra de freespunt iets het materiaal in hapt, haal je de frees 1mm naar boven via PrintRun, zet je de frees uit en reset je de mantis (via de resetknop in PrintRun). Dit zorgt ervoor dat de huidige positie als nulpunt gedefineerd wordt. Door vervolgens de freesdiepte op 1mm (0.04") in te stellen in pcb2gcode, komt de frees tijdens het frezen van de sporen precies zo laag als je hem met de hand had gebracht). Dit lijkt alleen niet te werken icm met de outline in meerdere passes frezen (zie verderop), die freest altijd in gelijk passes beginnende bij 0mm. Hiervoor is het dus handiger om het nulpunt echt precies boven, of zelfs precies op de gewenste spoorfreesdiepte in te stellen.

Na het frezen is het oppervlak van de PCB behoorlijk ruw: langs randjes kan er koper omhoog gaan staan wat net niet helemaal goed afgesneden is (dit gebeurt niet altijd, wellicht dat het gerelateerd is aan de freesdiepte). Het kan zo lijken dat de sporen los komen van de PCB of te smal zijn, maar na er een fijn schuurpapiertje (eerst 120, dan 400 werkte voor mij) overheen gehaald te hebben, ziet het er toch netjes uit. Wellicht dat het nog zou helpen om de dremel sneller of langzamer te zetten, hij stond nu op stand 3.

Verder waren niet alle sporen goed uitgefreesd, het lijkt erop dat de PCB niet zuiver vlak ligt. In de linker onderhoek van de PCB begon de frees over het koper heen te schampen zonder het weg te frezen. Om dit op te lossen probeerde ik te pauzeren, de motors uit te zetten, de frees met de hand een fractie naar beneden te draaien en weer verder te frezen. Ik meen dat dat één keer heeft geholpen, bij de volgende twee pogingen sloeg de kop op hol bij het resumen (hij ging naar heel ver links onder en ging weer naar beneden - ik weet niet of ie gewoon verder ging of ook de Z-as verkeerd terecht kwam omdat ik hem snel heb gereset). Jammergenoeg zorgde deze reset er wel voor dat mijn nulpunt ook gereset is, dus het tweede gedeelte van de PCB is net 0,3 a 0,4 mm verschoven.

Daarna heb ik gecorrigeerd door terug te gaan naar 0,0,0, te corrigeren, te resetten en opnieuw te beginnen. Om de al uitgefreesde sporen niet opnieuw te doen heb ik de gcode ge-edit en de al afgeronden sporen eruit gegooid. In dit ontwerp ging dat makkelijk omdat er een lange rij van vierkante pads in zitten die in de gcode goed herkenbaar zijn, maar mbv de gcode visualizer en wat trial en error moet het anders ook wel kunnen.

Bij de laatste correctie heb ik vermoedelijk overgecorrigeerd, want het onderste stuk van de PCB lijkt wat dieper uitgefreesd te zijn (nauwelijks merkbaar aan de diepte van de isolatiesporen, maar de kleur van de sporen is iets anders en ze zijn breder, wat mij doet vermoeden dat er dieper gefreesd is. Het zou ook aan iets anders kunnen liggen (freesje bot geworden, of los gaan zitten in de Dremel?). Wat ook zou kunnen meespelen is dat dit traces zijn die erg dicht op elkaar liggen. Op zichzelf liggen ze ver genoeg uit elkaar en pcb2gcode klaagt niet dat de offset overschreven wordt, maar aangezien twee aangrenzende sporen allebei afzonderlijk uitgefreesd worden, gaat de freeskop twee keer over de isolatie tussen de twee kopersporen in - wellicht dat dat ook de kopersporen versmalt?

Hoe dan ook, de extra isolatiebreedte heeft er voor gezorgd dat een aantal van de onderste kopersporen te smal zijn geworden (hier en daar zelfs helemaal geen koper meer) en deze PCB niet meer bruikbaar gaat worden. Wellicht is het dus verstandiger om, waar mogelijk, bredere sporen te gebruiken. Nu heb ik een track width van 0,015" (0,38mm) en clearance van 0,020" (0,50mm) gebruikt. Op zich lijkt dit dus wel haalbaar (meer dan de helft van de PCB is prima geworden), maar het lijkt erop dat het onder sommige omstandigheden (niet helemaal duidelijk welke, misschien niet-platte PCB of een botte frees, of nog iets heel anders) toch niet goed gaat. Iets bredere tracks zouden hier kunnen helpen. In een volgende poging gebruikt ik tracks van 0,5mm.

Bredere tracks kun je in Kicad ontwerpen, maar het lijkt ook mogelijk om in pcb2gcode gewoon een grotere offset op te geven. De offset is de afstand van de freeskop tot de kopersporen en is normaal gesproken de helft van de tool diameter. Door deze groter te maken (wat in feite ook kloppend is als de tool diameter in feite breder is dan gehoopt) houdt pcb2gcode meer afstand. Als er in Kicad toch sporen (te) dicht op elkaar liggen, gaat pcb2gcode klagen dat ie de clearance requirements niet kon vervullen. In de praktijk betekent dit dat de freeskop dan maar precies tussen twee kopersporen door gaat. Oftewel, daar waar ruimte is worden de sporen breder gemaakt, daar waar geen ruimte is blijven ze smal (en hopelijk dan niet te smal).

Draaisnelheid

Bij het frezen van de sporen en het boren heb ik in eerste instantie (voor v1, v2 en de gaten van v3) stand 3 gebruikt van de Dremel. Bij v3 heb ik met een paar spoortjes geexperimenteerd met snelheid 1-4, maar er leek weinig verschil. De rest van de sporen van v3 heb ik dus op stand 1 uitgefreesd, dan maakt de machine (iets) minder lawaai. Wellicht dat dit nog anders is wanneer de verplaatsingssnelheid tijdens het frezen (mill-feed in pcb2gcode) anders is, maar de nu gebruikte 6"/min (150mm/m) leek prima en snel zat (frezen van de sporen duurde ong 10 minuten, boren van gaten ongeveer 25, waarschijnlijk vanwege de trage verplaatsing).

Online wordt gezegd dat een hogere draaisnelheid beter is, omdat je dan sneller kan frezen. Dit suggereert dat de verplaatsingssnelheid wellicht nog flink omhoog kan.

Bij het boren is een andere draaisnelheid wellicht ook nog handig, maar daar heb ik nog niet mee geëxperimenteerd.

Outline frezen

Het frezen van de outline kan waarschijnlijk ook met dezelfde frees, maar kan niet in 1 pass gebeuren. Een freesdiepte van 1,5mm (met het nulpunt op 1mm, dus 0,5mm het materiaal in) leek al teveel, de frees klinkt alsof ie er moeite mee heeft. Dmv de --cut-infeed optie kun je pcb2gcode vertellen om de outline in meerdere passes te doen. Een --cut-infeed van 0.01" (== 0.254mm) lijkt wel aardig te gaan. Ik heb dit geprobeerd met een zcut van 0.04, wat 5 passes oplevert (eerste pass is op 0 diepte). Dit ging prima, hoewel de 3e en 4e pass wel iets moeizamer gaan dan de eerste twee. Voor dit outline frezen is het waarschijnlijk goed om een botter freesje te gebruiken, dan slijten de nieuwe freesjes niet zo snel.

Voor het frezen van de outline wil je eigenlijk dat er onderbrekingen in zitten, zodat de print vast blijft zitten tijdens het frezen. Als je de hele PCB dikte wegfreest langs een ononderbroken rechthoek zal op het laatst de PCB los gaan zitten, met kans dat eea gelanceerd wordt. Wellicht is dit op te lossen door eerst te boren en door de boorgaatjes wat spijkertjes te zetten, maar onderbrekingen in de outline zijn waarschijnlijk beter (maar zo te zien niet mogelijk in pcb2gcode?).

Bij versie 2 heb ik met de hand onderbrekingen toegevoegd (alleen in de laatste 4 passes om moeite te besparen). Als je dit doet kun je helemaal door frezen. De PCB is ongeveer 1.5mm dik, ik heb uiteindelijk tot ongeveer 1.7mm gefreesd om hem er helemaal uit te krijgen.

Omdat het frezen van een outline voor zo'n puntige frees eigenlijk wel heel veel werk is, hij waarschijnlijk snel bot wordt en er eigenlijk niet zo'n precisiefrees nodig is, heb ik ook een wat grotere, rechtere frees geprobeerd. Ongeveer van de vorm van 116 hieronder, 115 zou nog iets beter zijn:

Wellicht zijn er nog geschiktere freesjes, maar deze leek al prima te voldoen en zit vaak in gewone dremel assortimentsdoosjes. Het outline frezen lukt hiermee ook in één pass, wat een hoop tijd scheelt.

Het lijkt wel belangrijk te zijn dat de frees niet te groot is - een diameter van 3mm werkte prima, 4,5mm verbrandde het freesje. Het is niet helemaal zeker dat dit aan de diameter ligt, het is nog een beetje de vraag of dit type frees uberhaupt echt geschikt is of dat het wellicht te snel slijt.

Gaten boren

Normaal gebruikt pcb2gcode zogenaamde "canned cycles" (G81 code) voor het boren. Dit wil zeggen dat in de gcode een G81 code staat die specificeert hoe een gat geboord moet worden (hoe diep, hoe snel, hoe ver terug). Vervolgens staat er een lijst met XY coordinaten, waar voor elk coordinaat die canned cycle uitgevoerd zou moeten worden. Helaas ondersteunt de mantis / Marlin firmware geen canned cycles. Pcb2gcode heeft ook nog een --milldrill optie die gaten kan boren met een normale freeskop, door met de frees te plungen en dan de freeskop in een rondje te laten bewegen. Echter, dit werkt natuurlijk alleen met een rechte frees, niet met de puntige die wij gebruiken. Wellicht zou het kunnen om de offset (== halve tool width) zo in te stellen dat die de tool width precies overeenkomt met de gatgrootte. Wellicht dat pcb2gcode de G2 code voor het draaien van een rondje weglaat. Echter, het lijkt er op dat --milldrill ook variabelen gebruikt, die Marlin waarschijnlijk ook niet ondersteund.

Er is een patch voor pcb2gcode die de --primitive-gcode optie toevoegt. Deze zorgt ervoor dat ipv de G81canned cycle, losse codes gebruikt worden om de boorkop apart aan te sturen. Dit lijkt beter te werken. http://sourceforge.net/p/pcb2gcode/feature-requests/11/

Om een klein boortje (0.8mm) te gebruiken, heeft de Dremel ook een ander klemmetje (dat messing busje dat in de kop zit) nodig. De kopjes die ik in het Fablab kon vinden waren allemaal (veel) te groot. Met een klemmetje van mijn eigen dremel lukt het net om een 0,8mm boortje in te klemmen, kleiner dan dat wordt het niet (later vond ik in het Fablab nog een klemmetje wat ook klein genoeg is, zit bij de freesjes bij de Mantis). Dit gaat over normale boortjes (uit een speciaal Dremel-setje zelfs), waar de schacht even dik is als de boor. Er ligt in het Fablab een doosje met velleman boortjes waarbij de schat dikker is dan het boortje zelf. Hiervoor is nog steeds een smaller kopje nodig, maar hij hoeft minder klein te zijn. Het kleinste boortje uit dat Vellemansetje leek een beetje krom, dus ik heb bij versie 2 (zie verderop) de één-na-kleinste (0,7mm) gebruikt. Overigens leken de Vellemanboortjes grotere gaten te boren dan ze beloofden, maar wellicht had ik niet het goede boortje (ze zitten op volgorde in het doosje maar zijn verder niet gelabeld), of wellicht dat vooral de ingang van het gat wat groter is (vanwege het wiebelen, zie onder).

Bij het boren wiebelt de top van het boortje een beetje, dus bij het dalen van de boorkop schampt ie eerst een beetje over het koper heen, todat er een gat ontstaat wat de top van de boor stabiliseert. Het lijkt erop dat hierdoor de boor op den duur  nog wel eens zou kunnen breken. Door de daalsnelheid te beperken wordt dit effect verminderd en gaat het boren soepeler. Waarden van F35 en F50 (mm/min) leken goed te gaan. Ik gebruik nu verder 40 mm/min (1.57"/min, dus drill-speed=1.57 in het millproject).

Bij het boren in kleine pads (zelfs in versie twee van 1.5mm) die verder nergens aan vast zitten werd vaak al het koper van de PCB getrokken. Dit gebeurde met name bij het omhoog gaan van de boor, dan wiebelt de top nog even rond als ie net uit het gat komt en neemt ie het koper mee. Het verhogen van de snelheid bij het omhooggaan naar 200mm/min helpt hier redelijk tegen (kan alleen via editen van de gcode source lijkt het, F200 toevoegen, maar dan ook F40 oid toevoegen bij alle naar-beneden-commando's).

Met een boortje van 0.8mm in pads van 1.27mm diameter is het lastig om goed genoeg in het midden uit te komen en blijft er weinig koper over. In de ietd grotere pads van 1.5mm die KiCad standaard gebruikt gaat het al een stuk beter, wellicht dat een boortje van 0.6mm ook nog zou helpen (mits de pootjes van componenten dan nog passen...). Een ander probleem is dat boren vlak naast de rand van een pad er voor kan zorgen dat het boortje de isolatiegeul ingetrokken wordt. Dit is waarschijnlijk te verhelpen door eerst te boren en dan te frezen (is misschien sowieso handig).

Voor de boorpositie is het handig om de frees met een handmatig G0 X0 Y0 naar 0,0 te bewegen. Dan met de hand opnieuw de diepte instellen (boor tegen de PCB aan, komt niet heel nauw) en de frees resetten (zodat de huidige positie 0,0,0 wordt). Bij het plaatsen van de boor moet je overigens wel oppassen dat de frees niet beweegt (waarschijnlijk komt de as niet iets anders uit als je de dremel als geheel draait in de Mantis, nog geen last van gehad).

Qua boordiameter blijkt 0.7mm of 0.8mm prima voor de meeste through-hole componenten (weerstandjes, diodes, etc.). Voor (male) pin headers bleken ze echter te klein. Die hebben vierkante pinnen met zijden van 0.7mm (dus 1.0mm diagonaal). Boren met een boortje van 1.0mm lijkt te werken, misschien 0.9mm ook al wel. Through-hole ICs hebben vaak rechthoekige pinnen en vermoedelijk nog iets grotere gaten nodig.

Als je bij het boren verschilende boordiktes gebruikt, groepeert pcb2gcode de boorgaten op dikte en zitten er pauseer-instructies bij, zodat je het boortje kan verwisselen. Helaas ondersteunt de gebruikte firmware (of PrintRun, ik weet niet precies wie dat zou moeten doen) deze instructies niet, waardoor ie in één keer door gaat. Om toch van boortje te kunnen wisselen heb ik de gcode met de hand gewijzigd om steeds maar 1 boordikte tegelijk te doen.

Vergeet ook niet om bij het wisselen van de boor opnieuw de boordiepte in te stellen (door naar 0,0 te gaan, de Z-as ook op 0 te zetten en te resetten).

rapid-pcb.com

Als alternatief voor pcb2gcode lijkt http://rapid-pcb.com wel wat. Ik heb er even naar gekeken, maar er lijkt geen mogelijkheid om de settings te exporteren, meerdere files (voorkant, achterkant, etc.) tegelijk te uploaden, er is geen source beschikbaar, het lijkt niet te werken in (iets oudere?) Firefox.

chilipeppr.com

Als alternatief voor Printrun lijkt dit een aardige tool. Hij is web-based met een simpel serial->websocket servertje voor toegang tot de hardware en een realtime preview van het proces. De tool ondersteunt echter alleen standaard baudrates, dus de 250.000 die de Mantis gebruikt werkt niet.

Temperature errors

Af en toe bij het aanzetten van de Mantis, klaagt ie over de extruder temperature. Een paar keer resetten lost dit meestal op. Ergens tijdens het printen kreeg ik ook klachten over de maximum extruder temperature, resetten hielp niet, maar de USB ontpluggen en repluggen gelukkig wel.

Dit zal wel een bij-effect zijn van het gebruik van een 3dprinter firmware. In principe zijn er geen temperatuursensors aangesloten, maar wellicht is er op het bordje nog een interne sensor? Of leest ie bogus readings?

Voorzichtig met het freespuntje.

Zorg bij het wisselen gereedschap (bitjes) dat je het bitje vast houdt bij het losdraaien. Als je de kop opendraait valt anders de frees eruit en breekt het punten.

Zorg er verder voor dat je nooit een zijwaartse beweging maakt, zonder draaiende frees, wanneer de freespunt in het materiaal zit - de freespunt breekt dat direct af. Altijd voor je handmatig / via Printrun een beweging maakt, controleren dat de freespunt hoog genoeg is.

Versie 2

Na een eerste PCB gefreesd te hebben (maar niet echt uitgezaagd, niet alle traces klopten helemaal), is het tijd voor een tweede versie. Ik heb het volgende gewijzigd:

  • De kleinste vierkante pads waren 1,27mm groot, die zijn nu 1,5mm groot om het boren te vergemakkelijken
  • De traces waren 0,38mm (0.015") en zijn nu 0,5mm om wat extra speling te hebben
  • Ik heb eerst de outline gefreesd met een zcut van 0 (dus 1 pass op diepte 0). Daarbij bleek dat ik de nuldiepte wat te laag had gezet. Daarom heb ik zwork (spoorfreesdiepte) op 0.008" (0.2mm) gezet, dit leverde precies de goede diepte op voor de sporen.
  • Het freesje lijkt wat botter te worden, na 1 trace gefreesd te hebben heb ik de isolatiebreedte gemeten op 0,8 mm. Ik heb daarom de offset (halve freesbreedte) aangepast naar 0,016" (0,8mm). pcb2gcode klaagt dan dat de clearance requirements niet overal voldaan kunnen worden, maar dat nemen we maar voor lief - hij gaat op de knelpunten nu als het goed is precies tussen de traces door. Overigens heb ik later nog een paar testjes gedaan met hetzelfde freesbitje en kwam ik daarmee nog op 0,5mm uit (0,6mm wanneer het bitje erg ver uit de kop steekt), dus ik weet even niet goed waarom de isolatiebreedte zo hoog uit kwam eerder.
  • Ik heb nu eerst een "Velleman" boortje van 0,7mm gebruikt ipv 0,8mm ("Dremel"). Deze leek echter eigenlijk alleen maar grotere gaten te maken en ook het koper van de PCB te trekken, dus ik ben terug naar de 0,8mm "Dremel" boor gegaan. Deze liet het koper ook niet netjes zitten, maar na aanpassen van de opwaartse snelheid ging dit al een stuk beter. Wellicht dat dit ook met het "Velleman" 0,7 mm boortje beter zou gaan. Wellicht dat de draaisnelheid van de dremel aanpassen ook nog zou kunnen helpen - verschillende boordiktes en vormen hebben verschillende optimale boorsnelheden.

Na het uitfrezen is het bordje in elkaar gezet en werkte het. Er waren een aantal verbindingen met de kleine vierkante pads aan de zijkant die net niet helemaal goed pakten, maar of dat nou aan de sporen of de soldeerverbinding (die wat moeite had met de kleine pads) lag, was niet helemaal duidelijk. Resultaat: (op de achtergrond ligt versie 3)

IMG_0037.JPG

Verder bleek er een fout in het ontwerp te zitten, de pin headers zaten te dicht op elkaar, waardoor een normale flatcableconnector niet paste. Tijd dus voor een versie 3.

Versie 3

Hierbij was dus het ontwerp in Kicad wat aangepast en heb ik geprobeerd eerste te boren en dan pas te frezen

Eerst boren lijkt goed te werken, de pads zijn nu allemaal heel gebleven. Echter, de isolatiebreedte die de frees wist te realiseren was nu een heel stuk smaller (rond de 0,4mm, zelfs met een iets botter freesje) dan bij versie 1 en 2, om redenen die ik niet goed kan doorgronden. Het lijkt niet te verklaren door:

  • Een ander freesje - volgens mij heb ik exact hetzelfde freesbitje gebruikt
  • De frees minder ver laten uitsteken (dus meer zwabberen) - ik heb voor versie 3 wat proefjes gedraaid waaronder met een ver uitstekende frees
  • De freesdiepte - Op het oog is de freesdiepte vergelijkbaar (wellicht is v3 zelfs een fractie dieper). Verder is de hoek van de frees zo flauw dat een paar tiende millimeter extra diepte minder dan een tiende millimeter extra breedte op zou leveren.

Een mogelijke oorzaak lijkt te zijn dat misschien de dremel niet helemaal goed in de houder gezeten heeft. Ik heb bij versie 3 geprobeerd om de frees zo diep mogelijk in de dremel te steken, waardoor de freeskop niet altijd laag genoeg kwam. Om dat toch te laten werken heb ik extra opgelet dat de frees zo laag mogelijk in de houder zit, maar dat levert ook direct een hoop stabiliteit op. Met opzet de Dremel hoog (losjes) in de houder zetten zorgt weer voor freessporen van ongeveer 0,7mm (lijken nog net iets smaller dan op versie 2).

IMG_0035.JPG

Versie 4

Om de verplaatsingssnelheid te fixen (dwz dat snelle verplaatsingen met de freeskop omhoog met het G00 commando ook echt snel zijn heb ik met deze commando's de gcode nabewerkt:

        sed -i 's/^G00\? /&F1000 /' *.ngc
        perl -pi -e 'if (/^G0?1.*( F[0-9.]+)/) { $$F=$$1; } else { s/^G0?1 /$$& $$F /; }' *.ngc

Hierdoor krijgen alle G00 commandos een snelheid van 1000mm/min, maar omdat de Mantis gewoon de laatste snelheid onthoudt, gaat dit ook gelden voor all G01 commando's. Daarom onthoudt het perl scriptje steeds de snelheid van het G01 commando en voegt het script die snelheid toe aan alle G01 commando's.

Met deze wijziging lukt om in ongeveer 45 minuten een printje te frezen (ongeveer 20 minuten machine-tijd en 25 minuten wisselen van gereedschap wisselen).

Bij het frezen van de outline liep ik wel tegen problemen aan - het freesje begon te verbranden en te roken. Ik heb geprobeerd minder diep te frezen, minder snel te draaien, minder snel te verplaatsen, allemaal zonder resultaat. Achteraf bleek dat de kopse kant van het freesje helemaal was afgesleten, maar het is niet duidelijk of dat vooraf al zo was of tijdens het frezen gebeurd is. Verder bleek dat ik een ander freesje gepakt had dan bij versie 3 - de vorm was hetzelfde, maar de diameter was 4,5mm ipv 3mm. Vermoedelijk zorgt de extra diameter ervoor dat het freesje te snel draait, of wellicht was dit freesje al bot vooraf. Het doet wel de vraag rijzen of dit type freesje wel echt geschikt is voor outlines.

Verder leek het alsof er bij het frezen helemaal geen braamvorming was, ik kan me in ieder geval niet herinneren dat ik schuurpapier gebruikt heb. Wellicht heb ik me dit verbeeld, want bij versie 3 was er wel behoorlijke braamvorming. Deze pagina suggereert dat braamvorming veroorzaakt door een te lage verplaatsingsnelheid (ten opzichte van de draaisnelheid) en wordt verergerd door trilling. Wellicht dat het vastzetten van de dremelkop heeft bijgedragen aan het reduceren van de trillingen en daarmee de braamvorming. Het lijkt er ook op dat versie 4 iets dieper gefreesd is, wellicht dat dat ook helpt.

Nieuwe controller

Om toch grbl te kunnen gebruiken, vervang ik de electronica door een Arduino Uno met een grblshield van protoneer. Hier staat nu de laatste versie van grbl op (git master, dus nieuwer dan 0.9). Voor de historie, dit is de oude setup:

En dit is de nieuwe in wording:

IMG_0050.JPG

GRBL moet verder nog geconfigureerd worden.

De gebruikte stappenmotor is een 17pm-h103-p2 (voor alledrie de assen dezelfde). Deze heeft 200 stappen / rotatatie (1.8°/stap), verdere specs ontbekend (datasheet is onvindbaar, fabrikant heeft niet op een vraag gereageerd).

De schroefdraad op de assen heeft 3mm afstand tussen 2 "tanden" van de schroefdraad. Er zijn 2 afzonderlijke spiralen, dus 6mm / rotatie

Dat betekent dus:
 - 200 stappen / 6mm = 33 1/3 stap / mm
 - Met 1/16 microstep -> 533 1/3 stap / mm

Polulu A4983 stepper drivers http://www.pololu.com/product/1201
  - minimum pulse width 1us, grbl kan niet minder dan 3us (maar langer zou geen probleem moeten zijn).

X
 - Feedrate: 3350 mm/min stalled, 3300 mm/min gaat nog goed. 3000mm/min ingesteld. Later stalde 2650 wel, 2600 (net) niet.
 - Acceleratie: 65mm/s/s stalled, 60mm/s/s gaat wel goed. Ingesteld op 50mm/s/s. Later lukte 250mm/s/s ineens wel, 500mm/s/s niet meer. Dus maar ingesteld op 250mm/s/s

Y
 - Feedrate: 4750 stalled, 4500 werkt wel. Ingesteld op 4000 mm/min.
 - Acceleratie: 1000mm/s/s werkt nog zonder problemen, dus eigenlijk is een slow-start niet zo nodig. Ingesteld op 250mm/s/s, is nagenoeg instant.

De stepper drivers hebben een potmetertje waarmee je de maximale stroomsterkte kunt instellen. Volgens de datasheet kun je vref meten (klein koperen pad op de PCB) en met 2,5 vermenigvuldigen om de stroomsterkte te krijgen. De ingestelde waarden waren:

 - X: Vref 0.30 -> Imax 0.75
 - Y: Vref 0.15 -> Imax 0.375
 - Y: Vref 0.27 -> Imax 0.675

Het lijkt erop dat de _hogere_ current limit van de X-as de snelheid beperkt. Als ik vref naar 0.15 draai, waardoor de current limit omlaag gaat, kan de X-as ook sneller. Ergens lijkt dit tegenstrijdig (meer current zou meer snelheid moeten opleveren), maar wellicht dat de 0.75A boven het maximum van de motoren ligt? Wellicht dat dat ook verklaart waarom de waargenomen maxima nog wat varieerden. Specs van de motoren zijn jammergenoeg nergens te vinden...

Met een vref van 0.15V op de X-as reageert deze net als de Y-as qua acceleratie en snelheid, dus die is nu ook hetzelfde ingesteld (4000mm/s, 250mm/s/s).

De Z-as heb ik ook meteen op 0.15 gezet, aangezien dit ook dezelfde motor is (labeltje is niet zichtbaar, maar toen de motor even los was heb ik het nummer gecontroleerd).  Daarmee liggen de max rate en acceleration values op hetzelfde als de andere assen. Wellicht kan het verstandig zijn om op de Z-as nog wat lagere snelheid te laten draaien (dat lijkt gebruikelijk te zijn), maar voor nu zet ik ze allemaal op 4000mm/s.

Endstops

Om te zorgen dat een homing cycle mogelijk werd, was er één extra limit switch nodig (de bestaande limit switch op de Z-as triggert op het laagste punt, maar als er een freesbitje in de Mantis zit kun je geen homing cycle doen door de kop helemaal naar beneden te draaien, dan breek je mogelijk je freesbitje). Er moest dus een tweede limit switch op de Z-as bij. Omdat ik dan toch bezig was heb ik:

 - Een tweede limit switch op alle assen gezet, zodat de Mantis nooit buiten z'n werkgebied kan komen.
 - De bestaande limit switch op de Y-as verplaatst. Deze zat op het bed gemonteerd, maar zit nu in de achterwand. Dit maakt het bed mooi leeg en voorkomt dat de draad voortdurend heen en weer beweegt.
 - De limit switches normally-closed gemonteerd (ipv normally-open).  Dit zorgt ervoor dat, als de bekabeling ooit kapot gaat, of de limit switch per ongeluk losgaat, de mantis uit gaat, ipv doorwerkt zonder werkende limit switches.

Om normally-closed switches zonder externe pullup weerstanden werkbaar te maken was er een wijziging in de grbl software nodig, zie deze bugreport: https://github.com/grbl/grbl/issues/542

IMG_0051.JPGIMG_0052.JPGIMG_0056.JPG

Werkruimte

Van endstop tot endstop is het:

 - X: 192mm
 - Y: 143mm
 - Z: 40mm

Deze waarden zijn ook ingesteld als max travel values, waarmee grbl de soft limits berekend (dwz, stoppen als de machine zou beginnen aan een beweging die buiten het bed zou uitkomen).

Kabels

Diverse kabels zijn nu ook beter weggewerkt. Er is een trekontlastig toegevoegd op de power en usb kabels en de kabels die naar de bewegende freeskop lopen zijn nu gebundeld en op de achterwand vastgezet, zodat de kans wat minder groot is dat er ergens iets blijft hangen.

IMG_0054.JPG

De voeding van de steppermotors heeft schroefcontactjes voor het aansluiten van de diverse kabels. Dit betekent dat de 220V aansluiting redelijk bloot ligt. Iemand anders gaat een kapje maken om deze contacten af te schermen.

GRBL settings

Uiteindelijk levert dit de volgende settings op:

$0=3 (step pulse, usec)
$1=25 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=0 (dir port invert mask:00000000)
$4=0 (step enable invert, bool)
$5=1 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=3 (status report mask:00000011)
$11=0.020 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=0 (report inches, bool)
$14=1 (auto start, bool)
$20=1 (soft limits, bool)
$21=1 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=0 (homing dir invert mask:00000000)
$24=20.000 (homing feed, mm/min)
$25=1000.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=2.000 (homing pull-off, mm)
$100=533.333 (x, step/mm)
$101=533.333 (y, step/mm)
$102=533.333 (z, step/mm)
$110=4000.000 (x max rate, mm/min)
$111=4000.000 (y max rate, mm/min)
$112=4000.000 (z max rate, mm/min)
$120=250.000 (x accel, mm/sec^2)
$121=250.000 (y accel, mm/sec^2)
$122=250.000 (z accel, mm/sec^2)
$130=192.000 (x max travel, mm)
$131=143.000 (y max travel, mm)
$132=40.000 (z max travel, mm)

Chilipeppr

Nu er grbl op draait, die de standaard 115200 baudrate gebruikt, is het ook mogelijk om chillipeppr te gebruiken. Gebruik hiervoor de grbl workspace van Chilipeppr. Bij het verbinden met de serial port moet je als type 'grbl' selecteren en als snelheid 115200.

Homing

Grbl is geconfigureerd met homing support. Dit betekent dat er na het opstarten altijd een homing cycle gedraaid moet worden. Hierbij trekt ie de freeskop helemaal omhoog, en daarna helemaal naar rechtsboven op het freesbed (dus freeskop naar rechts, freesbed naar voren). Hij gaat hierbij door totdat ie de limit switches raakt en stelt dat punt in als 0 op de betreffende as. Daarna neemt ie weer 2mm afstand om de limit switch weer los te laten (pulloff).

Door deze orientatie van assen ligt het nulpunt zo dat de alle zinnige coordinaten van de machine negatief zijn ("negative machine space"). Dit gaat om de machinecoordinaten, het is mogelijk om daarbovenop nog een ander nulpunt te definieren voor het werkstuk (zie onder).

Doordat de Mantis nu precies zijn nulpunt kent en de werkruimte geconfigureerd is, kan hij soft limits toepassen. Dit betekent dat als een G-code dreigt buiten het werkgebied te komen, de Mantis zijn werk stillegd voordat ie aan de betreffende gcode begint, ipv pas op het moment dat ie de limit switch raakt. Dit maakt het handiger om daarna weer verder te gaan (hoewel je na een soft limit wel een soft reset moet doen en dan een homing cycle of `$X` unlock commando, zie ook dit bugreport).

Mocht het na het opstarten niet mogelijk zijn om een homing cycle te draaien (of na een soft reset niet nodig) kun je die omzeilen door een handmatig unlock commando `$X` te geven. Dit is een grbl-specifiek commando, geen G-code. Let wel op, na het opstarten weet grbl niet waar ie is, dus dan werken de soft limits niet naar behoren (na een soft-reset lijkt dit wel goed te gaan).

Nulpunt instellen

Om met grbl het nulpunt in te stellen, kun je het G92 commando gebruiken. Hiermee stel je het work coordinate system in. Alle normale gcode coordinaten worden in dit stelsel geinterpreteerd. De envoudigste versie is "G92 X0 Y0 Z0", waarmee je het huidige punt als nieuw nulpunt instelt. Chilipeppr heeft hiervoor een "zero out" knopje. Je kunt ook maar 1 as zero-en en de rest ongemoeid laten (in Chilipeppr zit er een zero-out axis optie in het submenutje voor een axis), of je kunt coordinaten meegeven aan G92 zodat het huidige punt de gegeven coordinaten krijgt (in Chillipeppr moet je hiervoor met de hand het G92 commando typen).

Ik geloof dat G92 coordinaten bij een (soft) reset of powerdown vergeten worden. Er was sprake van coordinaten die wel over resets en reboots in EEPROM bewaard werden, maar ik weet even niet hoe dat zat.

In g-code zijn er nog andere coordinatenstelsels gedefineerd, maar ik weet even niet of grbl daar nog meer van ondersteunt.

Vervangbaar freesbed

Om te voorkomen dat het freesbed door boren en outline frezen beschadigd wordt, had ik er een plankje opgeschroefd. Omdat dat nog niet echt handig is (je moet de schroefgaatjes precies positioneren, of steeds nieuwe boren, schroefgaatjes zijn maar beperkt herbruikbaar, etc.) heb ik een viertal rampamoeren in het freesbed gemonteerd. In die rampamoeren kun je weer normale (M4) boutjes draaien om een tijdelijk bed mee vast te zetten. De rampamoeren zijn zo geplaatst dat ze buiten het werkgebied liggen, waardoor je niet per ongeluk met de frees over zo'n boutje kunt gaan.

De bedoeling van de moeren was om ze op 20mm van elke zijkant te plaatsen, maar door wat gepruts met lijndiktes in inkscape zijn ze uiteindelijk allemaal 0.7mm in beide richtingen verschoven. Het bed is 262mm bij 128mm, de gaten zitten op (19.3, 19.3), (19.3, 107.3), (241.3, 19.3) en (241.3, 107.3). De afstand tussen de moeren is 222mm over de X-as en 88mm over de Y-as. Onderaan deze pagina vind je de SVG om een nieuw bed te kunnen uitsnijden op de lasersnijder.

Het freesbed had ik gemaakt voor het verplaatsen van de eindstops, dus er zit nu nog een uitsparing in de bovenhoek voor het eindstopje.

PCB uitsparing

Nu ik een vervangbaar freesbed heb, kan ik daar natuurlijk ook naar hartelust in gaan frezen. Om het makkelijker te maken om PCB's te frezen, maak ik een uitsparing in het freesbed ter grootte van de volledige PCB zodat de PCB er gewoon in gelegd kan worden. De diepte van de uitsparing wordt 1mm, zodat de PCB nog 0.5mm uitsteekt. Mocht het nodig zijn, zou je daardoor nog 2 latjes over de PCB kunnen leggen en met de moeren vastzetten, zodat je de PCB naar beneden aandrukt. Door de uitsparing met de frees te maken weet je ook direct dat de bodem van de uitsparing perfect vlak wordt.

Voor het uitfrezen heb ik een ontwerpje gemaakt in openscad en met jscut de gcode gegenereerd. Het is nog niet gelukt om het bed goed uit te frezen. Een eerste poging met een klein freesje (iets zoals deze) leek wel aardig te gaan, maar freesde niet zo diep als hij zou moeten. Een latere poging met een wat grotere en splinternieuwe frees werkte ook niet lekker. Het lijkt erop dat deze frezen zijwaarts prima kunnen frezen, maar verticaal moeite hebben. Ze hebben op zich wel snijvlakken op de kop, maar als je verticaal neerdaalt kan hij vermoedelijk geen zaagsel kwijt waardoor de snijvlakken vollopen en gaan verbranden. Wellicht is dit op te lossen door schuin neer te dalen, maar jscut kan dat iig niet.

Een volgende poging met een spiraalfreesje werkte al beter. Deze frees is goed geschikt voor verticaal neerdalen en loopt horizontaal redelijk soepel (op 500mm/min ging het nog ok). Het ding maakte wel behoorlijk veel herrie en ik ben er niet van overtuigd dat dit freesje helemaal bedoeld is voor deze manier van frezen.

Waarschijnlijk is en HSS frees zoals deze meer geschikt, maar die kon bij de Gamma niet vinden. Wellicht online nog eens proberen te vinden.

Verder ging het frezen zelf niet altijd helemaal goed. Tijdens frezen zakte de freeskop ineens een extra millimeter, zonder dat daar een instructie voor in de gcode stond. Ook was de gerapporteerde Z-positie niet verandert, dus ik snap niet wat daar misging. Verder sloeg de frees ergens een keer een paar lijnen over, maar wellicht werd dat veroorzaakt doordat ik wat in de buffer van chilipepr had zitten klikken in een poging de feedrate wat te verlagen.

Een volgende poging met een echt 5mm houtfreesje van Proxxon ging al beter. Je merkt goed dat deze frees bedoeld is voor dit werk: Ook op hogere snelheden werkt hij prima en het oppervlak wat ie achter laat is heel mooi vlak. Ik heb nu steeds horizontaal 2mm materiaal per keer weggehaald (step over 0.4 in jscut; 2mm = 0.4 * 5mm) en verticaal 1mm diep gefreesd en dan lukt het zelf nog om op de maximumsnelheid van 4000mm/min te frezen. Het klinkt wel alsof ie er een beetje moeite mee heeft, dus ik heb het even op 2000mm/min gehouden (dit gaf later nog wat problemen, 1000mm/min is misschien nog beter). Op deze snelheid lukt het ook nog wel om een volledig nieuwe snede te maken (dwz, aan beide kanten 2,5mm materiaal weghalen, wat jscut doet om een rechthoek te beginnen, maar niet echt van harte (ik heb een bug bij jscut geopend hierover).

Het frezen heb ik gedaan op stand 4. De frees zegt dat de optimale snelheid 12.000 - 20.000 rpm is. De dremel kan 8.000-30.0000 RPM, dus dan komt stand 4 ongeveer overeen met 20.000 (wellicht nog wel iets meer, dus misschien is stand 3 beter).

Na het frezen bleek dat het formaat net niet klopt - het lijkt erop dat de OpenSCAD SVG export iets fout doet. Dit is inmiddels gefixt.

Voor het frezen van het bed heb ik jscut de gcode laten centreren, en het nulpunt van de mantis midden op het freesbed gelegd (Dat is op X-96 Y-77.7. X is de helft van het werkbereik, maar Y niet aangezien de freespunt net niet precies in het midden van de Y-as zit).

Scheve frees

Bij het frezen van het PCB bed leek de breedte van de frees niet te kloppen - hij freesde een kleiner rondje dan gespecificeerd. Het bleek dat de frees niet helemaal recht in de freeskop zat, dwz dat de as van de frees net net overeen komt met de draaias. Hierdoor draait de frees net niet helemaal over z'n eigen as, waardoor het freesprofiel net niet klopt. Bij een freesje met 1 mes betekende dit het freesprofiel iets groter werd als het mesje naar buiten toe gekanteld was, of kleiner als ie naar binnen gekanteld werd. Bij een freesje met 2 messen was er altijd 1 mesje naar binnen en 1 naar buiten waardoor altijd iets groter gefreesd werd (of allebei zijwaarts, dan was er amper merkbaar effect).

In eerste instantie leek het alsof de scheefheid altijd optrad - het draaien van de frees in de kop zorgde ervoor dat ie de andere kant op gekanteld werd. De scheefheid was ook goed te zien door met de hand wat aan de kop te draaien. Het proberen van andere "grijpertjes" en zelfs een ander schroefkopje op de frees leverde op het eerste gezicht geen of beperkt resultaat op. Verder experimenteren liet zien dat het, met dezelfde onderdelen en zelfs ook zonder de frees in de kop te draaien, mogelijk was om de frees zowel recht als scheef te kunnen monteren. Het lijkt erop dat alle onderdelen goed los te maken en in een neutrale positie te houden en dan de kop dicht draaien het beste resultaat oplevert. Bij het gebruik van een PCB-sporenfreesje was de scheefte ook goed te zien en wanneer de frees er echt goed recht in zat lukte het om een supersmal spoortje (vermoedelijk < 0,2mm) te frezen. Als het freesje er zo recht in zit, kun je ook een miniem puntje frezen (in plaats van een groter cirkeltje) door de frees alleen te laten zakken. Dit is meteen een goede manier om te testen of de frees er recht in zit (hoewel dat ook vrij goed te zien is).

Vermoedelijk waren de eerdere observaties dus (gedeeltelijk) toeval. Sterker nog, later lukte het niet meer om de freesjes opnieuw zo scheef in de kop te zetten dat de eerdere effecten opnieuw zichtbaar waren.

Eindstops ongewenst getriggerd

Tijdens het testen schoot GRBL af en toe in de "Alarm" stand. Dit betekent dat de hard of soft limits getriggerd zijn. Steeds gebeurde het wanneer de Mantis niet aan het frezen was, als ik dan weer verder wilde bleek ie in de alarmstand gesprongen te zijn. Aangezien er dan dus geen G-code commando's gegeven werden, zal het geen soft-limit zijn, maar zal een van de limit switches getriggerd zijn. Het is mogelijk dat ik gewoon per ongeluk een limit switch ingedrukt heb, maar lijkt me onwaarschijnlijk dat 8 keer gebeurd is. Wellicht komt het door elektrische storing (wellicht dat kleinere pullups dat zouden kunnen fixen - de interne 20-50k pullups van een Arduino zijn redelijk groot). He tzou ook kunnen dat er ergens een soldeerverbinding slecht is, aangezien de switches normally-closed zijn is elke (korte) onderbreking een alarm. Zie verderop voor een uitgebreidere analyse

Hoogte van het bed

Het vaste bed van de Mantis is redelijk laag - om met een freesje nog bij het bed te kunnen komen moet het freesje vrij ver uitsteken (wat de stabiliteit en nauwkeurigheid niet ten goede komt). Om dit op te lossen, heb ik het bed iets verhoogt door, naast het werkplankje wat ik al had, nog 2 extra plankjes te lasersnijden en die er onder te leggen. Hierdoor kan een freesje goed diep in de kop gestoken worden en toch nog bij het bed. Dit zou ook de precisie van de PCB traces ten goede kunnen komen.

Nadeel is wel dat, zelfs in de hoogste stand van de Z-as, de ruime tussen de freeskop en het bed beperkt is en het soms een beetje pielen is om de freesjes uit de kop te krijgen.

PCB Uitsparing, poging 2

Nadat ik van het eerste plankje een bende had gemaakt, was het tijd voor een nieuw plankje. Er was al gebleken dat zelfs met een gefixte SVG export in OpenSCAD de maat nog niet helemaal klopt (scheelt minder dan een mm). Wellicht zit er wat afwijking in het opmeten van de PCB, de grootte van het freeskopje of de steps/mm van de Mantis. Waarschijnlijk een combinatie van oorzaken, maar de afwijkingen die ik kon vinden zaten in de buurt van de onnauwkeurigheid van mijn schuifmaat, dus helemaal uitsluitsel lukte niet. Om dit op te lossen heb ik de tekening gewoon iets groter gemaakt. Om uit te vogelen hoe hoog precies heb ik een stukje testgcode gemaakt:

; Test code for Mantis PCB bed size
; Measured size was 121x182mm, but that turned out to be slightly too
; small. Exact cause is unknown - possible the measurement is off a bit,
; or the mill head isn't exactly 6.5mm, or the mantis has a small error
; on its steps/mm, probably all of the above.
;
; This test simply mills a cross to check the measurements. Initially I
; started with 121x182
G21         ; Set units to mm
G90         ; Absolute positioning
G1 Z2 F2540 ; Move to clearance level
 
; Rapid to initial position
G0 X-4 Y57.5 ; (121.5 - 6.5) / 2
; Plunge
G1 Z-0.2000 F50
; Cut
G01 X0 F500
G01 Y-57.5
G01 X-4
; Move to clearance level
G1 Z2 F200
 
; Rapid to initial position
G0 X87.9 Y-4 ; (182.3 - 6.5) / 2
; Plunge
G1 Z-0.2000 F50
; Cut
G01 Y0 F500
G01 X-87.9
G01 Y-4
; Move to clearance level
G1 Z2 F200

Deze gcode freest een kruis van de goede grootte, zodat je daar vervolgens de PCB tussen kunt steken om te passen. Aan de uiteinden freest ie nog een klein stukje dwars (zeg maar een serif-streepje), omdat een rechte kopse kant wat representatiever is dan een ronde. Hiermee heb ik bepaald dat het freesbed 121.5 x 182.3mm zou moeten zijn.

Het daadwerkelijk uitfrezen ging redelijk, maar niet probleemloos. Er bleek dat bij het aanzetten van de stofzuiger de eindstopjes afgingen, vermoedelijk door storing via het stopcontact. Hier moeten we nog eens naar kijken, wellicht dat kleinere pullups helpen.

Verder bleek dat bij 2000mm/min (en 1mm diep frezen op stand 3) de freeskop op den duur vastliep, dus ben ik opnieuw begonnen op 1000mm/min op stand 4, dat gaf verder geen problemen.

Vervolgens bleek dat de uitgefreesde rechthoek niet helemaal haaks was. Als ik de PCB strak tegen de linkerkant aandrukte, was er links boven ruimte, en rechts boven niet. De ruimte linksboven was maar een halve mm ofzo, maar net genoeg om hem niet mooi te laten passen. Dit was het geval voor alle 4 de hoeken van de PCB, waaruit ik de conclusie trek dat de PCB haaks is, maar de uitgefreesde rechthoek niet. En dat zou weer betekenen dat de assen net niet haaks staan.

Ik heb dit opgelost door het onwerp aan te passen. In OpenSCAD heb ik deze transformatie over het hele object toegevoegd:

multmatrix(m = [ [1, 0, 0, 0],
                 [0.006, 1, 0, 0],
                 [0, 0, 1, 0],
                 [0, 0, 0, 1]
               ])

Dit geeft een iets geskewde rechthoek, die in de Mantis weer ongeveer een rechthoek oplevert. Ook bleek de uitsparing nog iets te klein, waardoor ik uitkwam op 121.7 x 182.3mm. Mogelijk dat het, als je de skew vanaf het begin toevoegt, het zelfs nog 121.8 of .9 moet zijn.

Klemmen van de PCB

De uitsparing die ik had kon mooi een PCB bevatten. Echter, omdat de PCB's zelf net niet helemaal recht zijn (en rechtbuigen wel een beetje lukt, maar niet perfect) blijft de PCB omhoogstaan aan de randjes of in het midden. Ook heeft ie de neiging om uit de uitsparing te floepen, wat tijdens het frezen natuurlijk problematisch is. Om de PCB in toom te houden heb ik twee rechthoekjes gesneden, ter hoogte van het bed en 45mm breed, met gaten. Deze plankjes kan ik vervolgens met dezelfde bouten vastmaken als de wegwerpplankjes. De breedte is zo gekozen dat ze net een paar millimeter over de PCB heen vallen.

Dit houdt de PCB op zijn plaats, maar zorgt er ook voor dat de PCB heel iets krom getrokken wordt - in het midden komt ie een stukje omhoog. Ik dacht dit op te lossen door een "raampje" te maken - eigenlijk precies zo'n wegwerpplankje, maar dan met een gat erin wat net een paar mm kleiner is dan de PCB. Dit plankje kan de PCB aan alle randen omlaag duwen. Echter, in de praktijk gebeurde met het plankje precies hetzelfde als met de PCB: het midden komt ook iets omhoog. De randjes van het plankje zijn te smal om voldoende stijfheid te bieden.

De onderliggende oorzaak voor het kromtrekken is dat de PCB nog ruime een halve millimeter boven de uitsparing uitsteekt, waardoor de klemplankjes scheef getrokken worden. Om dit op te lossen heb ik de uitsparing iets dieper gemaakt, nu 1.4mm. Dit betekent dat de PCB (die ongeveer 1.6mm hoog is) 0.2mm zou uitsteken, maar in de praktijk is het nagenoeg 0. Nu kun je beide kleine rechthoekjes erop schroeven en wordt de PCB perfect stabiel en plat (en het ziet er nog superstrak uit ook). Het "raampje" heb ik nog niet geprobeerd, maar lijkt eigenlijk ook niet nodig te zijn (en met alleen de twee zij-rechthoekjes als klemmen verlies je minder oppervlak).

Dit doet de vraag rijzen of de uitsparing eigenlijk wel echt nodig is. Op dit moment geeft de uitsparing goede support in de X en Y as, maar wellicht is alleen klemmen in de Z-as wel voldoende om de PCB op zijn plaats te houden op een plat bed zonder uitsparing. Hiervoor zou je kleine rechthoekige klemplankjes kunnen gebruiken met een 1.5mm uitsparing langs de lange kant (de aan de onderkant komt, zodat daar de PCB ik kan vallen). Als de breedte van die uitsparing goed gekozen wordt (zodat de PCB precies tegen de zijkant van de uitsparing komt) is er ook nog wat steun in de X-as. Precies breed genoeg is natuurlijk weer lastig, maar wellicht dat de schroefgaten in de rechthoek langwerpig kunnen worden, waardoor je de klem een beetje over de X-as kan schuiven (en dan fixeren met de bouten).

Nog makkelijker is om, in plaats van een uitsparing in het rechthoekje, gewoon een dun plakje (1.5mm) hout of plexiglas naast de PCB te leggen, en daar bovenop een rechthoekig klemplankje (met 2 gaten voor de bouten). De ene kant van het klemplankje wordt dan ondersteund door de PCB, de andere kant door het dunne plakje, zodat het klemplankje horizontaal blijft en druk kan uitoefenen zonder de PCB krom te buigen. Als je het dunne plakje wat groter maakt en ook 2 langwerpige gaten geeft, kun je het plakje nog gebruiken om de PCB in de X-as te klemmen (dit biedt meerwaarde omdat het plakje door een groter stuk van het klemplankje wordt geklemd dan de PCB en daardoor waarschijnlijk meer weerstand heeft).

Zelfs als de uitsparing niet nodig blijkt kan het nuttig blijven om een ondiepe uitsparing (0.1 of 0.2mm) te maken om het bed goed vlak te maken (tov de beweging van de frees). Idealiter zou je het hele bed vlakken, maar de frees kan niet bij de randjes. Alleen het middenstuk vlakken is waarschijnlijk ook wel voldoende (en omdat de maat niet precies komt en de diepte gering is kan het waarschijnlijk wel op 4000mm/min gebeuren, dus dan is het zo klaar).

Storing in de eindstops

Eerder bleek dat soms, meestal als de frees even niets aan het doen was, de eindstops op magische wijze getriggerd werden. Bij het frezen van het PCB bed bleek dat dit bijna altijd gebeurde wanneer de grote afzuiginstallatie aan- of uitgezet werd. Beide wijzen erop dat de eindstops gevoelig zijn voor EMI - elektromagnetische straling, of storing via de voeding (via de 220V).

In een poging om dit probleem te vinden bleek dat er diverse aspecten aan zijn. Als de voeding van de steppers aangesloten is op hetzelfde stekkerblok als de afzuiging, treed het probleem vaak op. Echter, zelfs als de steppervoeding helemaal niet aangesloten is en er geen enkele elektrische verbinding tussen de afzuiging en de Mantis is (de Arduino wordt gevoed via een laptop zonder adapter), treed het probleem nog steeds af en toe op - blijkbaar gaat het dus niet alleen om storing via de voeding, maar ook om EMI direct via de lucht. Dit effect kan worden versterkt door de voedingskabel van de afzuiging een paar centimeter parallel aan de kabel van een eindstop te leggen, dan triggert het weer bijna altijd (maar dat zou in de praktijk niet voor moeten komen).

Het probleem lijkt bij elke eindstop voor te komen, als ik er steeds twee losmaak en vervang door een jumpertje, gebeurt het nog steeds. Als ik ze alledrie losmaak, verdwijnt het probleem.

Een tweede probleem wat ik zag is dat soms de USB -> Serieelmodule op de Arduino zichzelf reset. Het USB device op mijn laptop verdwijnt dan even en meld zich direct weer opnieuw aan. Dit probleem doet zich ook voor zonder aangesloten eindstops. Een 10uF condensator tussen GND en 5V hielp niet, een extra pullup op de reset pin kon ik niet goed aanbrengen, dus dat zou misschien later nog eens geprobeerd moeten worden.

Dit resetten was in minicom (serial terminal) niet zo'n probleem, aangezien die direct de ttyACMx sluit en daarna weer opnieuw opent. Met de serial-port-json-server gebeurt dat niet - die houdt ttyACM0 open, waardoor na de reset de arduino op ttyACM1 uitkomt en de communicatie wegvalt. Dit is eigenlijk iets om in serial-port-json-server te fixen, maar hopelijk gebeurt de reset niet zo vaak. Dit moet even in de gaten gehouden worden in de toekomst.

Voor de storing op de endstops lijkt het te helpen om een iets kleinere pullup te gebruiken dan de interne (20-50k), maar vooral ook om een condensator toe te voegen. Samen vormen deze een laagdoorlaatfilter. Ik heb succes gehad met waarden van 1kOhm en 1uF, wat samen korte pulsen van minder dan een paar ms onderdrukt. Welicht kan de condensator nog wel wat kleiner en/of de weerstand wat groter.

Een poging om deze storingspulsen te meten lukte niet. Met een samplerate van 10Msps waren er geen grote afwijkingen zichtbaar op zowel de 5V lijn als de limit switch input. Vermoedelijk zijn de storingspulsjes dus veel kleiner dan een microseconde.

Tijdens het testen schoot er een draadje los uit de connector naar de steppermotor. Omdat de stepperdrivers daar niet tegen kunnen (ze blijven het voltage verhogen terwijl er geen stroom gaat lopen) is er ééntje overleden. Er lag nog ergens een andere, dus die is vervangen. Ook raakt ik een keer met de 24V voeding een pin, waardoor er op de Arduino nu een paar pinnen stuk gegaan zijn (ze komen bij output high niet verder dan ongeveer 1V). Volgende week neem ik een andere Arduino mee om dat op te lossen

Tijdens het testen heb ik ook de steppervoeding verhoogd van 20V naar 24V, omdat op de voeding 24V genoemd stond. Ik dacht dat  ie, omdat ie ver onder z'n nominale voltage zat, dat dat misschien nog storing op zou leveren, maar verhogen naar 24V leek geen verbetering op te leveren. Ik weet niet waarom ie op 20V stond ipv 24V (wellicht dat het ultiboard wat eerst gebruikt werd maar 20V kan?), dus wellicht moet ie weer even naar 20V teruggezet worden

Een volgende poging, met een filter van 1kOhm en 1uF op alledrie de pinnen, openbaart zich een nieuwe variant op het probleem: Als het freesbitje (een boortje in dit geval) contact maakt met het koper van de PCB, triggeren wederom de eindstops. Dit is te reproduceren door de frees omhoog te zetten en vervolgens met een draadje de PCB en het freeskopje te verbinden. Als de frees niet draait, gebeurt het niet. Vermoedelijk fungeert de PCB als zendantenne voor de storing die de multitool genereert, die weer door de eindstopjes opgepakt wordt. Met een miniscope zijn nog steeds geen pulsjes meetbaar, wat wel verdacht is (het filtertje zou pulsjes tot een ms ofzo weg moeten filteren, maar wellicht dat het niet helemaal werkt zoals ik denk). Het filter verbeteren door ook nog een 100ohm weerstand in serie met de switches te zetten (zo dicht mogelijk bij de Arduino input pin) lijkt ook geen effect te hebben.

Met een klein stukje testcode (met alleen een interrupt handler op de limit pins) is te zien dat, wanneer de PCB en frees met een draadje verbonden worden, er 0-20 interrupts per seconde gebeuren (meestal 1-5, soms uitschieters afhankelijk van hoe goed het contact is lijkt het). Wanneer in de interrupt handler de pin uitgelezen wordt is die eigenlijk altijd laag - het lijkt er dus dat het hele korte pulsjes zijn (reactietijd van de ISR zou maximaal een paar us moeten zijn). Een voordehandliggende oplossing zou dus zijn om in de ISR de pins nog even te controleren. Grbl heeft hier al wat support voor, je kunt de "software debounce" optie (bij het compileren) aanzetten, wat er voor zorgt dat als de pin interrupt getriggerd wordt, er even gewacht wordt en een korte tijd (+- 32ms) later de pin gechecked wordt. Pas als ie dan hoog is, (switch ingedrukt), wordt er een alarm gegenereerd. Dit is wellicht wat teveel van het goede, simpelweg de pin nog even uitlezen in de interrupt handler zou voldoende moeten zijn.

Deze laatste theorie wordt ondersteund door een volgend testje: Wanneer je voortdurende de pin uitleest (zonder interrupt handlers aan te zetten), leest ie altijd laag uit. Het lijkt er dus op dat er hele minieme pulsjes of andere storing is die voldoende is om de pin change interrupts te triggeren, maar niet genoeg om de pin input registers hoog te maken.

Als je meet tussen de randaarde en negatieve pool van de steppervoeding, zie je dat de negatieve pool behoorlijk varieert (aangenomen dat de randaarde goed constant is): Er is een golfvorm van 50Hz, met 15-20Vpp zichtbaar. Het verbinden van de randaarde en negatieve pool lost dat op, maar het probleem blijft bestaan. Vermoedelijk is die storing gewoon storing op de randaarde.

Met een echte oscilloscoop meten laat de storing wel zien. Het lijkt erop dat de er iets in de ground zit waar de storing vandaan komt. Als je de oscilloscoop laat meten tussen de ground van de Arduino en de ground van de endstop (op het grblshield), zie je bij het inschakelen van de frees (ook zonder koperplaat eraan) wat rommel (2-6Vpp). Echter, als je de ground van de probe ook aan de endstop ground hangt (dus samen met de punt van de probe), zie je ongeveer dezelfde rommel, wat suggereert dat de probe zelf ook als antenne fungeert. Als je dat geheel vervolgens niet aan de grblshield hangt, dan is de rommel nagenoeg weg, wat wel weer suggereert dat die er iets mee te maken heeft.

Boren met een Proxxonboortje

Boren met een Proxxon boortje ging vrij voorspoeding. Het lukte om de boor nagenoeg concentrisch te laten draaien, waardoor er (zoals eerder) geen "slingerbeweging" was bij het terugtrekken van het boortje, zodat er bij het terugtrekken niet nog wat koper weggeslepen wordt om het gaatje. Het kostte een paar pogingen om het boortje er goed in te zetten, dus wellicht dat dit me dezelfde boortjes als eerder ook goed zou kunnen. Dez Proxxonboortjes hebben een wat dikkere schacht dan het boortje zelf, waardoor je ook hele kleine boortjes (0,5mm) kan gebruiken (het kleinste klemmetje is vermoedelijk te groot voor 0,5mm). Jammergenoeg heeft de schacht van het boortje een andere diameter dan de isolatiesporenfrees, dus wisselen van klemmetje is tussendoor nog wel nodig.

Doordat de boor mooi concentrisch loopt, en mogelijk ook omdat het een goede scherpe boor is, kon het boren behoorlijk snel, zonder dat er ook maar enige weerstand zichtbaar of hoorbaar was. Ik heb getest tot 500mm/min, dat leek me snel zat. Bij de vorige pogingen zat ik op 40mm/min, omdat de boor even tijd nodig had om zichzelf goed te centreren en ik bang was dat bij een hogere plungesnelheid de boor zou breken. Wellicht dat de andere boortjes, mits goed gecentreerd, ook sneller kunnen, maar dat moet nog een keer getest worden.

Volgens het proxxonboortje is de ideale draaisnelheid 8,000rpm (voor zachte materialen, 3,000 rpm voor harde). De frees kan 8,000-30,000rpm, dus ik heb hem nu op stand 1 gezet, dat lijkt prima te gaan. De Proxxon boortjes mogen overigens tot 45,000rpm, dus dat gaat sowieso goed.

Met deze boortjes, cq goed gecentreerd gemonteerde boortjes, lukt het ook prima om eerst de sporen te frezen en daarna pas te boren. Het effect dat bij de opgaande beweging het koper afgeschraapt wordt lijkt nu helemaal niet meer voor te komen.

Toolchanges

Bij (iig de drill file) genereert pcb2gcode tool change commando's. Hij doet eerst een M6 "tool change", dan een commentje om aan te geven welke boor je nodig hebt, en dan een M0 "temporary machine stop". chilipeppr onderschept de M6 en stop vervolgens met gcode opsturen. Je krijgt een popup met uitleg, die zegt dat je linksboven in de gcode sender weer op "pause" moet drukken om te resumen. Chillipeppr laat comments even heel kort zien, maar omdat het comman na de M6 staat heb je daar weinig aan. Ook is coment na een paar seconden weer weg, maar misschien dat ie het laat zien totdat er een volgend commando gedaan wordt, dan zou het wisselen van de comment en M6 kunnen helpen. Chilipeppr doet niets met de M0, maar het lijkt erop dat GRBL M0 interpreteert als een feed hold - hij stop dan met gcode interpreteren. Vervolgens heeft ie een cycle start (~ knopje) nodig om weer verder te gaan. Dit is een beetje dubbelop en onverwacht, wellicht moet hier nog even iets voor geregeld worden. Een makkelijke manier zou zijn om gewoon in chilipeppr de M6 te negeren, of de M0 weg te halen (via een sed scriptje, of een wijziging in pcb2gcode). Voor nu druk ik gewoon even op "pause" en "cycle start".

Testprintplaatje

Om te kijken hoe klein we kunnen had ik eerder een testprintje ontworpen, daar heb ik nog een 2x5pins 1.27mm pitch connector aan toegevoegd (rechtsboven) en gefreesd:

Eerder had ik met dit testprintje al aangetoond dat het mogelijk is om tussen de pinnen van een standaard 2.54mm pin header door een spoor te laten lopen (rechtsonder), waardoor het PCB ontwerp significant eenvoudiger kan zijn als je twee van die pin headers 1-op-1 moet verbinden. Echter, ik had dit nu eigenlijk nodig met een pin header van 1.27mm spacing. Het leek me onwaarschijnlijk dat het zou lukken om daar een spoortje tussendoor te laten lopen, maar na wat rekenen (naar schatting was de isolatiebreedte ongeveer 0.2mm, maar mijn schuifmaat is niet precies genoeg om dat echt te meten) leek het misschien toch te lukken. Gewoon proberen dus:

Wonderwel lijkt dat prima te gaan. De linker heeft _hele_ smalle spoortjes, rechts heb ik de pads iets smaller gemaakt zodat de spoortjes iets breder konden. Verder heeft de linker de gaatjes net niet helemaal goed zitten, vermoedelijk omdat ik de gaatjes voor beiden pas op het laatst geboord heb en er iets afwijking was ontstaan.

Rechts zie je dat de gaatjes ongeveer even breed zijn als de pads, op sommige plekken zitten de gaatjes zelfs heel iets in de isolatie. Dit zou geen probleem moeten zijn - als er een pinnetje in gesoldeerd wordt, worden beide kanten toch weer verbonden. Het is wel even de vraag of het soldern goed genoeg gaat, maar ik verwacht dat er voldoende koper om de pin zit om dat goed te laten komen.

Rechts zie je ook dat de gaatjes niet overal strak in het midden zitten en dat niet alle spoortjes even breed zijn. Het lijkt erop dat dat wat variatie in het proces is - bijvoorbeeld veroorzaakt door onnauwkeurigheid in de assen, en/of hoogteverschillen in de PCB (als je inzoomt zie je dat de isolatiesporen ook niet allemaal even breed zijn). Dit suggereert wel dat, zelfs al zou je het freespuntje nog smaller krijgen, je nu wel een beetje tegen de grenzen van de machine aan zit.

Bij het testen bleek grbl steeds na het frezen te resetten, en daarbij z'n nulpunt te verliezen. Eerst was ik bang dat dit weer door storing (van het uitzetten van de frees bijvoorbeeld) kwam, maar het blijkt dat pcb2gcode aan het eind van z'n programma een "M2 program end" commando geeft. Dit reset allerlei zaken die wenselijk zijn (terug naar mm, absolute coordinaten, etc.) maar de coordinate offset wil je juist houden (voor bijvoorbeeld het boren). Je kunt de coordinate offset, die door chilipeppr weergegeven wordt, kopieren en dan weer instellen, maar het instellen met G92 is weer wat lastig (je moet of rekenen, of naar je nulpunt gaan en reset to zero doen). Voor nu haal ik gewoon het M2 commando even weg, maar het zou nog handiger zijn als chilipeppr een history bijhoudt van coordinate offsets, zodat je makkelijk kunt wisselen. Ik heb hierover een feature request ingediend.

Bij het testen bleek ook dat de freesdiepte vrij precies komt, zelfs met de fancy PCB-klem-constructie bolt ie in het midden nog heel ietsje op. Ipv 0.1mm 0.2mm diep frezen helpt, maar dan worden de spoortjes hier en daar wel iets dieper dan nodig en wenselijk (geen groot probleem, maar net jammer). Dmv probing en correctie van de gcode zou dit nog verbeterd kunnen worden. Hier zou grbl en chilipeppr ondersteuning voor moeten hebben, dus dat kunnen we nog eens proberen.

Outline frezen

Eerdere pogingen om de outline te frezen werkten wel, maar de gebruikte freesjes waren nog niet echt ideaal. Een test met een 1mm hardmetaalfreesje van Proxxon werkt beter. Deze frees gaat zonder veel problemen door de printplaat heen. Het resultaat is heel mooi strak. Ik heb nu getest op een snelheid van 250mm/min. Het is een vrij smal freesje, dus ik wil niet te snel gaan en de frees breken. Ik denk dat hij op zich nog zonder risico een stuk sneller zou kunnen, maar op zich is dit al redelijk rap (en zoveel outline is er niet).

Omdat het zo'n smal freesje is, kun je er zelfs kleine gaatjes mee boren, wat weer tool changes scheelt (1.0mm gaat sowieso, grotere gaatjes voor bijvoorbeeld mounting holes, kan door te boren en dan een rondje uit te frezen, pcb2gcode heeft daar als het goed is een optie voor). Het lijkt er wel op dat de gaatjes in de praktijk ongeveer 1.2mm à 1.3mm worden, wat eigenlijk wat te groot is voor standaard pin header pads. Toch maar beter een echt 1mm boortje pakken voor 1mm gaatjes.

De schacht van het freesje is wel onhandig van maat: 3mm. Het grootste klemmetje werkt perfect voor 3.2mm schachten, maar pakt 3mm net niet goed, en de kleinere klem is weer te klein. Ik heb nu een klemmetje van een andere multitool gebruikt die op zich wel werkt, maar eigenlijk net niet goed in de multitool zelf past, waardoor het niet lukt om het freesje er 100% recht in te zetten. Een ander klemmetje van thuis past beter, maar het is nog steeds lastig om hem recht in de frees te zetten.

De draaisnelheid van deze outlinefreesjes is optimaal 20.000 rpm, dus dat zou ongeveer stand 3 zijn. Ik heb met zo'n zelfde freesje, maar dan van 3mm geprobeerd gaten te boren op stand 1, met een snelheid van 500mm/min, en dat ging moeizaam (klonk af en toe alsof je het freesje aan het slopen was). Op 250mm/min was het iets beter, maar nog steeds niet ideaal. Vermoedelijk komt dit door de lage stand, op stand 3 heb ik de 3mm frees niet geprobeerd. De 1mm frees werkte prima op stand 1 met 250mm/min.

Bij het frezen van de eerste echte outline op deze manier liep de frees behoorlijk in de soep. Het leek erop dat de Mantis na een paar cm in eens veel te diep ging. Bij nader inzien bleek dat het freesbitje uit de kop getrokken werd. Blijkbaar zat het bitje niet goed genoeg vast en/of was de snelheid te hoog. Na stevig aandraaien en het verlagen van de snelheid naar 200mm/min ging het beter.

Rafeligheid en freesbreedte

Bij het frezen van een volgende PCB (een verloopstukje voor mijn JTAGICE3), bleek dat de randen van de freessporen ineens heel rafelig werden. Bij de vorige teststukjes waaren de randjes direct na het frezen al mooi strak, geen schuurpapier nodig, maar bij deze PCB waren ze behoorlijk rafelig. Ook had ik de freesbreedte nu wat naar beneden bijgesteld naar 0.3mm, dat leek me realistischer, maar het gevolg was dat de kopersporen ineens een stuk smaller werden. Een freesbreedte van 0.6mm (dus offset 0.3 in pcb2gcode) werkte beter. In de praktijk ligt de isolatiebreedte waarschijnlijk tussen deze twee waarden in, maar het is altijd beter om te overschatten - de sporen worden dan misschien ietsje breder, wat nooit kwaad kan. Op de plekken waar de sporen dicht op elkaar liggen maakt het niet uit - pcb2gcode stuurt de frees daar sowieso netjes middendoor (en klaagt dat de clearance requirements niet gehaald werden, maar dat is dan niet per se erg).

De eerste poging voor de PCB werkte niet - er waren een aantal spoortjes te smal geworden en verdwenen (op 2 punten waar er een spoortje tussen gaatjes met 1.27mm spacing door moest). In principe zou op deze punten de ingestelde freesbreedte geen rol spelen, aangezien het er toch allemaal te krap is om de clearance daar te halen. De oorzaak van dit probleem zit hem dus in de rafeligheid en/of te brede isolatiesporen.

Wat experimenteren met teststukjes laat zien dat rafeligheid verbeterd wordt door:

  •  De verplaatsingssnelheid te verhogen of de draaisnelheid te verhogen. Het lijkt erop dat, wanneer de frees te snel draait of te langzaam verplaatst, de frees niet genoeg materiaal heeft om weg te snijden en dus steeds maar wat koper voor zich uit duwt. De verhouding tussen deze twee lijkt vooral belangrijk te zijn. In de praktijk werkte een draaisnelheid van stand 1, en een verplaatsingssnelheid van 500mm/s prima. Dit zou suggereren dat met een hogere draaisnelheid de verplaatsing nog sneller kan, maar dat heb ik niet getest.
  • De freesdiepte. Als je zo min mogelijk in het koper zit, zijn de randjes het mooist. Als je iets dieper zit (0.2mm ipv 0.1mm), dan worden de randjes al rafelig. Omdat het koper niet helemaal vlak ligt, moet je vaak wat dieper dan je eigenlijk zou willen, vermoedelijk speelt dat mee. Om deze reden lijkt het autoproben van de diepte extra interessant.

Vermoedelijk is het verschil tussen het teststukje en de echte PCB met name de freesdiepte - omdat het teststukje maar klein was, zijn de hoogteverschillen kleiner. Wellicht is ook het freesbitje wat botter geworden.

Bij de tweede poging heb ik de freesdiepte zo klein mogelijk gehouden - frees laten zakken tot ie net het koper raakt. Bij het frezen van de outline bleek dat dit niet genoeg was, vervolgens een paar keer 0,05mm (en op het laatst 0,025mm) laten zakken totdat langs de outline overal het koper weggefreesd  werd.

Pauzes

Tijdens het frezen van de sporen, pauzeert de Mantis af en toe even. Kijkende naar de debug output van serial-port-json-server lijkt het erop dat chilipeppr niet snel genoeg data doorstuurt. Het lijkt er ook op dat er maar een heel beperkt flow-control mechanisme is: standaard stuurt chilipeppr elke 1000ms 50 regels door. Dit betekent dat normaal serial-port-json-server een grote buffer heeft (uiteindelijk de hele gcode file), tenzij er stukken zijn waar veel meer dan 50 regels / seconde uitgevoerd worden. In de schuine stukken van kopersporen lijkt dat het geval te zijn, om de één of andere reden zijn dat in de gcode geen rechte lijnen, maar een hoop korte stukjes.

Vermoedelijk is dit een kwestie van wat spelen met de chilipeppr instellingen, ik heb nog niet echt wat geprobeerd.

Rommelige en overgeslagen gaatjes

Bij het printen van die JTAGICE3 PCB ging het boren van 0.5mm gaatjes één keer niet goed: De gaatjes waren net niet goed gepositioneerd. Ze zouden netjes in een grid van 2x5 moeten liggen, maar de meeste gaatjes waren net verkeerd geplaatst, steeds ook met een afwijking een andere kant op. Bij de tweede versie van de PCB ging het wel goed. Wellicht dat het boortje niet helemaal recht zat en dat dus het moment dat het boortje de PCB raakt de afwijking bepaald, hoewel dat wel onwaarschijnljk klinkt.

Verder werd er af en toe een gaatje overgeslagen. Bij eerdere testen gebeurde dat ook al - het gat werd gewoon niet geboord. Ik weet niet zeker of ie wel naar de positie van het gat bewoog, of ook die stap oversloeg. Kijkende naar de debug output van serial-port-json-server zou de positie van het gat wel naar grbl gestuurd zijn. Wellicht was de buffer van grbl vol en heeft ie het commando nooit gezien? Zou wel toevallig zijn als er _precies_ 1 regel gcode overgeslagen wordt, en ook wel toevallig dat het nooit het retract commando is (dan zou er XY beweging zijn met het boortje in het materiaal en het boortje breken).

"Silkscreen" / opdruk met de lasersnijder

In Kicad kun je onder File -> Plot, SVG als formaat selecteren. Selecteer alleen de F.Silk laag. Als je "Exclude PCB edge layer from other layers" uitvinkt, komt de PCB outline ook in de SVG terecht, waardoor de positionering makkelijker wordt. Wel weer even aanvinken voordat je gerbers gaat plotten, aangezien pcb2gcode anders geen traces meer genereert.

Later bleek dat File -> Export handiger is. Daar kun je meerdere layers aanvinken (en "all in one file" selecteren), zodat je bijvoorbeeld F.Silk en F.Fab allebei kunt laseren (in de laatste laag staan ook de componentnamen die wel handig zijn bij het in elkaar solderen).

Deze SVG kan direct visicut in. Selecteer als profiel "mark everything". Als settings heb ik 20% power, 100% speed gebruikt, maar dat is eigenlijk wat te snel. De letters zijn niet helemaal mooi gelijkmatig, sommige zijn net iets groter of kleiner uitgevallen, vermoedelijk vanwege de snelheid. Een lagere snelheid is wellicht beter, maar dan moet de power ook omlaag. Een latere poging met diverse settings (waaronder met een lagere acceleratie in de LaOS config) laat zien dat het eigenlijk altijd een beetje wobbly blijft, dus wellicht moet er in de svg of de LaOS code nog iets verbeterd worden. Nog een latere poging laat zien dat 5% power en 2% speed mooie strakke letters geeft, en ook kleine letters (1x1mm in Kicad) zijn nog leesbaar.

Voor het positioneren is het handig om een stukje schilderstape in de lasersnijder te plakken, de opdracht een keer uit te voeren (eventueel wel op 100% snelheid) en dan daarbovenop de PCB te leggen. Als het een ingewikkelde print is kan het de moeite waard zijn om in Inkscape alles behalve de outline even weg te halen.

Het resultaat is mooi leesbare en strakke tekst.

IMG_0086.JPG

Zie ook deze blogpost voor wat achtergrondinfo over deze specifieke printplaat en zijn doel.

pcb2gcode 1.2.2

Deze versie bevat een aantal verbeteringen. Millimeters worden nu helemaal ondersteund, zowel voor configuratie als g-code output. Verder is er nu de "nog81" optie, die hetzelfde deed als de "primitive-gcode" waar eerder een patch voor nodig was. Er is wat optimalisatie toegevoegd waardoor met name de boorgaatjes op een handigere volgorde gebeuren. Er is "bridges" support toegevoegd, om kleine bruggetjes in de outline te laten zitten, wat ik eerder met de hand deed. Er is ook support voor autoleveling, om te compenseren voor een PCB die niet 100% vlak ligt, maar dat heb ik nog niet geprobeerd.

PCB for the big mill

We need a PCB / Arduino shield for the big mill, which I milled using the Mantis.

Used -0.12 milling depth, due to unevenness in the board (seems adding 0.04 was enough to go from barely touching to properly milled). Also used bit of doublesided tape to keep the board more level, probably works better with more and thinner tape.

I tried drilling using the Velleman drills, which worked fine at the same speed as the proxon drills (500mm/min). The 1mm drill holes seem to be slightly big (at least for the pads). They might be bigger than 1mm, haven't measured or fitted yet. I might have used the wrong drill, though.

The 3.0mm holes were drilled using the 1mm drill, I will manually drill them larger (didn't have a 3mm drill handy).

Drilling the 1mm and 3mm holes could be done using the outline milling bit. If you would have a 0.8mm milling bit, all holes could be milled by it, saving toolchanges. However, Grbl does not seem to support the G2 (arc) command used by milldrill.

The bridges work nicely, though it seems the're a bit thinner than expected (should be cut 1mm out of 1.5mm of material, so 0.5mm left, but it's more like 0.1mm or 0.2mm left.

Traces are nice, also the SMD pads. There is a solder jumper in the design, which didn't work out, the middle trace is pretty much gone (the isolation width is probably too wide for an effective solder jumper anyway, so I'll have to solder in a wire to bridge the jumper).

Outline seems to be slightly smaller than designed - is this perhaps the outline width parameter?

The traces are a bit narrow, probably because the offset parameter was optimistic (but setting it higher than 0.15 made pcb2gcode error out, see https://github.com/pcb2gcode/pcb2gcode/issues/18#issuecomment-165102103 Fixing the offset might help, or reducing the tool width. Increasing the trace width would also help, but that won't help for the pads.

Perhaps try an end-mill bit like this: http://precisebits.com/products/carbidebits/tapered_stub_125.asp https://plus.google.com/photos/+JohnLauerGplus/albums/622004260278517392... (done with 0.13mm endmill)

Result: http://fablabamersfoort.nl/fotos/index.php/16-Dec-2015/IMG_0141

Flatcam

Flatcam seems to be a fairly new alternative to pcb2gcode - worth trying some time.

 

 

TODO

  • Olie toevoegen om stof en braamvorming te voorkomen
  • Hogere verplaatsingssnelheid tijdens het frezen (evt ook hoger toerental)
  • Andere (niet-Proxxon) boortjes testen
  • PCB bed vastzetten met klemplankjes zonder uitsparing in het bed
  • Handige coordinatenoffsets (origin in het midden, linksonder, ?) voorprogrammeren met G10/G54/etc.
  • Pcb2gcode aanpassen zodat ie retract in machine coordinates (voorkomt limit alarms en zorgt dat ie automatische zo ver mogelijk retract)
  • Toolchanges (M6 vs M0) verbeteren (in pcb2gcode of chilipeppr misschien?)
  • Probing voor oneffenheden proberen
  • pcb2gcode (of Kicad) schuine lijnen als 1 lijn laten genereren (misschien dat optimise=1 in pcb2gcode dat nu al doet?)
  • grbl updaten (laatste versie heeft fixes voor M0 / toolchanges)

Wordt vervolgd :-)

Failures: 

 

Further developments: