Polskie Forum FPV

Co użyć zamiast komputera PC do drukarki 3D? Coś w stylu RaspberryPi albo podobnego, aby drukować z plików GCODE .ngc na karcie SD?

A co masz za druksę? Do RAMPS'a (przykładowo) wystarczy dokupić płytkę z wyświetlaczem i slotem na kartę SD i możesz druczyć bez peceta.

_________________
Ten wredny...

Ja tylko tak drukuję, moja drukarka nigdy nie widziała kompa. Płyta to Rumba.

_________________
________________
Cobra

Jeszcze nie mam. Ale chcę żeby była całkowicie "stand alone". Przenośna i bez komunikacji przez usb - laptop.

Wrzucam pliki g kodów na sd i drukuję.

Jedyne co mi brakuje aby skompletować zestaw to informacja czy takie płytki są (już wiem że są, dzięki!) i która jest najlepsza.

Wydaje mi się że procesor na takiej płytce musi być klasy wyższej niż 8 bit aby prowadzić sprawnie takie obliczenia?

Sprawdzę ramps i rumbę, dzięki !

Na tych płytkach do kart SD nie ma nic poza podstawką pod SD i paroma rezystorami dla dopasowania sygnału. Całą robotę robi procesor z drukarki, czyli wspomniany 8 bitowy AVR.

_________________
Pzdr. -----MIŚ-----

I w związku z powyższym zdecydowanie sugeruję kierować się czym innym przy wyborze płytki. RAMPS jest ok bo to tanie jak barszcz ale ubogie w dodatkowe bajery - np tylko 2 wyjścia na napęd ekstrudera więc jakbyś chciał kiedyś Krakena od E3D to już lipa. Poza tym jakość zastosowanych rozwiązań jest taka sobie i wskazane są drobne usprawnienia jak zmiana bezpieczników na samochodowe czy dodanie stabilniejszego źródła 5v. Mam bo na nic lepszego w onym czasie nie chciałem wyłożyć kasy i dzięki wskazówkom kolegów jeszcze mi nie padł ale żeby to był Mercedes to nie powiem.
To samo jest z doborem softu który ci to będzie poganiał.

_________________
Ten wredny...

A są jakieś interpretery na choćby ARM które działają na rtos i liczą wszystko na bierząco?

Możesz sprecyzować swoje pytanie? Albo rozwinąć je? Są gotowe firmware do drukarek. Odczytuje gcode i przy okazji robienia kilku innych rzeczy zajmują się głowie wydawaniem komend silnikom krokowym jak w starych dobrych maszynach CNC. Co jeszcze chcesz robić? Wczytuje gcode i maszyna bezmyślnie wykonuje wszystko co w tym gcode jest napisane.

_________________
Pozdrawiam,
Przemek

Chcę aby interpreter na bierząco obliczał położenie maszyny. Jak w normalnym sprzęcie. Protezy i sztuczki programistyczne mnie nie interesują.

Rtos i obliczanie aproksymacji on the fly.

Ewentualnie pokazanie aktualnej pozycji i feedrate, linijki kodu.

Po co? Duże prędkości, precyzja.

Możesz podać przykład takiego "normalnego sprzętu"?

Jeżeli pod nazwą "normalny sprzet" rozumiesz sterowanie ze sprzężeniem zwrotnym na serwomechanizmach a nie na prostych silnikach krokowych to Twój wybór jest mocno ograniczony a właściwie nie istnieje.

Każdy firmware drukarki odczytuje kod i na podstawie różnicy współrzędnych (odczytany między jedną a druga linijka kodu) wysyła do silników krokowych odpowiednią liczbę impulsów w danym okresie czasu. I tyle albo aż tyle. To jest system powiedz i miej nadzieje że silniki nie zgubia kroku.

Nie znam oprogramowania do drukarki, która odczytywalaby porcję silników i na bieżąco korygowało ich pozycję.

. Sterowniki typu Simulink, Simatic, Hidenhan otd to overkill i kosztują 10x co sama drukarka...

