G / M - code referens, ngn som har?!

[NeoTech]

Tänker jag fråga ngt riktigt korkat som jag garanterat kommer få äta upp när forumtrollen hittar detta.

Men ja letar efter en G/M kod referens, om hur dessa skall implementeras. Och hur de skall läsas / tolkas
innan de förs över till hårdvara.

Anledningen är väl den att jag börjat grotta ner mig djupare o djupare i embedded pc system, och börjat
mecka runt med en Raspberry Pi mikrodator. Och funderar på hur jag kan få den att kontrollera mina stegmotor
drivare istället för smoothsteppern.

Visst det går jue o få en raspberry o snurra en stegmotor X grader/steg .. men hur skulle man gå tillväga för
att få den och kontrollera säg 5 axlar... För detta behöver ja lära mig lite mer om språket som skall driva det.

[säter]

Det här svaret fick jag av H.O, i en annan tråd.

Du ställer in accelerationen i Mach3 precis som vanligt - och den är linjar, precis som med LPT-port drivern.

Mach3 "planerar" rörelserna och skickar dom som hastighetsdata för respektive axel. Det finns en ställbar uppdateringsfrekvens, (controller frequency) 1-4kHz tror jag, som talar om hur många "hastighetsuppdateringar" varje axel får per sekund. I princip kan man säga att det som skulle vara en perfekt cirkel egentligen blir en tusenhörning om den tar en sekund att "köra" och "uppdateringsfrekvensen" är 1000Hz.

SS har en buffert med ett visst djup, ju högre "uppdateringsfrekvens" man ställer in desto högre krav ställer det på PC'n att fylla på bufferten med nya hastighetsdata - innan den "går torr". Mach3 planerar upp till 1 sekunds rörelse och skickar till SS som börjar exekvera, när bufferten har tömts lite grann signalerar den till Mach3 att den är redo för mer data och Mach3 har då "gott om tid" på sig att planera och sända över mer data så att bufferten håller sig flytande.

Sen finns det förstås en himla massa detaljer men i princip är det så den fungerar.

Om jag tolkar detta svar rätt, så är det fortfarande Mach3 som utför alla beräkningar.
Smoothstepper fungerar enbart som buffert.

[labmaster]

Enligt mitt sätt att se det så verkar du inte fundera på ett korkat projekt. Men det finns ju en hel det sådana på forumet så om någon har behov av att bedöma ditt projekt i förhållande till andra så går det ju alltid bra att göra.

Hur som helst, om du nöjer dig med Gkoden för LinuxCNC så finns följande:

G Code Overview
G Codes
M Codes
O Codes
Other Codes
G Code Examples

Vill du spara tid kanske det går att porta hela LinuxCNC till Raspberry Pi. Det kanske rentav redan är på gång någonstans.

[sprawl]

Hej,

jag hade samma funderingar. Dock efter lite ytterligare funderingar så tror jag att det nog är dumt att styra själva hårdvaran ifrån RPi och har istället tänkt bygga ett kontrollerkort baserat på AVR/Arduino och lämna mer högnivådelarna till RPi.

Finns exempel på os g-code interpreters såsom http://grbl.tumblr.com, finns även en "spec" på g/m-code på reprap-wikin http://reprap.org/wiki/G-code
---

Såg att det kommit en post av labmaster emellan, vad jag vet så är det problem med att få LinuxCNC att fungera på RPi pga att RPi saknar de delar för realtime i linux som LinuxCNC kräver. Om någon löser det så är det säkert den bästa lösningen


/s

[säter]

Jag kanske missförstod frågan?

Vad respektive G-kod får för resultat i slutänden gissar jag att TS redan har koll på.
Jag trodde han var ute efter vad Mach3 skickar för kommandon till Smoothstepper, vid t.ex. en G3.

[labmaster]

Japp i portning av LinuxCNC till RPi ingår också jobbet med realtidkomponenterna.

[NeoTech]

ah, awsome. ja jag e inte så intresserad av linuxcnc utan mer vill gräva ner mig själv i o bygga en g-kods tolk som sedan kan köras över en RBi, med ett hårdvaru gränssnitt.
Så de där referenserna är perfekt för mitt syfte.. Det är högst exprimentiellt just nu.. Personligen så e målet att dumma ner kontroll gränssnitten mer än LinuxCNC, ngn som
har sett PlasmaCAM eller deras mjukvara förstår vad jag far efter för nivå av "nerdummning". =)

[labmaster]

Nej, jag har inte sett PlasmaCam men däremot har jag läst koden för Gkod-tolken i LinuxCNC. Det är Open Source så du skulle kunna spara en del tid om du använder den delen av LinuxCNC.

[NeoTech]

Aha, så den är så pass fristående från resten att man skulle kunna lyfta ut den. Ja det e är jue klart värt att titta på isf.
Har lite "inläsning" o göra dock här vilket som, lära mig att förstå G kod så blir de lättare att felsöka . =)

[säter]

Labmaster:
Du som är med på tåget, kan du förklara vad TS försöker bygga?

Jag trodde det rörde sig om en hembyygd Smoothstepper, men så är det tydligen inte.

[sprawl]

Därför jag länkande till grbl också, det är en dum gkod interpretator (som är tänkt att köra på arduino). Jag lider också av NIH (Not Invented Here) och gillar att bygga saker själv . Jag tror jag har haft liknande tankar som dig runt projektet så det blir spännande att följa hur du går vidare.

[NeoTech]

Säter, jag försöker skapa ett generiskt styrsystem för CNC.. som snurrar på en typ av mikrodator som e extremt billig. (350.-).
Men som har fördelen av att man kan koppla ihop det direkt mot det generiska I/O systemet i datorn, utan o behvöa passera
parallell port eller usb eller ngt annat trams.

Vilket öppnar möjligheter att styra systemet på andra sätt låt säga vi ett webui, eller en iOS/Android klient. Och man kan ta ner
programmeringen på en mer exprimentiell nivå i script form eller liknande.

[labmaster]

Säter, räcker det med NeoTech:s förklaring eller behöver du ytterligare input från mig?

[Andax]

För några år sedan började jag på något likande. Gjorde en enkel G-kodsparser och sedan gjorde jag kod som drev en stegmotor. Dokument kring g-kod hittade jag i någon referens från LinuxCNC. Ska rota lite.
Själva stegmotor-timingen var baserad på en intressant artikel där de visade hur man skulle justera steg-timingen optimalt när man hade acceleration och decceleration med i stegningen.
Som sagt, ska rota lite och se vad jag hittar.

[NeoTech]

ah nice, ja få till en gkods parser känns lite som steg 1.. typ parsea kod o rita ut det på ngt sätt. Iaf i mitt huvud, jag kan ha fel.