wycinanie napisów z gerbera

W dniu 21.11.2017 o 12:08, Piotr Gałka pisze:

W przeciwnym podejściu, gdy osadzasz element na schemacie to musisz wybrać mu obudowę, no chyba że zostawiasz domyślnie. W CvPCB przechodziłeś do kolejnego elementu z listy .net i w tym czasie na schemacie kursor ci skakał do tego elementu. Wybierasz obudowę z rozwiniętej listy obudów i szybko przyporządkowujesz footprint do elementu. Jak masz mieć kolejne elementy w tej samej obudowie to tylko klikasz enterem i ustawiasz ją dla wielu elementów. Np 0603 a potem dla serii innych 0805. Gdy chcesz przejrzeć i coś zmienić to masz od razu listę elementów, wartości i footprintów, a tak to musisz wejść do właściwości elementu widocznego na schemacie żeby sprawdzić jaki footprint.

Ja dostosowuję footprinty w projekcie to tego co do tej pory mam na magazynie i do wymagań np. mało miejsca albo wydzielanie ciepła. Przed produkcją drukuję sobie powiększone widoki płytki z oznaczeniem kolorowymi opisami właściwości elementu (wartość + footprint). Szufladki oznaczam wartość + footprint a nie symbol. Symbol to u ciebie C1 C2 R15 itd? Na każdy symbol osobna szufladka? A co jak masz 30 kondensatorów

100nF 0603?

Akurat ściągnąłem bo ktoś pisał o jakiejś nowince a była to wersja niestabilna. Ale skoro pracuję na wersji 2013 to znaczy że nie potrzebuję nightly buildów :)

No to gdy będę miał jakiś całkiem nowy projekt to będę musiał przyjrzeć się bibliotekom i zobaczyć jak do niej dołożyć swoje własne ze starszej wersji. Albo dorobić nowe.

W dniu 22.11.2017 o 01:28, Mario pisze:

W sensie że w projekcie masz 30 kondensatorów 100 nF 0603? musisz mieć

30 szufladek?

W dniu 22.11.2017 o 01:02, Mario pisze:

Sprawdziłem to na ostatniej wersji nocnej, nie wiem czy w wersji stabilnej też to jest.

W dniu 2017-11-21 o 21:50, Marek S pisze:

I z czystym sumieniem polecasz program w którym DRC, które jak nazwa wskazuje ma tylko sprawdzać reguły, jest używane w jakiś sposób do modyfikowania płytki. Ktoś coś źle zdefiniował na początku projektu, albo potem ktoś wstawiał jakieś łatki nie myśląc o zachowaniu logicznej spójności wszystkiego, albo źle używasz Ty (lub oni) pojęcia DRC. P.G.

W dniu 2017-11-22 o 01:28, Mario pisze:

W moim podejściu nie ma etapu 'musisz wybrać mu obudowę'. Wybieram element z biblioteki i on ma już zdefiniowaną obudowę i koniec tematu. Jak w wyjątkowej sytuacji decyduję, że np. z braku miejsca na płytce postanawiam użyć tego procesora w mniejszej obudowie to zmieniam cały element na schemacie (jeśli nie stosowałem wcześniej tego procesora w tej obudowie to będzie to poprzedzone dodaniem jednego elementu do biblioteki).

Nie pamiętam, aby kiedykolwiek mi się zdarzyło zaglądać do elementu na schemacie aby sprawdzić jaki footprint - czemu to miałoby służyć? Jeśli pojawia się potrzeba zmiany footprintu to wynika ona z jakiegoś problemu na PCB, a tam po prostu widzę footprinty (nie nazwy, a realne wymiary).

Nie, nie, nie. C1, C2,... to identyfikator/desygnator elementu i to jest związane tylko z konkretną płytką a nie z żadnymi szufladkami. A symbol to przyjęte oznaczenie dla konkretnego elementu w konkretnej obudowie. Symbole to: 22, 100, 1k, 2k2 - oznaczają rezystory 0603, 15p,

