|
Projekt - Program steruj?cy ploterem/frezark? CNC |
| Autor |
Wiadomość |
vegelus
Specjalista poziom 1

Dołączył: 19 Sty 2005 Posty: 132 Skąd: Olsztyn
|
Wysłany: 2005-08-08, 16:54
|
|
|
Rozumie ze chodzi o nadawanie przestrzeni BMP
To mi ulecialo z glowy
Co do wymagan systemowych to czmu az Win2000 potrzeba ja pracuje na 98 i jakos nie kwapie sie do przejscia na cos lepszego dopuki nie wymienie kompa. No i jeszcze pozostaje linux. |
|
|
|
 |
anjak
Znawca tematu

Dołączył: 16 Lip 2004 Posty: 93 Skąd: Ostrołęka
|
Wysłany: 2005-08-08, 16:58
|
|
|
a to pech z tą w98 , a bmp jest też mi potrzebne |
|
|
|
 |
Piroman1024
Sympatyk forum poziom 2

Dołączył: 29 Mar 2005 Posty: 44 Skąd: D?browa GĂłrnicza
|
Wysłany: 2005-08-09, 22:50
|
|
|
Witam.
Ja również chciałbym coś dodać od siebie do tego projektu o ile to mozliwe.
Mogę coś zrobić w:
-Delphi(Coś do programu głównego)
-OpenGl(wizualizacje)
-GCC na AVR
Czytałem czły wątek jednak nie jestem pewien jakie są założenia ostateczne co do języku programowania.
Z tego co wiem program główny powinien chodzić zarówno pod Windows jak i Linuks.
Pozdrawiam. |
_________________ "Mathematics is the language of nature" |
|
|
|
 |
vegelus
Specjalista poziom 1

Dołączył: 19 Sty 2005 Posty: 132 Skąd: Olsztyn
|
Wysłany: 2005-08-10, 07:24
|
|
|
No wszyscy sie uparli na C++ wiec siedze i czytam
Co do wizualizacji to mysle ze moze nam cos wyjsc bardzo fajnego gdyz kilku ludzi juz jest
Napisz moze co chcialbyc i w jaki sposob wizualizowac. Jak nie ma nic napisane to nie ma jak dyskutowac. A jak nie ma dyskusji to nie ma kolejnych krokow do przodu a jak ich nie ma to projekt stoi. A jak projekt stoi to ladachwila moze sie przewrocic . Choc niezupelnie bo z tego co sie oretuje to i tak kilka programow jest w trakcie pisania |
|
|
|
 |
anjak
Znawca tematu

Dołączył: 16 Lip 2004 Posty: 93 Skąd: Ostrołęka
|
Wysłany: 2005-08-10, 09:14
|
|
|
Piroman1024, podaj swoje GG/TLEN lub kliknij na moje.
Czy jest ktoś jeszcze kto chce zająć się wyłącznie opengl ?
Wiadomość proszę na maila lub GG |
|
|
|
 |
Piotr Rakowski
Specjalista poziom 3 rakuś


Pomógł: 31 razy Dołączył: 29 Lip 2005 Posty: 947 Skąd: Warszawa
|
Wysłany: 2007-02-17, 00:03
|
|
|
Jak wiecie popełniłem właśnie swój pierwszy program sterujący STEP2CNC więc pozwolę sobie wtrącić swoje 3 grosze. Wczytywanie formatu CDR nie jest dobrym pomysłem z dwóch powodów:
1. format nie jest udostępniony publicznie przez firmę COREL Corp. i można się narazić na niepotrzebne nieprzyjemności,
2. zawiera wiele niepotrzebnych śmieci, których interpretacja będzie niepotrzebnie skomplikowana (w końcu są tam informacje o ustwaieniach programu i obiektach zaimpotowanych - np. bitmapach).
Program Corel pięknie eksportuje do HPGLa i ina tym możecie się operzeć.
Zdecydowanie polecam zrobić interpretację plików IGES i STL - stworzonych specjalnie do zapisu i interpretacji ścieżek modeli 3D. |
_________________ Piotr (rakuś) Rakowski, eduCAD CNC, PLT2CNC, STEP2CNC
Oprogramowanie: http://www.soft4cnc.pl maszyny: http://www.grawerki.biz |
|
|
|
 |
Wodzu
Specjalista poziom 3


Pomógł: 10 razy Dołączył: 29 Lip 2006 Posty: 680 Skąd: z sasiedztwa
|
Wysłany: 2007-02-17, 00:33
|
|
|
| Ja tez jestem za tym zebyscie pracowali nad Igies, parasolid itp. Praktycznie kazdy program jest w stanie sobie poradzic z tymi plikami. |
_________________ Prawda leży pośrodku -Arystoteles.Może dlatego wszystkim zawadza -Wodzu. |
|
|
|
 |
triera
Specjalista poziom 2


