Не пересчитываются формулы в переменных

[KiDim]

А у Вас моделька случаем не из К15? Просто почти все переменные информационные, а этот баг пошел с К20.

[p3452]

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

С чем Вас и поздравляю! Надеюсь, принцип, поняли...
(сам не могу глянуть "Новую модель" т.к. она в v21)
Что касается ЭТОГО:

Ваш "стиль" работы с переменными (использование служебных переменных в выражениях) - стиль мазохистов.

Вы используете в выражениях "служебные" переменные "v51", "v49", "v323", что гарантирует трудности (-боль ==> "мазохисты") при последующей работе...
Как бы поступил я (один из возможных вариантов):
1. При простановке размера (например v51), сразу бы ввел символьное имя будущей переменной - в результате, автоматически, создалась бы переменная и ей было-бы присвоено значение равное значению "v51".
2. В выражении, для других переменных, где Вы использовали "v51", указал бы ЭТУ новую переменную...   

[Pokemon]

"Надо понимать так, что в старой модели наблюдали глюк Компаса?"

Это я ещё жду от службы тех. поддержки. Запрос создал, модель им направил.

[Pokemon]

"А у Вас моделька случаем не из К15?"
Дата создания 05.2023 - из нового шаблона, созданного уже в 21-ой версии.


"Просто почти все переменные информационные, а этот баг пошел с К20."
Переменные информационные - всё верно, ошибки нет - так они в данной сборке созданы.

[Pokemon]

"(сам не могу глянуть "Новую модель" т.к. она в v21)"

В версии 20: v20 новая модель.zip


"
Как бы поступил я (один из возможных вариантов):
1. При простановке размера (например v51), сразу бы ввел символьное имя будущей переменной - в результате, автоматически, создалась бы переменная и ей было-бы присвоено значение равное значению "v51"."

Понял вашу позицию.

Если указывать переменную при задании размера - создается новая переменная. Не всегда мне нужны новые переменные. Но в моем примере есть переменные которые были созданы похожим на ваш способ (отличие в том, что они они информационные - но они также служат для удобства использования этих размеров в модели), это:
s_fut - толщина футеровки;
s_met - толщина металла;
p - шаг между лопастями.


Эти переменные для меня было целесообразно ввести - я их и ввел.
Смысла в добавлении ещё дополнительных переменных я не видел.

"С чем Вас и поздравляю! "
Спасибо за то, что навели на проблемное место. Но эту модель ещё бы потестировать, прежде чем делать заключение.

[IgorT]

...
Спасибо за то, что навели на проблемное место...
...

А можно ещё раз для одарённых, где проблемное место в модели? Что-то туплю...

[Pokemon]

"... где проблемное место в модели? Что-то туплю..."

У меня в одном эскизе несколько размеров (под номером 1) считывались для формулы, другие размеры (под номером 2) прорабатывали графику.


Возможно, что где-то программа "запутывалась" - не знаю как корректнее выразиться. Меня на эту мысль навело сообщение от уважаемого p3452 "У Вас взаимоблокирующие размеры:"
Я попробовал разнести эти два типа размеров в разные эскизы. Теперь у меня считываются размеры для формулы по второму в модели эскизу, а графика прорабатывается по эскизу "Схема размещения отверстий".
На первый взгляд проблема ушла.

[IgorT]

Загадочно...  Очень интересно, что скажет на сиё явление Служба техподдержки.

[p3452]

del

[midreyk]

Возможно, что где-то программа "запутывалась" - не знаю как корректнее выразиться. Меня на эту мысль навело сообщение от уважаемого p3452 "У Вас взаимоблокирующие размеры:"
Я попробовал разнести эти два типа размеров в разные эскизы. Теперь у меня считываются размеры для формулы по второму в модели эскизу, а графика прорабатывается по эскизу "Схема размещения отверстий".
На первый взгляд проблема ушла.

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

[Nemyheim]

Друзья. Опишу один баг, может быть у вас проблема в этом.
В 21 компасе есть баг подтвержденный, но до сих пор не исправленный СТП.
Чтобы вызвать данный баг, нужно удалить любую деталь из сборки а потом вернуть ее через ctrl+z.
После нажатия данного сочетания клавиш все связи переменных в сборке слетают и вместо них подставляются значения. Если вовремя не заметили и сохранили сборку - пиши пропало - переназначай все буквы в эскизах и вставленных деталях.
Владельцы 21 компаса можете смоделировать ситуацию. Неприятно удивитесь. Влетал несколько раз, пока не вычислил закономерность.

[Pokemon]

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

Сталкивался с этим, но не понимал точной последовательности действий, которые приводят к исчезновению зависимостей. Просто видел, что слетали одна-две-несколько переменных. Удивлялся и прописывал их заново. Понимал, что где-то есть косяк, но не понимал где именно. Так вот где собака зарыта! Спасибо за уточнение.

[СВ]

Чтобы вызвать данный баг, нужно удалить любую деталь из сборки а потом вернуть ее через ctrl+z.

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

[Петрович-47]

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

Интересный метод... надо попробовать