Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Programy do tworzenia płytek od innej strony

szeryf.rm 19 Aug 2007 17:00 4550 43
IGE-XAO
  • #31
    McRancor
    VIP Meritorious for electroda.pl
    Warto by dodać jeszcze do tych bibliotek oznaczenie warstwy jaka ma być widoczna, żeby można było (podobnie jak w eaglu) wyłączać widok napisów, obrysu obudowy i samych padów.

    Dodałbym jeszcze jeden parametr do tych komend rysowania kresek i kółek, który określałby "warstwę" - czy jest to pad, czy obrys obudowy, czy dodatkowy bzdet który ładnie wygląda na warstwie opisowej, ale w czasie projektowania tylko przeszkadza.
  • IGE-XAO
  • #32
    szeryf.rm
    Level 22  
    hmm, to biblioteka ideowa, tam jeszcze nie ma warstw. Biblioteka PCB będzie 2 w kolejności.
  • Helpful post
    #33
    macha
    Level 19  
    Witam.
    Nie jestem programistą (dla mnie to prawie czarna magia) tylko konsumentem tego co gotowe.
    Więc kilka może bezsensu sugestji.
    Jak dla mnie przydałby się do tego programu osobny prosty program (graficzny?), w którym można pisać własne biblioteki, które po zaakceptowaniu zostały by automatycznie zapisane w odpowiednim katalogu programu do projektowania bez potrzeby importu tych bibliotek.
    Tyle na razie moich sugestji i czekam niecierpliwie na wynik końcowy.

    Proszę jeszcze o podanie nazwy tego programu by było łatwiej go znaleść i śledzić jego rozwój.

    Pommysł dobry P O W O D Z E N I A !!!!
  • Helpful post
    #34
    McRancor
    VIP Meritorious for electroda.pl
    Acha :)

    W takim razie dodaj jeszcze parametr do trójkątów kwadratów i kółek który określa czy obszar zamknięty jest wypełniony czy nie, czasem się to stosuje
  • IGE-XAO
  • #35
    szeryf.rm
    Level 22  
    hmm,, myślałem o wypełnianiu jednak z tego zrezygnowałem. Tylko 0.001% schematów jakie widziałem miały np. scalaki w innym kolorze. W praktyce to się chyba raczej rzadko stosuje, bo druki są czarnobiałe. Dlatego nie będę tworzył bajeru dla bajeru :).

    Nazwę już mam :). Jako polak zdecydowałem się podkreślić że program jest z polski i dlatego nazwa będzie po polsku. Ja mam swój język :).
    Nazwa programu: ElZworka
    Polska i swojska :)

    Z zapisywaniem to nie tak. Tutaj sprawa jest bardziej skomplikowana, ale na szczęście biblioteki wszystkie podziele na lokalne i globalne. Lokalne to pryszcz i zapisywać będą się mogły automatycznie w katalogu z projektem. Globalne będą zależne od tych którzy je tworzyli, bo warto zastosować w nich podział na grupy.
  • #36
    nedved
    Level 10  
    Witam

    Mam kilka uwag. ;)

    Wg mnie całości brakuje ładu i składu. Bez obrazy oczywiście.
    Format biblioteki wydaje mi sie nie mieć większego sensu.
    Każda biblioteka musi zawierać informacje o kilku rzeczach:
    -informacja o tym jak wygląda element na schemacie (symbol)
    -informacja o tym jak wygląda element na płytce (tzn. musi mieć jakąś
    obudowę)
    -informacja o tym jak to wszystko połączyć (tzn. dopiero teraz powinny pojawiać sie informacje co do czego przypisujemy i jak to sie nazywa)

    z rozbiegu mogę wymyślić coś takiego:
    nazwa_biblioteki .... informacje na temat samej biblioteki (wersja, opisy itd.)
    symbole:
    nazwa_symbolu:
    >>tu rysujemy<<
    >>informacje o wyprowadzeniach<<
    ...
    ...
    obudowy:
    nazwa_budowy
    >>tu rysujemy<<
    >>wyprowadzenia<<
    ...
    elementy:
    co i z czym ( i w jaki sposób)

    Umieszczanie w bibliotece informacji o wartości elementu chyba mija sie z celem. Takie rzeczy powinno sie umieszczać w pliku schematu. Jeśli ma to być w pliku tekstowym tak jak chciałeś to może wyglądać np tak:
    nazwa pliku .... informacje o schemacie
    nazwa_ połączenia które piny których elementów
    .....
    .....
    element taki i taki:
    nazwa
    wartość
    itd, itp

    Sądzę że to jak na plik schematu powinno wystarczyć (na razie)


    To tyle jeżeli chodzi o biblioteki.
    Po za formatami plików pozostaje jeszcze jedna bardzo ważna rzecz(chyba nawet ważniejsza niż formaty plików).
    Interfejs użytkownika-to od niego zależy czy ktoś będzie używał Twojego programu czy też nie. Użytkownik będzie miał w d...e jaki masz format plików. Jego to nie interesuje. A Ciebie interesuje w jaki sposób zapisywane są informacje w OrCad-zie, Eagle-u, Protelu i innych podobnych programów??? Szczerze wątpię, no chyba że piszesz jakieś konwertery. Ja sam jestem użytkownikiem takich programów i szczerze Ci powiem, że mało mnie to obchodzi.
    Myślę, że najpierw powinieneś zabrać sie za sam program i zastanowić sie jak chcesz rozwiązać pewne sprawy związane z obsługą programu (kwestie prowadzenia ścieżek na płytce itd.)

    Mam nadzieje, że moje uwagi okażą sie pomocne i zachęcą do dalszej pracy. :D

    P.S. Fajnie, że napisałeś. :)
  • #37
    Ptolek
    Level 36  
    Od strony użytkownika, dopowiem coś w kwestii bibliotek.
    W/g mnie biblioteki do schematu i PCB powinny być jednak całkiem rozdzielone i związane netlistą. Bo nie wiem czy dobrze zrozumiałem post powyżej. Ale elementy tak samo oznaczone na schemacie mają różne obudowy, i na odwrót. Powinna być możliwość łatwego tworzenia własnych obudów, bez zajmowania się schematem. Osobiście projektuję wszystkie płytki patrząc na kartkę ze schematem, ustawiam na monitorze tylko obudowy elementów. Nie mówię, że netlista jest zła (jest genialna jeśli chodzi o kontrolę poprawności połączeń) ale po prostu nie chciałoby mi się wprowadzać do komputera najpierw schematu, a potem jeszcze płytkę, jak mogę tylko płytkę. Dlatego uważam, że powinny być osobne biblioteki dla schematu i dla PCB.
  • #38
    szeryf.rm
    Level 22  
    nedved wrote:

    Format biblioteki wydaje mi sie nie mieć większego sensu.
    Każda biblioteka musi zawierać informacje o kilku rzeczach:
    -informacja o tym jak wygląda element na schemacie (symbol)
    -informacja o tym jak wygląda element na płytce (tzn. musi mieć jakąś
    obudowę)
    -informacja o tym jak to wszystko połączyć (tzn. dopiero teraz powinny pojawiać sie informacje co do czego przypisujemy i jak to sie nazywa)

    z rozbiegu mogę wymyślić coś takiego:
    nazwa_biblioteki .... informacje na temat samej biblioteki (wersja, opisy itd.)
    symbole:
    nazwa_symbolu:
    >>tu rysujemy<<
    >>informacje o wyprowadzeniach<<
    ...
    ...
    obudowy:
    nazwa_budowy
    >>tu rysujemy<<
    >>wyprowadzenia<<


    nedved ten plik tekstowy z formatem można pobrać i nawet da się otworzyć :) Jak to zrobisz to w pierwszych linijkach masz

    Code:

    NAZWA: Nazwa elementu -> dowolna, może zawierać spacje
    POZN: X Y -> POZN czyli domyślna pozycja nazwy
    OZN: R? -> Domyślne oznaczenie elementu. W miejsce znaku/ów zapytania będzie wstawiana kolejna wartość ew. będzie ustawiana ręcznie.
    CZESCI: X -> Ilość części z których składa się element, np. operacyjka składać się może z 4 części.
    PCB 3 "Rodzaj obudowy1" "Rodzaj obudowy2" "Rodzaj obudowy3" -> najpierw liczba oznaczająca ilość PCB dołączonych do danego elementu. Nazwy powinny być w "" czyli same nie mogą zawierać tych znaków


    czyli pełen opis. Zaś nazwa biblioteki z elementami = nazwa pliku z tym elementem. Po co dodatkowo komplikować sprawę. Jak widać jest nazwa elementu, ilość części na które jest podzielona oraz obudowy PCB i 3D które będą odczytywane z innych plików, które jeszcze nie powstały (co zresztą logiczne)

    nedved wrote:

    Umieszczanie w bibliotece informacji o wartości elementu chyba mija sie z celem. Takie rzeczy powinno sie umieszczać w pliku schematu.


    Jak widać nie dla każdego. Dla mnie ma to znaczenie. Lista rozwijana z domyślnymi wartościami to dobra rzecz. Każdy kto korzysta z komputera wie, że łatwiej najechać na KOPIUJ niż wcisnąć CTRL+C. Więc łatwiej będzie wybrać wartość z listy niż ją wpisać, a dla ambitnych i taka możliwość zostanie (wpisanie ręczne).

    nedved wrote:

    Użytkownik będzie miał w d...e jaki masz format plików. Jego to nie interesuje.


    Faktycznie, ale ten wątek to nie tylko ten program, ale również wszystko co jest z nim związane, np. format plików. Jak program będzie gotowy to i mnie nie będzie interesowało co jest wewnątrz :), a na razie konsultacja jest ważna.

    nedved wrote:

    A Ciebie interesuje w jaki sposób zapisywane są informacje w OrCad-zie, Eagle-u, Protelu i innych podobnych programów??? Szczerze wątpię, no chyba że piszesz jakieś konwertery.


    W ogóle mnie to nie interesuje, tyle że ja to piszę, więc wypada żebym wiedział co piszę :). A jeśli w pliku nie będzie czegoś co by się przydało to potem nie będzie tego w interfejsie np. jeśli nie zawrę informacji o ilości części to jak to potem wprowadzę w życie... dlatego konsulatcja o formacie plików ≈ konsultacja o interfejsie

    nedved wrote:

    Myślę, że najpierw powinieneś zabrać sie za sam program i zastanowić sie jak chcesz rozwiązać pewne sprawy związane z obsługą programu (kwestie prowadzenia ścieżek na płytce itd.)


    Do ścieżek daleka droga, a przed przejściem przez nią trzeba ją wybudować. Tak samo z interfejsem. Żeby go zacząć trzeba wiedzieć co on ma zawierać i jak to potem będzie zapisane. Sądzisz że najpierw pojawiły się programy zapisujące BMP a potem ktoś ten format napisał? Raczaj było odwrotnie.


    Ptolek rozwiewam twoje wątpliwości. Ponieważ każda część będzie powstawała osobno to i osobno będzie można z niej korzystać, bo inaczej już dzisiaj musiałbym mieć odpowiedzi na wszystkie pytania i ten wątek nie miałby sensu. Ale że powiązania będę robił później to znaczy że każda część działać będzie razem lub/i osobno. Więc będziesz chciał tylko PCB zrobisz tylko PCB. Aha i będzie netlista.
  • Helpful post
    #39
    igawar
    Level 12  
    Podoba mi się pomysł z plikami w formacie tekstowym. Sama projektując płytki pod PCAD 4.5 często korzystam z możliwości edytowania plików tekstowych. Np jeśli chcę zmienić szerokość ścieżek to konwertuję bazę (PDIFOUT) na format ASCII i poprzez edycję cykliczną zmieniam szerokość ścieżek o wiele szybciej niż w Pccards, gdzie trzeba najechać na każdy odcinek ścieżki i przez QUERY zmieniać jego szerokość. Po zakończeniu wracam znowu do formatu binarnego (PDIFIN). W PCADzie zarówno bazę (.PCB) jak i elementy (.PRT) można konwertować do formatu tekstowego.

    Zgadzam się w 100% z tym co napisał "Ptolek". Rysunek ideowy elementu nie powinien być związany z rysunkiem obudowy tak na stałe. W moim PCAD 4.5 jest osobno SYM (rysunek symbolu elementu) i PRT (rysunek obudowy). W nowszych PCADach, w EAGLE i innych systemach od tego odeszli i moim zdaniem to duży błąd. Ja nie rysuję schematów tylko je dostaję już narysowane i to z przeróżnych systemów ja robię tylko płytkę i potrzebuję tylko rysunki obudów, symbole mi nie potrzebne a np w EAGLE aby zrobić sobie element do biblioteki muszę też zrobić jego symbol.

    Co do netlisty to jestem za. Często oprócz narysowanego schematu dostaję netlistę (pod starego pcada EAGLE i PROTEL dają całkiem dobre netlisty) i z niej korzystam.
  • #40
    szeryf.rm
    Level 22  
    Przyznam szczerze że już nie rozumiem o co chodzi z tym powiązaniem elementu ideowego z obudową.

    Quote:

    Ja nie rysuję schematów tylko je dostaję już narysowane i to z przeróżnych systemów ja robię tylko płytkę i potrzebuję tylko rysunki obudów, symbole mi nie potrzebne a np w EAGLE aby zrobić sobie element do biblioteki muszę też zrobić jego symbol.


    Przecież z formatu biblioteki ideowej na razie wynika, że element ideowy będzie powiązany z obudową (i to w dodatku nie na stałe, bo będzie można wybrać swoją inną obudowę), a nie obudowa z elementem ideowym. Z powszedniego zdania można zrozumieć, że biblioteki 3D i PCB nie będą zawierały miejsc łączących je z bibliotekami ideowymi. Jeśli ktoś zechce narysować jedynie element PCB to narysuje element PCB i użyje go. Ktoś zechce narysować jedynie ideowy, to narysuje jedynie ideowy i nie powiąże go z żadną obudową PCB i z żadną obudową 3D (będzie to mógł zrobić później. Podkreślam "mógł" a nie musiał). Dzięki temu że program będzie powstawał jakby to powiedzieć "w częściach" to nie grozi stworzenie ścisłych zależności, bo inaczej musiałbym znać je wszystkie dokładnie dzisiaj i już dokładnie wiedzieć jak wszystko będzie wyglądało. Tylko po co wtedy byłby ten wątek :)

    pozdr

    PS. Prace trwają. Na razie najgorzej przebrnąć przez różne kodowania systemów :). Już teraz blisko na 100% wiadomo, że pliki tekstowe będą wymagały kodowania UTF8 bez BOM z zakończeniem linii unixowym. Będzie to warunkiem poprawnej interpretacji wszystkich plików w różnych systemach i bardzo dobrze, że będzie wymagane jedno kodowanie :). Niestety z PCBSD na razie rezygnuje. Miałem zbyt wiele problemów z kompilacją. Na 1.3 poszło (średnio) a na 1.4 z takimi samymi parametrami już nie, bo wystąpił konflikt bibliotek. Na linuksie na szczęście tych problemów nie miałem. Chciałem jeszcze sprawdzić na FreeBSD, ale nie chciał się zainstalować, więc odpuściłem. Autor biblioteki FOX pisze że można używać jej pod BSD, więc pewnie później zajmę się kompilacją.
    Na dzień dzisiejszy na prostych częściach programu ćwiczę dziedziczenie klas w FOXie. Jest to proste, ale warto się przyzwyczaić :)
  • Helpful post
    #41
    igawar
    Level 12  
    O ile wiem, to w Eagle musi zawsze być zdefiniowane SYMBOL, DEVICE i PACKAGE. Nie można sobie zdefiniować samego symbolu trzeba mu od razu przypisać obudowę. Być może się mylę, bo z Eagle miałam niewiele do czynienia. Narysowałam w nim chyba ze 3 lub 4 schematy i to w b. starej wersji Eagla. Może w nowszych wersjach jest inaczej.
  • #42
    szeryf.rm
    Level 22  
    igawar to nie będzie eagle :) hehe. Bez obaw :). Porównania z innymi programami są potrzebne, żebym mógł wyeliminować błędy w moim programie, tyle że sprawę powiązanych elementów już komentowałem wcześniej, więc przepraszam, jeśli zabrzmiałem trochę niegrzecznie :) w ostatniej wypowiedzi, ale mam wrażenie że teraz każdy kto przeczyta twoją wypowiedź i nie przeczyta mojej dojdzie do wniosku, że trzeba się do was (ciebie i Ptolek) przyłączyć i znów to skomentuje :). Stąd pewnie i twój komentarz :), bo odpowiedź na Ptolek twierdzenie jest zaraz za jego postem.

    pozdr
  • Helpful post
    #43
    igawar
    Level 12  
    Ja Twojej wypowiedzi nie odebrałam jako niegrzecznej, przecież to jest dyskusja.
    Podziwiam Cię, że sam próbujesz zrobić program do wspomagania projektowania. Zwykle robi to sztab ludzi. Życzę powodzenia i zgłaszam się do ewentualnego testowania programu.

    W razie potrzeby mogę przesłać przykładowe pliki tekstowe zrobione z PCB, SCH, PRT, SYM i PS (definicja placka nakładanego na PIN). Oczywiście z PCADa, bo nim się posługuję przy projektowaniu. Niezależnie od systemu z którego taki zbiór pochodzi musi on zawierać wszystkie istotne informacje potrzebne do odtworzenia zbioru binarnego. Zbiory tekstowe z PCADa mają rozszerzenie PDF, przy czym PCADowego PDFa nie należy mylić z formatem PDF generowanym i czytanym przez Acrobata.

    PS.
    Ja dawno, dawno temu byłam w zespole projektującym taki system. Były to czasy ODRY i RIADa Jako język programowania królował FORTRAN. Nie było mowy o oglądaniu projektu płytki na ekranie monitora, a dużo by trzeba opowiadać. Większości użytkowników tego forum prawdopodobnie nie było jeszcze na świecie :)
  • #44
    szeryf.rm
    Level 22  
    igawar :) Spokojnie :). Ja tak tylko na wszelki wypadek, żeby ktoś (ty, ktoś inny) sobie źle nie pomyślał :).
pcbway logo