[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