[тау 30]

Есть вопросы именно по выложенному?

резисторы например раздробить по типоразмеру надо . Я это использую у себя, чтобы не наводить фильтрацию 0402 0603 0805 и т.п. (лишние движения на клаве и мышкой оптимизируются) Кроме этого у меня еще и проценты разные в разных классах.

По конденсаторам мелким тоже так.

[Uladzimir 96]

Конкретно по этой сборке могу сказать, что я ее положил бы в DIODES/TVS. Если таких сборок будет много, то введу каталог DIODES/TVS/ARRAYS, но суть не в этом

Суть в том, что приведенная мной классификация на самом деле рассчитана на понимание того, какие параметры являются характерными для каждой группы компонентов. Т.е. фактически деление происходит именно по набору параметров, и каждый набор получает свое имя (в виде названия ветки) и расположение (в виде места в дереве). Поэтому перед тем, как положить куда-то новый компонент, я всегда смотрю, какие параметры у него наиболее важны. Понятно, что эта сборка может быть рассмотрена и как IC, и как Bridge. Но кто ее будет использовать в качестве моста, например? Это надуманно, так же, как и микросхема.

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

Но, подумать, конечно, не мешает. Разные классификации, по-моему, это выход. Главное, четко продумать принципы, по которым будет строиться вторая, третья и т.п. классификации. Есть предложения?

Это первый попавшийся на ум компонент привел как пример, что такое в может быть.

Поэтому в принципе не нужно исключать, что компонент может присутствовать в РАЗНЫХ классификаторах

По поводу 2 и третьей TAY уже дал рекомендации

[vitan 2]

резисторы например раздробить по типоразмеру надо . Я это использую у себя, чтобы не наводить фильтрацию 0402 0603 0805 и т.п. (лишние движения на клаве и мышкой оптимизируются) Кроме этого у меня еще и проценты разные в разных классах.

По конденсаторам мелким тоже так.

По поводу 2 и третьей TAY уже дал рекомендации

Интересно, неужели так напрягают движения мышкой? :)

Просто получается, что по этому методу можно будет делить только резисторы с конденсаторами. Микросхемы не получится (нет у них точности).

Это я к тому, что такой метод годится не для всех компонентов. Поэтому лично у меня его и нет.

Идея только в ускорении фильтрации?

Видимо, для этого лучше подходят типовые наборы фильтров, нежели такая странная классификация.

Спасибо за наводку, этого у меня еще нету. :)

 

Поэтому в принципе не нужно исключать, что компонент может присутствовать в РАЗНЫХ классификаторах

Конечно, я уже говорил, что разное деление должно существовать параллельно.

[Uladzimir 96]

Интересно, неужели так напрягают движения мышкой? :)

Напрягают. Каждый раз вводить фильтр. Обычно в каждом проекте один типоразмер

Просто получается, что по этому методу можно будет делить только резисторы с конденсаторами. Микросхемы не получится (нет у них точности).

Отчего же. Просто у микросхем по другому параметру. У логики, например, ДТЛ, ТТЛ, HC, AC, ACT.

То есть для каждой группы делится свое. От коров-удойность, от лошадей быстрота :)

Идея только в ускорении фильтрации?

Видимо, для этого лучше подходят типовые наборы фильтров, нежели такая странная классификация.

Фильтрация замечательно. Но ее надо настраивать. В общем сейчас у меня только так. Как правило 3-4 характерных символа и список уже помещается на экране. Но для больших баз этого мало

Конечно, я уже говорил, что разное деление должно существовать параллельно.

Вот и замечательно. Главное, чтоб база это разрешала и поддерживала

[vitan 2]

Напрягают. Каждый раз вводить фильтр. Обычно в каждом проекте один типоразмер

Ну... Вы предлагаете вместо этого каждый раз выбирать новую классификацию? Ровно столько же движений мышкой.

Да и про один типоразмер - весьма спорное утверждение.

 

Отчего же. Просто у микросхем по другому параметру. У логики, например, ДТЛ, ТТЛ, HC, AC, ACT.

Естественно, я имел ввиду - по параметрам. Это и есть именно то, что я показал на скриншоте. Но тау говорит, что для определенных категорий компонентов нужна другая классификация. Например, для резистров и конденсаторов - по корпусам и точностям.

 

