UG-приложение: ЕСКД

[Igor_14 0]

ПРИЛОЖЕНИЕ 3: Программа помогает оформить конструкторскую документацию

в соответствии с требованиями ЕСКД.

Содержание прикрепленных файлов:

1) Fast_ESKD_EMAIL.zip - программа и инструкции.

2) _UG_GRIP_uc1613_s10.zip - необязательный файл с исходным текстом вспомогательного DLL (обмен данными между GRIP и C).

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

Fast_ESKD_EMAIL.zip

_UG_GRIP_uc1613_s10.zip

[Ug_user 638]

Вот они - НОВОГОДНИЕ ПОДАРКИ!!

[ART 511]

Igor_14

Спасибо за подарки...

[SHARit 2 810]

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

[master712 6]

ПРИЛОЖЕНИЕ 3: Программа помогает оформить конструкторскую документацию

в соответствии с требованиями ЕСКД.

Содержание прикрепленных файлов:

1) Fast_ESKD_EMAIL.zip - программа и инструкции.

2) _UG_GRIP_uc1613_s10.zip - необязательный файл с исходным текстом вспомогательного DLL (обмен данными между GRIP и C).

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

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

Так же было-бы неплохо если бы кто сделал прогу по формированию формата чертежа с заполнением штампа.

[valeo-ua 95]

было-бы не плохо если-бы сама симменс (ну нынешняя хозяйка ЮГ) сделала стандартные объекты и стандартные форматки под ГОСТ ну или на худой случай (вернее для всех ЕСКД - рисующих - лучший) - пусть купят "Компас" и перевяжут его как солид-эдж напрямую к ЮГ (тем более что судя по всему в Компасе таки ядро парасолид используют - ну оччень оперативно "кушаются" файлы-парасолиды даже от NX7.5) и тем самым закроют по СНГ рынок на 100% и по вертикали и по горизонтали :)))

но это так - топикстартеру - спасиб! будем пробовать.

[Igor_14 0]

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

Привязки в чертеже, как было сразу заявлено, пока только по позиции курсора (в моделировании - больше). Программа сделана без заглушек - т.е. каждый пункт меню вызывает то или иное действие (или сообщение, почему действие невозможно). Скажите конкретно, что у вас не работает. Заодно сообщите версию/разрядность вашего UG и Windows.

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

было-бы не плохо если-бы сама симменс (ну нынешняя хозяйка ЮГ) сделала стандартные объекты и стандартные форматки под ГОСТ ну или на худой случай (вернее для всех ЕСКД - рисующих - лучший) - пусть купят "Компас" и перевяжут его как солид-эдж напрямую к ЮГ (тем более что судя по всему в Компасе таки ядро парасолид используют - ну оччень оперативно "кушаются" файлы-парасолиды даже от NX7.5) и тем самым закроют по СНГ рынок на 100% и по вертикали и по горизонтали :)))

но это так - топикстартеру - спасиб! будем пробовать.

С этим у меня связана некоторая история. В прошлом веке доводилось общаться с представителями разных CAD-фирм и по поводу ЕСКД тоже. Их общее мнение было примерно таким:

1) В следующей версии их продукта все будет.

2) (Неофициально) - ЕСКД это некий местный колорит, в чем-то похожий на ISO. Поскольку страна успешно избавляется от своих народных причуд, то скоро она перейдет на этот самый ISO или какой-нибудь ASME, а мы в этом ей поможем.

Потом я несколько лет где-то ходил, потом возвращался. И увидел, что ЕСКД не умерло, а поддерживается уже не сверху (как раньше), а снизу. Потому-что это язык общения тех, кто еще что-то здесь пытается делать. Есть реализации ЕСКД, но они, либо защищены своими от своих, и/или неустойчивы в работе (тут спасибо политике Microsoft и нашим программерам, которые массово подсели на ее иглу).

