CNConv v15

Czesc

Ktora wersje uznajesz teraz za stabilna?

q

Planowałem zrobienie generatora plików HPGL i widzę, że nic mi to nie da, bo:

prokopcio pisze: 1. program CNConv dorobił się swojego pliku projektu *.cnv zamiast dotychczasowego *.kon powiązywanego z plikiem importowanym. Teraz po zaimportowaniu jakiegoś pliku nie jest on już potrzebny jak w każdym normalnym programie.

Wiesz, coś ci się pomyliło z pojęciem "normalnym programie".
Taki własny format zamknięty ("binarny") modny był kilkanaście lat temu. Od dobrych paru lat nawet Microsoft wycofał się z zamkniętych formatów i teraz z XML korzysta: http://en.wikipedia.org/wiki/Microsoft_ ... ML_formats - zobacz to jest nowoczesność! Dla zmniejszenia rozmiaru można to na dysku przechowywać w formie skompresowanej gzipem. Przykładowo pliki KML są kompresowane i hulają po internecie jako KMZ. To jest właśnie wygoda i trzymanie się światowych standardów.

http://earthquake.usgs.gov/earthquakes/catalogs/ - tu jest bardzo fajny plik, który po wczytaniu do google earth pokazuje wszystkie trzęsienia ziemi z ostatnich 7 dni. Polecam obejrzeć.

wiem wiem, planowałem, jednak już spieszę z wyjaśnieniem co mnie powstrzymało. Co prawda miał to być ini + plt nie xml + plt ale to bez większego teraz znaczenia, chodzi o to, że mam sporo klientów wykonujących PCB których pliki potrafią w tekście mieć bardzo duże wielkości (nie wnikałem szczegółowo dlaczego) co powodowało dość powolne ich przetwarzanie podczas wczytywania na słabszych komputerach ale to nie jest aż tak duży problem - nie wszystkie programy potrafią generować w jednym pliku dane dla różnych narzędzi co zmuszało klientów do bardzo częstego przeładowywania plików podczas jednej płytki, te cenne "sekundy" zyskali dzięki plikom w nowym formacie które się wczytują bardzo szybko.

pitsa pisze:Dla zmniejszenia rozmiaru.......przechowywać w formie skompresowanej gzipem.

to tylko wydłuży czas wczytywania - trzeba rozpakować przed wczytaniem

[ Dodano: 2012-10-31, 23:10 ]

pitsa pisze:Planowałem zrobienie generatora plików HPGL i widzę, że nic mi to nie da, bo:

prokopcio napisał/a:

1. program CNConv dorobił się swojego pliku projektu *.cnv zamiast dotychczasowego *.kon powiązywanego z plikiem importowanym. Teraz po zaimportowaniu jakiegoś pliku nie jest on już potrzebny jak w każdym normalnym programie.

napisz proszę w czym to przeszkadza? przecież poprzednie pliki działają chyba bez zmian Jeśli importowany plik będzie miał przypisany plik .kon to program zassie z niego dane automatycznie.

prokopcio pisze:przecież poprzednie pliki działają chyba bez zmian

Jeśli chcesz wczytać nowy plik na stary sposób to jeszcze nie działa tak jak powinno w tej nowej beta wersji.

Zatrzymałem się na wersji 14 bo każda modyfikacja bazy plików to możliwość popełnienia błędu. Działa dobrze więc nie zmieniam. Mam dostęp do plików tekstowych, które mogę własnym dodatkowym programem do zarządzania projektami dostosować do moich potrzeb. Na przykład zamieniam sobie automatycznie wszystkie pióra na SP1 i dzięki temu w Corelu mogę pozostawić kolorki jakie mi pasują, a w CNConv robię wszystko jednym frezem. Wcześniej zdarzało mi się, że nagle jakiś fragment robił się na "dzikich" parametrach..

Zmiany w programie powinny być przemyślane. Na przykład jedną niedogodnością jest to, że kiedyś tam w założeniach przyjąłeś skalę pliku jako bazową informacje o wymiarach projektu. Skala to sprawa wewnętrzna programu.

