Dobrý den,

děkuji za námět. Takové funkce v editoru zatím nejsou. Pokud by šlo jen o to jmenovitě vypsat či ve schematu zvýraznit předlohy součástek, které se jakkoli liší od stejnojmenných v knihovně, neměl by to být velký problém. Zkusím se na to výhledově podívat. Nicméně detailní porovnání nalezených dvojic a posouzení, která z nich je "novější", musí zůstat na uživateli. "Automatickou aktualizaci" slíbit s čistým svědomím nemohu.

52

(4 odpovědí, posláno do Dotazy a náměty ke schematickému editoru)

Dobrý den, uvedené dva "grupové" příkazy je možno použít i pro Drag a Move. Vyberte jimi požadovanou skupinu prvků (případně ještě můžete některé prvky doplnit či odebrat pomocí Add/Sub) a skupinu pak posouvejte v režimech Move Group a Drag Group.

Jenže ono skoro vždycky někde něco někam přesahuje. Pak se nejspíš ukáže, že namísto přesouvání do "grupového" menu kvůli příkazům Window & Border a Window Interior a zase zpět je jednodušší označit blok přímo v menu Edit a pak případně doladit výběr pomocí Add/Sub. Pro pohodlné přecházení mezi těmito třema režimy slouží střední tlačítko myši: Začnete příkazem Drag Block - jeden roh bloku vyznačíte levým tlačítkem, protilehlý pak tlačítkem středním - tak máte označený blok a zároveň jste v režimu Add/Sub - levým tlačítkem překlápíte příslušnost k označené skupině a středním tlačítkem se přesunete do režimu Drag Block. Analogické rychlé přesuny fungují i ve skupinách Move, Copy a Delete.

Možná bych popis pana Ocha měl trošku upřesnit: V programu ve skutečnosti není nikde použit předpoklad, že všechny sekce součástky jsou shodné až na čísla vývodů. Program jen při pokládání nabídne první z možných grafických podob součástky, protože nemůže předvídat požadavek uživatele.

Naše knihovny obsahují řadu předloh připravených právě pro to, že uživatel použije pro různé sekce různé obrázky. Např. LM4136CM obsahuje 4 sekce, z nichž jen jednu stačí zakreslit jako napájenou, pro ostatní je možno (podle uvážení konstruktéra) využít alternativní podobu.

Dokonce nestojí nic v cestě ani tomu, když jednotlivé sekce součástky jsou konstrukčně různé. Viz příklad relé obšírně rozebíraný ve vláknu www.formica.cz/forum/viewtopic.php?id=174.

Nové chování editoru, které se tam také zmiňuje, spočívá v tom, že přeskočí v seznamu možných podob ty z nich, které pro právě pokládanou sekci neobsahují žádné zobrazitelné vývody, a nabídne první z těch, kde nějaké vývody zobrazit může (není ovšem nijak zajištěno, že to je ta požadovaná).

Dobrý den, v současném stavu schematický editor umožňuje jediným způsobem elektricky propojit vývody uvnitř předlohy. Vývody (viditelné i skryté napájecí) se stejným Pin Indexem se považují za jediný nerozlišitelný vývod. Mohou se nacházet i v různých sekcích součástky. Z hlediska netlistu je to jeden vývod.

Jiné způsoby možné nejsou. Není podporováno propojení vývodů vodičem uvnitř součástky, ani propojení přímým dotykem vývodů. Jakékoliv obrázky uvnitř předlohy nenesou elektrickou informaci! Dokonce nebude správně fungovat, ani když si nakreslíte několik vývodů na sebe tak, že jejich přípojná místa budou splývat.

Není mi úplně jasné, jaké je vlastně požadované chování. LM334M má ve schematické značce 3 vývody, z nichž jeden (V-) je v pouzdře SO-8 vyveden na 4 piny (2,3,6,7), dva piny nezapojeny. Postup první "s větvenými vývody" by znamenal, že ve schematu by součástka měla 6 vývodů. Druhý postup "s propojenými vývody" (pokud by byl podporován) by měl zajistit, že připojením jediného vodiče by se k němu připojily všechny vnitřně propojené vývody. V netlistu by se pak objevilo propojení všech těchto pinů, dokonce i když by k nim žádný vodič připojen nebyl. To by nevadilo? Pokud by to nevadilo v tomto konkrétním případě, nemohlo by to vadit jindy?