Короче - считаю, что ЕСКД, как и полагается любому языку общения, должна быть в свободном доступе (например на этом сайте) и максимально тривиальна в обращении и установке (на уровне простого копирования файлов). Хорошо, если будут разные реализации разных авторов для свободного выбора конечными пользователями. Исходные коды могут быть открыты (пусть каждый сам решает).

Сделать ЕСКД, тем более в неполной комплектации - дело вполне подьемное. Любому человеку (мне сейчас во всяком случае) нужны деньги, чтобы на что-то жить, пока все это делаешь. Сел и написал прикидочную версию ЕСКД, поместил ее на этом форуме для обратной связи с теми, кто (как и я) работает с "сохой" и попутно разослал в несколько фирм, которые продают UG с предложением найти посильное вспомоществование для съемки последней серии "Ну, погоди", где Волк, наконец, ловит и съедает своего неуловимого Зайца. В ответ - тишина, или что-то типа: "Мы фирма серъезная, хотим стать еще серъезнее, нам не до программок. А еще скоро выйдет новая версия, где все-все есть...".

Видимо, если это не сделаем мы, за нас это не сделает никто. И не только для UG, но и для других CAD-систем (перегнать готовую математику под новую крышу дело хоть и трудоемкое, но нехитрое).

[pegasus 1]

Хочу спросить- а можно ли изначально писать программу как обычную прогу под винду, а затем при надобности встроить её в UG. Дело в том что я начинающий программист и сложновато сразу и в MSDN рыться и в доке по UG (слишком много инфы для одного мозга), поэтому пока пробую писать как отдельное приложение windows

[harbel 17]

В принципе можно. Но, смотря на чём. Под NET, например, вообще легко переносить. Что exe, что dll.

Даж точку входа менять не надо. Кстати, можно из Win-приложения вызывать функции UG (не требующие диалога с пользователем).

Изменено 28 декабря 2010 пользователем harbel

[nut888 3]

Хочу спросить- а можно ли изначально писать программу как обычную прогу под винду, а затем при надобности встроить её в UG. Дело в том что я начинающий программист и сложновато сразу и в MSDN рыться и в доке по UG (слишком много инфы для одного мозга), поэтому пока пробую писать как отдельное приложение windows

Нет

Этого сделать нельзя

Все библиотеки разные

Знание MSDN при программировании в UG не нужно - нигде не используется

в UG свои библиотеки

[Ug_user 638]

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

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

Ясное дело, если твое приложение использует окна Windows, диалоги Windows и пр. - импоссибал, Рррайка...

[nut888 3]

ПРИЛОЖЕНИЕ 3: Программа помогает оформить конструкторскую документацию

в соответствии с требованиями ЕСКД.

Содержание прикрепленных файлов:

1) Fast_ESKD_EMAIL.zip - программа и инструкции.

2) _UG_GRIP_uc1613_s10.zip - необязательный файл с исходным текстом вспомогательного DLL (обмен данными между GRIP и C).

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

Основная GRIP-программа "Fast_ESKD.grx" использует вспомогательный файл "_UG_GRIP_uc1613_s10.DLL" для улучшения интерфейса (ввод в некоторых случаях сразу нескольких строк текста). Основная программа может работать и без него.

Почему я использую связку языков GRIP и C, а не пишу все на C? Ответ - надежность GRIP. Под Linux, наверно, писал бы на C, а под Windows мы имеем "заботливую" (о самой себе) поддержку Microsoft, которая постоянно что-то меняет, лицензирует и т.п. и работавшие ранее программы перестают работать.

В итоге сейчас мы имеем:

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

- При использовании всех языков MS Visual Studio надо постоянно иметь под рукой исходные тексты программ, чтобы в "случае чего" заново все собрать. И, как я понимаю, интерес Microsoft в том, чтобы этих случаев было больше.

Короче - файл "_UG_GRIP_uc1613_s10.ZIP" содержит исходный текст "_UG_GRIP_uc1613_s10.DLL".

Да проблема с перекомпиляцией на C есть и никуда от нее не уйти

Может помочь разве что C++/CLI - компиляция под виртуальную машину микроcофт (net)