1n, 10n - oznaczają kondensatory 0603. Jeden wyjątek - 100n oznacza 0402 (to od czasu jak z każdej strony procka trzeba dać kondensator i żeby nie zajmował za dużo miejsca). Większe 100n oznaczyłem sobie nie rozmiarem a napięciem: 100n/25 i 100n/50. Podobnie ceramiczne uF oznaczam według napięcia bo wstawiając na schemat interesuje mnie napięcie a nie obudowa. Czyli w 0603 mam 1u/25, 4u7/16, a w 0805 mam 1u/50, 10u/16, 22u/6.3, a w 1206 10u/25. Wszystko to X7R lub X5R bo z Y5V zrezygnowałem. Wstawiając na schemat, nie jestem pewien w jakiej obudowie wstawiam kondensator, ale też nie widzę potrzeby posiadania takiej pewności. Jak zacznę robić płytkę to będę widział rozmiary elementów i dopiero jakby mi coś za żadne skarby nie wchodziło to będę dumał co z tym zrobić. Tak mi kiedyś nie wchodziło 16 rezystorów 100. Zapytałem producenta kontraktowego jakie mają na magazynie 0402 (wtedy to jeszcze nie był u nich standard) i od tamtej pory mam element o moim symbolu 82_04.

Aż zajrzałem do mojej wypowiedzi - czy faktycznie tak niejasno napisałem. Według mnie trudno było to tak zrozumieć, ale dawało się.

Podejrzewam, że nie masz w tej wersji tych właściwości, które skłoniły mnie do zainteresowania się w ogóle KiCadem - czyli tego co jest na 2 pierwszych filmikach na:

Bez tego uważałem, że jest gorszy od mojego starego Protela. Teraz wydaje mi się lepszy, choć niektóre kwestie będą mi trochę przeszkadzały

- głównie to będę musiał nauczyć się wycinać GND z pliku sieci. Ale to jest tak, że od stycznia moim głównym programem jest - zajmijmy się KiCadem, tylko, że zaraz wystąpiło przerwanie, potem drugie i kolejne i obecnie jestem gdzieś na 5-tym poziomie przerwań i nie wiem kiedy wrócę do głównego programu, bo co uda mi się zejść do poziomu 3 to zaraz znów ląduję na 5, czy 6 i tak ciągle.

Wydaje mi się, że planują wprowadzić wersję 5 i wtedy będą biblioteki po nowemu. Ale czy to za miesiąc, czy za 3 lata to nie mam pojęcia. P.G.

W dniu 2017-11-21 o 23:00, Zbych pisze:

No to ich nie wyłączaj! Nie masz na tyle silnej woli? :-) Jak widzisz coś, co wyłączyć można, to ręce Ci się trzęsą z wrażenia i rzucasz się na tą opcję w celu jej wyłączenia? Zupełnie nie rozumiem w czym rzecz.

I dokładnie tak jest! Podkreślałem to wielokrotnie. Wyjaśniłem, że to nie DRC jest wtedy za tą czynność odpowiedzialny lecz moduł o nazwie Route. DRC nie służy do rysowania ścieżek lecz właśnie Route! Jeśli potem poleceniem Move zażyczysz sobie korekt łamiących zasady, to po wywołaniu DRC/check te miejsca będą świecić jak choinka - używając Twojego sformułowania! Będą też wokół nich rysowały się białe prostokąty z graficznym linkiem do informacji o tym jaka reguła została naruszona. Potem można sobie wybrać coś w rodzaju "akceptuję to konkretne odstępstwo od zasad" albo je po prostu poprawić. W obu przypadkach powtórne powiadomienie zniknie w sensie dawania po oczach (w stosunku tylko do tego konkretnego fragmentu ścieżki, którego ono dotyczyło) ale nadal będzie dostępne w sekcji ukrytych ostrzeżeń.

Tak jak powyżej napisałem po raz 9765765 - mniej więcej tak właśnie jest. Technicznie nieco inaczej ale logicznie dokładnie tak.

Rany... w kółko macieju o tym samym gadamy. Może inaczej to ujmę, bardziej obrazowo. Traktuj DRC jako coś, co w innych programach zazwyczaj nazywa się "preferences" z jedną tylko różnicą: posiada jedną funkcję, która fizycznie coś robi. Jest nią:

1. Końcowa weryfikacja PCB.

a poza tym:

1. Ustawia minimalne nieprzekraczalne wartości jak grubość ścieżki, odstępy, otwory parę innych. Jeśli któryś Net Class definiuje mniej, to zostanie nadpisany.

1. Ustawia wiele innych wytycznych dla innych modułów: takich jak route (rysowanie ścieżek), rozlewania wielokątów (masy rozlane itp) itd.

Z tego wynika, że skutki jego ustawień są rozległe, wpływają na wiele modułów a skutek jego zadziałania z p.1 jest jeden: podświetlenie błędów.

