ZCAD - как платформа для САПР-АСУ

[gtfox]

Имеется такой, важный для меня, вопрос: что мы в итоге хотим построить?

1. Мы делаем мощную и универсальную среду, сособную угодить всем, на подобие Eplan
2. Мы делаем то, что нужно в первую очередь нам

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

По второму варианту я, можно сказать, прошел этот путь...
Есть ощущение, что оно никому не надо, кроме меня :) Но заявленные фукции оно выполняет, а кому нужно другое - могут взять и дописать...

Итак, есть желание реализовать функционал САПР-АСУ на базе Zcad.

Собственно главный вопрос: можно ли это сделать? Когда я делал САПР-АСУ на базе visio я был сам себе хозяин, делал что хотел. Тут возникают вопросы совместного использования ресурсов программы: интерфейса программы, структуры данных, программых модулей...

[zamtmn]

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

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

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

Интерфейса программы как такового нет, он минимален и делается по остаточному принципу. добавляй\убавляй окна, меню, тулбары - но руководствуясь предыдущим абзацем))

[veb86]

Я так же юзаю ZCAD в работе. Поэтому в целом он отработал во много раз уже отработал вложенное в него время.
1,2 - как я это вижу. Тут нужен баланс. Конечно в первую очередь нужно угодить себе. Затем остальным. Но надеяться на остальных сильно не надо, народ как правило статичен и предпочитает гигантов (AutoCAD EPlan). Запись видео для своих разработок, я буду делать когда доведу до ума генерацию схем и кабельных журналов. В целом просто нехватает времени на создание самих расчетов и шлифовку (без нее никак)
Как подступится к решению задачи САПР-АСУ не знаю, в целом я проектировал примитивные проекты, но масштаб слишком большой. Нужно сначала тебе выработать концепцию того что ты хочешь видеть и шаги по ее достижении. Лучше конечно шаги по обсуждать. Я стараюсь с Андреем обсуждать свои шаги, многое уже готово, многое можно легко решить

[gtfox]

Из увиденного на данный момент я нашел 70% инструментов для реализации задуманного.
План можно примерно накидать:

1. Рамки чертежей с extdrIncludingVolume - как основа всего проекта
2. Координаты зон чертежа
3. Нумерация элементов схем
4. Формы и код связей (самая большая часть, судя по САПР-АСУ)
5. База компонентов/элементов схем
6. База данных прайсов/избранного

Из того, что на данный момент не хватает/не подходит:

1. VarsLink - Подходит для связи Датчик ФСА -> Датчик ПЛАН, но не подходит для катушки реле->контакт реле, т.к. катушка KL1, а контакты KL1.1-KL1.4. Чистая замена переменных не подходит, но мы что-нибудь придумаем/переделаем или попросим у Андрея :)
2. Пока что провода - это не объекты, нумерация проводов отдельными устройствами, провода - не полилинии.

[zamtmn]

По не хватающему
1 - KL1.1-KL1.4 это лишь один из вариантов "именизации", причем не самый верный имхо. я всегда контакты называю как и катушку, разница только в нумерации клемм. т.е. клеммы на катушке A,B на контактах 11,12,14; 21,22,24...
имхо не проблема, можно ввести "декоративное" имя которое будет "имя"+"некий суффикс" и получится KL1.1
VarsLink в моем понимании перекрывает все сценарии использования, но вносит путаницы когда у "делегата" присутствует часть переменных, а остальные у "централи". причем эти переменные могут пересекаться.
Ну и это по большому счету один из вариантов. я не против сделать более простые\надежные\понятные

2 - сейчас провод это некая "квази сущность"

zcad/cad_source/zcad/entities/uzcextdrschconnector.pas

Line 45 in 83574e7

TNet=class

