CNC med inriktning att göra kretskort

[saxofon]

Det är roligt att läsa alla fräsiga trådar om lillsyrror.

Tycker det vore trevligt att kunna fräsa PCB'er istället för en massa handgrepp med vätskor eller printer-metoden som en del kör med. En sådan fräs behöver förmodligen inte vara lika kraftfull som en lillasyster. Man ska ju bara fräsa bort några "my-meter" koppar med andra ord räcker det kanske med en mindre motor än Dremel/Kress eller liknande.

Om jag förstår det hela rätt så funkar era fräsar ungefär så här:
1. Via CAD skapas det man ska göra, sparas och konverteras
till g-code.

2. G-code skickas till EMC2 (för de som vill köra linux) eller MACH3 (för de som vill köra windows)
(hmm vad är det man gör i själva verktyget?? ställer in parametrar beroende på vilket material, fräs-tapp etc man har?)

3. EMC2 el MACH3 skickar kommando via parallell-porten över till en servo-kontroller.

4. Servo-kontrollerna styr sedan servomotor drivare som till sist driver servomotorerna

Själv är jag riktigt insnöad på linux-system och håller mig så långt borta från dos/windows jag kan (har ju ändå nog med en massa andra OS som ThreadX, pSOS, VxWorks, OSE å annat skojsigt... )

Mina funderingar landar ungefär här just nu:

1. Linux-baserat och då menar jag riktigt native linux!
EMC2 kräver ju linux ovanpå RTAI, usch fy fasiken
Nä det ska göras rätt och okomplicerat.
Hoppas det går att modda EMC2 (annars blir ju sättet att
komma fram till den okomplicerade lösningen ganska komplicerad )

2. Varför ska man köra antika parallell-portar?
Finns ju snart inte datorer som har de längre.
Tittar lite på tex http://industrialcomponent.com/phidgets/motor.html
Då får man ju 4 st servomotor styrda via usb. Skulle de funka att driva servomotor-drivarna ni kör med i lillsyrrorna?
För phidget hw finns det stöd direkt i linux utan att man behöver göra egna drivrutiner. Dock behövs nog support för att styra servo kontrollern annat än via parallell porten läggas in i EMC2.
Helst skulle man vilja ha en liten embedded dator i fräsen som man kopplar dessa till, och som sedan via nätverket pratar med EMC2. Blir liksom en väldigt standardiserad lösning.

Får man en massa skäll nu när man slänger fram sådana här idéer mitt framför ögonen på de CNC-gurus som finns här? :-D

[PeterH]

Dom där "phidgets" du länkade till används för att styra RC-servomoter vilket inte är riktigt samma sak som stegmotorer. Men kanske man kan bygga en fräs med servon?

Annars är det en intressant tanke med enbart PCB-fräsning som jag har för mig finns i flera andra trådar...

/PeterH

[saxofon]

oja, det har du ju rätt i. så snabbt men fel jag tänkte
hmm... om man ändå tänker sig någon slags embedded controller så att man får ethernet som gränssnitt, då skulle den ju kunna ha ett gäng gpio's (för det är väl så parallell-porten används?
eller har ni något protokoll mellan parallell-porten och STEGmotor-kontrollern? )

[chille]

När man styr stegmotorer via LPT-porten så funkar det vanligtvis så att man har 2 I/O på motor. En pinne väljer riktning på motorn och den andra skickar en puls för att motorn ska hoppa fram ett steg.

Antingen fixar du något utvecklingskit eller liknande som har en nätverksport och låter den styra några drivkort till stegmotorerna, eller så kör du valfri 8bitars MCU och använder en FT232R för att få USB till den. Dock kommer ju problemet att man troligtvis kommer få fippla en del med EMC2 för att skriva ett eget plugin så den fattar hur den ska styra motorerna.

Om du skulle råka klura ut hur man gör så får du gärna hojta till, för jag håller nämligen själv på greja med en liten mini-CNC-fräs och har tänkt att använda mig av något inbyggt system med Linux. Självklart tänker jag ju inte använda någon gammal förlegad LPT-port i mitt bygge.