Dobrý den, nejdříve vysvětlím, co se pravděpodobně děje. V průběhu kopírování je skutečně možno narazit na limit. Mechanismus kopírování totiž funguje tak, že po zvednutí bloku se společně s kurzorem pohybují už nově vytvořené součástky (mají unikátní reference, které nekolidují s jinými součástkami ve schematu, případně došlo i ke změně čísel sekcí). Pokud povolená kapacita nestačí, může už při této operaci dojít k tomu, že se nevytvoří kopie celého bloku. Další kolize může nastat při pokládání, kdy dojde k dalšímu zmnožení součástek - ty z kurzoru se položí do schematu, a na kurzoru se zároveň vytváří další blok (zase přečíslovaný) připravený pro opakované kopírování. Běžně byste tento blok ihned zahodil pravým tlačítkem myši, takže by nevadilo, že se nevytvořil celý. Jenže automatické undo po chybě vrátí schema do stavu před celou operací.

Obejít tuhle nepříjemnost lze několika způsoby:
1) samozřejmě tak, že budete kopírovat po menších částech,
2) můžete použít operace Import Group a Export Group - ta první vytvoří kopii nikoliv na kurzor, nýbrž do souboru, a ta druhá pak provede nutné přečíslování a dovolí kopii bloku umístit na požadované místo, aniž by se vytvářením další přebytečné kopie vyvolala chyba.

Omlouvám se za nepohodlí. A děkuji za námět.

56

(2 odpovědí, posláno do Dotazy a náměty ke schematickému editoru)

Dobrý den, děkuji za námět.  Takové automatické zarovnání skutečně v programu není a mohlo by se hodit.

Pokud ovšem jde o
1) odstranění zmiňované nutnosti "pokaždé ručně přehazovat stranu zarovnání" a zároveň
2) snížení pracnosti při umisování kotvičky přesně na konec vodiče,
nabízí program jiný užitečný nástroj.

Mějme vodiče s návěštími, která nemusí být ani zarovnaná ani nemusí mít jednotně umístěné kotvičky.  Taková situace může jistě vzniknout nejen rychlým či "nepečlivým" umisováním, ale také například po kopírování z různých zdrojů. 

Stačí ale zvýraznit takový blok včetně vodičů a použít množinovou funkci Align

http://www.formica.cz/files/forum/align1.png

a všechna návěští (i jiné nezávislé texty) se zarovnají na požadovaný okraj.

http://www.formica.cz/files/forum/align2.png

Více podrobností o funkci Align naleznete v nápovědě. Vyjádření ostatních účastníků konference k oběma nástrojům jsou samozřejmě vítána.

Dobrý den,

pokusím se o podrobnější odpověď. Nabízejí se dva způsoby řešení:

A) Obecným řešením je vytvořit pro součástku alternativní podobu (schematickou značku), která namísto skrytých napájecích vývodů bude obsahovat piny viditelné. Ve standardní knihovně sice takové předlohy pro CMOS obvody nejsou, ale možnosti využití různých podob téže součástky lze ilustrovat například na součástce OPAMP. Ve čtveřici alternativních podob naleznete obě uspořádání invertujících a neinvertujících vstupů a zároveň viditelné a neviditelné napájecí vývody.

Vytvoření předlohy s viditelnými vývody z existující předlohy s piny neviditelnými bude obsahovat následující kroky:

