[Shoorup]

Необходимо посчитать длину кабеля.
Есть чертеж, в нем есть есть куча однострочных текстов такого формата (всегда один и тот же) 1230-3х1 (например). Т.е сначало идет длинна кабеля, а потом его жильность.
нужно сложить все кабели например 3х1, потом 4х2, потом, 7х1, 12х2 и т.д. Полученные данные свести в таблицу. Как мне кажеться это задача не очень сложная, но проблемма в том что я совсем не знаю Лиспа.
Если кто может помочь буду признателен

[Nikolay 2]

Supermax Программы есть, но все кусочками.... Написать что-то простое, типа для кабельного журнала - не проблема, но мне это не интересно....

Если можно выложи что-то для того как ты в посте #59 предлагаешь решить данную задачу. Сейчас работаю так: полилинией прокладываю трассу, в свойствах смотрю длину, вношу в таблицу (acad) каждый кабель в свою строку (вручную там же прописываю тип и жильность для каждого кабеля), затем ее экспортирую в Excel (при необходимости ввожу поправки на опуски/подъемы), обрабатываю скриптом, в итоге имею в Excel таблицу с нормальными длинами по каждому кабелю и общую длину по каждому типу кабеля. Не решена задача возврата рассчитанных значений длин к Acad на свои позиции (они вообще то и не определены в Cade, не знаю как это сделать, хотя мечта есть). Думаю ваши решения могут помочь...

Сообщение от zamtmn Nikolay 2 предлогается каждый кабель рисовать 2 раза? один для печати, другой для расчета?

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

Кулик Алексей aka kpblc В "чистом" AutoCAD'e решение такой проблемы малорентабельно. Я бы подумал об использовании либо AutoCAD MEP, либо Civil, либо Revit - в зависимости от круга задач.

Уже смотрю в сторону МЕР...., однако насколько я понял подоснова для моих нужд должна быть тоже сделана в нем?

[Supermax]

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

... вношу в таблицу (acad) каждый кабель в свою строку (вручную там же прописываю тип и жильность для каждого кабеля),...

Если программа будет заточена на промер каждого отрезка указанного типа линий, то она сама все сделает.

...при необходимости ввожу поправки на опуски/подъемы...

Тут тоже нужна программа, которая позволяет в 3D полилинии проставлять Z и добавлять вертикальные участки.

...Не решена задача возврата рассчитанных значений длин к Acad на свои позиции (они вообще то и не определены в Cade,...

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

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

[Nikolay 2]

Supermax

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

В блоках не силен, да еще и запихнуть туда нужно кабели....попробую, может что и получится...посмотреть бы как это делается...

[zamtmn]

Supermax
>>Поскольку в блоке содержется вся информация о кабеле, который
>>обозначен указанными типами линий, в слое, где лежит этот блок, то
>>сформировать и проставить обозначения в модели - пустяк.

Блоки играют роль только "удобного" инструмента ввода данных в программу?

>>Если программа будет заточена на промер каждого отрезка
>>указанного типа линий, то она сама все сделает.

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

>>Тут тоже нужна программа, которая позволяет
>>в 3D полилинии проставлять Z и добавлять вертикальные участки.

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

>>Все элементы модели имеют значение последовательности создания.

не знаю как сейчас, но раньше сохранность последовательности создания примитивов в автокаде не гарантировалась при дальнейшем редактировании чертежа

[Nikolay 2]

zamtmn

Блоки играют роль только "удобного" инструмента ввода данных в программу?

Это я понимаю

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

Да это ключевая задача

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

У нас пока в 99% случаев это 2D. Может быть это можно сделать в параметрах блока?

не знаю как сейчас, но раньше сохранность последовательности создания примитивов в автокаде не гарантировалась при дальнейшем редактировании чертежа

Тогда совсем плохо, сам знаешь, меняется все и часто...

[Supermax]

zamtmn,

Блоки играют роль только "удобного" инструмента ввода данных в программу?

Блок это не инструмент ввода данных в программу, а бирка на конкретных типах линий (цвет линий тоже иожно использовать как идентификатор кабеля). В бирке свойствами устанавливаются свойства кабеля, а атрибут "метод расчета" - проволочка, с помощью которой эта бирка вешается на кабель. В атрибутах блока есть не только "Позиция в спецификации", но и "номер по схеме". Кабель, как известно, одним концом подключается к одному прибору, а другим - к другому.
Тут, я вижу, упорно пытаются именно кабелю приписать адреса подключения, но напомню, что если кабель многожильный,то с одной строны может быть один прибор, а с другой много + еще клеммы всякие.
Вы запутаетесь в блоках. Один блок с 20-тью атрибутами, другой с 10-тью, пятый с 30-тью.
Таблицу соединений нужно составлять опросив приборы. Вот к ним и надо делать атрибуты с номерами кабеля и их жил.
Кабель - это материал. Когда его сделали на заводе, еще не знали, кто и для чего его будет использовать. А блок с данными на кабель - его свойства и не более (я так считаю).

[zamtmn]

тут произошел глюк)) удалите пжста

