STEP2CNC - ZAKOŃCZENIE PRAC NAD PROGRAMEM

Piotr Rakowski · Post napisał: **Piotr Rakowski** » 07 mar 2007, 06:29

To niestety wymaga sporej wiedzy, której nie mają nawet twórcy Macha. Oni użyli drivera kupionego w firmie Taiwańskiej (pisałem już o tym). Koszt zakupu takiej licencji jest spory.

Poza tym w cale nie jestem przekonany, czy to rozwiązuje wszelkie problemy. Jak już pisałem mam listy od ludzi, którzy na Machu i KCamie polegli, a STEPa uruchomili i są zadowoleni.

Rozwiązaniem będzie dopiero sterownik mikroprocesorowy.

bartuss1 · Post napisał: **bartuss1** » 07 mar 2007, 08:41

znam paru co polegli na machu i zyją na stepie, chociaż jak na moj gust rewelką step nie jest, ale dla (prostych ludzi?) wystarczy ...

Piotr Rakowski · Post napisał: **Piotr Rakowski** » 07 mar 2007, 08:52

Bartuss1 - ponieważ bardzo mi zależy, żeby STEP był super - powiedz, co Ci w nim przeszkadza, a co dorobić, ew. zmienić.

jarekk · Post napisał: **jarekk** » 07 mar 2007, 10:30

Piotr Rakowski pisze:To niestety wymaga sporej wiedzy, której nie mają nawet twórcy Macha. Oni użyli drivera kupionego w firmie Taiwańskiej (pisałem już o tym). Koszt zakupu takiej licencji jest spory.

Poza tym w cale nie jestem przekonany, czy to rozwiązuje wszelkie problemy. Jak już pisałem mam listy od ludzi, którzy na Machu i KCamie polegli, a STEPa uruchomili i są zadowoleni.

Nie rozwiązuje. Z racji swojej pracy mam wgląd w bebechy drajwerów oraz procesorów. W dobie wielu procesorów oraz nadchodzącej wirtualizacji nie da się zbudować stabilnie pracującego drajwera generującego np. 50kHz sterowanie - znane mi rozwiązanie używają do tego zewnętrznego hardware'u. No może kiedyś - jak okrzepnie wirtualizacja - będzie można jeden procesor przeznaczyć na DOS'a

Mach działa - ale do tego należy odpowienio skonfigurować Windowsy - w sposób który ogranicza ich normalne wykorzystanie ( wystarczy jakiś mały program - śmieć który obciąża system i będą problemy).

Piotr Rakowski · Post napisał: **Piotr Rakowski** » 07 mar 2007, 14:42

Panie Jarku, jeśli ma Pan doświadczenie w tej kwestii proszę podzielić się z innymi skonfigurowaniem Windozy ograniczającym jej "normalną" pracę. Przyda się to wszystkim użytkownikom, nie tylko Macha, czy STEPa, ale i KCama, cncPlayera itd.

bartuss1 · Post napisał: **bartuss1** » 08 mar 2007, 09:35

no jest pare rzeczy które moga być niezastapione na przyszłośc :
- offset narzędzia i wybór kierunku obróbki - z prawej lub lewej zadanego konturu
- cykle - frezowanie kieszeni, otworu, powierzchni coonsa (taka topografia materiału iles tam połuidników i ileś równolezników o zadanej krzywiznie splinu) - rózne metody wejscia i prowadzenia narzędzia - np w jedną stronę, zigzag, z wejsciem helikoidalnym, spirale archimedesa itp.
- cykl wiercenia i gwintowania otworu
-cykl frezowania gwintu

mach tez taki super nie jest, ale podstawowe offsety i cykle ma.

Piotr Rakowski · Post napisał: **Piotr Rakowski** » 08 mar 2007, 10:22

A nie, tym niech się zajmują programy do generacji ścieżek (np. eduCAD, VisualMill itd.).