ему не сопоставлен напрямую никакой примитив чертежа. при перерасчете чертежа всем отрезкам имеющим расширения соединения создается этот TNet, при обнаружении соединения отрезков по некоторым критериям из ихних TNet`ов выбирается один и сохраняется в них обоих. По окончании расчета чертежа все соединенные отрезки имеют ссылку на один и тотже TNet.
Из текущих недостатков эти TNet после каждого расчета генерируются заново, но это можно решить
В деле пока я это не опробовал, только тестил - импортнул из еплана схему большого шкафа, привязал отрезкам расширения - всё объеденилось и редактировалось без тормозов
Такой подход я считаю более продуктивным чем отслеживание соединения полилиний. полилиния сама по себе сложный примитив и может быть замкнутой или самопересекающейся. кроме того например расчет соединений и пересечений полилиний с тысячами сегментов будет очень ресурсоемкой задачей при реализации в лоб.
Из проблем сейчасного решения - сложность реализации перетаскивания "проводов" за элементами схемы, сложность умного редактирования "проводов" - Это в принципе решаемо, но скорее всего отдельными командами, а не штатной текущей командой инлайн редактирования чертежа. Пока я в эту сторону только фантазировал, решать не пробовал

[veb86]

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

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

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

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

VarsLink - Подходит для связи Датчик ФСА -> Датчик ПЛАН, но не подходит для катушки реле->контакт реле, т.к. катушка KL1, а контакты KL1.1-KL1.4. Чистая замена переменных не подходит, но мы что-нибудь придумаем/переделаем или попросим у Андрея :)

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

Рамки чертежей с extdrIncludingVolume - как основа всего проекта

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

[gtfox]

KL1.1-KL1.4 это лишь один из вариантов "именизации", причем не самый верный имхо.

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

VarsLink в моем понимании перекрывает все сценарии использования

Возможно, я еще его не смотрел...

но вносит путаницы когда у "делегата" присутствует часть переменных

Не, не. Путаницы не надо :)
В САПР-АСУ ооочень много всяких элементов, где "связь" - это 1-2 переменные, а остальное это свои переменные, без них никак
Идеальным вариантом было бы, чтобы переменные родителя/централи попадали в дочернего/делегата в виде переменных с префиксом NET_ и подставлялись бы в шаблон обозначения

interface
uses System;
var
  NMO_Name:String;(*'Обозначение'*)
  NMO_BaseName:String;(*'Короткое Имя'*)
  NMO_Prefix:String;(*'Префикс'*)
  NMO_Suffix:String;(*'Суффикс'*)
  NMO_Affix:String;(*'Аффикс'*)
  NMO_Template:String;(*'Шаблон Обозначения'*)

  NET_NMO_Name:String;(*'Обозначение'*)
  NET_NMO_BaseName:String;(*'Короткое Имя'*)
  NET_NMO_Prefix:String;(*'Префикс'*)
  NET_NMO_Suffix:String;(*'Суффикс'*)
  NET_NMO_Affix:String;(*'Аффикс'*)
  NET_NMO_Template:String;(*'Шаблон Обозначения'*)
implementation
begin
  NMO_Name:='KL1.1';
  NMO_BaseName:='пофиг-заменено на NET_NMO_Name';
  NMO_Prefix:='';
  NMO_Suffix:='.1';
  NMO_Affix:='';
  NMO_Template:='@@[NMO_Prefix]@@[NET_NMO_Name]@@[NMO_Suffix]@@[NMO_Affix]';
end.

И обязательной переменной должна быть ссылка на родителя, а в родителе - ссылки на всех дочерних

2 - сейчас провод это некая "квази сущность"
проводу не сопоставлен напрямую никакой примитив чертежа

Да, это хорошо. Я когда-то планировал делать также, но в визио оказалось проще сделать фигуру-провод

всем отрезкам имеющим расширения соединения создается этот TNet, при обнаружении соединения отрезков по некоторым критериям из ихних TNet`ов выбирается один и сохраняется в них обоих
Такой подход я считаю более продуктивным чем отслеживание соединения полилиний.

Меня этот вариант вполне устраивает. То что оно отрезками - будем решать потом :)

[zamtmn]

А почему это проблема. Просто сделать ...

Проблема в сложности. мне это кажется очень сложной задачей

И обязательной переменной должна быть ссылка на родителя, а в родителе - ссылки на всех дочерних

Ссылки в расширениях есть. кроме того у нас есть навигатор, переходы\выделения можно делать им

[gtfox]

Ссылки в расширениях есть. кроме того у нас есть навигатор, переходы\выделения можно делать им

Хорошо, значит мне надо лучше разобраться как что уже работает....

[veb86]

Ссылки в расширениях есть. кроме того у нас есть навигатор, переходы\выделения можно делать им

Было бы конечно здорово, если они попадали в контекстное меню, которое мы вызываем правой кнопкой мыши. При нажатии на централь или делигата

[gtfox]

Интересно как мозги перестраиваются... Получается все связи можно делать командой и тыкать по устройствам... Получается не нужна ни одна форма как в визио...
Жись-то налаживается :)

[zamtmn]

Ни кто не запрещает наделать форм. я просто не умею и не люблю))

[gtfox]

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

[zamtmn]

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

[gtfox]

Листы удобны для печати и для проектировщиков других разделов проектов. Они еще любят видовые экраны :)
Но, нам-то никто не мешает печатать программно как захотим, поэтому листы - не необходимость

[veb86]

Листы удобны для печати и для проектировщиков других разделов проектов. Они еще любят видовые экраны :) Но, нам-то никто не мешает печатать программно как захотим, поэтому листы - не необходимость

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

В наружных сетях видовые окна это хлеб, без них ни как.