Я не согласен именно с подходом, когда одни компоненты классифицируются по одному признаку (резисторы - по корпусу, например), а другие - по другому (по точности микросхемы не поделишь).

Вместо этого я предлагаю использовать несколько классификаций, причем каждая будет распространяться на все компоненты. А для особенных случаев частого использования фильтров сделать предварительно настроенные наборы фильтрации.

 

Для удобства пользования (чтобы не вводить сто раз фильтры) предлагаю сделать возможность юзеру задавать типовые наборы для фильтров. По крайней мере классификация не должна от этого страдать.

В САПРе наверняка нельзя задать сразу (одним движением) несколько условий для поиска. Поэтому и типовые наборы фильтров тоже в САПРе работать не будут, максимум - в веб-клиенте. Но вот, сгенерировать по-быстрому библиотеку (в виде текстового файлика), озаглавив ее по имени набора фильтров, можно легко.

Например, юзер хочет поработать с резисторами 0603. Он заходит в веб-клиент, выбирает библиотеку резисторов, применяет к ней типовой набор фильтров под названием "вывести резисторы 0603". Сервер исполняет запрос SELECT * from resistors where package=0603 и выдает результат в окно браузера. Юзер нажимает кнопочку "сгенерить локальную библиотеку" и у него открывается диалог сохранения. Он указывает путь и получает CSV-файл под названием "резисторы 0603.csv". Подключает его к САПР (точнее, источник ODBC у него уже был настроен, просто обновляются данные) и все.

Вот так я вижу.

[Uladzimir 96]

Ну... Вы предлагаете вместо этого каждый раз выбирать новую классификацию? Ровно столько же движений мышкой.

Ну в принципе оно так. Ни сила привычки и костность мышления

Да и про один типоразмер - весьма спорное утверждение.

О нет. Как раз типоразмер присутствует во всех компонентах, которые устанавливаются на плату, и их посадочные места весьма даже классифицируются.

Вопрос в другом. Для резисторов, конденсаторов это актуально, так как выпускаются они во десятках типоразмеров. Чего не скажешь про микросхемы. Там раз, два, три и обчелся.

Естественно, я имел ввиду - по параметрам. Это и есть именно то, что я показал на скриншоте. Но тау говорит, что для определенных категорий компонентов нужна другая классификация. Например, для резистров и конденсаторов - по корпусам и точностям.

 

Я не согласен именно с подходом, когда одни компоненты классифицируются по одному признаку (резисторы - по корпусу, например), а другие - по другому (по точности микросхемы не поделишь).

Вместо этого я предлагаю использовать несколько классификаций, причем каждая будет распространяться на все компоненты. А для особенных случаев частого использования фильтров сделать предварительно настроенные наборы фильтрации.

Давайте введем виды. Очень сложно делать классификацию насекомых, по аналогии с классификацией теплокровных.

У них одно общее-- они все твари божьи :)

Формально то, что вы предлагаете иметь несколько классификаторов и есть деление на более общие группы

В САПРе наверняка нельзя задать сразу (одним движением) несколько условий для поиска. Поэтому и типовые наборы фильтров тоже в САПРе работать не будут, максимум - в веб-клиенте. Но вот, сгенерировать по-быстрому библиотеку (в виде текстового файлика), озаглавив ее по имени набора фильтров, можно легко.

Например, юзер хочет поработать с резисторами 0603. Он заходит в веб-клиент, выбирает библиотеку резисторов, применяет к ней типовой набор фильтров под названием "вывести резисторы 0603". Сервер исполняет запрос SELECT * from resistors where package=0603 и выдает результат в окно браузера. Юзер нажимает кнопочку "сгенерить локальную библиотеку" и у него открывается диалог сохранения. Он указывает путь и получает CSV-файл под названием "резисторы 0603.csv". Подключает его к САПР (точнее, источник ODBC у него уже был настроен, просто обновляются данные) и все.

Вот так я вижу.

В фильтре в AD можно. Но это сложно долго не удобно, так как он перебирает все библы. Соответственно им не пользуются. Непосредственно в панели библиотек -нельзя. Поэтому TAY и хотел видеть уже отдельно. Формально просто выбирается нужная библиотека и ничего отбирать и фильтровать не нужно.

 