1) otevření příslušné předlohy v editoru předloh (Browse/Edit|Modify Mask|"jméno upravované předlohy")
2) vytvoření další podoby (Definition|Add Definition)
3) překopírování vývodů vzorové podoby (Definition|Load Pin Definition)
4) vymazání napájecích vývodů (překopírovaly se spolu s viditelnými; Power Pins|Delete)
5) překopírování grafické části vzorové podoby (Definition|Load Graphics Definition)
6) doplnění viditelných napájecích vývodů (Place|Pin); pro správnou elektrickou funkci je nutno správně nastavit čísla vývodů (jsou to ta čísla, která měly smazané skryté vývody); pro orientaci je vhodné konzistentně zvolit Pin Name (např. GND) a Attribute nastavit na "Power"; má-li součástka více sekcí, pak se nic nezkazí, pokud čísla napájecích vývodů budou ve všech sekcích stejná
7) uložit upravenou předlohu (Store)
8) návrat do schematu (Back to Schema)


B) Existuje ještě další řešení, které ale bude specifické jen pro konkrétní zapojení. Stačí totiž v předloze CMOS obvodu přejmenovat návěští napájecích vývodů a výstup napájecího obvodu jen opatřit příslušnými návěštími.

1) otevření příslušné předlohy v editoru předloh (Browse/Edit|Modify Mask|"jméno upravované předlohy")
2) výběr podoby, která je použita ve schematu (Definition|Switch to)
3) přejmenování napájecích vývodů (Power Pins|Edit)
4) uložit upravenou předlohu (Store)
5) návrat do schematu (Back to Schema)

Peroutka napsal:

Toto by snad šlo i u současné verze následujícím způsobem:
V menu 'C' (Name, Package,...) určit počet sekcí. Např. 3 a všechny mohou být zobrazeny různě. Pro dvě sekce např dioda + cívka relé v jedné součástce o 2 sekcích. Tato kombinace je určitě nesmyslná, ale jde to.
pak se zobrazí pro každý vývod 3 řádky pro zadání čísla vývodu. Pokud se pro každou ze sekcí (naprosto spolu nemusí souviset) využije jiný řádek a v ostatních se nechá 0. Je vývod zobrazen pouze u nenulového čísla.

Ano. Přesně tak je to uděláno ve výše uvedeném příkladu relé.

Peroutka napsal:

Sekce s '0' přiřazenou k vývodům (tedy nezobrazeným) by se nemohla do schematu položit (je to však žádoucí?)...

Děkuji za námět. Pojďme to ještě zkusit promyslet.

Přítomnost vývodu s indexem 0 v dané kombinaci sekce-předloha určitě neznamená, že se nemá používat. Existují například předlohy, kde se napájecí vývody zobrazují jen v sekci A, zatímco v ostatních jsou právě díky tomuto mechanismu skryty.

Snad by bylo řešením zakázat zobrazení sekce pomocí předlohy, kde jsou skryty úplně všechny vývody. Pomohlo by takové chování?

Současný stav umožňuje zobrazit třeba každou sekci pomocí jiné definice.  Zmiňované omezení tedy pravděpodobně spočívá v tom, že uživatel musí v takovém případě sám vybrat vhodnou definici. 

Situaci by snad zjednodušilo, kdyby předloha mohla oproti současnému stavu obsahovat navíc seznam zakázaných kombinací sekce-definice. Pak by se nová sekce při umísování vždy zobrazila pomocí první z přípustných definic.

Neporadím Vám nic výrazně jiného. Jen se pokusím poukázat na některé aspekty.

Především neexistuje žádné omezení na to, jak mají vypadat definice ani jak má být součástka rozdělena na sekce. Není sice možné zabránit tomu, aby pro vyobrazení určité sekce byla použita nevhodná předloha, ale použitím nulového indexu pinu lze většinou zajistit, že taková sekce neobsahuje žádná přípojná místa, což by jako upozornění na nesprávné použití mělo postačovat. Tento postup je ilustrován v následujícím schematu na příkladu relé, které pro sekci A předpokládá užití definice "civka", kde jsou zapojeny vývody 1 a 2, a pro sekce B resp. C definice "kontakt", kde jsou využity vývody 3 a 4, resp. 5 a 6:

http://www.formica.cz/files/forum/rele.png

