Solidworks API

[TomH 0]

Хочу чтобы SW открывался с новой сборкой и уже подгруженными файлами деталей в сторонней проге, ну например в EXCEL, кто - нибудь знает параметры запуска SW? 

[streamdown 1 567]

Для ярлыка. То же самое и с Excel и с макросами.

"C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS\SLDWORKS.exe" "C:\Users\Oleg\Documents\1111111111\Суперсборка1.SLDASM"

[TomH 0]

Нуу, тогда откроется пустая Суперсборка1.SLDASM , а как так, чтобы открылся с уже подгруженными деталями, например, предварительно выделенными в ексель, и доступные к сопряганию?

Изменено 6 октября 2015 пользователем TomH

[streamdown 1 567]

открылся с уже подгруженными деталями

 для этого надо эту сборку создать и вставить туда эти компоненты. Это уже не параметры запуска, это API

[TomH 0]

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

 

Dim swApp As Object

 

Dim Part As Object

Dim boolstatus As Boolean

Dim longstatus As Long, longwarnings As Long

 

Sub main()

 

Set swApp = _

Application.SldWorks

 

Set Part = swApp.ActiveDoc

boolstatus = Part.AddComponent("G:\sk\2202.SLDPRT", -1.05133312956696E-04, 1.14230163831053E-04, -9.07828706431246E-06)

 

End Sub

[streamdown 1 567]

папробую обьеснит.
Вот так работаит
 

Dim swApp As Object
Dim swModel As SldWorks.ModelDoc
Dim Part As Object
Dim boolstatus As Boolean
Dim longstatus As Long, longwarnings As Long
Dim nErrors As Long
Dim AssemblyTitle As String
Dim errors As Long
Dim nWarnings As Long
 
 
Sub main()
 
Set swApp = _
Application.SldWorks
 
Set Part = swApp.ActiveDoc
AssemblyTitle = Part.GetTitle
Set swModel = swApp.OpenDoc6("G:\sk\2202.SLDPRT", 1, swOpenDocOptions_Silent, "", nErrors, nWarnings)
Set Part = swApp.ActivateDoc3(AssemblyTitle, True, swUserDecision, errors)
 
boolstatus = Part.AddComponent("G:\sk\2202.SLDPRT", -1.05133312956696E-04, 1.14230163831053E-04, -9.07828706431246E-06)
 
End Sub

Деталь сначало нужно открыть, а патом вставлять.

[TomH 0]

Спасибо уважаемый, все получилось. Вот еще тогда спрошу)

Как можно изменить порядок деталей в штатном спецификаторе с помощью API, рекордер опять ничего не записывает, хотелось чтобы номера были такиеже как в екселе?

[maxfox 3]

Доброго времени суток, товарищи!

Прошу подсказать, направить в обучении.

Сейчас пытаюсь написать последовательность действий:

- пользователь выделяет грань в модели SW

- пользоватеь нажимает кнопку "запомнить" в моем ехе=app.

- - пользователь выделяет другую грань в модели SW

- пользоватеь нажимает вторую кнопку "запомнить" в моем ехе=app.

- пользоватеь нажимает кнопку "применить" в моем ехе=app.

-после чего приложение рисует некую геометрию в SW..

 

вопрос в том, как сохранить выделенные грани , тобы потом на первой орисовать эскиз? Саму ссылку на грань мне удалось получить методом GetSelectedObject6(). Однако поучить какой то идентификатор грани, при помощи которого её можно потом выделить, мне не удалось найти. И каким методом организовать выделение нужного компонента? Метод SelectByID2 заставляет явно указать имя. Или нужно вычислять центр масс полигона и за счёт этого выделять грань?

[streamdown 1 567]

GetPersistReference3

Или по имени GetEntityName

[maxfox 3]

большое спасибо, добрый человек! метод GetEntityName навёл меня на верный путь!

правда для этого пришлось писать несколько строк, а сам метод не понадобился:

//сохраняем
fEntity = (Entity^ )cFace;
selData = detal->ISelectionManager->CreateSelectData();

//выделяем
fEntity->Select4(false, selData);

[maxfox 3]

п.с., Оказалось что метод выделения работает в 1 строку: 

fEntity->Select4(false, nullptr);

Но вот мой кричащий вопрос!:

Слушайте, создав небольшой код я был неприятно удивлён его быстродействием.

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

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

Я сразу заметил что алгоритм работает мега-медленно для такого простого алгоритма. Расставив временные метки по ходу выполнения кода я получил:

-что общее время выполнения задачи составляет: 4,5 СЕК.

-из них, создание эскиза с привязками, составляет: 0.78 СЕК.

Всё остальное время  - это расчёты. Я ожидал совсем наоборот - что прорисовка займет значительное время, а вот расчёты будут иметь минимальные временные затраты.

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

Вот, к примеру, этот код занимает 62 МСЕК:

