|
||
| Правила | Регистрация | Пользователи | Поиск | Сообщения за день | Все разделы прочитаны | Справка по форуму | Файлообменник | |
|
Поиск в этой теме |
|
||||
КИП, АСУ ТП, слаботочка Регистрация: 02.09.2010
Москва-Тюмень
Сообщений: 422
|
А кто что может сказать по поводу использования словарей чертежа? Там хранить данные вроде бы удобно. Хотя словари я еще никак не изучал.
МОжете рассказать или дать ссылку, что такое словари и есть ли к ним доступ через стандартный интерфейс Автокада (меню там может какой особенное)? Supermax идея иметь полилинию как отображение кабеля, и присвоить ей данные о кабеле - это здорово! Я ее обязательно буду воплощать в жизнь, но только не на плане трасс. Кабель - это не трубы. Мне не нужно пару сотен слоев, в которых будут изображены кабели. А по другому нельзя будет при необходимости увидеть трассу именно одного конкретного кабеля. Мое решение подходит целиком моим требованиям - все трассы хранятся где-либо (внешний файл, блок или может даже в словаре чертежа) в виде списков точек. При желании всегда можно увидеть любую трассу любого кабеля - она нарисуется по сохраненным данным. Это, как мне кажется, вполне легко и очевидно - но именно для такого плана трасс, какой есть у меня - см. внимательнее первый пост, я там описал что именно представляет мой план изначально - это чертеж с нанесенными на него линиями, обозначающими расположение кабельных эстакад на площадке, от объекта к объекту. И опять-таки по поводу автоматической трассировки - очень редко когда случается, что есть 2 возможный варианта, как провести кабель отобъекта А к объекту Б. Чаще всего это лишь 1 вариант (идет еще и от нормативки электриков - нельзя строить параллельные эстакады!). Пока утрясаю программы и функции, делаю хотя бы минимальную проверку ввода. Думаю, потом выложу все сюда, как результат наших дискуссий. Хотя все функции - это либо измененные под мои нужды либо вообще неизмененные коды, взятые с этого форума. Моя работа - это лишь написание главных управляющих функций каждой программы и сортировка прикладных функций по библиотекам. К моему сожалению, пока не могу найти бумажного варианта книги "САПР на базе Автокад", а скачанный электронный вариант как-будто специально (даже уверен, что именно специально :-) ) не содержит очень многих важнейших страниц Насколько я разобрался, списки с номером кабеля и набор точек трассы - это ассоциативный список, очень удобная вещица для дальнейшего использования и обработки, а также для сортировки. А пока для начала сделал несколько кнопочек для редактирования текста (и МТекста) по одному щелчку на нем, а также для массового редактирования. Ну, и в благодарность помогающим мне, решил вставлять такой код в программки :-) Код:
Последний раз редактировалось Frigate, 28.09.2010 в 13:18. |
|||
|
||||
КИП, АСУ ТП, слаботочка Регистрация: 02.09.2010
Москва-Тюмень
Сообщений: 422
|
В общем, на данном этапе переделал под себя и оттестировал код для рисования всего и вся при помощи легковесной линии :-)
Естественно, что в основе своей этот код - честно сподсмотренныйй в различных листингах на форуме и сайте ru_CAD. Но пока не протестировал полностью и не понял все строчки кода, не вводил эту функцию в состав своих программ. Вот она, прошу строго не судить :-) Код:
Пока всю отработанную уже и протестированную библиотеку храню в .doc файле, вполне удобно организованном при помощи оглавления. Вот такое пока содержание: Цитата:
И у меня вопрос есть. Если можно, посоветуйте, как сделать: надо вставлятьТЕКСТ или МТЕКСТ в рамку размером 5 на 10 мм. Чтобы, если не быдет влезать в рамку, коэф-т сжатия текста уменьшился. Как это реализовать? Последний раз редактировалось Frigate, 29.09.2010 в 12:33. |
|||
|
||||
Moderator
LISP, C# (ACAD 200[9,12,13,14]) Регистрация: 25.08.2003
С.-Петербург
Сообщений: 39,833
|
Во-первых, я бы все же задумался о применении http://autolisp.ru/2009/10/21/lisp-overloading/
Во-вторых, http://dwg.ru/search.php?zone=1&mod=2&sName=ruCAD&type= никуда не делся. В-третьих, вот мой вариант создания lwpolyline: Код:
P.S. Код тестировался прежде всего для мировой системы координат, в пользовательских вроде бы работал нормально для версий 2005 и 2006. Дальше не гонял.
__________________
Моя библиотека lisp-функций --- Обращение ко мне - на "ты". Все, что сказано - личное мнение. |
|||
|
||||
Thượng Tá Quân Đội Nhân Dân Việt Nam Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381
|
Вот мой рабочий вариант создания полилиний:
Код:
В этом варианте аргументов меньше, чем у Алексея, но для практических целей ничего дополнительного в сотнях программ и не понадобилось. |
|||
|
||||
КИП, АСУ ТП, слаботочка Регистрация: 02.09.2010
Москва-Тюмень
Сообщений: 422
|
Алексей, спасибо большое за ссылки!
Очень хотелось этот просмотрщик. Уже хотел сам в Visual Studio такой писать. В WORD никак не смог сделать предпросмотр ShaggyDoc, я с Вами согласен, что нужен обработчик ошибок. Но на все нужно время. Я пока не начал серьезно разбираться с алгоритмом облработки ошибок, лишь использовал Ваши функции для выбора объекта (entsel и entsel by type). Я такой человек, что не могу использовать что-то , не понимая полностью сути работы этого "что-то". Код Ваш и Алексея еще пока сложен для меня. Но я учусь и быстро Сейчас я понимаю, что аргументов в моей функции вполне достаточно, чтобы иметь возможность дальше развить ее, как и другие функции, но УЖЕ СЕЙЧАС иметь возможность ее применять и тестировать в разных рабочих ситуациях. Надеюсь, когда я вернусь через несколько недель после командировки, вы не сочтете за труд пркомментировать некоторые строки своего кода? Пока об этом не прошу, ибо для этого надо сначала самому поразбирться в нем и сформулировать чтко, что не ясно. Кстати, спасибо за примеры - теперь знаю, что можно не менять реальное число аргументов, а при дополнении функции просто можно запрашивать сразу несколько аргументов списком И список может быть любым - может и сключать и не включать в себя разные элемнты, которые для функции просто будут равны нулю либо nil. А сейчас хочу попросить: 1) объяснить, где у Lightweightline параметр WIDTH? Width сегмента есть, а где глобальная ширина? Что-то ее не нашел в описалове объекта. 2) как, интересно, во многих стндартных функциях организован алгоритм, что можно опускать какой-то аргумент? Ведь если внутри функции аргумент и может быть равным Nil, то при инициализации функции nil задавать нельзя, только 0... Последний раз редактировалось Frigate, 29.09.2010 в 19:55. |
|||
|
||||
Thượng Tá Quân Đội Nhân Dân Việt Nam Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381
|
Цитата:
Цитата:
Цитата:
Но "если очень хочется, то можно" - в виде списка. В _kpblc-ent-create-lwpline это аргумент lst. Но этот аргумент слишком сложен для поседневного применения и наверняка у хитрого Алексея есть дополнительные функции-обертки поверх этой "низкоуровневой" функции. Неспроста у нее имя начинается с "_". |
|||
|
||||
КИП, АСУ ТП, слаботочка Регистрация: 02.09.2010
Москва-Тюмень
Сообщений: 422
|
ShaggyDoc
Цитата:
Про списки то я понял. Если что-то нужно будет поменять в функции - получать еще один аргумент, то можно будет изначальный входной аргумент принимать как первый элемент списка. Подскажите, пожалуйста, какое свойство все-таки лучше использовать для LWpolyline - constantWidth или lineWidth? Чем обуславливать выбор - только внешним видом при уменьшении масштаба чертежа? Кстати, как я понимаю, ConstantWidth имеет приоритет перед весом линии. Последний раз редактировалось Frigate, 30.09.2010 в 09:25. |
|||
|
||||
Thượng Tá Quân Đội Nhân Dân Việt Nam Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381
|
Когда-то ширина полилинии и только полилинии (Width) было единственным средством делать "жирные" (основные) линии на экране. Ширину можно менять и у каждого сегмента, достигая интересных эффектов. Физическая ширина имеет ряд преимуществ, но и недостатки есть.
Linewight - средство более гибкое. Но тоже не без недостатков. Например, плохо смотрятся на экране стыки. Главное преимущество - постоянная визуалная ширина. При любом масштабе будет заданная ширина, только надо правильно смотреть - через видовой экран. Да, для полилиний ConstantWidth имеет приоритет. Легко проверяется опытным путем. Что применять - решает каждый сам, благо выбор есть. Я лично остановился на использовании Lineweight, за исключением некоторых случаев, когда обязательно, по характеру изображения, нужна фиксированная ширина. Или когда нужна переменная ширина, да ещё неотключаемая. Например, при рисовании всяких стрелок. |
|||
|
||||
КИПиА Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
|
Frigate
Цитата:
|
|||
|
||||
Инженер СКС Регистрация: 21.08.2009
г. Домодедово МО
Сообщений: 72
|
Цитата:
Цитата:
|
|||
|
||||
Программист-энтузиаст Регистрация: 17.07.2009
Воронеж
Сообщений: 571
|
NEDIS, пример добавления расширенных данных
Код:
__________________
cadtools |
|||
|
||||
Регистрация: 25.09.2006
город Ч на Волге
Сообщений: 20
|
тоже озабочен подобной задачей. тружусь в области автоматики, вторичной коммутации.
Вот некоторые соображения. 1. Надо определиться какая информация является "первичной" (исходной), а какая "вторичной" (производной). Чем выше уровень автоматизации, тем больше информации переходит в разряд "вторичной". В моем случае "первичная" информация это: а) принципиальные схемы (само собой); б) схемы расстановки оборудования; в) планы кабельных трасс (эстакады, лотки, траншеи и т.п.). Все остальное - вторично. В идеале инженер должен разрабатывать только первичные данные. 2. "Первичная" информация (исходные данные) должна быть наглядной. Сам разработчик (не программист, а разработчик КИПиА, АСУТП, РЗА ... !!! ) или другой специалист должен иметь возможность проверять и корректировать исходные данные, пользуясь, по возможности, привычными способами - черчение в граф. редакторе, редактирование таблиц и т.п. 3. Крайне нежелательно дублирование "первичной" информации - это потенциальный источник ошибок. 4. Получение выходной документации выполняется несколькими этапами. Надо дать пользователю возможность видеть промежуточный результат каждого этапа и, если требуется, вносить коррективы. Пример: инженер разработал принципиальные схемы (ПС), на основе ПС автоматически создается таблица соединений (ТС), на основе ТС создается кабельный журнал (КЖ) (пока без длин - для расчета длин требуется предоставить и обработать другую исходную информацию - расстановку оборудования и план кабельных трасс). вот как-то так. Может немножко сумбурно, но, надеюсь, мысль понятна. В последние месяцы совершенно нет времени продолжать разработку такой само-сапр , но я не оставляю эту идею. |
|||
|
||||
КИПиА Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
|
Lesha
>>а) принципиальные схемы (само собой); В чем вы делаете принципиальные схемы? >>В последние месяцы совершенно нет времени продолжать разработку такой само-сапр , но я не оставляю эту идею. Хоть чтото из перечисленных пунктов реализовано? |
|||
|
||||
Регистрация: 25.09.2006
город Ч на Волге
Сообщений: 20
|
Принципиальные схемы делаю а autocad. Наработал необходимые блоки для элементов схем, использую отдельные слои для линий связи, устройств и элементов принципиальной схемы и для всего остального (вспомогательного).
Из того что есть и нет: Есть экспорт данных из принципиальной схемы в отдельный файл. Данные это содержимое слоев, содержащих линии связи и устройства. Нет (пока) первичной обработки данных принципиальной(-ых) схемы. Обработка должна будет заключаться в преобразовании экспортированных данных (координаты вершин линий, точек соединения, зажимов блоков и их обозначений в таблицу соединений). Так что от экспорта пока толку нет . Таблицу соединений пока приходится заполнять вручную. Есть автоматическое разбиение эл. цепей на кабели на основе таблицы соединений и типов цепей. Есть авт. подбор типа кабеля по типу эл. цепи (количества и сечения жил), но только для контрольных кабелей. Вручную можно указать любой тип кабеля. Нет (пока) авт. расчета длин кабелей. Длины задаются вручную. Есть авт. создание кабельного журнала и подсчет суммарной потребности кабелей. Есть контроль правильности исходных и промежуточных данных (например, подключение к одной точке цепей с разным обозначением или подключение к одной клемме более 2х проводов вызовут предупреждающее сообщение). Ну есть еще кое-какие удобности и улучшайзеры. Нет (пока) еще очень многого... Начиная с таблицы соединений все делается в excel. |
|||
|
||||
КИПиА Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
|
>>Есть экспорт данных из принципиальной схемы в отдельный файл.
>>Данные это содержимое слоев, содержащих линии связи и устройства. на стороне обрабатывать данные, выдергивая связи - ИМХО самый неудобный вариант... при нахождении ошибок лезть в чертеж по координатам ошибки? почему не Electrical? |
|||
|
||||
Регистрация: 25.09.2006
город Ч на Волге
Сообщений: 20
|
Цитата:
Как быть иначе, если схем несколько десятков? В каждую открытую принципиалку подгружать данные из других схем и потом эти данные разбирать? Как говорится - те же яйца... Во-вторых внешняя обработка меньше завязывает на конкретный граф. редактор. Разонравится вот мне завтра акад, перейду на визио. Перепишу функцию экпорта данных и продолжу работать в привычной среде. В третьих, разделение труда. Я разрабатываю принципиалки, а какой-нибудь студент на основе моих схем все остальное. И не нужен будет ему для работы ни акад, ни визио. Electrical мне показался бедноват функционалом. Не дает он всего, что нам нужно. |
|||
|
||||
идущий по граблям Регистрация: 26.05.2005
Сообщений: 5,095
|
Дык это (наверно) самое сложное.
Цитата:
На кульмане? |
|||
|
||||
КИПиА Регистрация: 21.03.2005
Tyumen
Сообщений: 1,352
|
Цитата:
Цитата:
|
|||
|
Опции темы | Поиск в этой теме |
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Посоветуйте программу для построения профилей наружных сетей? | dextron3 | Вертикальные решения на базе AutoCAD | 18 | 11.03.2012 16:37 |
Сводный план сетей | proekt_mep | Инженерные сети | 42 | 16.06.2011 23:09 |
Ищу книгу "Проектирование кабельных сетей и проводок" под редакцией Г.Е.Храпченко 1980 | Инзиля | Поиск литературы, чертежей, моделей и прочих материалов | 8 | 03.02.2009 14:47 |