[Supermax]

Добавлю.
Вот у вас 150 линий связи, каждая выполнена каким-то типом кабеля. Так получилось, что все 150 кабелей одинаковой марки. Если в блок, который символизирует марку кабеля входит еще и адреса подключений, то Вам придется копировать этот блок 150 раз. и все линии должны быть разные, либо по цвету, либо по типу линий. Это не удобно. Думаю, надо сделать отдельные блоки-маркеры, с указанием адресов подключения, а привязку к линии делать с помощью атрибутов с формулами. Программно можно прочесть указатель на линию, с которой берется длинна для атрибута и посмотреть в каком слое она лежит. Найти в этом слое блок-бирку "привязанную" к этой линии и считать данные на кабель.
В блоке-бирке даже номера по схеме не должно быть.
А блок-маркер можносделать в виде разъема.

[zamtmn]

>>Блок это не инструмент ввода данных в программу, а бирка на конкретных типах линий (цвет линий тоже иожно использовать как идентификатор кабеля). В бирке свойствами устанавливаются свойства кабеля, а атрибут "метод расчета" - проволочка, с помощью которой эта бирка вешается на кабель. В атрибутах блока есть не только "Позиция в спецификации", но и "номер по схеме". Кабель, как известно, одним концом подключается к одному прибору, а другим - к другому.

А если кабелей 500? на каждый вставлять блок? и ждать когда кончится разумное количество уникальных слоев или типов линий?

>>Тут, я вижу, упорно пытаются именно кабелю приписать адреса подключения, но напомню, что если кабель многожильный,то с одной строны может быть один прибор, а с другой много + еще клеммы всякие.
Вы запутаетесь в блоках. Один блок с 20-тью атрибутами, другой с 10-тью, пятый с 30-тью.

если кабелей 2, то можно сделать всяко, если больше то дополнительные блоки-слои-типылиний причинят больше неудобств чем пользы. кстати кабель соединяет 2 прибора в общем случае. бывают шлейфовые подключения, но фактически это уже разные кабели))

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

Опрашивать можно хоть приборы хоть кабели. а лучше и то и другое. про жилы кабеля я ниче не говорю, это другой разговор. да, материал, но каждый кабель имеет свои условия прокладки, длину и т.д. это всё в проекте должно быть учтено, а не просто строка в спецификации "кввг - 5км"

>>то Вам придется копировать этот блок 150 раз
а вам придется 300 раз редактировать свойства устройств которые этот кабель соединяет.

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

[Supermax]

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

Если пишется программа для всех, а не только для себя, любимого, то надо очень тщательно все продумывать. Записывать данные в расширенные данные примитива - упремся в формат таких записей. Кончится тем, что созданную тобою модель может посчитать только созданная тобою же программа, а создать такую же модель другому человеку будет не легко. Формат данных - это самая гадкая штука, на которой погибло очень много хороших идей. Чем меньше мы используем расширенные данные, тем лучше.
Кто мешает в модели держать открытую, легко читаемую таблицу соединений? Не для выпуска листа документации, а для служебных целей. Если в такой таблице есть несколько М-текстов с полями, которые указывают на нужную линию и нужные объекты (приборы) - вот тебе и связь. Обрабатываем такую таблицу и делаем на основе данных, заключенных в ней любые документы.
В такой таблице и на блок-бирку можно М-текстом указатель вставить, чтобы проге легче было его выискивать. Тогда вообще отпадает необходимость в привязке блока-бирки к линиям по типу или цвету линий.
Читаем таблицу и в строке видим первый М-текст указывающий на нужную линию, второй - на блок-бирку, третий - на прибор №1 (контакт прибора), четвертый - на прибор №2 (или конктретный контакт) и т. д.
Все легко редактируется, копируется, читается и понятно даже полным блондинкам.
Блок-бирка - один на все кабели такого типа, просто он в таблице связан с кучей М-текстов. Чтобы посчитать общий расход кабеля достаточно его найти и обработать его "метод расчета".

Короче, я за служебную таблицу, а не за расширенные данные.