Library (
  (0 32 140 352 2 
    ("PRIKLAD RELE" 0 80 4) ("Re" 0 0) ("" 0 -40 4 8) 
    Definition ("civka" 
      ( Pins (
          ((2 0 0) 120 0 5 (("2" "" "") 72 0 4) 0 120) 
          ((1 0 0) 120 320 5 (("1" "" "") 72 320)))) 
      ( Lines (
          (120 0 120 40 0) 
          (120 280 120 320)) 
        Arcs (
          (0 120 60 20) (0 120 100) (0 120 140) (0 120 180) 
          (0 120 220)   (0 120 260) (3 120 60)  (3 120 100) 
          (3 120 140)   (3 120 180) (3 120 220) (3 120 260)))) 
    Definition ("kontakt" 
      ( Pins (
          ((0 4 6) 120 0 5 (("" "4" "6") 72 0 4) 0 120) 
          ((0 3 5) 120 320 5 (("" "3" "5") 72 320)))) 
      ( Lines (
          (120 0 120 40 0)  (120 80) 
          (120 240 120 280) (120 320) 
          (120 100 140 220 162)) 
        Circles (
          (120 90 10) 
          (120 230)))))) 
Layout ("0" 
  Boxes ((120 80 2040 600)     (120 600 2040 1800)) 
  Lines ((120 600 2040 1800 2) (120 1800 2040 600)) 
  Components (
    (200 160 0 (("PRIKLAD RELE" 470 120 4 2) ("Re1" 362 480) ("") (""))) 
    (920 160 0 (("PRIKLAD RELE" 1190 120) ("Re1" 1082 480) ("") ("")) 1 1) 
    (1520 160 0 (("PRIKLAD RELE" 1790 120) ("Re1" 1682 480) ("") ("")) 1 2) 
    (200 760 0 (("PRIKLAD RELE" 470 720) ("Re2" 362 1080) ("") (""))) 
    (920 760 0 (("PRIKLAD RELE" 1190 720) ("Re2" 1082 1080) ("") ("")) 0 1) 
    (1520 760 0 (("PRIKLAD RELE" 1790 720) ("Re2" 1682 1080) ("") ("")) 0 2) 
    (200 1360 0 (("PRIKLAD RELE" 470 1320) ("Re3" 362 1680) ("") ("")) 1) 
    (920 1360 0 (("PRIKLAD RELE" 1190 1320) ("Re3" 1082 1680) ("") ("")) 1 1) 
    (1560 1360 0 (("PRIKLAD RELE" 1830 1320) ("Re3" 1722 1680) ("") ("")) 1 2)))

Ve složitějších případech takový postup nepomůže. Pak si uživatel musí sám dávat pozor, aby si do schematu nevnesl zbytečný zmatek. V knihovně jsou například předlohy, které umožňují rozdělit součástku na jednotlivé sekce anebo ji pomocí jiné definice užité pro sekci A zobrazit jako jeden celek. Pokud se zároveň zobrazí celek a některá sekce, pak je příslušnou sekci možno připojit nezávisle na obou místech. Připomínám, že vývody označené stejným indexem se v netlistu chápou jako jediný vývod.

Implicitní propojování vývodů je ovšem také možno využít ve spojení se sekcemi. Shodně číslované vývody v různých sekcích součástky mohou posloužit např. k propojení různých výkresů.

Chování, jak ho popisujete v první větě, je plně v souladu s nápovědou pro "Text s pruhem", kde si můžete přečíst: "Text, v němž se vyskytuje pruh, musí mít na začátku znak ~ (vlnka). Pruh začíná vlnkou lichou v pořadí a končí vlnkou sudou v pořadí (pokud pruh má začít uvnitř textu, musí mít text na začátku dvě vlnky). Pokud text obsahuje lichý počet vlnek, při vypisování se automaticky vkládá vlnka za jeho poslední znak." Nejde tedy o projev závady.

Toto složitější řešení bylo implementováno zejména proto, že bylo rychlejší vyhodnocovat pruhování jen u textů začínajících vlnovkou. Tento aspekt sice časem poněkud ustoupil do pozadí, ale kvůli zpětné kompatibilitě není vhodné chování měnit, protože zároveň umožňuje vložit do textu také skutečnou vlnovku.