Co do własnego formatu zapisu mam taką uwagę z doświadczeń z wieloma programami. Jeśli stosujesz zapis do własnego formatu to pamiętaj o tym, że po jakimś czasie klienci zaczną zwracać się z prośbą o odzyskanie dawnych projektów w formacie źródłowym. Jeśli robisz import z HPGL do cnv to obowiązkowo musi być export z cnv do HPGL. I nie mów, że każdy trzyma wszystkie pliki i coś takiego nie może się zdarzyć.

pitsa pisze:...Jeśli stosujesz zapis do własnego formatu to pamiętaj o tym, że po jakimś czasie klienci zaczną zwracać się z prośbą o odzyskanie dawnych projektów w formacie źródłowym. Jeśli robisz import z HPGL do cnv to obowiązkowo musi być export z cnv do HPGL. I nie mów, że każdy trzyma wszystkie pliki i coś takiego nie może się zdarzyć.

Guzik tam - nie musi.
Co to producenta programu obchodzi ze klient posial wlasne pliki?

To nie program do konwersji plikow, tylko sterowania maszyna - jest z setka
rzeczy ktore program musi miec, lub powinien ale to to akurat cudowanie...

q

[ Dodano: 2012-11-01, 09:11 ]

pitsa pisze:Zmiany w programie powinny być przemyślane. Na przykład jedną niedogodnością jest to, że kiedyś tam w założeniach przyjąłeś skalę pliku jako bazową informacje o wymiarach projektu. Skala to sprawa wewnętrzna programu.

A co Ci to pole przeszkadza? Wpisujesz raz na jutro skale i zapominasz

Skala jest przydatna gdy chcesz poprawic jakosc plikow z Corela ktory jak
wiadomo eksportuje kwadratowe PLTy Przy cieciu tworzyw tego nie widac
ale juz gdy tniesz aluminium i chcesz uzyskac jak najlepsza powierzchnie
widac niekiedy ksztalt PLTa na materiale.

Wystarczy wtedy przed eksportem powiekszyc rysunek np. 5x, zmienic skale
na 0.5 i juz mamy 5x wieksza rozdzielczosc krzywych

I tu dochodzimy do rzeczy ktora wartoby zmienic - rozdzielczosc pracy interpolatora
na poziomie 0.01mm jest za niska. Wystarczy wyciac wieksza kolko w aluminium zeby
sie o tym przekonac

Prosze Autora - nie daloby sie podniesc rozdzielczosci???

q

oprawcafotografii pisze:Co to producenta programu obchodzi ze klient posial wlasne pliki?
To nie program do konwersji plikow, tylko sterowania maszyna - jest z setka
rzeczy ktore program musi miec, lub powinien ale to to akurat cudowanie...

Nie chodzi, że "posiał" tylko zaufał producentowi, a potem okaże się, że musi przejść na wyższy poziom dokładności i przejść na inne oprogramowania, a tu ślepa uliczka - format własny wsysający pliki, ale nie dający z siebie na zewnątrz żadnego.

Ja od takich programów trzymam się z daleka.


Można zejść z dokładnością poniżej 0,01.

Nie chodzi, że "posiał" tylko zaufał producentowi, a potem okaże się, że musi przejść na wyższy poziom dokładności i przejść na inne oprogramowania, a tu ślepa uliczka - format własny wsysający pliki, ale nie dający z siebie na zewnątrz żadnego.

CNConv nie zjada otwieranych plikow HPGL wiec o czym piszesz?

Można zejść z dokładnością poniżej 0,01.

A jak to zrobic to pewnie tajemnica?

q

Nie jest tajemnica. Przecież sam podałeś przepis z powiększaniem obrazków w Corelu.

Ograniczenie jest w stosunku najmniejszego odcinka do obszaru roboczego. Pliki i program ustawiasz na obszar roboczy, pod który twórca programu przygotował kontroler, czyli te 600x600 i 0,01. Projekty też trzeba skalować tak aby użyć większą część tego obszaru. Wyciąga się tym sposobem jak największą możliwą rozdzielczość impulsów.