[zamtmn]

>>Если пишется программа для всех, а не только для себя, любимого, то надо очень тщательно все продумывать. Записывать данные в расширенные данные примитива - упремся в формат таких записей. Кончится тем, что созданную тобою модель может посчитать только созданная тобою же программа, а создать такую же модель другому человеку будет не легко. Формат данных - это самая гадкая штука, на которой погибло очень много хороших идей. Чем меньше мы используем расширенные данные, тем лучше.


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

Кто мешает в модели держать открытую, легко читаемую таблицу соединений? Не для выпуска листа документации, а для служебных целей. Если в такой таблице есть несколько М-текстов с полями, которые указывают на нужную линию и нужные объекты (приборы) - вот тебе и связь. Обрабатываем такую таблицу и делаем на основе данных, заключенных в ней любые документы.
В такой таблице и на блок-бирку можно М-текстом указатель вставить, чтобы проге легче было его выискивать. Тогда вообще отпадает необходимость в привязке блока-бирки к линиям по типу или цвету линий.
Читаем таблицу и в строке видим первый М-текст указывающий на нужную линию, второй - на блок-бирку, третий - на прибор №1 (контакт прибора), четвертый - на прибор №2 (или конктретный контакт) и т. д.
Все легко редактируется, копируется, читается и понятно даже полным блондинкам.
Блок-бирка - один на все кабели такого типа, просто он в таблице связан с кучей М-текстов. Чтобы посчитать общий расход кабеля достаточно его найти и обработать его "метод расчета".

Короче, я за служебную таблицу, а не за расширенные данные.

Никто не мешает. но возникают большие головняки - поддерживать эту таблицу в актуальном состоянии. У меня был такой подход, пришлось отказаться и генерировать таблицу соединений-подключений только тогда когда она нужна. на словах всё вроде просто и понятно. когда начинаешь делать - всё сложнее))

[Supermax]

Вообще-то я сторонник того, чтобы элемент нес в себе все необходимые данные, в частности "приписанные свойства" и атрибуты. Под "приписанными свойствами" я подразумеваю такие свойства, которые принадлежат не графическому примитиву, а той физической сущности, которую он изображает. Я динамические блоки взял за основу хранения данных об изделиях и материалах именно поэтому.
Расширенные данные тоже своего рода "приписанные свойства", но я их использую для хранения значений видимости по группам. У меня прога, которая формирует много вариантов видимости модели (как в динамическом блоке) и я выбирая первый, или второй, или третий и т.д. указатель в расширенных данных, устанавливаю данному элементу параметр видимости. Расширить свой формат расширенных данных для хранения "приписанных свойств" можно, но тогда каждая линия в модели превратится из примитива в сложный объект и стереть ее и прорисовать заново будет уже не просто. Хотя с таблицей тоже самое будет.

Может лучше поднапрячься и сделать распознавание места соединения начала и конца 3D полилиний с конкретными точками на приборах?
Ведь по идее, только те точки, которые имеют одинаковые координаты X, Y, Z в пространстве модели и являются местом соединения провода с проводом, провода с клеммой и т.п. Программно вполне реализуемо.

[zamtmn]

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

>>Может лучше поднапрячься и сделать распознавание места соединения начала и конца 3D полилиний с конкретными точками на приборах?
у меня это есть, информация о подключениях строится динамически при редактировании кабелей

[Nikolay 2]

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

[Supermax]

Считаю необходимым разделить задачи.
Я занимаюсь моделированием строительных процессов и для этого мне надо создавать "модель тела" и "модель действий". "Модель тела" я создаю в Автокаде и от нее мне требуется точное количество и параметры всех ее элементов. Такие данные, как, кто, с кем соединен и для чего - тут не нужны, хотя где-то это тоже должно быть.
Все мои потуги направлены на специфицирование модели в зависимости выбора условий (этап строительства, участок строительства, вид работ по разделам проекта и т.п.).
Здесь же, как я понимаю, идет базар о кабельных журналах и увязке элементов друг с другом по факту их совместной деятельности. Единственное что объединяет эти две задачи, это то, что и там, и там все делается на основе модели объекта, выполненной в масштабе 1:1.
Правда тут и про геоподоснову тоже пару слов есть, но поскольку она хоть и 2D, но 1:1 будем считать, что она тоже модель объекта.

