Stránka 4 z 6

Napsal: 7. 2. 2008, 10:14
od robokop
tyhle kontrolery jsou i hotove staci se podivat po netu
je toho celkem dost a vzhledem k pracnosti jsou i ceny celkem adekvatni tj. kolem 10 000
ja treba takhle pouzil kartu od gravosu
nejdriv jsem se tohodle reseni zdrahal ale protokol byl celkem prehlednej a srozumitelnej
umi to externi hardwarova preruseni a spoustu praktickych veci

v podstate to prijima jednotlive vektory a dela to linearni interpolace prdi to ven krok/smer
a slusne to cvici i AC servama

kruhove interpolace a podobne veci clovek musi udelat nad tim v PC a poslat jen miliony usecek

Napsal: 8. 2. 2008, 7:21
od CZ_Pascal
Co se tyka ceny 10000 a podobne tak to je protoze je toho na trhu malo a velice malo lidi je schopno si to ubastlit doma.

Ja mam v planu postavit vlastni kontroler ktery bude zvladat jak linearni tak kruhovou interpolaci jako centralniho svabika chci pouzit take ARM7 protoze ma se svyma 32 bitama a 60 MHz podstatne lepsi moznosti nez nejaky AVR 8 bit a jen 20 MHz.

Jediny co zatim nespocitam v na desce (protoze jsem to zatim nezkousel) jsou patricna zrychleni ktere vsak muze pocitat kompl a ric proste pojedes tuhle linearni/krhovou interpolaci touhle rychlosti a stakovym zrychlenim. A neni mozny aby to deska nestihala naprosto pravidelne a presne na 70 kHz
(a tech 70 je jeno odhad a pocitam ze to bude vic). Kdyby nahodou nejake vzorkovani nestihal ARM (presto ze jede na 60 MHz tak jeho vstupy a vystupy stihaji jen nekolik MHz) tak tam supnu jeste CPLD ktery si bude taktovat rychlost a zrychleni samo a z ARMa (pres nejakou vyrovnavaci panet) bude tahat jenom smer a krok.

A to cele rozhodne nebude stat 10 000 (teda vyvoj mozna nakonec ano ale ne jeden kus)

Napsal: 8. 2. 2008, 7:34
od robokop
ja bych rekl ze ted uz 20
protoze ta prvni varianta nebude chodit :)
takze se bude delat dalsi vyvoj a dalsich rekneme 10 za praci padne na vyvoj :-)

spis bych to vzal z druheho konce
so mi posle EMC a co musim naprogramovat
nez si rict budu delat kruznice a cary

dalsi problem je to zrychleni
taky naruby
zrychlovat a zpomalovat potrebujes delat predevsim hardwarove
treba takove najeti na koncak musis resit vcetne zrychleni hardwarove
protoze jinak nezmeris konec stroje s dostatecnou opakovatelnou rychlosti

pak taky potrebujes resit buffer

protoze do stroje musis nahrat dostatek dat dopredu aby byl schopny kontinualne pracovat
tudiz treba navazujes na predchozi vektory bez zastaaveni jen tim ze po zmene vektoru upravis rychlosti motoru

ovsem co udelas kdyz je najednou z nejakeho duvodu buffer prazdny?

na petniku nezastavis
musis zpomalit
takze se nakonec musis naucit pocitat zrychleni na hardware

a nejake kruznice
ty tam nakonec muzes posilat jako stovky, tisice usecek

podstatne horsi pro tebe bude zachovat vzdy za kazdou cenu presnou frekvenci kroku i v pripade ze pri tom budes v tu samou chvili pocitat spoustu slozitych veci

Napsal: 8. 2. 2008, 7:44
od CZ_Pascal
Takovou samozrejmost jako jsou bufery na vstupu jsem ani nezminoval.

Zadruhe na koncak se da dojet i pomalu a udelat dva koncaky s tim ze od toho prvniho budu zpomalovat urcitou rychlosti az se dostanu na ten kde chci zastavit.

Soustredit se na to co leze z MACHu se neda protoze tam leze jen step/dir (coz je naprosto fajn) ale rozhodne neni fajn rachlost a pravidelnost frekvence, takze i ten krasny step a dir jsou k nepouziti.

Co se tyce velikosti buferu tak poduk tam nebudu hrnout miliony linek ale jednu kruznici tak mi 2MB buferu staci skoro na celou praci a za tri sekundy mam bufer zase plny. Nehlede na to ze se doplnuje v prubehu.

A ta absolutne stala frekvence kroku je PODSTATNE mensi problem nez jekym jsou vypocty zrychleni. A jak jsem psal i na ne dojde.

A vyvoj prvniho prototypu nebude stat 10 000 protoze svou praci do toho nepocitam (kdyz to delam pro sebe).

Napsal: 8. 2. 2008, 8:03
od robokop
o machu jsem nemluvil
ale budiz
napis si plugin nebo pouzij grexovej a pojede ti z nej mnohem vice uzitechnych dat nez step dir