Тут еще вопрос в другом. AD указывает откуда взят компонент и если это база-- из какой таблицы.

Соответственно может обновить параметры, сформировать BOM и т.п.

Формально "резисторы 0603.csv" это одна библиотека с одной таблицей. Но библиотека динамическая!!! Она каждый раз регенерируется. Еще вопрос будут ли обновлятся компоненты.

Наверное будут. Но возможны и потери

 

Подключает его к САПР (точнее, источник ODBC у него уже был настроен, просто обновляются данные) и все.

Вот тут еще больше телодвижений мышкой.

так при куче таблиц я подключил один раз базу и все имею.

Теперь вставил резистор- хорошо. Нужно конденсатор-- сначала надо пере подключить новую базу ввиде CSV

Хочу только резисторы )0805 Тоже:

1 Запрос на общую на выборку

2. Заход и подключения выборки

3. и наконец в панель за компонентом.

Первые 2 пункта уж больно костылем выглядят

[vitan 2]

О нет. Как раз типоразмер присутствует во всех компонентах, которые устанавливаются на плату, и их посадочные места весьма даже классифицируются.

Ну я же не спорю, что надо классифицировать посадочные места. Я как бы даже за... :)

Я против классификации компонентов по посадочным местам. Видите разницу?

 

Вопрос в другом. Для резисторов, конденсаторов это актуально, так как выпускаются они во десятках типоразмеров.

Для них это актуально, я думаю, не поэтому, а потому что есть нужда их выбирать по параметрам. А параметров у них, действительно, много. Причем корпус - это всего лишь один из параметров.

Я, например, очень часто вообще не задумываюсь о корпусе, когда ищу резистор. Мне часто важнее что-то другое (номинал и точность, например). Корпус я редко ввожу как критерий отбора.

 

Чего не скажешь про микросхемы. Там раз, два, три и обчелся.

Вот те раз! Вы видели сколько корпусов в том же калькуляторе? :)

 

Давайте введем виды.

Давайте! :) Только что такое виды и чем они отличаются от типов? Тут важно даже не договориться о терминах, а поянть именно признак, по которому происходит деление. В моей классификации таким признаком является набор параметров компонентов. При этом некоторые параметры наследуются от родителей.

Но тут Вы справедливо упомянули о прблемах со сросшимися ветками, после чего я предложил упростить видение путем введения нескольких классификаций.

И мое предложение - это никак не то, что вы говорите:

Формально то, что вы предлагаете иметь несколько классификаторов и есть деление на более общие группы

Более общие группы должны стоять выше по дереву, а я говорю про совершенно независимое второе (третье, четвертое) деление. И для него я предлагаю найти признак. По этому признаку должны будут делиться _все_ компоненты, поэтому я считаю, что корпус, точность и т.п. не годятся для этого.

Вот, к примеру, делить элементы на пассивные и активные мне кажется неплохо. Только видов как-то маловато, всего два...

На тех же digikey и т.п. есть более развернутые варианты, но я уже говорил, что все они страдают от того, что признаков там несколько. Вот и предлагаю подумать на признаками. Если надо (лично я пока особой нужды не испытывал).

 

 

В фильтре в AD можно. Но это сложно долго не удобно, так как он перебирает все библы. Соответственно им не пользуются. Непосредственно в панели библиотек -нельзя.

Т.е. при рисовании схемы нельзя? Это ожидаемо.

 

Тут еще вопрос в другом.

...

Но библиотека динамическая!!!

...

так при куче таблиц я подключил один раз базу и все имею.

...

Теперь вставил резистор- хорошо. Нужно конденсатор-- сначала надо пере подключить новую базу ввиде CSV

Да. Здесь есть над чем подумать. Надо, чтобы было удобно пользоваться. Я попробую еще помучить текстовые файлы, может, в них получится засунуть несколько библиотек в один файл. А, может быть, как-то по-другому можно будет это решить, но мне бы очень хотелось это сделать именно в рамках текстовых файлов.

 

UPD. Помучил. Никаких проблем не вижу. Одна таблица - один файл. Несколько файлов в каталоге образуют один DSN (источник данных). При обновлении данных ничего переподключать не надо. Все прекрасно. :)

[Uladzimir 96]