Хочу также заметить, что таблицы соединений и принципиальные схемы хоть и показывают кабели, но их длинна там не соответствует действительности. Но зато там есть все данные о соединениях. По принципиальным схемам никто спецификцию не составляет. Только по монтажным. В кабельный журнал безусловно надо вносить длинну кабеля, но только после того, как кабель проложен в модели.
А как он там прокладывается? - рисуем линию, определяем ее цвет, тип, слой; вешаем на нее блок-бирку; вешаем на нее блок-указатель для связи с кабельным журналом. С чем еще надо связывать? да больше не с чем. Блок-бирку видно? - видно. Блок-указатель для связи с кабельным журналом видно? - видно. Если убить линию, то блок-указатель потеряет с этим объектом связь (там полем М-текста связь установлена). Прога легко найдет такой потерянный блок-указатель. Если на линию не ссылается ни один блок-указатель, но эта линия привязана к блоку-бирке, то прога начнет ругаться и укажет вам, где вы пропустили блок-указатель.
Мне блоки-указатели в модели не нужны, поэтому я их просто выключу. А вам они надо - вы их включите.
Можно прогу написать так, что линию вы будете строить из под проги, а она автоматически будет создавать блоки-указатели и приписывать к блокам-биркам. Блоки-указатели можно в стороне группировать в кучку, чтобы модель не нагружать, и с помощью все той же проги, выделив блок-указатель, подсвечивать нужную линию в модели (и наоборот).
С расширенными данными раз плюнуть забыть их в линию вставить или отредактировать. Их ведь не видно!
По сути, поле М-текста связывает два примитива в одну группу и это по сути почти блок. В М-ткст можно вставить связь сразу на несколько линий или примитивов.

[Nikolay 2]

Supermax

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

Это уже в идеале увязка между элементами нужна, но на данном этапе я это не планирую.

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

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

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

Да это конечно так

А как он там прокладывается? - рисуем линию, определяем ее цвет, тип, слой; вешаем на нее блок-бирку; вешаем на нее блок-указатель для связи с кабельным журналом. С чем еще надо связывать? да больше не с чем.

Как сказал ранее еще надо связать с этим же номером кабеля на схеме соединений внешних проводок

Блок-бирку видно? - видно. Блок-указатель для связи с кабельным журналом видно? - видно. Если убить линию, то блок-указатель потеряет с этим объектом связь (там полем М-текста связь установлена). Прога легко найдет такой потерянный блок-указатель. Если на линию не ссылается ни один блок-указатель, но эта линия привязана к блоку-бирке, то прога начнет ругаться и укажет вам, где вы пропустили блок-указатель. Мне блоки-указатели в модели не нужны, поэтому я их просто выключу. А вам они надо - вы их включите.

Все логично

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

Вот в этом то и дело, кто бы взялся ее написать?

В М-текст можно вставить связь сразу на несколько линий или примитивов

Для моей задачи получается нужно связать два поля, это возможно?

[Supermax]

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

Для моей задачи получается нужно связать два поля, это возможно?

Что-то не догнал. Поле может показывать содержимое другого поля. В М-тексте можно вставить хоть сто полей и каждое из них будет указывать на значение свойства нужного примитива.

[zamtmn]

Поля не самое удачное решение
- много возни при копировании/вставке
- нет арифметики. те не зделать (фактическая длина +3м на подъем/опуск +0.5м на разделку кабеля) * 0.1 потомучто это фрагмент плана в такомта масштабе

[Nikolay 2]

Supermax

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

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

Что-то не догнал. Поле может показывать содержимое другого поля. В М-тексте можно вставить хоть сто полей и каждое из них будет указывать на значение свойства нужного примитива

Имею в виду, что поле значения, например, "длина кабеля КВВГ4х1" должно быть связано с кабельным журналом и схемой соединений внешних проводок
zamtmn

- много возни при копировании/вставке

Supermax написал же выше:

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

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

- нет арифметики. те не зделать (фактическая длина +3м на подъем/опуск +0.5м на разделку кабеля) * 0.1 потомучто это фрагмент плана в такомта масштабе

а что в полях разве нельзя формулу завести?

[Supermax]

- много возни при копировании/вставке

Ничего копировать и вставлять не надо. Все создается программой.

- нет арифметики. те не зделать (фактическая длина +3м на подъем/опуск +0.5м на разделку кабеля) * 0.1 потомучто это фрагмент плана в такомта масштабе

Во-первых, модель в 1:1. Во-вторых, и подъем и опуск в модели уже есть. В-третьих, все прекрасно наращивается любыми прибавками.
Если вы "рисуете", а не моделируете, то ручками и калькулятором длины вычисляйте. Я, всякие умозрительные представления о компоновке, даже мысленно делать не хочу. Только 3D модель и ее развертки в окнах Layout.