Intressant ide med en kretskortsfräs. Man kanske nästan skulle göra ett försök att bygga en sådan sen när man fått ihop frösta fräsen. Borde man inte kunna använda små motorer från typ RC-plan som frässpindel? De snurrar väl på så innihelvette och borde ju ändå ha kraft nog att snurra ett litet fräsverktyg som kan fräsa bort lite koppar.

Futurlec har ju några mini-stegmotorer som kostar typ 20kr/st. Kanske skulle räcka för att flytta runt ett litet PCB. De är ju så små så de borde gå att driva med typ en ULN2004A eller liknande

[Meduza]

Absolut, fixar du ett Ethernet-interface som kan prata med EMC2 och ge samma stabilitet och hastigheter så är jag den första att köpa ett exemplar!

Anledningen att använda paralellporten är att det är den enda port där man kan få tillgång till ett stort antal I/O som går att kontrollera uppemot 100khz under rätt förhållanden som är vanlig på datorer...

Stegmotorkontrollerna styrs med Step/dir-signaler, sök så förstår du hur det fungerar.

[saxofon]

http://www.siliconchip.com.au/cms/A_104837/article.html

Vad sägs om ovanstående?

hmm... mjukvara är ju mina bitar så jag kanske börjar i den änden...

Ska pula med EMC2 och få den att fungera utan rtai och sedan prata eth med en simulator som får simulera något slags eth-stegmotor-kontrollerkort. Sedan kan man gå vidare att speca ett bra protokoll på eth som passar den hw-lösning man väljer på det inbyggda kortet i fräsen.
Det bästa är ju ifall man inte skickar "stegmotor-rådata" till fräsen utan mer N stycken kommando-set.
Ett kommando-set skulle då beskriva hur alla motorer ska röra sig, tex för en parallell linje så rör sig ju bara en motor typ (x eller y) men vill man ha en diagonal måste man ju röra både x och y samtidigt. EMC2 vill förmodligen styra alla jädrans steg på alla motorer själv (och då behöver man rtai el motsv). Hur många set man skickar kan ju bero på minnes-storlek på
kontrollern, innan det är dags för nästa verktygs-byte (tills man fixat auto-tool-change ) osv

Länken överst verkar peka på några kontrollers som har lite mer logik men man måste ju iallafall synka de olika kontrollerna tillsammans antar jag.

Jag har några små kort med Netsilicons nätverksprocessor (ARM7TDMI) som man skulle kunna plugga in, har två serieportar och gpio (iofs parallell-portar också men de är inte framdragna...)
kanske att jag kör med de...

så... vi ses väl någon gång efter 2011 år-skiftet när det börjar bli dags med mekaniken

[chille]

Fixar du mjukvaran så kan jag ställa upp och designa hårdvara.

Problemet med att göra som du säger och istället för att skicka "rådata" använda någon form av kommandon är att du har du ju i princip uppfunnit G-kod på nytt. Hela grejen med EMC2 och/eller Mach3 är ju att den tar G-kod och styr fräsen därefter. Skulle man kunna tillverka en liten box som tar G-kod och styr motorerna så skulle ju EMC2 bli värdelöst och man skulle istället låta CAM-programmet skicka datan direkt till fräsen.

[saxofon]

jahaja är g-code så komplett?
så emc2 översätter "bara" motions till rådata för ett antal motorer så att det blir 3d-rörelser?
när man gjort g-code i tex eagle, tar den hänsyn till tjockleken på fräs-tappen?
Hittade inget sånt när jag testade lite lätt med eagle och gcode.zip för nån dag sedan
(men har ju heller inte grundforskat så mycket än som ni märker )

Nåja, mjukvara gör jag gärna ska göra simuleringen först som sagt så att jag ser att det inte blir för mycket jobb. Det kan ju vara trevligt att ta omvägen via EMC2 så att man får bättre stöd ifall det kommer något nytt protocol istället för g-code tex. Kanske att man kan få drivkraft från
EMC2 gänget också ifall man skulle köra fast någonstans eller så.

[saxofon]