Ну я же не спорю, что надо классифицировать посадочные места. Я как бы даже за... :)

Я против классификации компонентов по посадочным местам. Видите разницу?

Вижу. Я тоже против. это частный случай.

Но как подкласс в третьем (четвертом) колене -- отчего же и нет.

Причем корпус - это всего лишь один из параметров.

Я, например, очень часто вообще не задумываюсь о корпусе, когда ищу резистор. Мне часто важнее что-то другое (номинал и точность, например). Корпус я редко ввожу как критерий отбора.

Ну да. Первым номинал. Вторым, если это лишь бы резистор- корпус.

Если прецизионный-- то сначала точность по разбросу и температурный уход, потом номинал а корпус- в последнюю очередь.

Короче всегда ищется в первую очередь по КРИТИЧЕСКОМУ параметру. А уж при большом выборе- остальные опции

Цитата(Владимир @ Oct 23 2010, 22:32) Чего не скажешь про микросхемы. Там раз, два, три и обчелся.

Вот те раз! Вы видели сколько корпусов в том же калькуляторе?

Я не про то. Резисторов с номиналом 1 килоОм куча корпусов, еще в догонку

Найдите процессор-- он один. выпускается в 1 корпусе иногда в 2-3. В 4 это уже такая редкость

Тоже про логику. Корпусов то море, но зашивают конкретную микросхему в раз два, как я и писал

Давайте! Только что такое виды и чем они отличаются от типов?

Ну давайте.

Вы сами предлагали.

1 уровень. Вид. То что по ГОСТ 1 буквой обозначается. Например D

микросхема

2 уровень. Класс. То что по ГОСТ 2 буквами обозначается. Например DA Микросхема аналоговая

3. Подкласс. Микросхемы цифровые программируемые

Микросхемы циaровые TPROM

Но и так далее

Более общие группы должны стоять выше по дереву, а я говорю про совершенно независимое второе (третье, четвертое) деление. И для него я предлагаю найти признак. По этому признаку должны будут делиться _все_ компоненты, поэтому я считаю, что корпус, точность и т.п. не годятся для этого.

Вот, к примеру, делить элементы на пассивные и активные мне кажется неплохо. Только видов как-то маловато, всего два...

На тех же digikey и т.п. есть более развернутые варианты, но я уже говорил, что все они страдают от того, что признаков там несколько. Вот и предлагаю подумать на признаками. Если надо (лично я пока особой нужды не испытывал).

Ну вот выше я привел скажем основной классификатор. За основу ГОСТ

Можно брать классификатор digikey и это и будет тем параллельным классификатором.

Может надо и держать не один, а несколько классификаторов.

То, что удобно найти на Digikey иногда плохо найти альтернативу на Elpha и так далее.

Просто иметь в базе номер по классификатору ГОСТ, Digikey или иного типа

Да. Здесь есть над чем подумать. Надо, чтобы было удобно пользоваться. Я попробую еще помучить текстовые файлы, может, в них получится засунуть несколько библиотек в один файл. А, может быть, как-то по-другому можно будет это решить, но мне бы очень хотелось это сделать именно в рамках текстовых файлов.

 

UPD. Помучил. Никаких проблем не вижу. Одна таблица - один файл. Несколько файлов в каталоге образуют один DSN (источник данных). При обновлении данных ничего переподключать не надо. Все прекрасно.

Ну это я может и зря волну поднимаю. Ну лучше поднять, чем потом ею накроет :)

Я тоже думаю будет работать.

Единственно больное место-- размер CSV файла. Когда он раздуется до больших размеров- точно будут проблемы.

Но это отдаленная перспектива. И я думаю система фильтров при подготовке будет большая. Так чтобы получать оптимальный по размеру файл, отсекая лишнее

[vitan 2]

1 уровень. Вид. То что по ГОСТ 1 буквой обозначается. Например D

микросхема

2 уровень. Класс. То что по ГОСТ 2 буквами обозначается. Например DA Микросхема аналоговая

3. Подкласс. Микросхемы цифровые программируемые

Микросхемы циaровые TPROM

Вижу. Я тоже против. это частный случай.

Но как подкласс в третьем (четвертом) колене -- отчего же и нет.

У меня есть сомнения по поводу ГОСТа. Здесь просматривается деление по первым буквам рефдеса. А это, как мы сказали, подходит для классификации УГО, а не компонентов.