Niestety z matematyki miałem tylko czwórkę. O ile offset zewnętrzny (powiększający) jest łatwy do policzenia, o tyle offset wewnętrzny wektorów, szczególnie między krzywą i prostą lub dwoma krzywymi jest dla mnie niepoliczalny. Może, jak znajdę kiedyś takie algorytmy...?

Ideą STEP2CNC jest li tylko interpretacja G-kodu. Musi być on przygotowany w jakimś programie generującym wektory. Automatyzacja ich przeliczania niepotrzebnie spowalnia pracę czaso-zależnego procesu, jakim jest generowanie impulsów.

bartuss1 · Post napisał: **bartuss1** » 08 mar 2007, 11:09

czyli generalnie cykle obróbkowe pozostawimy programom typu CAM, tylko jak to wyjasnic klientowi który nie ma pojęcia o CAMie ?
chyba że ... samouczek programowania G kodów do stepa ?
np klient nie chce bawic sie edu cadem tylko stepem
i uczulić go tylko na średnicę narzędzia - przedstawic graficznie kontur detalu i środek narzedzia odsuniety o iles tam i przykładowy Gkod i dlaczego tak własnie jest
cykle frezowania kieszeni czy otworu takze.
takie programowanie pozwoli na darowanie sobie rysunku technicznego przy obróbce np 2,5D

Piotr Rakowski · Post napisał: **Piotr Rakowski** » 08 mar 2007, 12:06

bartuss1 pisze:czyli generalnie cykle obróbkowe pozostawimy programom typu CAM, tylko jak to wyjasnic klientowi który nie ma pojęcia o CAMie ?

No właśnie po to są takie "konglomeraty", jak np. eduCAD + STEP. W jednym rysujesz i skupiasz się tylko na tym. A drugi Ci to wycina. Reszta klienta nie powinna obchodzić. Mało tego - planuję taką agregację, która w ogóle wyeliminuje konieczność korzystania z G-kodów, czy innego cholerstwa. Ludzie chcą gotowych rozwiązań - np. do robienia tabliczek znamionowych. I trzeba im je dać! A uczenie G-kodów trzeba raczej zostawić pasjonatom.

bartuss1 pisze:chyba że ... samouczek programowania G kodów do stepa ?

Samouczek dodać mogę, ale chyba tylko dla wytrwałych.

bartuss1 pisze:np klient nie chce bawic sie edu cadem tylko stepem
i uczulić go tylko na średnicę narzędzia - przedstawic graficznie kontur detalu i środek narzedzia odsuniety o iles tam i przykładowy Gkod i dlaczego tak własnie jest
cykle frezowania kieszeni czy otworu takze.
takie programowanie pozwoli na darowanie sobie rysunku technicznego przy obróbce np 2,5D

Uniwersalnym "językiem" ludzi "technicznych" jest rysunek. To on ma załatwiać większość kwestii. To na jego etapie powinno się definiować offsety, kierunki, wybrania typu "kieszenie" itd. Brnięcie w wirtualny G-kod, czy inny zapis wektorów to wg mnie ślepa uliczka. Im więcej gotowych rozwiązań tym lepiej.

Zauważ, jak dobrze radzą sobie takie programy jak Wrykrys - dlaczego? - bo tam są nawet gotowce (makra) do rozkrojów. Klikasz, wspisujesz parametry i zrobione!

STEP2CNC - ZAKOŃCZENIE PRAC NAD PROGRAMEM

Złącze enkodera LIKA EPFL 121 M23, 12-pin, żeńska

Dysk na rzepy 150 H21N/P806H

STEP2CNC - ZAKOŃCZENIE PRAC NAD PROGRAMEM

Złącze enkodera LIKA EPFL 121 M23, 12-pin, żeńska

Dysk na rzepy 150 H21N/P806H

Zaloguj się • Zarejestruj się

Połącz się z kontem sieci społecznościowej