Но Grip уже кончился - устаревшая технология не имеющая перспектив

Если Вам не нравится Microsoft может есть смысл подумать о java - под нее возможно писать под UG

Так как программа выполняется также под виртуальной машиной то проблем с переносимостью быть не должно

С выполнением программ в 32/64 на виртуальных машинах также проблем нет

[harbel 17]

...Ясное дело, если твое приложение использует окна Windows, диалоги Windows и пр. - импоссибал, Рррайка...

Не всё так плохо с этим, я ж говорю, смотря на чем писать. Здесь на форуме были уже примеры на С++ и MFC.

А на CBuilder'е еще проще- фактически только меняешь имя main на ufusr + UF_initialize/terminate .

Сам сейчас пишу под NET на С# - WinForms используется без ограничений.

Окна и диалоги какие хочешь. На java тоже самое. Примеры, кстати, идут с UG в каталоге UGOpen.

И с х64 тож совместимо (в отличии от того же CBuilder'а, который всем хорош, да нету под него 64-битного компилятора).

[pegasus 1]

Не всё так плохо с этим, я ж говорю, смотря на чем писать. Здесь на форуме были уже примеры на С++ и MFC.

А на CBuilder'е еще проще- фактически только меняешь имя main на ufusr + UF_initialize/terminate .

Сам сейчас пишу под NET на С# - WinForms используется без ограничений.

Окна и диалоги какие хочешь. На java тоже самое. Примеры, кстати, идут с UG в каталоге UGOpen.

И с х64 тож совместимо (в отличии от того же CBuilder'а, который всем хорош, да нету под него 64-битного компилятора).

Вот, я тоже пишу на C# и использую Windows Form. Читал документацию по UG там каким-то образом нужно "подцепить" библиотеки UG в Visual Studio!??

[harbel 17]

Да всё просто:

- открываешь проект и смотришь панель Solution Explorer

- в дереве проекта есть папка References

- встаешь на нее и по правой кнопке мышки - Add References - > Browse

добавляешь библиотеки из \UGII\managed\

А чтоб сам проект сразу под UG создать, надо скопировать папки из

NX\UGOPEN\vs_files\VC#\ в соответ-щие папки:

"C:\Program Files\Microsoft Visual Studio 8\VC#\VC#Wizards"

"C:\Program Files\Microsoft Visual Studio 8\VC#\CSharpProjects"

и в студии появится мастер создания проектов для UG .

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

Изменено 29 декабря 2010 пользователем harbel

[Igor_14 0]

Тема ушла в программистский туман, ну пусть так и будет.

Да проблема с перекомпиляцией на C есть и никуда от нее не уйти

Может помочь разве что C++/CLI - компиляция под виртуальную машину микроcофт (net)

Но Grip уже кончился - устаревшая технология не имеющая перспектив

nut888, Вы, конечно, правы, если более перспектиным считать то, что приносит больше денег. Но я перспективным считаю то, что более надежно. В этом плане архаичный и простой GRIP перспективен. Думаю, он будет жить столько, сколько живет UG, оставаясь в тени (масса написанных ранее программ используется и будет использоваться дальше, т.к. они просто делают свое дело и не требуют практически никакой поддержки). Постепенно в тень уходит и язык C, на котором создаются все новые языки.

Поясню на примере возобладавший сейчас подход к перспективности:

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

Вывод: чтобы с его помощью извлекать больше денег, надо понизить его надежность и увеличить количество войн. Это происходит.

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

3) Microsoft (как наверное многие убедились) - те-же "Жигули".

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

Понятно, что на самом деле все они вызвывают из недр UG одну-и ту-же древнюю и надежную как лом функцию, написанную, возможно, даже не на C, а на FORTRAN-IV. Это ядро UG, которое вдобавок и очень быстрое, т.к. не тратит ресурсов на обслуживание модных объектно-ориентированных связей, создали люди, которые прежде всего думали о надежности системы. Оно имеет трудоемкость, измеряемую сотнями человеко-лет, теперешние хозяева UG в него, без крайней нужды, наверняка не лезут и вокруг него пляшут все разработчики приложений.

Вернемся к нашим программам построения точки. В чем их различие, если точка в UG одна и та-же? В стоимости жизненного цикла. Microsoft не даст вам забыть о себе. И чем больше будет приложений из под его крыши, тем более зависимы от него, те кто их создает. Язык C создавался инженерами как переносимый для удобства работы, сейчас по требованию манагеров для удобства извлечения денег на нем создаются "непереносимые" языки. UG все более зависит от монополии Microsoft, но еще поддерживает Linux-версию. Остальные CAD и СУБД монстры тоже сохраняют многоплатформенность. С монополиями иногда что-то происходит.

[nut888 3]

Тема ушла в программистский туман, ну пусть так и будет.

nut888, Вы, конечно, правы, если более перспектиным считать то, что приносит больше денег. Но я перспективным считаю то, что более надежно. В этом плане архаичный и простой GRIP перспективен. Думаю, он будет жить столько, сколько живет UG, оставаясь в тени (масса написанных ранее программ используется и будет использоваться дальше, т.к. они просто делают свое дело и не требуют практически никакой поддержки). Постепенно в тень уходит и язык C, на котором создаются все новые языки.

Поясню на примере возобладавший сейчас подход к перспективности:

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

Вывод: чтобы с его помощью извлекать больше денег, надо понизить его надежность и увеличить количество войн. Это происходит.

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

3) Microsoft (как наверное многие убедились) - те-же "Жигули".

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