plynulost kroku je problem zcela zasadni zvlast u krokovych motoru
kdyz ti rychlost bude kolisat a je jedno jestli na vsech osach soucasne
krokovy motor tohle nemusi vydejchat a ztrati kroky

co se koncaku a bufferu tyce
co kdyz pri obrabeni dojedes na koncak (napr. kvuli ztrate kroku)

pred sebou mas par tisic linek v bufferu jedes nejakou rychlosti a co ted
musis okamzite zastavit jinak se stane prusvih
zeptas se PC na to jak mas decelerovat ?
kam ti to to pc posle?
na konec bufferu?
smazes ten buffer?
jak by jsi pak zjistil kde jsi byl naposledy v programu?

jak zmenis rychlost obrabeni kdyz mas v bufferu predpocitany program na dalsich 5 hodin obrabeni?
jak spolehlive zajistis vymazani bufferu prepocitani dat a jejich znovunacteni do bufferu bez toho aby se stroj zastavil pote co zmenis rychlost obrabeni

ono to ve finale neni tak jednoduche a nabaluje se na to moc a moc veci
a troufam si tvrdit ze kdyz budes dobrej tak cca za 2roky budes moct rict ze mas prvni verzi ktera se da povazovat za produktivni a to tam budes mit 20% toho co by to mohlo ve finale umet

jo a kdejakej driver potrebuje ruzne pauzy mezi log sinaly step a dir
melo by to jit menit aby jsi mohl pouzit ruzne drivery

taky jsem byl takovej
ale jsem ted trosku vic realista
a zameruju se na problemy kterym se neda vyhnout a ze jich je pozehnane
interpolatory existuji
ale napr. vykresy na poradnej stroj s dobrejma vlastnostma a vykonem...

Napsal: 8. 2. 2008, 8:31
od CZ_Pascal
Asi jsem se spatne vyjadril.

Nemyslel jsem to tak ze absolutni presnost frekvence kroku neni potreba, ale ze to nebude problem.

Pokud pri obrabeni dojedu na koncak pri ztrate kroku tak je neco setsakramentsky v neporadku a to co zbyde v buferu me uz nezajima protoze uz to co se delo predtim bylo spatne. Ono totiz nepocitam ani se ztratou jedineho kroku. Na to jsou snad motory dimenzovane a jejich zrychleni spocitane tak aby mely jeste bohatou rezervu na zrychlovani.

Pokud potrebuji okamzite zastavit tak je opet neco setsakramentsky spatne a o nejakou deleleraci a pripadnou ztratu kroku se moc nestaram a proste to zastavim.

Rychlost zmeny obrabeni v prubehu obrabeni ??? Proboha proc ??? Snad mam dany nejake rezne podminky a v tech to chci obrabet.

Komunikaci s drivery ktere vyrabim si samozrejme zajistim protoze vim presne jak driver ridim a co stiha a co ne.

A ted to nejdulezitejsi: Nevyrabim nejaky system pro nasazeni na profi masiny, ale na moji malinkatou usmudlanou jeste nevyrobenou frezku.

Napsal: 8. 2. 2008, 8:33
od CZ_Pascal
Jo a jeste k te pravidelnosti frekvence kroku.

To je prave duvod proc to cele delam a nespokojim se s nejakym nahodnym casovanim lezoucim z LPT.

Napsal: 8. 2. 2008, 9:06
od robokop
doporucuji v prvni rade zaexperimentovat treba s machem, tam zjistis o cem je CNC obrabeni a o cem je CNC obrabeni na hoby masince
zjistis ze rezne podminky ktere krasne vypocitas podle tabulek mohou platit treba pro litinovou masinu ne vsak pro tvoji frezku a ihned co najedes do materialu zjistis z priserneho zvuku ze
1) potrebujes okamzite zastavit!!!
2) snizit reznou rychlost
3) pokracovat v obrabeni toho co je v bufferu

tedy hned 3 veci ktere jsi si myslel ze nepotrebujes

je potreba ziskat praxi a vedet o cem to je nez se pustis do vyvoje neceho sveho
teorie je vetsinou velmi stroha a nemluvi o spouste veci
diky tomu budes vyvijet software a hardware kdyz by jsi treba mohl pouzit neco hotoveho napr. mach a LPT mnohem lepe nez neco nedodelaneho protoze s postupujicim vyvojem se na problem nabaluje spousta dalsich veci az ti to preroste prez hlavu a budes muset zajit znova a jinak
celkove zmenit koncepci atd...

doporucuju tedy zacit machem a LPT za to nic nedas ale hodne ziskas
pak zjistis co vlastne potrebujes ovladat a jak to vlastne oni delaji
a podle toho se muzes rozhodnout jestli ti stoji za to neco vyvijet a nebo se ti vyplati to treba koupit od gecka nebo kohokoli jineho

Napsal: 8. 2. 2008, 9:13
od dslav
Myslím že potenciometr pro ovládání rychlosti je nutný. Pak je taky nutné mít možnost kdykoli řízeně zastavit s tím že se po spuštění bude pokračovat normálně dál. Když jsem dělal svůj kontroler tak toto byly podmínky ze kterých nelze ustoupit. Vyšel mi z toho závěr že rychlosti a rampy může úřipravit PC ale o řízení rychlosti se musí postarat kontroler který pracuje v realtime režimu.

