Не открывается файл

[IgP 122]

Пользователи создали файл .....

При попытке его открыть:

1. Выводится Инфо-окно с "The following circular update was detected:"

2. Сообщение:

"Could not open <file_name>.

The following files could not be loaded

Causing this open to fail:

<file_name> - There is an object depends on itself"

файл не открывается ...

NX7.5.5.4 MP08, а файл создан в NX7.5.5.4.MP02(но может и MP06)

Помогите решить проблему ...

установил UGII_DISPLAY_DEBUG=1, вижу тоолбар "Debug",

но как с ним решать данную задачку ............ ? (мои попытки ни к чему не привели)

вот ещё из log:

Entity <Extracted Body(1)> &000007FFFA5842B8 [35076] added as dependent of its child <file_name.prt C>: <UGS::BREF> &000007FFFA5A4CA8 [35078]

понятно, что проблема с <Extracted Body(1)>

(может сделать его UNPARAMETRIZED ?, но как ?)

[niki 0]

Этот файл содержит сборочные компоненты ?

Regardzzz...

[IgP 122]

Этот файл содержит сборочные компоненты ?

Файл, расположен в объекте ТС.

у объекта структуры ТС нет.

Файл детали.

есть ли там компоненты - не знаю, но знаю точно что проблемы не в них.

При попытке открыть файл из ТС используем "ONLY Structure".

достали файл, посредством именованных ссылок из базы ТС,

в файловую систему ОС - также не открывается, с абсолютно идентичными сообщениями.

[niki 0]

Этот файл содержит сборочные компоненты ?

Объясню, почему я спросил про компоненты (хотя к вашей ошибке скорее всего это не имеет отношение).

Иногда ошибки типа "The following circular update was detected:" возникают примерно по такой схеме:

1. Есть сборка a.prt , в которую входят компоненты b.prt, c.prt, d.prt, e.prt и т.д.

2. компонент b.prt пока что вставлен в a.prt в абсолют (без mating conditions/assembly constraints).

3. в компоненте b.prt "нарисован" кубик.

4. в компоненте c.prt "нарисован" цилиндр.

5. из компонента b.prt делается позиционно-зависимый linked face (модуль wave) грани кубика в a.prt

6. компонент c.prt привязывается (mate conditions) к этому linked face-у (см. п.5)

7. компонент b.prt привязывается (mate conditions) к компоненту c.prt

при хитром сочетании в load options опций partial loading и load interpart data, количества загруженных компонент (а так же более длинной цепочки mate conditions для b->c->d->e-> ... ) иногда получается ситуация, когда :

положение b.prt (в сборке a.prt) зависит от позиции его linked face-a (см. п.5), положение которого зависит от положения b.prt, который зависит от позиции его linked face-a (см. п.5), положение которого зависит от положения b.prt, который ... (ну и так далее) :)

Для данного случая решение простое - грузим сборку a.prt БЕЗ компонентов, подавляем/удаляем циклические mate conditions и далее загружаем компоненты.

Regardzzz

[niki 0]

в вашем случае (Entity <Extracted Body(1)> &...[35076] added as dependent of its child <file_name.prt C>: <UGS::BREF> &...[35078] ) скорее всего получилось так, что

"обновление фичи" Extracted Body(1) (в навигаторе модели) начало зависить от её "детей" (UGS::BREF -> solid body), а должно быть наоборот :)

Идеальным решением в данном случае будет обращение в GTAC (http://support.industrysoftware.automation.siemens.com/gtac.shtml).

Ну и если вы перешлете файл на niki_niki_niki@mail.ru, то я попробую поколдовать над ним и вернуть его к жизни :)

Regardzzz ...

[Intento 357]

решение простое - грузим сборку a.prt БЕЗ компонентов

так ведь ТС и написал выше:

используем "ONLY Structure"

может сделать его UNPARAMETRIZED ?, но как ?

попробуйте конвертировать деталь в step: Программы - Siemens - Трансляторы - Step AP214

[IgP 122]

to niki "про компоненты"

про все эти фокусы я знаю не по наслышке ....

но в таком случае есть (как Вы и пишите) простое решение:

открыть файл СЕ без компонент, а дальше уже дело техники ....

(всё видно и компоненты, и дерево фичеров)

попробуйте конвертировать деталь в step

Извините, но это будет уже не лечение файла, а создание другого ...

со всеми вытекающими последствиями ...

Коллеги! Большое всем спасибо.

Давайте закроем тему, а то опять в баян превращается ...

По сути это баг в ПО - есть аналогичные запросы в GTAC.

Мы же решили этот вопрос пересоздав файл из предъидущей ревизии.

PS: единственно, что бы мне хотелось, так это услышать мнение

уважаемого мной "nut888".