Pomógł: 28 razy Dołączył: 16 Paź 2005 Posty: 595 Skąd: Świecie
|
Wysłany: 2007-02-17, 01:35
|
|
|
wczoraj sprawdzałem jak pięknie eksportuje się hpgl z Corel11
- zmiana wymiaru 1000/1016 = 0,9842519685% wymiaru zadanego
(w porównaniu z CorelDraw9)
zmiana parametrów przy eksporcie:
skalowanie (nawet 200%) i ilości jednostek
nie pomogło - zmian nie zaobserwowano.
Na szczęście mogłem wprowadzić korektę na poziomie
interpretera HPGL. |
|
|
|
 |
Piotr Rakowski
Specjalista poziom 3 rakuś


Pomógł: 31 razy Dołączył: 29 Lip 2005 Posty: 947 Skąd: Warszawa
|
Wysłany: 2007-02-17, 08:41
|
|
|
Dlatego właśnie jeśli swoje działania chcecie oprzeć na programach typu Corel to polegniecie.
Jasne, że jest najpopularniejszy - ale to niczego nie dowodzi. Trzeba sprawdzić jeszcze, jak eksportuje do DXF, bo do WMF też eksportuje "podobnie".
Możecie się przyjżeć bliżej formatowi WMF - bo to "natywny" format Windozy i większość programów wektorowych i CADowskich bez problemu sobie z nim radzi. Ba, Windoza obsługuje schowek w formacie WMF - więc przenosznie przez clipboard jest bardzo proste. |
_________________ Piotr (rakuś) Rakowski, eduCAD CNC, PLT2CNC, STEP2CNC
Oprogramowanie: http://www.soft4cnc.pl maszyny: http://www.grawerki.biz |
|
|
|
 |
x
Specjalista poziom 1


Pomógł: 9 razy Dołączył: 29 Mar 2006 Posty: 209 Skąd: okolice Warszawy
|
Wysłany: 2007-02-28, 00:42
|
|
|
| Piotr Rakowski napisał/a: | 1. format nie jest udostępniony publicznie przez firmę COREL Corp. i można się narazić na niepotrzebne nieprzyjemności,
2. zawiera wiele niepotrzebnych śmieci, których interpretacja będzie niepotrzebnie skomplikowana (w końcu są tam informacje o ustwaieniach programu i obiektach zaimpotowanych - np. bitmapach). |
A znasz jakieś "nieoficjalne" specyfikacje? Latem 2005 nie znalazłszy żadnej pożytecznej dokumentacji rozgryzałem CDR i doszedłem do wnosku, że to może się udać, ale dałem za wygraną przez pliki skompresowane. Prawdopodobnie to jest kompresja Huffmana, ale jak odzyskać drzewo kompresji?
| Piotr Rakowski napisał/a: | | Zdecydowanie polecam zrobić interpretację plików IGES i STL - stworzonych specjalnie do zapisu i interpretacji ścieżek modeli 3D. |
STL jest fajny (tylko strasznie dużo dysku zajmuje). DXF v.12 też jest O.K. ale ten format został niestety znacznie "ulepszony" - pdf z opisem najnowszej wersji to cała cegła, większość danych to dla generatora G-kodu śmieci.
No niestety wygląda że projekt zdechł w przedbiegu. Sam mam kilka programów (głównie C++), które utknęły w martwym punkcie. Wina - nadmierne rozbudowanie projektu. Ilość czasu potrzebna do pisania programu rośnie wykładniczo do ilości klas i metod. Teraz staram się działać w duchu weekend-hack ( w rzeczywistości month-hack ).
FLTK ma własne środowisko FLUID do budowania interfejsu, i szkieletu programu w C++. Toporne, ale działa.
Gdyby jeszcze ktoś chciał się bawić, to proponuję pisanie w języku skryptowym - np. Python-ie. Znacznie mniej pracochłonne, szybko widać efekty pracy. Jest wiele modułów, w tym toolkity okienkowe, coś do OpenGL. Działa to i pod Win i pod Lin. Sceptycznie nastawionym mogę powiedzieć, że to wcale nie jest takie głupie. Np. interfejs programu ac3d jest robiony w Tcl/TK (wbudowany interpreter). EMC2 pracujący przecież w reżimie czasu rzeczywistego, także ma interfejsy do wyboru m.in. w TCL, i Python-ie. Te 20% kodu który zajmuje większość czasu procesora można później przepisać w C, i dalej używać jako moduł Python-a.
I zdecydowanie zminimalizować zakładaną ilość właściwości, oraz wybrać lidera który wskaże kierunek, i odwali z 10% roboty. A na starcie 150%.
Do czego ten program właściwie ma służyć? Do modelowania? Wczytywania gotowców i przetwarzania na G-code? Komunikacji z modułem wykonawczym? I przy okazji jeszcze wizualizacja i symulacja? |
_________________ "Później doświadczyłem jeszcze jednego zjawiska: gdzieś w połowie roboty okazuje się, że mieliśmy pomysł tylko na tę połowę roboty." - Adam Cebula (wnioski po budowie gołębnika) |
|
|
|
 |
|
|