|
||
| Правила | Регистрация | Пользователи | Сообщения за день | | Поиск | | Справка по форуму | Файлообменник | |
|
Поиск в этой теме |
|
||||
Регистрация: 27.02.2008
Сообщений: 140
|
Цитата:
Цитата:
Цитата:
Последний раз редактировалось Nikolay 2, 18.05.2009 в 08:43. |
|||
|
||||
Nikolay 2, для начала нужно сделать блок на какую-нибудь часто используемую группу кабелей. Можно по конкретному производителю.
Выбираем производителя, смотрим что он выпускает, составляем список его продукции и запихиваем в блок. О лиспе поговорим, когда блок будет готов. Поскольку в блоке содержется вся информация о кабеле, который обозначен указанными типами линий, в слое, где лежит этот блок, то сформировать и проставить обозначения в модели - пустяк. Цитата:
Цитата:
Цитата:
Про вертикальные решения ничего сказать не могу. У меня в модели не только кабеля, но и трубы и арматура и насосы и пр. А жить ведь как-то надо. |
||||
|
||||
Регистрация: 27.02.2008
Сообщений: 140
|
Supermax
Цитата:
|
|||
|
||||
КИПиА Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
|
Supermax
>>Поскольку в блоке содержется вся информация о кабеле, который >>обозначен указанными типами линий, в слое, где лежит этот блок, то >>сформировать и проставить обозначения в модели - пустяк. Блоки играют роль только "удобного" инструмента ввода данных в программу? >>Если программа будет заточена на промер каждого отрезка >>указанного типа линий, то она сама все сделает. Нужно не только получить общую длину линий в слое, а сопоставить (поли)линию на плане с блоком на схеме подключений и проставить в этот блок ее длину. такчто без добавления дополнительных свойств в (поли)линии на планах не обойтись. >>Тут тоже нужна программа, которая позволяет >>в 3D полилинии проставлять Z и добавлять вертикальные участки. Если человек проектирует на 2д подоснове, то это неудобно, нужно обойтись условной длиной добавляемой к измереной длине кабелей. ее тоже нужно гдето хранить >>Все элементы модели имеют значение последовательности создания. не знаю как сейчас, но раньше сохранность последовательности создания примитивов в автокаде не гарантировалась при дальнейшем редактировании чертежа Последний раз редактировалось zamtmn, 18.05.2009 в 12:35. |
|||
|
|||||
Регистрация: 27.02.2008
Сообщений: 140
|
zamtmn
Цитата:
Цитата:
Цитата:
Цитата:
|
||||
|
||||
zamtmn,
Цитата:
Тут, я вижу, упорно пытаются именно кабелю приписать адреса подключения, но напомню, что если кабель многожильный,то с одной строны может быть один прибор, а с другой много + еще клеммы всякие. Вы запутаетесь в блоках. Один блок с 20-тью атрибутами, другой с 10-тью, пятый с 30-тью. Таблицу соединений нужно составлять опросив приборы. Вот к ним и надо делать атрибуты с номерами кабеля и их жил. Кабель - это материал. Когда его сделали на заводе, еще не знали, кто и для чего его будет использовать. А блок с данными на кабель - его свойства и не более (я так считаю). |
||||
|
||||
Добавлю.
Вот у вас 150 линий связи, каждая выполнена каким-то типом кабеля. Так получилось, что все 150 кабелей одинаковой марки. Если в блок, который символизирует марку кабеля входит еще и адреса подключений, то Вам придется копировать этот блок 150 раз. и все линии должны быть разные, либо по цвету, либо по типу линий. Это не удобно. Думаю, надо сделать отдельные блоки-маркеры, с указанием адресов подключения, а привязку к линии делать с помощью атрибутов с формулами. Программно можно прочесть указатель на линию, с которой берется длинна для атрибута и посмотреть в каком слое она лежит. Найти в этом слое блок-бирку "привязанную" к этой линии и считать данные на кабель. В блоке-бирке даже номера по схеме не должно быть. А блок-маркер можносделать в виде разъема. |
||||
|
||||
КИПиА Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
|
>>Блок это не инструмент ввода данных в программу, а бирка на конкретных типах линий (цвет линий тоже иожно использовать как идентификатор кабеля). В бирке свойствами устанавливаются свойства кабеля, а атрибут "метод расчета" - проволочка, с помощью которой эта бирка вешается на кабель. В атрибутах блока есть не только "Позиция в спецификации", но и "номер по схеме". Кабель, как известно, одним концом подключается к одному прибору, а другим - к другому.
А если кабелей 500? на каждый вставлять блок? и ждать когда кончится разумное количество уникальных слоев или типов линий? >>Тут, я вижу, упорно пытаются именно кабелю приписать адреса подключения, но напомню, что если кабель многожильный,то с одной строны может быть один прибор, а с другой много + еще клеммы всякие. Вы запутаетесь в блоках. Один блок с 20-тью атрибутами, другой с 10-тью, пятый с 30-тью. если кабелей 2, то можно сделать всяко, если больше то дополнительные блоки-слои-типылиний причинят больше неудобств чем пользы. кстати кабель соединяет 2 прибора в общем случае. бывают шлейфовые подключения, но фактически это уже разные кабели)) >>Таблицу соединений нужно составлять опросив приборы. Вот к ним и надо делать атрибуты с номерами кабеля и их жил. Кабель - это материал. Когда его сделали на заводе, еще не знали, кто и для чего его будет использовать. А блок с данными на кабель - его свойства и не более (я так считаю). Опрашивать можно хоть приборы хоть кабели. а лучше и то и другое. про жилы кабеля я ниче не говорю, это другой разговор. да, материал, но каждый кабель имеет свои условия прокладки, длину и т.д. это всё в проекте должно быть учтено, а не просто строка в спецификации "кввг - 5км" >>то Вам придется копировать этот блок 150 раз а вам придется 300 раз редактировать свойства устройств которые этот кабель соединяет. пысы. Я не предлагаю на каждый кабель вставлять блок, а говорю что без информации о каждом отрезке кабеля не обойтись. Где ее хранить - другой вопрос. имхо лучше в расширенных данных примитива имитирующего кабель Последний раз редактировалось zamtmn, 18.05.2009 в 19:06. |
|||
|
||||
Цитата:
Кто мешает в модели держать открытую, легко читаемую таблицу соединений? Не для выпуска листа документации, а для служебных целей. Если в такой таблице есть несколько М-текстов с полями, которые указывают на нужную линию и нужные объекты (приборы) - вот тебе и связь. Обрабатываем такую таблицу и делаем на основе данных, заключенных в ней любые документы. В такой таблице и на блок-бирку можно М-текстом указатель вставить, чтобы проге легче было его выискивать. Тогда вообще отпадает необходимость в привязке блока-бирки к линиям по типу или цвету линий. Читаем таблицу и в строке видим первый М-текст указывающий на нужную линию, второй - на блок-бирку, третий - на прибор №1 (контакт прибора), четвертый - на прибор №2 (или конктретный контакт) и т. д. Все легко редактируется, копируется, читается и понятно даже полным блондинкам. Блок-бирка - один на все кабели такого типа, просто он в таблице связан с кучей М-текстов. Чтобы посчитать общий расход кабеля достаточно его найти и обработать его "метод расчета". Короче, я за служебную таблицу, а не за расширенные данные. |
||||
|
||||
КИПиА Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
|
>>Если пишется программа для всех, а не только для себя, любимого, то надо очень тщательно все продумывать. Записывать данные в расширенные данные примитива - упремся в формат таких записей. Кончится тем, что созданную тобою модель может посчитать только созданная тобою же программа, а создать такую же модель другому человеку будет не легко. Формат данных - это самая гадкая штука, на которой погибло очень много хороших идей. Чем меньше мы используем расширенные данные, тем лучше.
Если пишем не только для себя - важно не только продумывать как храним, а также хорошенько все документировать. По вашим блокам просто так тоже не каждый поймет для чего они. хорошо документированая сложная система - ничуть не сложнее простой недокументированной. Невозможно сложную программу написать оперируя "простыми" и "понятными" данными. Кто мешает в модели держать открытую, легко читаемую таблицу соединений? Не для выпуска листа документации, а для служебных целей. Если в такой таблице есть несколько М-текстов с полями, которые указывают на нужную линию и нужные объекты (приборы) - вот тебе и связь. Обрабатываем такую таблицу и делаем на основе данных, заключенных в ней любые документы. В такой таблице и на блок-бирку можно М-текстом указатель вставить, чтобы проге легче было его выискивать. Тогда вообще отпадает необходимость в привязке блока-бирки к линиям по типу или цвету линий. Читаем таблицу и в строке видим первый М-текст указывающий на нужную линию, второй - на блок-бирку, третий - на прибор №1 (контакт прибора), четвертый - на прибор №2 (или конктретный контакт) и т. д. Все легко редактируется, копируется, читается и понятно даже полным блондинкам. Блок-бирка - один на все кабели такого типа, просто он в таблице связан с кучей М-текстов. Чтобы посчитать общий расход кабеля достаточно его найти и обработать его "метод расчета". Короче, я за служебную таблицу, а не за расширенные данные. Никто не мешает. но возникают большие головняки - поддерживать эту таблицу в актуальном состоянии. У меня был такой подход, пришлось отказаться и генерировать таблицу соединений-подключений только тогда когда она нужна. на словах всё вроде просто и понятно. когда начинаешь делать - всё сложнее)) |
|||
|
||||
Вообще-то я сторонник того, чтобы элемент нес в себе все необходимые данные, в частности "приписанные свойства" и атрибуты. Под "приписанными свойствами" я подразумеваю такие свойства, которые принадлежат не графическому примитиву, а той физической сущности, которую он изображает. Я динамические блоки взял за основу хранения данных об изделиях и материалах именно поэтому.
Расширенные данные тоже своего рода "приписанные свойства", но я их использую для хранения значений видимости по группам. У меня прога, которая формирует много вариантов видимости модели (как в динамическом блоке) и я выбирая первый, или второй, или третий и т.д. указатель в расширенных данных, устанавливаю данному элементу параметр видимости. Расширить свой формат расширенных данных для хранения "приписанных свойств" можно, но тогда каждая линия в модели превратится из примитива в сложный объект и стереть ее и прорисовать заново будет уже не просто. Хотя с таблицей тоже самое будет. Может лучше поднапрячься и сделать распознавание места соединения начала и конца 3D полилиний с конкретными точками на приборах? Ведь по идее, только те точки, которые имеют одинаковые координаты X, Y, Z в пространстве модели и являются местом соединения провода с проводом, провода с клеммой и т.п. Программно вполне реализуемо. |
||||
|
||||
КИПиА Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
|
Другой вариант - тыкаем в линию, узнать что это за "кабель". если линия хранит в себе эту информацию - всё ок, если нет нужно шарить по таблицам, вроде не критично, но всеравно не очень правильно.
>>Может лучше поднапрячься и сделать распознавание места соединения начала и конца 3D полилиний с конкретными точками на приборах? у меня это есть, информация о подключениях строится динамически при редактировании кабелей |
|||
|
||||
Регистрация: 27.02.2008
Сообщений: 140
|
Довольно давно пробовал подключить к Каду базу данных Access (она есть у меня в составе программы для составления спецификаций), подключилась, затем выбираю любой примитив (блок, созданный просто для удобства вставки "созать блок" без атрибутов и всего прочего) на чертеже присваиваю ему значение из базы данных и теперь при наведении на него мышкой подсвечивается что это, например, кабель КВВГ или датчик давления WIKA и пр. Как дальше все прикрутить, ну типа передать данные в таблицу (спецификацию) не пойму (в каде не очень продвинут). Может быть в эту сторону порыться?
|
|||
|
||||
Считаю необходимым разделить задачи.
Я занимаюсь моделированием строительных процессов и для этого мне надо создавать "модель тела" и "модель действий". "Модель тела" я создаю в Автокаде и от нее мне требуется точное количество и параметры всех ее элементов. Такие данные, как, кто, с кем соединен и для чего - тут не нужны, хотя где-то это тоже должно быть. Все мои потуги направлены на специфицирование модели в зависимости выбора условий (этап строительства, участок строительства, вид работ по разделам проекта и т.п.). Здесь же, как я понимаю, идет базар о кабельных журналах и увязке элементов друг с другом по факту их совместной деятельности. Единственное что объединяет эти две задачи, это то, что и там, и там все делается на основе модели объекта, выполненной в масштабе 1:1. Правда тут и про геоподоснову тоже пару слов есть, но поскольку она хоть и 2D, но 1:1 будем считать, что она тоже модель объекта. Хочу также заметить, что таблицы соединений и принципиальные схемы хоть и показывают кабели, но их длинна там не соответствует действительности. Но зато там есть все данные о соединениях. По принципиальным схемам никто спецификцию не составляет. Только по монтажным. В кабельный журнал безусловно надо вносить длинну кабеля, но только после того, как кабель проложен в модели. А как он там прокладывается? - рисуем линию, определяем ее цвет, тип, слой; вешаем на нее блок-бирку; вешаем на нее блок-указатель для связи с кабельным журналом. С чем еще надо связывать? да больше не с чем. Блок-бирку видно? - видно. Блок-указатель для связи с кабельным журналом видно? - видно. Если убить линию, то блок-указатель потеряет с этим объектом связь (там полем М-текста связь установлена). Прога легко найдет такой потерянный блок-указатель. Если на линию не ссылается ни один блок-указатель, но эта линия привязана к блоку-бирке, то прога начнет ругаться и укажет вам, где вы пропустили блок-указатель. Мне блоки-указатели в модели не нужны, поэтому я их просто выключу. А вам они надо - вы их включите. Можно прогу написать так, что линию вы будете строить из под проги, а она автоматически будет создавать блоки-указатели и приписывать к блокам-биркам. Блоки-указатели можно в стороне группировать в кучку, чтобы модель не нагружать, и с помощью все той же проги, выделив блок-указатель, подсвечивать нужную линию в модели (и наоборот). С расширенными данными раз плюнуть забыть их в линию вставить или отредактировать. Их ведь не видно! По сути, поле М-текста связывает два примитива в одну группу и это по сути почти блок. В М-ткст можно вставить связь сразу на несколько линий или примитивов. |
||||
|
||||||||
Регистрация: 27.02.2008
Сообщений: 140
|
Supermax
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
|
|||||||
|
||||
Прежде, чем сесть за написание проги, надо создать пару-тройку блоков-бирок и блоков-указателей. Ведь состав свойств и атрибутов этих блоков имеет принципиальное значение для написания проги.
Цитата:
|
||||
|
||||||
Регистрация: 27.02.2008
Сообщений: 140
|
Supermax
Цитата:
Цитата:
zamtmn Цитата:
Цитата:
Цитата:
Последний раз редактировалось Nikolay 2, 20.05.2009 в 12:53. |
|||||
|
||||
Цитата:
Цитата:
Если вы "рисуете", а не моделируете, то ручками и калькулятором длины вычисляйте. Я, всякие умозрительные представления о компоновке, даже мысленно делать не хочу. Только 3D модель и ее развертки в окнах Layout. |
||||
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Нужно ли сгущение арматуры под колонной при наличии металлич | Aleks ManaeFF | Прочее. Программное обеспечение | 3 | 19.07.2007 12:02 |
Нужно ли показывать с спецификации болты, гвозди, анкеры? | Колян | Прочее. Архитектура и строительство | 9 | 14.09.2006 08:09 |
Дали задачку на плаксисе посчитать | rust-resisting | Прочее. Программное обеспечение | 1 | 25.03.2006 13:42 |
на какие ключи в реестре нужно дать полный доступ | stanislav | AutoCAD | 1 | 19.10.2005 20:40 |
Когда нужно утеплять стены подвала? | Колян | Конструкции зданий и сооружений | 15 | 02.10.2005 00:58 |