[elektro] nyáktervező linux alá
Papp Zoltán
zombi at c2.hu
Fri Jan 11 00:34:04 CET 2008
2008.01.10. 23:32:15 dátumon Szlifka Tibor <eltib at monornet.hu> írta:
>
> Nem véletlen választjuk sokan az Altiumot, kicad-től ne várj ilyeneket..
>
Miért ne várnék? Mi pl. a multi-room cuccot rengetegszer használjuk, mert
nálunk, hangtechnikában pl. rengetegszer van egy készülékben több
"csatorna" ugyanazzal a funkcióval. Gondolj bele, ha egy csatornában van
30-50 alkatrész, mennyi munkától kímél meg egy ilyen.
Gondolom a kicad is valamilyen táblázatos (adatbázis) formában tárolja az
alkatrészeket és egyéb rajzi elemeket.
Ha belegondolok, a sch-nál az alkatrészek adatbázisba tárolásánál csak
szorozni kell az alkatrész-számot x-el, a referencia-számára lehet
megoldásokat adni (pl. R101,R201,R301 v. R1A, R1B, R1C, stb.), ill.
megfeleltetni, hogy az egyes csatornákon belül az egyes alkatrészeknek
melyik x db valódi alkatrész felel meg.
A blokk-vázlatba illesztésnél kell megalkotni, hogy a multi-sch 1
kapcsolata (ami valójában x db), az a blokkvázlat melyik x kapcsolatával
van összeköttetésben; esetleg mindegyik össze van kötve a blokk 1 netjével
(pl. táp). Ez netlista generálási probléma.
A nyáktervező részénél meg egyszerűen az ide eső alkatrészek x,y
pozícióját és orientációját kell beállítani az első lerakott alkatrészének
megfelelően, a shiftelést a lerakott "room"-ok egymáshoz képesti pozíciója
adja. A vezetékeknél ugyanez, csak ott a geometriát is át kell másolni.
Pl. Altiumnál ilyenkor a vezetékek csak másolódnak, és utána már
független, szabad vezetékek. Az alkatrészek meg eleve is független
alkatrészek, csak az attribútumai másolódnak.
Úgy vélem egy nyáktervező progi komplett megírása után egy ilyen csak
részfeladat, és még csak nem is 7.xx-ről növeli a verziószámot 8.0-ra,
max. 7.2.xx-ről 7.3.0-ra :). Az sch részét kell okosan átgondolni, a többi
már csak egyszerű adatbázis művelet.
Az, hogy egy alkatrészhez hozzáadhassak egy "custom" mezőt, az is egyszerű
adatbázis-művelet, nem hiszem, hogy nagy fejlesztést igényelne.
Az alkatrészek keresési szűrése meg aztán végképp alap adatbázis művelet.
Persze vágom én, hogy szabadidőben írogatni egy ilyen komplex programot
nem kis meló, de szerintem pont az ilyen "apróságok" vihetik előre az
ilyen progikat. Azért itt nem szimulációról vagy nagyfrekis
számolgatásokról van szó, csak egyszerű táblázat-kezelésről. Szerintem az
ilyenek még a 3D megjelenítéstől is fontosabbak. Majd megnézem a nyákomat
realtime :) és lefotózom.
Tudom, hogy nagyon szubjektív a megítélésem (nem is lehet más), de én pl.
ezeket hiányolnám nagyon egy nyáktervezőből, amit egyébként az Altiumban
szerettem meg. Az Altiumnak pár részét még felejteni is tudnám :)
A problémám az, hogy ezek az apró kényelmi funkciók azok, amiért megéri
nekem az Altiumot használni, viszont ezek meg nem érnek annyit, amennyibe
egyébként kerül a progi. Mivel hogy nem ezek kerülnek benne sokba. Ami
viszont jelentősen megdrágítja, azt meg én pl. nem is használom és jó
eséllyel nem is fogom sose. Mint ahogy van egy olyan érzésem, hogy aki
kisfrekis (<10-20MHz) 2oldalas nyákokat gyárt, az 10%-át nem használja ki
az ilyen progiknak.
A kicaddel így meg az a problémám, hogy jelentősen lassítaná a munkámat
(ezért is tértem át a DOS-os Tangóról a Protel DXP-re annó), és hiába
ingyenes maga a progi, mivel több időmbe (így több pénzbe) kerül a
tervezés. Ami igaz viszont, hogy ez az összeg valószínűleg még mindig
alatta marad az Altium árának.
Én inkább fizetnék pl. egy kicad-ért 50-100eFt-t is akár, ha olyan
hatékonysággal tudnám gyártani vele a sima, 2 oldalas, egyszerű
analóg+digitál nyákjaimat, mint az Altiummal. És tudnám, hogy a pénzem is
jobb helyre megy.
De úgy látszik egyelőre nincs közép-út (vagy csak még nem találtam meg)
Üdv
--
Papp Zoltán
OneWay Electronics - www.onewayelectronics.hu
Hangszerviz - www.hangszerviz.hu
More information about the Elektro
mailing list