W dniu 2017-11-22 o 01:01, Mario pisze:

Jasne, że tylko semantyka a raczej nie semantyka lecz inny sposób implementacji tych samych funkcji. Lecz Zbych uważa, że skoro nie DRC w Eagle robi takie rzeczy lecz Route, to Eagle jest beee. Nie potrafię mu tego przetłumaczyć.

W dniu 22.11.2017 o 13:53, Marek S pisze:

Ściągnąłem najnowszego eagla, otworzyłem przykładowy projekt i przesunąłem ścieżkę tak, żeby wlazła na drugą. Poza ledwie widocznymi kreseczkami pokazującymi miejsce kolizji nie zauważyłem żadnej reakcji.

W dniu 2017-11-22 o 08:49, Piotr Gałka pisze:

Wkleję na spodzie wypowiedzi fragment swojej wypowiedzi na temat DRC w Eagle. Odpowiadając: tak, z czystym sumieniem polecam.

Jeśli ktoś zdefiniował np. zbyt małe odległości między ścieżkami na początku, potem zakończył projekt i nagle chce kliknąć jeden magiczny guzik "popraw mi samoczynnie cały projekt do nowych wytycznych", to takiej funkcjonalności nie ma.

Co do słownictwa, to DRC pewnie można by w Eagle nazwać inaczej. Jak chcesz, to udaj się pod gmach Autodesku i wywieś transparenty. Może się ugną. W Eagle DRC (jak niżej szczegółowo wyjaśniam) łączy dwie funkcje: sprawdzania (jak przystało na DRC) i ustawień dla projektu, niekoniecznie mających związek ze sprawdzaniem czegokolwiek (np. włączenie / wyłączenie thermals dla via).

Oto cytat obiecany:

"Może inaczej to ujmę, bardziej obrazowo. Traktuj DRC jako coś, co w innych programach zazwyczaj nazywa się "preferences" z jedną tylko różnicą: posiada jedną funkcję, która fizycznie coś robi. Jest nią:

1. Końcowa weryfikacja PCB.

a poza tym:

1. Ustawia minimalne nieprzekraczalne wartości jak grubość ścieżki, odstępy, otwory parę innych. Jeśli któryś Net Class definiuje mniej, to zostanie nadpisany.
2. Ustawia wiele innych wytycznych dla innych modułów: takich jak route (rysowanie ścieżek), rozlewania wielokątów (masy rozlane itp) itd.

Z tego wynika, że skutki jego ustawień są rozległe, wpływają na wiele modułów a skutek jego zadziałania z p.1 jest jeden: podświetlenie błędów. "

W dniu 22.11.2017 o 14:10, Marek S pisze:

Pisałem ci że mi jest wszystko jedno kto to robi i jak się nazywa, byle to się działo w czasie gdy rysuję ścieżkę.

W dniu 2017-11-22 o 14:16, Zbych pisze:

Zwykle mawiam: jeśli nic nie pomaga, to czas zajrzeć do instrukcji obsługi :-) Nie chcę tu kursu Eagle prowadzić więc ograniczę się do pokazania jak są wskazywane błędy po użyciu DRC. Również przesuwam ścieżkę zbyt blisko. Oto wynik:

W dniu 22.11.2017 o 14:30, Marek S pisze:

Brak wyraźnego wyróżnienia kolorem miejsca kolizji na PCB + pewnie ręczne wywołanie DRC, żeby to sprawdzić.

Teraz obrazek z KiCada:

ż to gościom z eagle niech się uczą.

W dniu 2017-11-22 o 14:27, Zbych pisze:

Pamiętam.

Mój ojciec nazywa operację uruchamiania przeglądarki internetowej logowaniem się. Czy w związku z tym zaczniesz pisać na forum, że przeglądarka Ci się nie loguje? Jakie będzie zrozumienie problemu wtedy?

Wyjaśniłem Tobie 5x, że operacje jakie chcesz wykonać są do uzyskania w Eagle ale od strony technicznej wygląda to zupełnie inaczej niż w "Twoim" sofcie. Nie zamierzam zmieniać słownictwa i de facto fałszować opis zasady działania Eagle tylko dlatego, że używasz własnego słownika, być może właściwego dla innej aplikacji.