Dobrý den,
bohužel hromadná změna Definition není k dispozici. Zamýšlenou záměnu umožníte nejlépe tak, že do novější verze předlohy doplníte potřebný počet kopií té definice, která se má zobrazit. Pokud není nutné zachovat existující pořadí definic v nové předloze, můžete posunout indexování doplněním prázdných definic. Vyhnete se tak nutnosti v budoucnu udržovat několik (původně) shodných definic.

V každém případě děkuji za námět.

kolin napsal:

- Zajimava by byla ta moznost zakazat hybani s napisem, ktery neni ve vychozi pozici (viz Vase slova "...co se má stát, je-li prázdná/skrytá/přesunutá jinam/má nulovou velikost...")

Neměl jsem na mysli nějakou další možnost (např. zakázat hýbání). Jen jsem chtěl uvážit možnost "řetězeného nahrazování", kdy daná položka není na daném místě zobrazena nikoliv proto, že je neviditelná, nýbrž proto, že už předtím nahradila jinou položku.

kolin napsal:

Mno, kdyz jsem si napriklad u definice pro soucastku s vyvody jinam nez nahoru nastavil, ze veskere napisy chci mit vyskladane smerem nahoru, pak vznika takovy pitomy stav, kdy mam od nejvyse polozeneho radku: Reference, Part Name, Package, Value, Note. A ted, pokud nemam nic v Package, Value, nebo Note (prip.ani v jednom), pak mi tam vznika zbytecna mezera, ktera by byla u kazde takove soucastky.

To je pochopitelné. Popsané výjimky byly šité na míru výchozímu nastavení, kde se nikdy Package, Value a Note neumísovaly mezi PartName a součástku.

kolin napsal:

Predstavuji si to napr.tak, ze kdyz rozkliknu nekterou ze 16ti definic v "Default Image", uvidim dole vedle "Copy from >" jeste prepinac "Auto Align" (On/Off) nebo "dY numbering" (Absolute/Relative). Fungovalo by to tak, ze pokud bude prepinac na On (resp.Relative), a zaroven obsah polozky bude nulovy, nebo viditelnost jakekoliv z polozek Hidden, (ma se to vztahovat pro uplnost i na nulovou velikost pisma?) pak vsechny ostatni polozky, ktere lezi na radcich s vyssi absolutni hodnotou dY, se posunou o radek blize stredu soucastky.
Programatorsky to vidim nejak takto:

- pokud je Reference Corner roven Top Left nebo Top Right, tak
    - vezmi jeste neotestovanou polozku s nejnizsim cislem radku vetsim nebo rovnem nule
    - tuto polozku otestuj na neviditelnost, nulovy obsah, nulove pismo - pokud neco z toho splnuje, pak vsem polozkam s vyssim cislem radku dekrementuj jejich cislo o 1
    - opakuj do otestovani vsech polozek s cislem radku vetsim nebo rovnem nule
- pokud je Reference Corner roven Bottom Left nebo Bottom Right, tak
    - vezmi jeste neotestovanou polozku s nejvyssim cislem radku mensim nebo rovnem nule
    - tuto polozku otestuj na neviditelnost, nulovy obsah, nulove pismo - pokud neco z toho splnuje, pak vsem polozkam s nizsim cislem radku inkrementuj jejich cislo o 1
    - opakuj do otestovani vsech polozek s cislem radku vetsim nebo rovnem nule

Děkuji za námět. Rozmyslím si to. Ještě by to totiž vyžadovalo zobecnění na svislé nápisy apod.

A co kdyby pro každou z pěti položek součástky bylo v příslušné definici jenom uvedeno, co se má stát, je-li prázdná/skrytá/přesunutá jinam/má nulovou velikost? Možnosti jsou buď ponechat, anebo přesunout na její místo jinou určenou položku. To by jednak umožnilo jednoznačně řešit i případy, kdy leží více popisů na řádku, jednak by to umožnilo zahrnout současné výjimky do výchozího nastavení.