Teraz mechanicznie maszyna może mieć ten obszar znacznie mniejszy i w prosty sposób masz wtedy większą dokładność. Na przykład przy skali mechanicznej 1:5 program myśli że pracuje na obszarze 600x600 a robotę robi na 120x120. Rozdzielczość masz wtedy poniżej 0,01. Gdyby zastosować kontroler do budowy domów okazałoby się, że skalując uzyska się rozdzielczość rzędu milimetrów. Program jest tak napisany, że dostosowuje się do projektów.

Też mi początkowo brakowało dokładności. Prosiłem o możliwości wyłączenia zmniejszania liczby importowanych z HPGL wektorów i jest taka opcja. Wszystko po to aby nie tracić rozdzielczości.

Żeby zrobić większą rozdzielczość trzeba pewnie wrócić do założeń początkowych i napisać program od początku. Też liczę na zmianę w tym zakresie aby 0,01 mieć na obszarach 1500x1000 i większych.

Nie jest tajemnica. Przecież sam podałeś przepis z powiększaniem obrazków w Corelu.

Ale to nie poprawia rozdzielczosci z jaka pracuje maszyna (te 0.01mm) tylko
rozdzielczosc plikow, to nie to samo.

Ograniczenie jest w stosunku najmniejszego odcinka do obszaru roboczego. Pliki i program ustawiasz na obszar roboczy, pod który twórca programu przygotował kontroler, czyli te 600x600 i 0,01. Projekty też trzeba skalować tak aby użyć większą część tego obszaru. Wyciąga się tym sposobem jak największą możliwą rozdzielczość impulsów.

Mieszasz Po pierwsze kontroler juz od dawna moze pracowac > 600x600mm,
po druge trik ze skalowaniem plikow nie zmienia dokladnosci z jaka kontroler
wylicza kroki a ta wynosi 0.01mm. Skalowanie plikow nic tu nie pomoze.

Teraz przyszedl mi do glowy trik... Majac maszyne np. 500x500mm i podzial krokow
3200/5mm ustawiamy w programie format maszyny 5000x5000mm i podzial krokow
32000/5mm. W efekcie rozdzielczosc ruchu bedzie 10x wyzsza

(Chyba w sumie pisales o tym samym )

No ale to kombinacje alpejskie, moze Autor wymysli cos prostszego?

q

[ Dodano: 2012-11-01, 15:45 ]

pitsa pisze:...Też mi początkowo brakowało dokładności. Prosiłem o możliwości wyłączenia zmniejszania liczby importowanych z HPGL wektorów i jest taka opcja. Wszystko po to aby nie tracić rozdzielczości.

A to co bo nie kojarze? W ktorej wersji programu?

q

Zobacz plik Log.txt - masz tam podawaną informację o wczytywanych wektorach. Mniejsza liczba to wektory po zastosowaniu optymalizacji liczby wektorów (W konfiguracji importu pod automatycznym spawaniem przerw mniejszych niż ... mm).


No to załapałeś.

Na przyszłość do listy życzeń wpisujemy zwiększenie rozdzielczości programowej.

Podejrzewam, że to już na innym kontrolerze. No chyba, że prokopcio wpadnie na jakąś magiczną metodę obsługi wielkokrotnie większych obszarów bez znaczącego zwiększania ilości bitów informacji przekazywanych do kontrolera.

Mi przychodzi na myśl zastosowaniem czegoś podobnego do metody multigrid z siatką zgrubną i siatką dokładną w modelowaniu numerycznym.. coś w rodzaju obsługi pewnej liczby większych obszarów stycznych lub częściowo nakładających się. O na przykład tak jak w sieciach komórkowych - po wyjściu współrzędnych poza pewien obszar następowałoby przesunięcie współrzędnych i chwilowego środka układu współrzędnych tak jak telefon przeskakuje w trakcie rozmowy z jednej antenki BTS na inną ... ... matematyczne fantazje.