W Eagle też ten moduł DRC ma nie do końca właściwą nazwę (DRC = Design Rule Check) bo robi też za setup dla projektu. Ale nic na to nie poradzę. Nie ja jestem autorem Eagla. Ale wiem jak on działa i dzielę się to wiedzą.

W dniu 2017-11-22 o 14:42, Zbych pisze:

Rany. Masz tu zbliżenie:

Oby tylko ktoś teraz nie napisał, że "a u mnie pszczółka siada na errorze i gra na trąbce" więc spadajcie ze swoimi aplikacjami :-D

W dniu 22.11.2017 o 14:49, Marek S pisze:

Widziałem to już wcześniej - porażka.

W dniu 2017-11-22 o 14:56, Zbych pisze:

No i co wartościowego z tego ma wynikać, że efekty graficzne Ci się nie podobają?

No bo tylko o nich mówimy. Nie sposób przeoczyć błędów - wydaje mi się, że o to tylko chodzi przy DRC.

Ponieważ czuję, że komentujesz teraz na zasadzie szukania dziury w moście, to napiszę bardziej do innych aby nie wyciągnęli mylnych wniosków z Twojej uwagi. Poniżej sposób podświetlania błędów w Eagle:

Moim zdaniem, nawet gdy ktoś bardzo bardzo nie chce zobaczyć miejsca występowania błędu, to i tak go zobaczy i to bardzo precyzyjnie.

W dniu 22.11.2017 o 15:15, Marek S pisze:

To nie jest kwestia podobania, tylko widoczności. Chyba nie powiesz, że sposób z eagle rzuca się w oczy?

Nie, po prostu porównuję dwa programy i widzę, który to robi według mnie lepiej. A że lubisz bronić eagla jak Rejtan, to już nie moja sprawa.

W dniu 2017-11-22 o 15:30, Zbych pisze:

To też nie o to chodzi. Faktem jest, że bardzo mi on odpowiada ale to pomijam. Mnie suche dane interesują najbardziej ograniczające mocno swobodę indywidualnej interpretacji. Np. szybkość supportu w korygowaniu zgłoszonych usterek, możność/niemożność wykonania konkretnych operacji (jak ta dziwna nasza dyskusja z podświetlaniem błędów) itd.

A chodzi o to, ze w naszej dyskusji doświadczyłem niezrozumiałych komentarzy jak ten ostatni, typu "Eagle kiepsko podświetla błędy" (czyli w domyśle, że ich nie widać. Nie jest sprawą gustu czy indywidualnych upodobań nie widzenie:

1. wielkiego wskaźnika pokazującego obszar występowania błędu,
2. potem małego podświetlenia konkretnego punktu aby nie trzeba było szukać po całym obszarze,
3. wygodnego zoomowania kółkiem myszy na obszar błędu
4. lub niemożność zrozumienia jednoznacznego, jednowyrazowego opisu

Można się przyczepić do estetyki ale nie można powiedzieć "nie widzę" bo nawet przy -5 dioptriach bez okularów zaznaczenie byłoby widoczne. Nie ma tu nic do bronienia lub atakowania. Proces zero/jedynkowy.

Z tego właśnie powodu uznałem , że to już nie jest nieporozumienie, brak precyzyjnego wyrażania myśli lecz forma przekomarzania się albo HGW czego innego...

W dniu 2017-11-22 o 14:23, Marek S pisze:

Wydaje mi się, że tamta odpowiedź pojawiła się już po wysłaniu mojej, albo ja jej jeszcze nie przeczytałem pisząc.

Nic do Eagle'a nie mam poza tym, że jak mam się uczyć czegoś nowego (bo mój Protel został już przegoniony) to wolę się nauczyć czegoś darmowego niż płatnego i o tym już pisałem.

Nie natknąłem się też na dema Eagle'a które by mi się tak spodobały jak te filmiki o KiCadzie które wskazywałem, co nie znaczy, że takich nie ma, bo ich nie szukałem.

Ja w tej chwili nie znam ani Eagle'a ani KiCada. Oglądając filmiki tu:

w stanie stwierdzić, że wygląda to lepiej niż w moim Protelu, ale nie jestem w stanie porównać KiCada do Eagle'a.

Ty jesteś w stanie. Obejrzyj i napisz parę słów porównania. Aby uniknąć ponownego zarzutu, że marnujesz swój czas a ja i tak jestem zafiksowany to z góry mówię, że to nie wpłynie na moją decyzję. Więc jak Ci szkoda czasu to nie rób tego. P.G.