Да все уже прояснилось, когда я тупым поиском файлов по маске *tcl* прошелся по директории с ментором. Сразу нарылся и сам tclwtcom (собственно из чего я и понял, через что работать в tcl с ментором), и директорий doc в нем. И скромный текстовый файлик внутри doc. Вот так прячется документация от злобных юзеров , желающих вторнуться в святая святых - недра скриптинга . Я не ищу инфы, как писать на TCL. Я на нем наваял уже целую толпу PCELL-ов в каде по ИМС. Я ищу как и через что работать именно в менторе. Ну а остановился на TCL вроде как потому, что industry standard он для скриптов в мультиплатформенном еда софте. Т.е. большинство его юзает.

Вот еще мелкий вопросик.
А есть какое-то средство, помогающее безошибочно расставить атрибуты Supply Rename и/или Supply Pin? Ну, как самый минимум, чтобы просто глянуть на список supply (скрытых) пинов компонента из DxD...

глянуть [attachment=33439:Quick_Co...ion_View.7z]

Увы и ах. Не арбайтен. См. вложение.

А есть возможность (к примеру) поредактировать назначение скрытых пинов в виде таблички? Ну чтобы в ней были part number, ref des, и список всех его скрытых пинов с возможностью назначить каждому свою цепь?

Пишите свой сложный скрипт, т.к. придется обращаться к данным хранящимся в LM

А по поводу "Aborted "$@"" - можно какую-то расширенную диагностику включить? Может просто у меня в консерватории что-то не так, а я об этом и не знаю...

Ну я так понимаю ругается на строку 91 файла sdd_startmw. Т.к. у меня в виндах все нормально, то значит надо разбираться в вашем Linux, тем более что как вы говорите у вас и LM падает, значит явно что-то не так. Сертифицированный Linux ставить не пробовали?

Пробовал (на экспериментах с LM). Не помогает. И еще пробовал несколько разных несертифицированных, везде идентично, и не только у меня. Я, собственно, некоторое время и жил на официальном RHEL по некоторым лицензионным соображениям.

Ну это и я догадался В этой строчке делается собственно запуск самой программы, это последняя строка скрипта sdd_startmw, и она, эта программа, и падает, но почему-то молча, хоть бы сказала, что ей не нравится.

С LM я примерно разобрался, он падает изредка, в зависимости буквально от фазы луны. Проблема там у ментора, в синхронизации между двух процессов, где при каких-то особо неудачных обстоятельствах происходит segmentation fault - т.е. обращение к несуществующей памяти (я под strace пускал LM). Т.е. при закрытии какого либо editor-а (без зависимости от его типа) может упасть сам LM. А может и не упасть. Ну упадет - перезапущу, главное все без потерь данных. А тут вот ведь 100% падает. Ну щас тоже попробую strace, если нет официального способа verbose диагностики.

Вот попробовал strace:

Вывод... Нихрена непонятно... Считал IC.pdb, причем не первый раз, до этого оно еще pdb-шки читало, ну и взял да упал по SIGSEGV... Т.е. никакой "классики жанра" проблем консерватории - ненайденного файла, или еще чего-то такого нехорошего не наблюдается.


