Så ja, äntligen lite tid över som istället för att användas till
städning, diskning eller något annat elementärt prioriterades åt
något mycket viktigare... driva kretskortsfräsmanickenprojektet framåt
Tror jag hittat en lösning på problemet dator-utan-parallell-port-men-ändå-
gå-på-"gpio"-styrning-av-stegmotorerna... detta för att enkelt kunna använda
sig av EMC2 eller liknande installerad i en helt vanlig linux-laptop och sedan
koppla sig mot kort såsom jojjes stegmotordrivare.
(Jag vill ju inte mecka med rtai eller liknande junk)
Lösningen var ruskigt enkel och låg redan i skrivbordslådan i form av en
FTDI 245BM modul inhandlad till diverse andra projekt många år tidigare.
Det är en modul som är usb->8-bitars I/O, den har en kompis som är usb->uart
och som används i många sammanhang.
Nåväl, den har en liten finess som jag utnyttjat för att få fina pulser.
Bit-bang-mode! Tanken är väl främst för de som vill ha den till usb->i2c/spi
eller liknande men den funkar fint att generera pulser till stegmotorer också.
Eftersom den har en 128 byte buffer räcker det för hårdvaran att inom freq/128
hinna pytsa på denna buffer. En byte ut betyder att man har fyra steg/riktning-
par och att man alltså kan hantera fyra stegmotorer synkront. Vill man köra
fler är det ju bara att sätta dit en modul till... (eller... när jag väl får
igång kretskortsfräsen kommer det ju naturligtvis tillverkas ett kort där allt
är lött från början förstås)
Det blir så här fint när man kör på i lagom takt:
CNC Stepper tester
Current config:
Max step freq : 40000 Hz
HW resolution freq : 80000 Hz
HW resolution period : 0.0125 ms
HW FIFO freq : 625 Hz
HW FIFO period : 1.6000 ms
Frågan är ju nu hur det ser ut för er som kör med parallellport och DOS, win
eller rtai/linux... Jag skulle misstänka de inte går med samma jämna fina takt som ovan...
Så visst är det så att man kan få tillräcklig realtid även via USB för denna applikation?
Ovanstående är gjort med ett par trådar i userland. En som genererar data
(som ju egentligen kommer vara EMC2) och häller detta data i en cirkulär buffert.
(jag drog till med 1MB). En annan tråd tar data från denna circulära buffert och
pytsar ut till ftdi när det behövs. Detta görs via libusb (som faktiskt även finns till
windows och då öppnar det ju upp för att flytta över lösningen till windows
också
) så jag har ju faktiskt inte ens ansträngt mig att fippla till
linuxen för att köra realtid. Jag använder en helt vanlig fedora installation
på en helt vanlig laptop. Har kört testet under många timmar samtidigt som
det varit annan last på laptop'n som surfning på nätet, läsa mail, "konstlast"
i form av bonnie++ medans jag tog en promenad i det fina vårvädret.
Belastningen från testet är knappt mätbar utan det är datorns normala
aktiviteter som syns nedan, undantag är spiken på cpu-lasten som kommer från
när jag körde igång testet och det extra minnesutnyttjandet eftersom jag låst
processens minne så att det inte ska swappas ut.
Kunde inte trigga någon form av tappade pulser, fördröjda pulser eller
liknande.
Enligt datablad ska man kunna köra upp till 300KHz, många stegkontrollers
verkar maxa runt 40KHz så det får väl bli en default config. Provade dock var
gränserna gick för denna lösning och det verkar vara runt 240KHz
Tycker jag borde kunna koppla utgångarna på modulen direkt till Jojje's stegdrivare,
så ett test med "riktig hårdvara" är väl inte långt borta.
Den riktiga lösningen borde väl ha opto-kopplare emellan förstås.
Det som ska göras nu är att ta bort rtai-beroendet från EMC2, och sedan
låta den skicka bitströmmen till den circulära bufferten istället för parallell-porten.
Och så återstår det lilla jobbet att mecka ihop en fräs förstås... :-D
)