Jedyne 2 znane mi rozwiązania ze świata drukarek to niestety rozwiązanie hardwareowe.
1. Są silniki hybrydowe z enkoderami. Ich zaletą jest działanie plug and play w miejsce zwykłych krokowców. Z tym ze maja wewnętrzne sprzężenie i same siebie pilnują aby utrzymać zadane położenie wynikające z ilości otrzymanych od sterownika impulsów.

2. Gdzieś chyba przeczytalem że niektóre sterowniki TMC hardwarowo i na podstawie sprzężenia zwrotnego też potrafia pilnować czy aby na pewno silnik wykonał odpowiednią liczbę korków wynikająca z wysłanych impulsów. Jest to rozwiązanie zewnętrzne do silnika.

W obu przypadkach chodzi o upewnienie się ze silnik osiągnął żądaną pozycję. Sterownik - w sensie procesor drukarki - nic na bieżąco nie przelicza - tylko na ślepo wysyła sygnały elektryczne do sterowników silników krokowych. A co dzieje się potem to w świecie drukarek jest mało ważne.

_________________
Pozdrawiam,
Przemek

EDIT: firmware drukarki odczytuje kod sam z karty lub dostaje go od innego czytnika jakim jest np PC z kablem USB. Odczyt gcode to banalna sprawa. Ani PC ani sama drukarka nie mają bladego pojecia gdzie znajdują się w danej chwili silniki. One mają nadzieję że silniki są tam gdzie mają być. Jeżeli któryś silnik zgubił krok to tzw dupa. I jedyne zabezpieczenie to jak wyżej sprzężenie zwrotne.

_________________
Pozdrawiam,
Przemek

Tak, stepsticki TMC mają sporo fajnych bajerów - automatyczne dostosowywanie amperażu do obciążenia, wykrywanie kolizji (można zlikwidować krańcówki) czy właśnie wykrywanie zgubionych kroków - nie wiem tylko czy nie jest to goła informacja dzięki której można zatrzymać sobie cały proces.

_________________
Smart 650W Battery Discharger
Dragon X5 220/Matek F405-STD/Racerstar 30A ESC + Racerstar 2306S/5045@3S
Quadcopter 390/Matek F722-STD/Racerstar 30A ESC + Racerstar 2216/1038@4S
Octocopter 900/Pixhawk 2.4.8/Racerstar 30A ESC + Racerstar 4114/2060@4S

Nie pamiętam do czego TCM używały tej wiedzy. Ale na pewno firmware niewiele miał z tym wspólnego.

Czytając drugi raz post kolegi dochodzę do wniosku ze on jednak nie ma pojęcia ze byle który firmware drukarki jest właśnie interpreterem. Przynajmniej te dostępne od ok 4 lat. Co było wcześniej nie wiem.

Najprostsza płyta Ramps z Marlinem to właśnie interpreter rtos. Odczytuje komendy i na bieżąco wysyła odpowiednie impulsy do silników. Ot co.

Moje rozpisane w temacie sprzężenia zwrotnego wynikało z chęci obliczania (znajomości) pozycji drukarki na bieżąco.

Teoretyczna pozycja a realna to dwie rozne sprawy.

O ile mi wiadomo żaden firmware tego nie obsługuje bezpośrednio. One tylko odczytuja gcode i przekazują polecenia dalej. A czy silnik wykonał daną operację czy nie (np zgubił kroki) to już inna sprawa.

_________________
Pozdrawiam,
Przemek

Nie wiem, dlatego pytam.
A normalne maszyny cnc robią to tak jak niżej:

Jedyne co można sprawdzić to napisać procedurkę aby obliczyć przejście np. g2 z punktu 1 do punktu 2 w jedym kroku dla układu 3 osi i zasymulować wykonanie tej operacji. Zmierzyć ile cykli procesora wykorzysta, ile czasu potrzeba i czy zmieścimy się w rampie dla jakiś sensownych prędkości posuwu.

Nawet słabsze arm nie wydolą. I to bez dodatkowych bajerów jak wyświetlanie pozycji.

Jak to mówią, trzeba się cieszyć z tego co się ma :)