Вот, к примеру, микросхему физического уровня Ethernet в какой класс прикажете отнести: аналоговые или цифровые? Это раз.

Про пассив интересно, какое там может быть деление... Короче, не вижу системности, отличительного признака в делении.

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

В моей классификации для этого служит набор параметров компонента. Юзер смотрит, как Вы и сказали:

Короче всегда ищется в первую очередь по КРИТИЧЕСКОМУ параметру. А уж при большом выборе- остальные опции

и кладет компонент туда, где есть этот параметр. Если он есть в нескольких местах, то смотрит на остальные параметры и на описание и название каталога.

А как быть с этим ГОСТом я плохо понимаю.

 

Вы можете привести полную классификацию, а не только пример для микросхем? Чтобы предметно разговаривать.

 

Еще скажу, что у меня, например, деление по первым буквам рефдеса есть для УГО, но оно очень упрощено. Нет, например, букв DA и DD. Все микросхемы принудительно обозначаются как D. Очень помогает, знаете ли.

 

Единственно больное место-- размер CSV файла. Когда он раздуется до больших размеров- точно будут проблемы.

Но это отдаленная перспектива. И я думаю система фильтров при подготовке будет большая. Так чтобы получать оптимальный по размеру файл, отсекая лишнее

Я думаю, можно этого не бояться. Вот у меня база не маленькая, но т.к. библиотек много, то в каждой не так много строк. Хорошая классификация в этом деле поможет.

[Uladzimir 96]

У меня есть сомнения по поводу ГОСТа. Здесь просматривается деление по первым буквам рефдеса. А это, как мы сказали, подходит для классификации УГО, а не компонентов.

Вот, к примеру, микросхему физического уровня Ethernet в какой класс прикажете отнести: аналоговые или цифровые? Это раз.

У меня тоже. Тем паче по ГОСТ я почти и не работаю. Но это кок способ построения одной из классификаторов.

У меня кучи вопросов и по другим классификаторам. Я уже писал. Порой находишь нужный компонент там, где никак не ожидал.

Да и теперь микропроцессор с АЦП это цифровая или аналоговая?.

Поэтому в части микросхем естественно деление на

FGPA

RAM

MC

...

меня более устраивает. Именно поэтому я за несколько классификаторов.

Кстати "физического уровня Ethernet" я бы отнес к дереву

IC>>Interface>>Ethernet

Про пассив интересно, какое там может быть деление... Короче, не вижу системности, отличительного признака в делении.

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

В моей классификации для этого служит набор параметров компонента. Юзер смотрит, как Вы и сказали:

Да про пассив примерно та же ситуация, что и с обозначениями D (DA DD). Все это условно

Вы можете привести полную классификацию, а не только пример для микросхем? Чтобы предметно разговаривать.

Ну в принципе пора уже переходить к этому предмету. Вопрос назрел.

Опустим только слово "полную", начнем с начальной :)

Я думаю, можно этого не бояться. Вот у меня база не маленькая, но т.к. библиотек много, то в каждой не так много строк. Хорошая классификация в этом деле поможет.

Я не об этом. Для пользователя формируется на основе запросов отдельный CSV по многочисленным (пусть и маленьким) CSV общей базы для классов и подклассов.

Так вот этот сформированный может быть большим

[vitan 2]

У меня кучи вопросов и по другим классификаторам. Я уже писал. Порой находишь нужный компонент там, где никак не ожидал.

Вот именно! Я как раз с этой точки зрения и прошу посмотреть на мое творение. Сильно надеюсь, что оно от этих недостатков вылечено.

 

Да и теперь микропроцессор с АЦП это цифровая или аналоговая?.

Поэтому в части микросхем естественно деление на

FGPA

RAM

MC

Вот у меня почти так и есть. :)

...

 

Кстати "физического уровня Ethernet" я бы отнес к дереву

IC>>Interface>>Ethernet

В реальности она у меня лежит в IC/Communications

 

Ну в принципе пора уже переходить к этому предмету. Вопрос назрел.

Опустим только слово "полную", начнем с начальной :)

Шарик на Вашей стороне. :)

 

