od paja » 21.05.2015 21:27
Jenom abych se v zorientoval. Nahrali jste firmware z webu a nahrali i eprom z webu (je pribalena k FW) a dela vam to neco spatne ? Nebo jen ta defaultni eprom co si FW udela pri prvnim spusteni je spatne ?
Ono by asi slo upravit fw zpetne na hodnoty te eprom (aby se to spravne inicializovalo rovnou), ale nejak mne to nenapadlo. Nahravam do Arduin co prodavame oboji.
Mam k tomu i vtipnou historku: mel jsem den dovolene, kolegyni dosla arduina a pozadala kolegu z IT (je u nas kratce a je velmi schopny - ac to nikdy nedelal, tak to nastudoval a udelal) at ji je naprogramuje. Ja prijdu do prace a koukam, ze 50 nenaprogramovanych Arduin je naprogramovanych a ostitkovanych. Tak jsem to pro jistotu prekntroloval - FW ok, eprom nenahrana (nekdy je lepsi se holt zeptat). Ty rozdily nebyly velke, ale pro jistotu jsem jim dnes prehraval epromky. Takze pokud si v JRC koupite stavebnici nebo samostatne Arduino, a bude mit dve samolepky na sobe (jednu prefiknutou, odlepene a znovu nalepene byly hnusne), tak to byly tyhle.
Jeste poznamka k tem kruhum a fw. Jak se porad stouram v tom co by slo vylepsit /aktualne se uz pres mesic tesim na test plastovych kluznych pozder misto LM8UU, uz aby je vyrobce poslal/, tak si posledni dobou vsimam tisku kruhu, vibraci atp.
Co jsem vysledoval je, ze pokud se tiskne kruh, ktery se sklada z vice usecek /rekneme nejaky hull kulovitych objektu v openscadu s velkym $fn, prehnano pres slicer - v gcode jsou jen kratke usecky/ ma tendenci se zadrhavat. Nejede to po te kruznici plynule.
Dan nahodil zajimavou myslenku, ze to muze byt i displejem. Resp. FW. Kdyz to rozvedu: procesor je relativne pomaly. Mame drivery s 32 mezikroky. A FW pravdepodobne neustale aktualizuje displej. Takze je mozne ze kdyz se aktualizuji soucasne X a Y tak to procesor nedava. A projevuje se to tim, ze mu dojde buffer a ze shlukuje kroky do burstu (coz vyvola nasledne rezonanci). Je to jen teorie. Ale projevuje se to vic pri vyssich rychlostech tisku.
Ted vysel 0.923, ale nejak nemam cas se k tomu dohrabat, co tam zmenili a jestli to muze pomoct.
Teoreticka kalkulace: tisk ve dvou osach rychlosti 141mm/sec. Tj v kazde ose 100mm/sec. Pri 160 krocich/mm to je 2x100*160=32k operaci/sec. Ta operace zahrnuje udelat krok (impuls pro driver), prepocitat hodnoty pozic, zobrazit pozice na displeji (tam je ale jen 4 bit sbernice). Procesor ma 16MHz. Tj 500 taktu na operaci. Mezitim to musi stihat cist data, regulovat teplotu, osahavat tlacitka a volic, kontrolovat endstopy, ... Takze je to mozna na hrane.
Pokud mate nekdo prozkoumany FW (ne jako ja jen z rychliku), hodte pls nazor.
Ted jsem jenomu zakaznikovi serizoval tiskarnu. Krome chyb v sestaveni a zadratovani to bylo o neco vic vibrujici. Nejvic pri pohybu sikmo a kruzich. Prelestil jsem tyce, pomenil nejake loziska a furt to nebylo ono. Tak jsem vyhodil drivery a nechal jen jeden pro X a po jednom je testoval. Nasel jsem jeden, ktery byl postrehnutelne vic vibrujici nez ostatni. Chtel jsem to prozkoumat a zkusil jsem vymenit (s tim postizenym driverem) postupne zdroj, arduino a ramps. Nic nemelo vliv. Takze jsem dal novy driver (na Z by byval stacil bez ztraty kvality).
Jak tady nekdo psal cim se lisi FW JRC od originalu, tak je tam jedna drobna uprava. Nefungovalo dobre pozastaveni tisku. Jezdilo to nekam mimo (napr. Z by stoupalo az by roztrhlo tiskarnu, nahodne podle pozice nevimceho). Tak jsem to trochu patchnul. Je tam jeste jedna chyba pri pauze - nenastavoval jsem v tom patchi rychlost posuvu do pozice X=10mm, prebere se nejaka co je aktualne ve FW. Takze nekdy se to plouzi.
... ale nekdy se k tomu dostanu... 