IPartDoc^ part =(PartDoc^ ) detal;
array<Object^>^  aBodies =safe_cast<array<Object^>^>( part->GetBodies2(0,true) );

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

 

Я пишу код на С++/cli.

Кто пишет на других языках/скриптах, расскажите как у вас дела со скоростью выполнения.

[streamdown 1 567]

Рассказываю, самая большая беда в быстродействии SW API это, как ни странно, графика ))) а именно, если происходят хоть какие то выделения (не путать с человеческими  ), получение свойств граф. объектов. Те же пробежки (Traverse). И про кастование, а вы уверены, что именно получение тел а не это кастование занимает время?

Так же, переключение конфиг в любом случае. Хоть чертёж, хоть модель, хоть сборка.

Есть ещё более жуткое    Может связано с .NET Если деталь имеет, к примеру, 100 конфигураций, то программное переключение где-то на 50-ой ооочень сильно вешает программу. Или даже не программу, а солид. Даже если применить все фишки ускорения.

[fox1001 789]

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

[maxfox 3]

 самая большая беда в быстродействии SW API это, как ни странно, графика )))

Блин, я то как раз и читаю, что это и должна быть должна быть самая медленная часть взаимодействия. Но в моём же случае всё совершенно наоборот.

Очередной мой опыт показал, что чем больше "Get", тем хуже.

вот вариант определения длины ребра полностью через SW API:

IEdge^ cEdge = (IEdge^)arEdges[e];
ICurve^crv = (ICurve^) cEdge->GetCurve();
CurveParamData^ cParam =  cEdge->GetCurveParams3();//рашсширенные переметры ребра

float cLen = (float)crv->GetLength3(cParam->UMinValue, cParam->UMaxValue);

а во втором варианте я решил обойти объект кривой (ICurve), решив что он тормозить может:

IEdge^ cEdge = (IEdge^)arEdges[e];
IMathVector^ pnt1;
IMathVector^ pnt2;
pnt1 =(IMathVector^) cMath->CreateVector( (array<double >^)edg->IGetStartVertex()->GetPoint() );
pnt2 =(IMathVector^) cMath->CreateVector( (array<double >^)edg->IGetEndVertex()->GetPoint() );
IMathVector^ vect = pnt1->ISubtract( (MathVector^)pnt2 );


result = (float)Math::Abs( vect->GetLength() );

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

 

 

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

А вот этим вы меня совершенно расстроили..((( придется VBA учить..

 

п.с. а можно ли как то запускать VBA макросы по нажатию кнопки на моём ехе-приложении?

[fox1001 789]

а можно ли как то запускать VBA макросы по нажатию кнопки на моём ехе-приложении?

да легко. RunMacro2

Изменено 18 октября 2015 пользователем fox1001

[Shvg 68]

А вот этим вы меня совершенно расстроили..((( придется VBA учить..

 

п.с. а можно ли как то запускать VBA макросы по нажатию кнопки на моём ехе-приложении?

Не надо учить VBA. Если пишете exe-приложения, не забывайте использовать свойство SldWorks.CommandInProgress. несколько ускоряет работу приложения. А так, наибольшую производительность дают addins-ы

[streamdown 1 567]

написанного на Net с макросом, написанным на VBA

 

Да, это так. Ибо в одном адресном пространстве. Но вот что странно, аддон DLL написанный на C# тоже в одном пространстве, но бывает тормозит на некоторых операциях жутко. Скорее всего из-за COM обращений. Но ведь VBA тоже не напрямую взаимодействует, а через API. Может быть скорость железа влияет?

@@maxfox, вы там не на ноутбуке программируете?

Может попробуем совместными усилиями найти причину и обход зависаний? Что скажете @@maxfox, как владеющий "сями"?

[maxfox 3]

Ура! Спасибо Shvg. CommandInProgress - это божественно!

Теперь мой код отрабатывает за 1.2. сек, и при этом 0.82 из них - это собственно прорисовка эскиза. Теперь нет ощущения зависания, и это здорово.

 

п.с. я не на ноуте, но комп хоть и старенький, но всё же не на столько, чтобы те тормоза на него списывать. А по поводу "СОМ" ничего не могу сказать, по скольку я пишу же на манаджед Си, и ком-обёртками не пользуюсь. В зависимость от железа не верю. Просто по той причине, что у меня такой простой код, что любой комп 5-ти летней давности должен проглатывать его на лету. Тут в общем, и пол-секунды это много, но подозреваю, что когда я запрашиваю у солида, допустим, массив ребер для данного тела, то он на лету генерит новый массив и передает его мне в виде ссылки. т.е. у него по умолчанию нет такого массива. И так с любыми данными. Ну и да - в этом случае, конечно, чем шустрее память и проц - тем быстрее отработает код.

[streamdown 1 567]

на манаджед Си, и ком-обёртками не пользуюсь

   уфф. Ясно. Понятно.

[maxfox 3]

Подскажите пожалуйста, как добраться од этих свойств документа?:

до свойств в конфигурации я добрался, а как быть с этими?