chille: förresten så är din idé med små stegmotorer och någon liten spindel-motor precis i de riktningar jag tänkte mig.
Kanske med tre fyra fasta verktyg för olika ändamål (fräs, borr, rita tex)
Man skulle kunna ha magasin liknande de för vanlig printer (A3, A4 osv) fast med olika PCB format oftast utgår man ju från några få olika standardformat...

[Meduza]

Läs "G-Code Basics" från linuxcnc.org:
http://www.linuxcnc.org/handbook/gcode/g-code.html

Finns även en hel del läsvärt om g-kod i EMC2's Integrators Handbook och Users Handbook

Dock tror jag inte att 20kr/st stegmotorerna kommer ge nog med kraft, men det finns ju billiga små NEMA17-motorer med 30-40oz/in för 20-30 dollar/st på nätet...

[saxofon]

mja... att gå på g-code direkt känns inte rätt. som redan sagts så gör man i princip en egen emc isåfall. har läst lite på http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Kinematics
där beskrivs ju några saker att tänka på "mellan g-code och stegmotor data".
kan man utnyttja så mycket av emc som möjligt är ju det bra.
tänker mig kanske tillbaka till usb lösningen och något med http://www.stepperboard.com/prod12-sd4dp.htm
så får man fixa emc att förstå sig på lite "intelligentare" kommunikation med stegmotorkontrollern, alltså inte på lägsta direction/step nivå utan lite ovan det på en nivå med set av motions. (där ett set beskriver en kombinerad rörelse för alla servon)
ser ut till att behövas några veckors letande runt i emc-koden

[Meduza]

Man får tänka på att man vill mata ut så att man har rätt mycket styrdata liggande i förväg hos kontrollern, eftersom USB's timing är rätt kass...

[saxofon]

mja... usb är inte kass

Det är designen som är kass ifall man gör så att man överlastar någon länk i systemet.

Tänk på att jag skissar att flytta bort den lägsta nivån FRÅN emc TILL någon slags kontroller.
Detta för att slippa de hårda realtidskraven där emc körs och därmed bli av med rtai eller liknande
vilket bara är FEL FEL FEL sätt att använda linux ur min synvinkel iallafall

Så, istället för att emc ska hålla reda på en hel rörelse, ska den räkna ut den (görs ju idag iallafall)
och sedan ska detta skickas till kontrollern som sedan ser till att putsa ut i rätt takt till hw.
Har kollat source i natt och det ser görbart ut även ifall emc inte är så värst strukturerat...
(återigen ur min synvinkel, andra tycker/tänker säkert olika)

[Meduza]

Det USB är kasst på är att den påverkas rätt mycket av övriga systemets belastning, speciellt på moderkort med inbyggda usb-kretsar, om något annat belastas så kan USB plötsligt bli väldigt segt...

Men som sagt, ligger man med en hyfsat stor buffer i hårdvarudelen så bör man inte påverkas av detta.

Ska ditt system kunna hantera återkoppling också?

[saxofon]

USB kan i en del implementationer ha problem, då det ofta skyfflas data utan DMA (kan det gälla alla PC??) i många embedded varianter, tex IXP465, så görs det dock med DMA och borde avlasta CPU'n en hel del. (det är iallafall den kritiken som förts mot USB vers Firewire som väl är implementerat med DMA oftast, även på PC platformen? lite ute och cyklar är jag nog här men men... )

Ska inte vara några problem dock, jag tänker mig hela rörelser så ifall länken inte hinner med (usb, eth whatever) så kommer fräsen bara stanna till ett tag innan flödet kommer igång igen
(ska alltså inte jämföras med den nuvarande rådata lösningen som lider stort ifall det blir hack i dataströmmen)

Återkoppling? hmmm du tänker på regler-loopen för rörelsen? den ska ju göras helt i kontrollern så visst. Eller menas absolut positionering? EMC verkar ha stöd för det men det har jag inte planerat, verkar inte som fräsarna här har de eller de billigare kommersiella heller.

Jag har ju lite forskning att göra först innan det står klart för mig hur allt detta hänger ihop iofs så det får väl tas med en nypa salt