Co se týká procesoru tak ARM7 na 60MHz by těch 70kHz STEP-DIR mohl zvládnout. Sám jsem o tom uvažoval jestli neudělat implementaci MegaCNC na LPC2106. Tato možnost tady pořád je ale zdá že by to chtělo ještě něco rychlejšího. 70kHz je málo a bylo by to jen 4x rychlejší než stávající MegaCNC.

Napsal: 8. 2. 2008, 10:12
od CZ_Pascal
Pánové je pravda ze o obrabeni toho zase tak moc nevim a kdyz rikate ze tohle jsou veci nutne tak je samozrejme do sve ridici jednotky dam.

Co se tyka toho MACHu tak mam samozrejme v planu se nejprve podivat jak to na nem jezdi a pak teprve neco delat po svem inspirovany potrebami ktere z toho vseho vyplynou.

Uznavam ze na MegaCNC bylo urcite spousta prace a vyvoj nebyl levny, ale 20 000 bez DPH za neco co mohu postavit levneji proste dat nemohu.

Tim nechci rict ze to prodavate predrazene nebo tak, ale rozhodne vyrobni cena toho kontroleru (nepocitaje lidskou praci) ja tak asi ctvrtinova ne-li mensi.

Ale samozrejme Vam to zabralo spoustu casu to vyvyjet a take nabizite nejake zaruky takze to stoji kolik to stoji a je to tak spravne.

Co se taka te rychlosti jak rikam kdyz nebudu stihat carovat s piny na ARMu tak si pomohu CPLD a v nejhorsim pripade FPGA. Jinak ten ARM ma vyhodu ze ma v sobe rovnou i USB:-)

Napsal: 8. 2. 2008, 10:25
od robokop
s tim USB muze byt taky problem
vetsina vreten dela takovy bordel v eteru ze USB bude hodne nespolehlive
me treba prestane makat klavesnice na USB jakmile bezi vreteno

Napsal: 8. 2. 2008, 10:44
od dslav
Uznavam ze na MegaCNC bylo urcite spousta prace a vyvoj nebyl levny, ale 20 000 bez DPH za neco co mohu postavit levneji proste dat nemohu.
Uplně na začátek musím říct že nikoho nenutím aby si cokoli koupil. Taky ten můj příspěvek neměl nikoho odradit od jeho záměrů. Pouze jsem chtěl upozornit na možná úskalí CNC kontroleru.

A teď k ceně kontroleru MegaCNC. Osobně si myslím že by cena kontroleru a panelu včetně SW neměla přesáhnout 5000kč. To že se to snaží Kavan (techtronex) prodávat za 20000 hodnotím tak že ten projekt !zabil cenou!. Aby to bylo úplně jasné tak tento náš dlouholetý spor vyůstil do situace kdy jsme spolu absolutně přestali komunikovat. Takže pokud by měl někdo nápinky si to koupit u Kavana tak platí někomu kdo nemá zdrojové kodý a nemůže tudíž provádět jakoukoli změnu nebo opravu. Kdyby si to někdo chtěl postavit tak na mém webu jsou výrobní podklady a pokud to opravdu někdo uděla dostane od mě poslední verzi SW. A kdyby se našel někdo kdo by sám chtěl udělat nějaké úpravy tak bych mu mohl poskytnout i zdrojáky.

Napsal: 8. 2. 2008, 12:27
od robokop
to zni velmi slusne
tech 20 000 bylo opravdu prilis
proto jsem o tom nikdy neuvazoval a pouzil jsem gravos ktery byl vyrazne levnejsi a mel par funkci navic

Napsal: 8. 2. 2008, 1:04
od CZ_Pascal
No za 5000 by to bylo opravdu parada, a dostalo by se to do ruk spouste lidi kteri si to neumi postavit sami a myslim ze by byli nadmiru spokojeni (mozna az na tech 16 kHz vystup).

Nakolik si cenite zdrojoveho kodu pro MCU ?? Chtel bych se inspirovat a nevynalezat objevene (hlavne tedy co se tyka akcelerace a rychlosti).

Trochu jsem nad tim premyslel a zatim me nenapadlo jak elegantne zvladnout plynuly prechod rychlosti z jednotlivych G kodu. Tedy treba kdyz mam na sebe dve kolme linky tak se jedna osa uplne zastavi a druha nasledne rozjede, ale kdyz ty linke nejsou na sebe kolme tak nemusi (nesmi) dojit k nejakemu zastaveni, ale pouze zpomaleni na rychlost ve kter bude jeden motor pokracovat - pokud to tedy bude rychlostne stihat druhy motor).

Napsal: 8. 2. 2008, 1:45
od dslav
Na všechno ostatní je MasterCard a pak jsou věci které penězi nezaplatíš.

Když mě přesvědčíš o upřimnosti svého záměru, můžeme se dohodnout za jakých podmínek ty zdroje poskytnu.