Я не об этом. Для пользователя формируется на основе запросов отдельный CSV по многочисленным (пусть и маленьким) CSV общей базы для классов и подклассов.

Так вот этот сформированный может быть большим

Ммм... Как же это "не об этом"? Вроде, как раз об этом... Мы собираемся динамически генерить юзеру файлы в зависимости от того, какую он выбрал классификацию, и какую группу компонентов он хочет поюзать в этой классификации. Содержимое группы будет сформировано запросом. Так вот, я говорю, что если групп (классов) много, то в каждом классе будет не так и много компонентов.

А что означают слова

по многочисленным (пусть и маленьким) CSV общей базы

?

Вы хотите и общую БД в текстовых файлах хранить? Я сильно против.

[Uladzimir 96]

Шарик на Вашей стороне. :)

Чуть позже, когда свободней буду

Ммм... Как же это "не об этом"? Вроде, как раз об этом... Мы собираемся динамически генерить юзеру файлы в зависимости от того, какую он выбрал классификацию, и какую группу компонентов он хочет поюзать в этой классификации. Содержимое группы будет сформировано запросом. Так вот, я говорю, что если групп (классов) много, то в каждом классе будет не так и много компонентов.

А что означают слова?

Вы хотите и общую БД в текстовых файлах хранить? Я сильно против.

 

Об этом. Я и писал об этом. Если "динамически генерить юзеру файлы" значит меняется структура подключенной базы. Следовательно нужно реконнестить подключение. Это будет напрягать еще больше. Все пойдут по пути наименьшего сопротивления.

Следовательно будут формировать максимально общий запрос, который и даст (как из кинофильма, бац, а тут вторая смена :) ) здоровенный по объему файл CSV.

[vitan 2]

Об этом. Я и писал об этом. Если "динамически генерить юзеру файлы" значит меняется структура подключенной базы. Следовательно нужно реконнестить подключение.

Да нет же! Источник данных (DSN) один раз настраивается на каталог с файлами CSV и все. Если меняется структура имеющихся файлов, или их содержимое, или добавляется новый файл, то не надо ничего переподключать. Надо только обновить в САПР либу и все. В менторе это выглядит как повторный выбор. Или выбрать новую либу. Список доступных либ САПР читает в момент обращения к DSN. Разве альтиум делает не так?

[Uladzimir 96]

Да нет же! Источник данных (DSN) один раз настраивается на каталог с файлами CSV и все. Если меняется структура имеющихся файлов, или их содержимое, или добавляется новый файл, то не надо ничего переподключать. Надо только обновить в САПР либу и все. В менторе это выглядит как повторный выбор. Или выбрать новую либу. Список доступных либ САПР читает в момент обращения к DSN. Разве альтиум делает не так?

Да здесь также. Повторный выбор или реконнект.

Но для этого нужно держать открытым файл DbLib. Перекидываться в это окно и дважды кликать кнопку реконнекта. И так какждый раз, при формировании нового запроса, то есть класса компонентов.

Это достает. При создании схемы постоянно нужны кондесаторы, резисторы, диоды именно в том порядке, как удобно создавать схему.

Конечно можно набросать резистор, потом конденсаторов потом. Но главное ведь удобство пользования.

Возможно и при таком подходе проблем нету. Нужно просто написать скрипт, который реконнектит при новом запросе и все.

Но пока его то нету

[vitan 2]

Да здесь также. Повторный выбор или реконнект.

Но для этого нужно держать открытым файл DbLib. Перекидываться в это окно и дважды кликать кнопку реконнекта. И так какждый раз, при формировании нового запроса, то есть класса компонентов.

Это достает.

Я никак не пойму. Что, в альтиуме всегда открывается только одна библиотека?

Вы можете сделать скриншотик наподобие того, что я привел в посте 88 ?

Во всех САПР, что я видел, есть возможность выбирать библиотеку без переконнекта.

 

Получается, файл DBLIB всегда коннектится только к одной библиотеке (точнее, к одной таблице)? Вообще-то при использовании ODBC любая программа должна видеть _все_ таблицы, которые предоставляет DSN.

Вот, в моем скриншоте слева видно, что САПР читает все таблицы в моем DSN (там выпадающий список открытый). Как только я его выберу, САПР прочтет содержимое таблицы со всеми параметрами. У Вас не так что ли???