......
......
......
access("/home/s-markov/work/mentor-lib/Mylib/PartsDBLibs/IC.pdb", W_OK) = 0
access("/home/s-markov/work/mentor-lib/Mylib/PartsDBLibs/IC.pdb", F_OK) = 0
open("/home/s-markov/work/mentor-lib/Mylib/PartsDBLibs/IC.pdb", O_RDONLY|O_LARGEFILE) = 67
fcntl64(67, 0xd /* F_??? */, 0xffbd0a30) = 0
fstat64(67, {st_mode=S_IFREG|0664, st_size=50080, ...}) = 0
fstat64(67, {st_mode=S_IFREG|0664, st_size=50080, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0x1000) = 0xfffffffff1c6d000
read(67, "\1p\4\0\f\3\0\37\1`\374\0\10\1\0\0\364\5\0\0x\7\0\0\374\10\0\0\10\n\0\0"..., 4096) = 4096
_llseek(67, 0, [4096], SEEK_CUR) = 0
_llseek(67, 4096, [4096], SEEK_SET) = 0
read(67, "\1\0\0\0\1@\4\0\27\0\0\0\0010\4\0\1\0\0\0\1@\4\0\31\0\0\0\0010\4\0"..., 4096) = 4096
read(67, "\37\0\0\0 \0\0\0 \0\0\0!\0\0\0!\0\0\0\"\0\0\0\"\0\0\0\"\0\0\0"..., 4096) = 4096
read(67, "\3\0\0\0\4\0\0\0\1\0\0\0\2\0\0\0\3\0\0\0\4\0\0\0\1\0\0\0\2\0\0\0"..., 4096) = 4096
read(67, "\2\0\0\0002\0\0\0\2\0\0\0003\0\0\0\2\0\0\0004\0\0\0\2\0\0\0005\0\0\0"..., 4096) = 4096
read(67, "\1\0\0\0\267\2\0\0\1\0\0\0\271\2\0\0\1\0\0\0\272\2\0\0\1\0\0\0\265\2\0\0"..., 4096) = 4096
read(67, "$\1\0\0\36\1\0\0\27\1\0\0\r\1\0\0\4\1\0\0+\1\0\0\3\1\0\0'\1\0\0"..., 4096) = 4096
read(67, "\0\0\0\0\1\0\0\0\0\0\0\0\\\0\0\0\0\0\0\0\1\0\0\0\2\0\0\0\3\0\0\0"..., 4096) = 4096
read(67, "\1\0\0\0004\2\0\0\1\0\0\0003\2\0\0\1\0\0\0002\2\0\0\1\0\0\0001\2\0\0"..., 4096) = 4096
read(67, "\34\0\0\0\35\0\0\0\0010 \0\n\0\0\0IC:ad8231\0\0\0\t\0\0\0"..., 4096) = 4096
read(67, "\4\0\0\0DIR\0\4\0\0\0NXT\0\4\0\0\0STP\0\4\0\0\0~CS\0"..., 4096) = 4096
read(67, "\3\0\0\0\3\0\0\0\1\0\0\0\1@\10\0\224\2\0\0\232\2\0\0\0010\34\0\1\0\0\0"..., 4096) = 4096
read(67, "\0\0\0\0\5\0\0\0VCCB\0\0\0\0\1@\10\0h\2\0\0k\2\0\0\0010 \0"..., 4096) = 928
fcntl64(67, 0xd /* F_??? */, 0xffbd09e0) = 0
stat64("/home/s-markov/work/mentor-lib/Mylib/PartsDBLibs/IC.pdb", {st_mode=S_IFREG|0664, st_size=50080, ...}) = 0
close(67) = 0
munmap(0xf1c6d000, 4096) = 0
stat64("/home/s-markov/work/mentor-lib/Mylib/PartsDBLibs/IC.pdb", {st_mode=S_IFREG|0664, st_size=50080, ...}) = 0
access("/home/s-markov/work/mentor-lib/Mylib/PartsDBLibs/IC.pdb", F_OK) = 0
futex(0xf5bb6784, FUTEX_WAKE_PRIVATE, 1) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
rt_sigaction(SIGABRT, {0x1000000000000000, [], SA_RESTORER|SA_STACK|SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_RESETHAND|0x3bd15c0, (nil)}, {0x10000004f5c400c0, ~[HUP INT QUIT ILL FPE KILL SEGV USR2 ALRM TERM STKFLT CONT URG RT_1 RT_2 RT_3 RT_4 RT_5 RT_8 RT_9 RT_11 RT_12 RT_14 RT_15 RT_16 RT_18 RT_23], SA_RESTART|SA_INTERRUPT|SA_NODEFER|0x3f458}, 8) = 0
open("/tmp/mwcore.QuickConnectionView.5668", O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 67
close(8) = 0
open("/tmp/mwcore.QuickConnectionView.5668", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 8
mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE, 9, 0x3000) = 0xfffffffff1c6b000
write(8, "Process information of process: "..., 8192) = 8192
write(8, "E/SDD_HOME/dx/help:/opt/mentor/E"..., 5894) = 5894
fstat64(8, {st_mode=S_IFREG|0664, st_size=14086, ...}) = 0
...
...
...



PS.
Линуксоиды, а у кого нибудь это работает?

Вот еще вопрос, сразу скажу, конечно, я играюсь сейчас с символами и прочее, чтобы понять все нюансы. Меняю их, туда сюда пины перебрасываю. И вот уже несколько раз возникает такая ситуация,
при запуске на упаковку в DxD вылетает вот такое сообщение
ERROR: Symbol pin name: (null) not found in PDB
on Symbol: ClassSymbols:N of Part: 24LC128_1
for Symbol Reference: $1I474 on
Sheet: Schematic1(1) at Path: Schematic1

Здесь 24LC128 название символа
$1I474 номер символа на схеме.

Если задать символ заново, все работает, но стоит только чего то там туда сюда поменять, то после вылетает и все. Причем, верификация символа проходит нормально.
Верификация схемы проходит без ошибок. А упаковщик стабильно выдает вот это сообщение про несуществующий пин. А там все нормально, 8 пин, ничего лишнего.
В документации искал подобное сообщение, такого просто нет или не нашел.
Что это может быть? И как с этим бороться. Да когда 8 пин это несложно изменить. Но вводить какого нибудь монстра заново что то не очень хочется если начнет такая
же ошибка вылетать.

Сообщение отредактировал tAmega - Jun 9 2009, 07:08

А символ-то проапдейчен в DxD после изменения?

Да, конечно. В том то и вопрос, вылизал все что можно, а упаковщик уперся и все тут...

Что означает фраза "Если задать символ заново" ?

Это означает создать новый символ вручную и прикрепить его к детали, вместо старого в библиотеке. Старый просто удалить.

Все нашел, в чем причина. Значит, создается символ, встраивается в деталь. Затем открывается проект, символ вставляется
в схему, и запускается упаковщик. Все работает нормально. Упаковщик ставим на самый мощный вариант упаковки, с нуля,
Rapackage All Symbols и Delete local data, then rebuild all local library. Все работает.
Теперь идем в символ, который уже прикреплен к детали, меняем имя пина. И сохраняем. Он сохраняется без звука, что что то не так.
И далее переоткрываем схему, даже если удалить со схемы деталь, перепаковать, затем задать снова, еще раз перепаковать,
все равно вылетает ошибка. Вот эта (null). Все дело в том, что в самой детали в gate стоит старое имя пина. Просто так переименовать
в детали его не получится, нужно удалять gate, удалять символ, и по новой загружать символ в деталь. В принципе это конечно
экстремальная операция, менять имена пинов на живой детали. Согласен. Но в диагностике вместе (null) могли бы просто написать
"конфликт имен пина", и все было бы ясно...

Сообщение отредактировал tAmega - Jun 9 2009, 11:54

Изменять имена и номера зарегистрированных в PDB символов и ячеек надо через LM>Tools>Modify_Cell_&_Symbol_Pins

Спасибо за наводку, очень полезный момент.