Altium Designer, Unit mil или mm Опции

[Serguey_A]

Altium Designer позволяет в Document Options сделать выбор между дюймовой и метрической системой.
Очень хочется работать в метрической (привычнее).
Вопрос к знающим – если я выберу метрическую систему, какие проблемы я получу в дальнейшем?
Altium только осваиваю и совсем не хочется в середине проекта поиметь проблемы.

[LeonY]

2 Serguey_A: в Protel-е пересчеты Imperial/metric (как, впрочем, и многое другое) реализованы по-уродски. Поэтому готовьтесь к бАААльшим проблемам на платах большой плотности и при наличии помеси дюймовых и метрических корпусов. Подробней можете поискать на форуме, эта проблема уже обсуждалась. Повторюсь и приведу пример на котором я и приплыл: надо было разместить несколько BGA с шагом 0.5мм и, естественно, вытащить дорожки для fan-out наружу. Размер площадки - 0.2мм, мин. зазоры и ширина дорожки - по 0.1мм. Вроде все должно работать, но не тут-то было. Protel пересчитывал координаты пинов в дюймы и обратно с ошибками округления и после всего этого каждый пин выдавал ошибку в DRC. Как мы это побороли уже не помню, давно было, но похлебали дерьма достаточно.

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

[Yuri Potapoff]

в Protel-е пересчеты Imperial/metric (как, впрочем, и многое другое) реализованы по-уродски.

В самом протеле пересчет сделан нормально по формуле. Но через ж...

Главный косяк с пересчетом возникает при обмене данными между модулями. Заявленная точность протела 0.001 мила или миллионная доля дюйма. То есть, на плате все все будет округляться до 0.030 микрон. Это на два порядка выше, чем в пикаде, там точность 0.1 мила или 3 микрона соответственно.

Но при передаче данных в трассировщик в протеле данные округляются именно до этой точности 0.1 мила. То есть если вы зададите ширины и зазоры в круглых милах, все будет идеально. А если в круглых микронах - то по возвращению из трассировщика появятся бесконечные дроби. например ранее было 100 микрон, по возвращению 99.99, что вполне может нарушить настроенные правила и привести к ошибке DRC.

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

Но протел тут не одинок. Аппарат LaserGraver в софте имеет такой же баг при обработке метрических файлов староко пикада. При получении постскрипта метрический файл пересчитывается в дюймы, точность режется до роковой цифры 0.1 мил, растеризуется и гробит точность с заявленного 5 класса на 3-ий.


Все проблемы в неправильном подходе к обработке внутренних данных. Большинство данных придставленны в виде целых чисел, а обработка их ведется как вещественных.

В бухгалтерских программах этих проблем еще больше, особенно при расчете НДС.

[LeonY]

В бухгалтерских программах этих проблем еще больше, особенно при расчете НДС.

Ну "бухгалтерские программы" "особенно при расчете НДС" - есть проблема сами по себе, независимо от того, как они считают. Эти проблемы еще более усугубляются при расчете подоходного налога и прочих поборов