Понятно, что на самом деле все они вызвывают из недр UG одну-и ту-же древнюю и надежную как лом функцию, написанную, возможно, даже не на C, а на FORTRAN-IV. Это ядро UG, которое вдобавок и очень быстрое, т.к. не тратит ресурсов на обслуживание модных объектно-ориентированных связей, создали люди, которые прежде всего думали о надежности системы. Оно имеет трудоемкость, измеряемую сотнями человеко-лет, теперешние хозяева UG в него, без крайней нужды, наверняка не лезут и вокруг него пляшут все разработчики приложений.

Вернемся к нашим программам построения точки. В чем их различие, если точка в UG одна и та-же? В стоимости жизненного цикла. Microsoft не даст вам забыть о себе. И чем больше будет приложений из под его крыши, тем более зависимы от него, те кто их создает. Язык C создавался инженерами как переносимый для удобства работы, сейчас по требованию манагеров для удобства извлечения денег на нем создаются "непереносимые" языки. UG все более зависит от монополии Microsoft, но еще поддерживает Linux-версию. Остальные CAD и СУБД монстры тоже сохраняют многоплатформенность. С монополиями иногда что-то происходит.

Многих вещей на grip скорей всего не написать

Например - резиновая нить, ассоциативная привязка и обновление, сложные менюшки ...

А с помощью древних сишных библиотек UgOpen все это реализуется

То что касается привязки к компилятору Microsoft на Windows

причина только одна в том что Ug собран на этом компиляторе и запускаемая dll должна быть собрана на той же версии компилятора во избежание проблем

[Vovaldo 0]

То что касается привязки к компилятору Microsoft на Windows

причина только одна в том что Ug собран на этом компиляторе и запускаемая dll должна быть собрана на той же версии компилятора во избежание проблем

Если писать на .net языках, то внешний компилятор может вообще не понадобиться. ;-)

[pegasus 1]

А чтоб сам проект сразу под UG создать, надо скопировать папки из

NX\UGOPEN\vs_files\VC#\ в соответ-щие папки:

"C:\Program Files\Microsoft Visual Studio 8\VC#\VC#Wizards"

"C:\Program Files\Microsoft Visual Studio 8\VC#\CSharpProjects"

и в студии появится мастер создания проектов для UG .

Я так и сделал только у меня студия 2010 и проект для 7 версии UG- создаёт, а вот для 5 версии нет. Как быть, ведь надо для 5 версии в первую очередь.