kolin napsal:

Samozrejme necekam ze by se napisy mely "sesypat" k soucastce jakmile napis schovam, ale staci, pokud se sesypou v okamziku kdy otocim soucastku, stejne jako se az tehdy hybe napisy nyni.

Estetický problém může představovat opačná situace, kdy skrytou položku zviditelním.

Dobrý den,
Váš požadavek je na jedné straně velmi rozumný (tak nějak to člověk udělá ručně, aniž by nad tím moc přemýšlel), na druhé straně mi není jasné, jak by mělo vypadat ovládání takového chování a jaké by mohlo umožňovat smyslupné modifikace. (Možná něco vyplyne z tohoto vlákna.)

A proto je podobné chování v editoru už dlouhá léta pevně zabudováno. Namísto dlouhého vysvětlování uvedu komentář ze zdrojového textu, který snad dostatečně popisuje, jak program umísuje popisy součástek, pokud jsou PartName nebo Reference nulové velikosti, případně pokud je PartName skryto (skrytá Reference do výjimek zahrnuta není, na důvod už si nevzpomínám). Pokud první výjimka vede na nějakou změnu, pak druhá zachází s přesunutými nápisy.

    // vyjimka: neviditelne PartName nebo nulove velikosti ->
    //   pozice PartName blize stredu soucastky nez Value1 ->
    //     Value1 prevezme pozici od PartName a Value2 od Value1
    //   else
    //     pozice PartName blize stredu soucastky nez Value2 ->
    //       Value2 prevezme pozici od PartName

    // vyjimka: Reference nulove velikosti ->
    //   pozice Reference blize stredu soucastky nez PartName ->
    //     PartName prevezme pozici od Reference a Value1 od PartName a Value2 od Value1
    //   else
    //     pozice Reference blize stredu soucastky nez Value1 ->
    //       Value1 prevezme pozici od Reference a Value2 od Value1
    //     else
    //       pozice Reference blize stredu soucastky nez Value2 ->
    //         Value2 prevezme pozici od Reference

Dobrý den, soubor jménem "lib 440-A.pcb" není součástí instalačních sad Formica. Psal jste předtím o rozšiřování knihoven. Můžete popsat, jak ten soubor vlastně vznikl?

Uvnitř programu musí být jména PartNames jednoznačně uspořádána, aby bylo možno rychle nalézt předlohu podle jména. Pokud je navíc abecední řazení vyhovující, není důvod měnit fungující mechanismus.

V případě pouzder se žádně setřídění nevyžaduje. Zachovává se pořadí, v němž byla jména pouzder vložena. Doplnit funkci pro uživatelské setřídění by nebyl problém.

Programy Formica 4.40 (nevztahuje se na volně šířené omezené verze) vyžadují pro spuštění s plnou licencovanou kapacitou hardwarový klíč HASP, v němž je nahrán licenční certifikát.

Pokud je klíč HASP zapojen do USB nebo LPT portu počítače, kde jsou programy provozovány, postačí jen instalovat ovladače klíče podle postupu popsaného na našich webových stránkách.

Za určitých okolností je také možno nebo nutno použít klíč NetHASP, který komunikuje s programy Layout a Schematic prostřednictvím některého síového protokolu. V takovém případě nemusí (ale může) klíč být připojen k té stanici, kde se programy spouštějí. V obou případech na stanici s klíčem musí být instalovány ovladače a program Licence Manager.

Typické případy použití klíče NetHASP:

(1) Počítačová laboratoř nebo vývojové pracoviště, kde jeden klíč může obsloužit větší počet stanic. Licence Manager pak zároveň hlídá počet současně spuštěných programů.

(2) Formica provozovaná na emulátoru v prostředí Linux nebo MacOS, kde není možno správně instalovat ovladače lokálního klíče. Zde se využívá skutečnosti, že ovladače klíčů HASP a také Licence Manager jsou pro uvedená prostředí k dispozici.

