REBEL 3D

Nevim, jestli nejaky problem nemuze by t iv cinskych arduinech...

Mel jsem vse od JRC, nahranou EEPROM.. tisknu zasadne pres kartu a proste z niceho nic mi to jednou zaclo zlobit...
Kdyz jsem prepsal EEPROM, tak vse se dalo zase do poradku... A za nejaky cas se to zase opakovalo...
Tak nevim, jestli nemuze byt neco spatne v tom arduinu, jinak si to nedokazu vysvetlit...

Když už jsme u těch kruhových perimetrů, mě to dělá tohle:



Je to normální nebo mám něco špatně nastaveného?
(myslím ty zbytečné výjezdy mimo, děje se tak jen u kruhových dutých tvarů)

Co to používáš za tiskový program , tam máš přidaný nějaký dodatečný odjezd - normálně to tak nedělá a ani není potřeba ,aby to dělal u tak velkého kruhu .Kdyby byl malý ,tak bych pochopil ,že to pomůže uchladit perimetr .

Je to normálně Repetier-Host a Slic3r nic neobvyklého. Oboje v poslední verzi pro Mac.

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.

h4wk3y píše:Nevim, jestli nejaky problem nemuze by t iv cinskych arduinech...

Mel jsem vse od JRC, nahranou EEPROM.. tisknu zasadne pres kartu a proste z niceho nic mi to jednou zaclo zlobit...
Kdyz jsem prepsal EEPROM, tak vse se dalo zase do poradku... A za nejaky cas se to zase opakovalo...
Tak nevim, jestli nemuze byt neco spatne v tom arduinu, jinak si to nedokazu vysvetlit...

Jestli mas i Arduino od JRC, tak napis na 3d@jrc.cz - poslu ti jine na test.

paja píše:

h4wk3y píše:Nevim, jestli nejaky problem nemuze by t iv cinskych arduinech...

Mel jsem vse od JRC, nahranou EEPROM.. tisknu zasadne pres kartu a proste z niceho nic mi to jednou zaclo zlobit...
Kdyz jsem prepsal EEPROM, tak vse se dalo zase do poradku... A za nejaky cas se to zase opakovalo...
Tak nevim, jestli nemuze byt neco spatne v tom arduinu, jinak si to nedokazu vysvetlit...

Jestli mas i Arduino od JRC, tak napis na - poslu ti jine na test.

Diky moc, ale prave Arduino jsem bral primo od cinana.. skladal jsem to tak napul... mechanika od Vas a elektronika z Ciny... Mam druhou Megu v supliku, ale je pro me rychlejsi vzdycky prehrat EEPROM, kdyz si vsimnu zhorseni tisku, nez to tam rozebirat a menit arduino ... ale nekdy se k tomu dostanu...