Pro komunikaci je možno použít protokoly IPX, NetBios nebo TCP/IP. Pro doladění provozu v konkrétních podmínkách slouží řada dalších parametrů, které se nastavují na straně Formiky v souborech nethasp.ini a na straně Licence Manageru v souboru nhsrv.ini (v Linuxu a MacOS může být konfigurační soubor pojmenován libovolně).

Programy si sice někdy poradí i bez konfiguračních souborů, přesto doporučuji věnovat nastavení alespoň minimální pozornost. Nevhodné parametry mohou jednak zpomalit provoz nebo zcela zabránit nalezení klíče, na druhé straně může při souběžném použití několika protokolů dojít k tomu, že se program loguje pomocí každého z nich, což Licence Manager vyhodnotí jako několik souběžných spuštění.

Pro ilustraci uvádím jednoduchý konfigurační soubor, který se může hodit úplně každému uživateli licencované verze Formiky. Pokud je totiž umístěn v adresáři vedle chráněného programu, který bývá provozován s lokálním klíčem, pak ovlivní jeho chování v případě, kdy není klíč připojen. Namísto dlouhého hledání klíče v okolní síti se program omezí jen na lokální počítač. Každého jistě napadne, že by stačilo zakázat všechny protokoly, jenže s takovým použitím zřejmě konstruktéři nepočítali.

;začátek souboru -----------------------------------

[NH_COMMON]
NH_IPX = Disabled
NH_NETBIOS = Disabled
NH_TCPIP = Enabled

[NH_TCPIP]
NH_SERVER_ADDR = 127.0.0.1       
NH_TCPIP_METHOD = TCP

;konec souboru -------------------------------------


Nakonec dvojice konfiguračních souborů, která by mohla fungovat ve většině situací, včetně výše uvedených (1) a (2):

nethasp.ini:
;začátek souboru -----------------------------------

[NH_COMMON]
NH_IPX = disabled
NH_NETBIOS = disabled
NH_TCPIP = enabled

[NH_TCPIP]
NH_SERVER_ADDR = xxx.xxx.xxx.xxx     ; IP adresa stanice se síovým klíčem
NH_TCPIP_METHOD = TCP

;konec souboru -------------------------------------



nhsrv.ini
;začátek souboru -----------------------------------

[NHS_IP]
NHS_USE_UDP      = disabled
NHS_USE_TCP      = enabled

[NHS_IPX]
NHS_USE_IPX       = disabled

[NHS_NETBIOS]
NHS_USE_NETBIOS   = disabled 

;konec souboru -------------------------------------

69

(2 odpovědí, posláno do Dotazy a náměty ke schematickému editoru)

Ve verzi 4.40.65.15 byl doplněn přepínač "Options|Preferences|Panning Qualifier", který umožní jemněji nastavit podmínky pro přesun výřezu pohybem myši.

70

(2 odpovědí, posláno do Dotazy a náměty ke schematickému editoru)

Ve verzi 4.40.65.15  byl doplněn přepínač "Options|Preferences|Panning Qualifier", který umožní jemněji  nastavit podmínky pro přesun výřezu pohybem myši.

Ve verzi 4.40.65.15  se operace "Drag (Pick)" takto chová. Pro přelomení segmentu je nyní nutno při jeho uchopení přidržet klávesu <Shift>.

Ve verzi 4.40.65.15  je toto opomenutí napraveno.

Ve verzi 4.40.65.15  byla do množinové výměny pouzder "Edit|Group Operation|Change|Packages" doplněna tabulka pro rychlý výběr obsahující jména pouzder, která jsou společná pro všechny vybrané součástky.

Verze 4.40.65.15  obsahuje v menu "Edit|Group Operations|...|Components" příkazy pro zvýraznění součástek, jejichž PartName, Package, Value případně Note vyhovují zadané masce.

Na adresu www.formica.cz/files/Schema440r65p15.exe jsem vystavil tentokrát kompletní instalační sadu schematického editoru verze 4.40.65.15. 
Výčet hlavních úprav naleznete v souboru Zmeny.txt.

Tato verze neobsahuje nové rysy, které by měly vyvolat podnětnou diskusi. Naopak je to typický "Release Candidate".